令和元年度
サイバーセキュリティ対策事業報告書

医療機器サイバーセキュリティ－ 国際協調に向けた課題 －令和２年３月国立医薬品食品衛生研究所
医療機器部 蓜島由二

目次
Ⅰはしがき .......................................................................................................................................... 1

Ⅱ

報告書.............................................................................................................................................. 3
用語・略語集 ................................................................................................................................ 5
1. はじめに ................................................................................................................................ 15
1.1 背景 ..................................................................................................................................... 15
1.2 目的 ..................................................................................................................................... 15
2. 医療機器規制の中でサイバーセキュリティを理解する上で重要な事項 ............................... 16
2.1 概要 ..................................................................................................................................... 16
2.2 製品のライフサイクル全体 ................................................................................................. 18
2.3 共同責任 .............................................................................................................................. 19
2.4 情報共有 .............................................................................................................................. 20
2.5 部品表（SBOM/CBOM） ................................................................................................... 22
2.6 製造販売業者開示書 ............................................................................................................ 23
2.7 製品セキュリティのための対応 .......................................................................................... 25
2.7.1 部品表と情報共有 ............................................................................................................. 25
2.7.2 SBOM のフォーマット ..................................................................................................... 25
2.7.3 脆弱性情報の共有 ............................................................................................................. 26
3. 各国のガイダンス .................................................................................................................. 27
3.1 近年の動向 .......................................................................................................................... 27
3.2 米国 FDA ............................................................................................................................ 27
3.2.1 市販前ガイダンス ............................................................................................................. 28
3.2.2 市販後ガイダンス ............................................................................................................. 30
3.3 豪州 TGA ............................................................................................................................ 32
3.3.1 市販前ガイダンス ............................................................................................................. 33

3.3.2 市販後ガイダンス ............................................................................................................. 34
3.4 加国 Health Canada .......................................................................................................... 35
3.5 仏国 ASNM ........................................................................................................................ 37
3.6 欧州ガイダンス ................................................................................................................... 38
4. 国際規格 ................................................................................................................................ 41
4.1 近年の動向 .......................................................................................................................... 41
4.2 ISO 14971: 2019 .................................................................................................................. 41
4.3 AAMI TIR 57: 2016 ............................................................................................................. 45
4.4 IEC/CD 80001-5-1 ............................................................................................................... 47
4.5 IEC/DTR 60601-4-5 ............................................................................................................ 47
5. 国際協調に向けた課題........................................................................................................... 48
6. まとめ .................................................................................................................................... 50
7. 参考文献 ................................................................................................................................ 51
Ⅲ

IMDRF 最終文書 ............................................................................................................................ 53

Ⅳ

医療機器のサイバーセキュリティに関する IMDRF と日本のガイダンス比較表 ...................... 106

Ⅰ はしがきはしがき近年、病院内のイントラネット環境構築が進み、医療機器のサイバーセキュリティの確保が大きな社会的課題となっている。国際医療機器規制当局フォーラム（International Medical Device
Regulators Forum：IMDRF）では、サイバーセキュリティに関するガイダンス案「医療機器サイバ
ーセキュリティの原則及び実践」が取りまとめられ、2019 年 10 月にパブリックコメントが募集された。この作成作業に並行して、各国での対応についても別途ガイダンス化が進んでいる。
米国では、早期にサイバーセキュリティへの対応が検討され、2017 年に FDA はサイバーセキ
ュリティの市販前ガイダンスを発行し、医療機器製造販売業者にサイバーセキュリティ対策を求めた。その後、カナダ、オーストラリア、フランス等からも自国の考え方に関するガイダンスが公表されている。欧州では、欧州医療機器規則（Medical Device Regulation: MDR）附属書 I の要
求事項の中で IT セキュリティの記載があり、その適合性評価のための欧州整合規格を想定した
IEC/ISO 80001-5-1 規格策定作業が進められている。当該規格では、IEC 62304 で要求されている
SOUP の管理をより効果的に行うことを目的に、ソフトウェア部品表（Software Bill of Materials:
SBOM）を利用したソフトウェア資産管理の仕組みの構築に向けた議論が進んでいる。
従来の医療機器におけるリスクマネジメントの考え方ではサイバーセキュリティへの対応が難しく、別途 AAMI TIR 57 による解釈が加えられてきたが、2019 年 12 月に ISO 14971 の第 3 版が発行され、これに伴い改訂された ISO/TR 24971 ではリスクマネジメントの視点でサイバーセキ
ュリティの考え方が提示されている。
本報告書では、IMDRF のガイダンスを理解する上で必要な基本的事項、各国のガイダンス及び国際規格の動向を調査結果としてまとめ、IMDRF のガイダンス案の邦訳版を作成し、さらに、平成 30 年 7 月 24 日付け薬生機審発 0724 第 1 号・薬生安発 0724 第 1 号厚生労働省医薬食品局医療機器審査管理課長・医薬安全対策課長連名通知別添「医療機器におけるサイバーセキュリティの確保に関するガイダンス」 との比較を表にした。今後、国内の医療機器規制においても国際整合化が図られることが予測されるため、参考とされたい。

令和２年 ３月 吉日
国立医薬品食品衛生研究所
医療機器部 蓜島由二

ー1ー

Ⅱ

報告書

用語・略語集（五十音順）
インシデント

情報管理やシステム運用に関して保安上の脅威となる事象のことを指し、セキュリティインシデントとも呼ばれる。ウイル
ス感染や不正アクセス、アカウント乗っ取り、Web サイト改竄、
情報漏洩、迷惑メール送信及びサービス拒否攻撃等が含まれる。

英国のトラスト

保健省の統制下にあった国営企業たる保健サービスを、地域ごとに独立させ、効率を上げることが目的で設立された組織。従来は、各地域に設置されていたプライマリ・ケア・トラスト（PCT）が地域保健サービスを提供していたが、2012 年 NHS
改 革 法（Health and Social Care Act 2012）により 2013 年
4 月以降は、多くの地域保健サービスの提供は地方自治体の責務とされた。

オープンソース

コンピュータプログラムであるソースコードを広く一般に公開し、誰でも自由に扱ってよいとする考え方。また、そのような考えに基づいて公開されたソフトウェアのこと。

コーディングルール

コードの書き方に関する決まりごと。プログラミング言語の文法とは異なり、様々な書き方が可能な場合にどのような書き方にするかを集団内の約束として決めたもの。変数や関数等の命名規則や、利用してはいけない機能等の禁止事項、インデント
やスペース、括弧の書き方等で構成される。

コンポーネント

IT の分野では機器やソフトウェア、システムの構成する部品や要素等のことを意味する。ソフトウェアの分野では、特定の機能を持ち単体で完結しているが、単体では使用せず（できず）、
他のプログラムから呼び出されたり連結されたりして使用されるプログラム部品のことをコンポーネントという。

ステークホルダ

組織やその活動について何らかの関わりや影響があり、利益を得たり損害を被る人や組織等のこと。

製品セキュリティポリシー

開発・製造する製品の情報セキュリティを確保するために製造販売業者が定める基本方針。

ソフトウェアライフサイク

ソフトウェアの構想・設計から開発、導入、運用、保守及び破ル

棄に到るまでの工程全体のこと。また、それらの工程について
個々の作業内容、用語の意味等を標準化した枠組み。

ブラックリスト型プロテク

対象を選別して受け入れたり拒絶したりする仕組みの一つで、

ト

拒絶する対象を列挙した目録（リスト）を作り、そこに載っていないものは受け入れる方式。又は、そのような目録のこと。

ー5ープラットフォーム

機器やソフトウェアを動作させるのに必要な、基盤となる装置、ソフトウェア及びサービス、あるいはそれらの組み合わせ（動作環境）のことをプラットフォームという。

ベストプラクティス

方法や工程、その実践例の中で、ある基準に従って最も優れていると評価されたもののこと。

ホワイトリスト型プロテク

通信・ネットワークの分野では、通信やアクセスを許可するアト

ドレス等のリストを作成し、それ以外は拒否・禁止する方式を
ホワイトリスト方式という。アクセスを許可する Web サイトの URL を列挙した URL フィルタや、受信を許可するメールア
ドレス等を列挙した迷惑メールフィルタ、通信可能な IP アド
レスやポート番号の組み合わせを列挙したファイアウォールの設定等がこれに当たる。

マルウェア

不正かつ有害な動作を行う意図で作成された悪意あるソフト
ウェア及びコードの総称であり、ウイルス、ワーム及びトロイの木馬等全てを含む。

ライブラリ

特定の機能を持ったコンピュータプログラムを他のプログラ
ムから呼び出して利用できるように部品化し、そのようなプログラム部品を複数集めて一つのファイルに収納したもの。

ランサムウェア

マルウェアの一種で、感染したコンピュータを正常に利用できない状態に置き、復元のために犯人への金品の支払いを要求する不正ソフトウェアのこと。

レガシー機器

過去に広く普及したが、すでに代替規格・製品等が存在し「時代遅れ」となった仕様や規格に基づく機器や装置のこと。

ー6ー（アルファベット順）
AAMI

米国医療機器振興協会(Association for the
Advancement of Medical
Instrumentation)
AIMD

欧州能動埋込医療機器指令（Active Implantable
Medical Devices Directive）
ANSM

仏国 医薬品・保健製品安全庁（Agence Nationale desécurité du Médicament etdes produits de santé）
ATO

ネットワークにおける運用認定。DIACAP 下で与えられるセキ(Authority to Operate)

ュリティ認定。

（Approval to Operate）
CAP

サイバーセキュリティ認証プログラム（Cybersecurity
Assurance Program）
CAPEC

セキュリティ攻撃パターンを網羅的に分類・カタログ化したも（Common Attack Patternの。

Enumeration andClassification）
CBOM

SBOM にハードウェアを含めた部品表を指す。

（Cybersecurity Bill ofMaterials）
CC

契約条項

（Contract clause）
CD

意見陳述用委員会原案（Committee draft forcomment）
CDV

投票用委員会原案（Committee draft forvote.）
CERT

米国にあるインターネットセキュリティを扱う研究・開発チー（Computer Emergency

ム。CSIRT の草分けであり、同分野で最も権威ある組織の一

Response Team）

つである。

CDRH

医療機器・放射線保健センター（Center for Devices andRadiological Health）

ー7ー

CPE

共通プラットフォーム一覧。MITRE 社が策定する情報システ（Common Platform

ムを構成するハードウェア及びソフトウェア等を識別するた

Enumeration）

めの共通の名称基準で、CPE 名（製品の種別、ベンダ名、製品名、バージョン、アップデート、エディション及び言語等）
リストを形成している。随時更新されている。

CSIRT

CSIRT（Computer Security Incident Response Team、シー（Computer Securityサート）とは、コンピュータやネットワーク（特にインターネ

Incident Response Team）

ット）上で何らかの問題（主にセキュリティ上の問題）が起きていないかどうか監視すると共に、万が一問題が発生した場合にその原因解析や影響範囲の調査を行う組織の総称。CSIRT以外に CIRT（Cyber Incident Response Team）という略称が使われることもある。

CVE

共通脆弱性情報識別子。米国の支援を受けた非営利団体の（Common Vulnerabilities

MITRE 社が 1999 年に実現したベンダ非依存の脆弱性情報辞

and Exposures）

書であり、報告された脆弱性情報を評価して CVE 番号を発番している。この CVE 情報が NVD で提供される仕組みである。
日本から脆弱性情報を登録する場合は、JPCERT を通して行うことができ、同様に CVE 番号が得られる。

CVSS

CVSS は、情報システムの脆弱性に対するオープンかつ汎用的（Common Vulnerability

な評価手法であり、ベンダに依存しない共通の評価方法を提供

Score System）

している。CVSS を用いると、脆弱性の深刻度を同一の基準の下で定量的に比較できる。また、ベンダ、セキュリティ専門家、管理者及びユーザ等の間で、脆弱性に関して共通の言葉での議論が可能となる。

CWE

共通脆弱性タイプ一覧。ソフトウェアにおけるセキュリティ上（Common Weaknessの弱点（脆弱性）の種類を識別するための共通基準の記載を目

Enumeration）

標としている。

CWSS

ソフトウェアの脆弱性を計測する共通脆弱性評価システム。

（Common Weakness

CVSS とは異なるが、競合するものではないため、併せて利用

Scoring System）

が可能である。

DDoS 攻撃マルウェア等で不正に乗っ取った複数のコンピュータから同(Distributed Denial of

時に大量のアクセスを集中させて、対象のサーバーを処理不能

Service Attack)（アクセス不能）にする悪意ある攻撃のこと。

DHS

米国国土安全保障省（United States
Department of Homeland
Security）
DoD

米国国防総省（Department of Defense）

ー8ーDIACAP

米国国防総省や米軍関連施設向けシステム入札要件（Defense Information
Assurance Certification
and Accreditation
Program）
EOL

ハードウェア及びソフトウェアのサポート期間を含めた寿命（End Of Life）を考慮したソフトウェアの使用期限を指す。

EOS

サポート終了（End of Support）
FISMA

連邦政府機関が情報セキュリティを強化するため、NIST に対（Federal Information

し、規格やガイドラインの開発を義務付けた連邦情報セキュリ

Security Management Act

ティマネジメント法。この法律の対象となるのは、連邦政府機of 2002）

関や、連邦政府機関より業務委託を受けている民間の外部委託
先である。

GDPR

欧州連合 (EU)の一般データ保護規則。欧州議会・欧州理事会（General Data Protection

及び欧州委員会が EU 内の全ての個人のためにデータ保護をRegulation）

強化し統合することを意図している規則である。EU 域外への個人情報の輸出も対象としている。

HDO

医療提供機関。医療機器の運用管理とリスクマネジメントを行（Healthcare Delivery

う病院等Organization）
Health Canada

加国 保健省

HIMSS

医療情報管理システム学会（Healthcare Informationand Management Systems
Society）
HIPAA

医療情報の相互運用性と説明責任に関する法律（Health Information
Portability andAccountability Act）
H-PoC WG

ヘルスケアの概念実証 WG（Healthcare Proof ofConcept WG）
ICS

産業用制御システム(Industrial Control
System)ー9ー

IMDRF

International Medical Device Regulators Forum、すなわち、（International Medical

国際医療機器規制当局フォーラムは、医療機器規制の国際整合Device Regulators Forum） 化について将来の方向性を議論するフォーラムとして 2011 年
2 月に立案された。IMDRF は、GHTF（Global Harmonization
Task Force）における強固な基盤作業を土台とする、世界各国の医療機器規制当局による任意の活動であり、国際的な医療機器規制の整合化と収束を促進するものである。
IoT

モノのインターネット（Internet of Things）
IPA

独立行政法人 情報処理推進機構(Information-technology
Promotion Agency)IT

IT とは、情報を取得、加工、保存及び伝送するための科学技術。

（Information

特に、電気、電子、磁気及び電磁波等の物理現象や法則を応用

Technology ）したコンピュータ等の機械や器具及びその内部で動作するコンピュータプログラム（ソフトウェア）を用いて情報を扱う技
術のこと。

ITU

国際電気通信連合。情報通信に関する国際標準の策定等を行う(International

国際機関。国際連合と協定を結ぶ専門機関の一つ。本部はスイTelecommunication Unio)

スのジュネーブ。

ISAC

脅威・脆弱性に関する情報共有組織。要インフラ事業者の業界（Information Sharing &（セクター）ごとに脅威や脆弱性に関する情報の共有・分析を

Analysis Center）

行う組織である。一般の民間部門で情報共有を広く進めるための組織が ISAO である。

ISAO

サイバーセキュリティ関連情報の収集、分析、共有及び発信の（Information Sharing

ために設置された組織である。ISAO はサイバーセキュリティ

Analysis Organization）

情報の共有と民間セクター内の協力、さらに民間セクターと国との協力の中心的役割を担うことを目的としている。製造業者
が ISAO に積極的に参加することで、患者やユーザとの連絡や調整を含むリスクコントロール手段のタイムリーな展開を通じて、サイバーセキュリティの脆弱性に積極的に取り組み、悪用を最小限に抑えることで、企業、医療機器コミュニティ、ヘルスケア・公衆衛生（HPH：Healthcare and Public Health）
分野を支援することができる。

IVDD

欧州体外診断用医療機器指令（InVitro Diagnostic
Medical Device Directive）
IVDR

欧州体外診断用医療機器規則

ー 10 ー

（In Vitro Diagnostic
Regulation）
JVN

日本で流通・利用されているソフトウェアの脆弱性に関連する（Japan Vulnerability

情報を収集しているデータベースの一つ。Web サイトの形で公Notes）

開され、誰でも閲覧・検索が可能である。JPCERT/CC と IPA（情報処理推進機構）が共同で運営している。
JPCERT/CC 等に寄せられたソフトウェア脆弱性について、概要や影響受ける製品やシステム、想定される影響や危険性、発行元の対応状況、対策方法、問題の回避方法等を掲載している。
CERT/CC 等海外の機関が公開した情報等も掲載している。

JPCERT/CC

日本を代表する CSIRT で、国内向けのセキュリティ関連情報（Japan Computerの提供や各国代表 CSIRT との連携窓口となっている機関をEmergency Response

JPCERT/CC という。正式名称は一般社団法人 JPCERT コー

Team/Coordination

ディネーションセンター。

Center）

インターネット上で発生するセキュリティ関連事象の情報を収集、分析し、詳細情報の公表や注意喚起及び国内 CSIRT のインシデント対応支援を行っている。また、ソフトウェアに発見された保安上の弱点（脆弱性）について、発見者からの報告の受付窓口となり、開発者等に情報を提供して対応を促す等の活動も行っている。

MDD

欧州医療機器指令（Medical Devices
Directives）
MDISS

医療機器の革新、安全及びセキュリティに関するコンソーシア(The Medical Device

ム。医療機器のサイバーセキュリティに着目して公的健康と患

Innovation, Safety and

者安全を確保するための米国非営利組織。

Security Consortium)
MDR

欧州医療機器規則。

（Medical Devices
Regulation）
MDS2

医療機器セキュリティに関する製造業者開示書を指す。MDS2（Manufacturer

は、医療機器のセキュリティ機能に対し、医療提供者及び製造

Disclosure Statement for

業者が検討するために必要となる情報について、該当の有無をMedical Device Security）

文書にして示すものであり、製造業者の自己宣言書である。

MOU

了解覚書、基本合意書。行政機関等の組織間合意事項を記した(Memorandum of文書であり、通常、法的拘束力を有さない

Understnading)
Nessus

セキュリティ脆弱性スキャンツールの名称で、Tenable
Network Security 社がコンピュータセキュリティに関して開発した包括的な脆弱性検知スキャナである。ATO 取得に際しー 11 ーて、DIACAP で使用することを認定しているソフトウェア。同
様なツールに Retina もあるが、現在は Nessus が指定されて
いる。
NEMA

米国電気機器製造業者協会（National Electrical
Manufacturers
Association）
NIST

NIST とは、米国の連邦政府機関の一つで、科学技術に関連す(National Institute Of

る標準の研究等を行う機関。主に度量衡や計測・計量についてStandards Andの標準を管理し、関連する科学研究や技術開発を推進していTechnology)

る。1988 年に前身の国立標準局（National Bureau ofStandards：NBS）から改組された。

NIST CSF

NIST の運用するサイバーセキュリティに関する推奨ベースラ（NIST Cyber Security

イン。部門、規模にかかわらず、どの組織でも使用できる。世

Framework）

界中で採用されている。

NITA

米国商務省電気通信情報局。

（National
Telecommunications andInformation
Administration）
NHS

英国国民保健サービス。

（National HealthService）
NVD

NIST が管理している脆弱性情報データベースである。米国が（National Vulnerability

2002 年に発表した「サイバーセキュリティ国家戦略」におい

Database）て、「国土安全保障局は一般市民に対して、脆弱性情報を通知する義務がある」という理由によって、ICAT をベースに機能強化されたものとして作成された。

OTS ソフトウェア

システムに組み込む際に検証が必要な市販ソフトウェア。基本(Off-the-shelf)

OS、TCP/IP プロトコル・スタック及び外部接続機器用ドライ
バ等を含む。

PHI

保護対象保健情報（Protected Health
Information）
PSIRT

開発・販売する製品、コンポーネント及びサービス等の、脆弱（Product Security

性リスクの特定や評価、自社製品の脆弱性への対応及び製品のIncident Response Team）

セキュリティ品質管理・向上を目的とする組織。PSIRT と組
織内 CSIRT の違いは、前者はその活動の中心が製品のセキュ
リティであるのに対し、後者は組織のインフラを構成するコン
ピュータシステムやネットワークのセキュリティに重きを置ー 12 ーいている点にある。ただし PSIRT は組織内 CSIRT と協調する事で相乗効果を発揮する。

SAM

ソフトウェア資産管理とは、組織内で利用するソフトウェア資（Software Asset

産のライフサイクル管理である。

Management）
SaMD

プログラム医療機器（Software as a Medical
Device）
SBOM

SBOM は、アプリケーションの部品表である。使用されている(Software Bill ofコンポーネントを可視化し、潜在的セキュリティリスク及びラMaterials)

イセンスの問題を特定することができる。

SCC

標準契約条項（Standard contractual
clauses）
SCT

ソフトウェアコンポーネント透明性（Software Component
Transparency）
SingHealth

現在 6 つあるシンガポールの公的地域医療グループのひとつ(Singapore Healthで、国民ヘルスケアグループ(National Healthcare Group：

Services)

NHG) と同時に 1999 年に設立された。非営利企業であり、株式は全て政府が保有している。なお、患者情報はグループ間を超えて共有されている。

SNDGG

スマート国家デジタル政府グループ（Smart Nation and
Digital Government
Group）
SOUP

オープンソフトウェアを含む、開発過程が不明なソフトウェア（Software Of Unknown

を指す。

Provenance）
SPDX

ソフトウェアパッケージに関連するコンポーネントやライセ（Software Package Data

ンス、コピーライト等の情報をやり取りするための標準的なフExchange）

ォーマットの仕様。

SSL

ネットスケープコミュニケーション社によって提案された汎（Secure Socket Layer）

用セキュアプロトコルスキーム。より上位層の HTTP や
POP, IMAP 等のアプリケーションプロトコルにセキュリテ
ィ機能を与える。SSL ハンドシェイクプロトコルと SSL レ

ー 13 ーコードプロトコルから構成される。

STIG

ソフトウェア及びハードウェアのインストール及びメンテナ（Security Technical

ンスに関して標準化されたセキュアの方法と具体的な要求事

Implementation Guide）

項の規定。DoD に指示されたセキュリティ要件へのコンプライ
アンスを確実にするために米国国防情報システム局 (Defense
Information Systems Agency：DISA) によって作成されたル
ール、チェックリストおよびその他のベスト・プラクティスの
セット。

SWID

ソフトウェアの導入状況を把握するための、ソフトウェア識別（Software Identification） タグ規格
TGA

技術情報報告書（Therapeutic Goods
Administration）TIR(Technical Information
Report)
TPLC

製品のライフサイクル全体（Total Product Life
Cycle）UDI

米国 FDA が導入したシステム規則で、UDI の表示は固定デー（Unique Device

タである機器識別子(Device Identifier：DI)と可変データであIdentification）

る製造識別子(Production Identifier：PI)で構成される。

UL CAP

米国の第三者安全科学機関である UL Inc.の提供するサイバー（Underwriters

セキュリティ認証プログラムのこと。UL が開発した UL 2900

Laboratories

は ANSI （米国規格協会）、FDA（米国食品医薬品局）、そCybersecurity Assuranceの他規制当局に認められた世界初の医療機器業界向け IoT セキ

Program）

ュリティ評価規格である。

V&V

検証と妥当性確認（Verification andValidation）
WD

WG メンバ発行の作業原案文書（Working draft.）ー 14 ー1. はじめに1.1 背景近年、海外の医療施設では、サイバー攻撃による被害を受け、医療機器や医療情報システムが使用不能となる事例が多数報告されている。
英国では、2017 年 5 月に国民保健サービス（National Health Service：NHS）のトラストと病院 40 カ所超がランサムウェア WannaCry の感染による被害を受け、情報技術（Information
Technology：IT）システムの稼動と患者情報へのアクセスが不能となった。この事態を受け、英国では、2018 年にサイバーセキュリティ強化のため、サイバーセキュリティセンターを新設することが発表された。
シンガポールは、サイバーセキュリティ分野で世界をリードする諸外国の一つであるが、同国の保健省と情報通信省は、SingHealth が運営する専門外来病院や総合病院の患者 150 万人分の個人情報が流出したことを 2018 年 7 月に共同発表した。首相府管轄下にあるスマート国家デジタル政府グループ（Smart Nation and Digital Government Group：SNDGG）は政府のシス
テムを見直すと共に、スマート国家構想に基づくプロジェクトの一部を中断した。現在、同国
では、SingHealth や公的部門における IT システムのマネジメントと保護の強化が進められている。
我が国においては、重大案件が 2019 年以降も頻発している。国内における医療機器のサイバ
ーセキュティに関する考え方としては、平成 30 年 7 月 24 日付薬生機参発 0724 第 1 号・薬生
安発 0724 第 1 号厚生労働省医薬・生活衛生局医療機器審査管理課・医薬安全対策課長通知別添「医療機器のサイバーセキュリティの確保に関するガイダンス」[1]が発出されている。医療機器製造販売業者は、当該ガイダンスを参考にして適切に対応することが求められると共に、国際動向を踏まえた更なる対応の強化が必要となる。

1.2 目的2019 年 10 月、国際医療機器規制当局フォーラム（International Medical Device Regulators
Forum：IMDRF）において作成されたサイバーセキュリティに関するガイダンス案「医療機器サイバーセキュリティの原則及び実践」（Principles and Practices for Medical Device
Cybersecurity）[2]のパブリックコメントが募集された。今後、国内の医療機器規制においても国際整合化が図られることが予測されるため、本調査では、海外でのサイバーセキュリティへの対応動向を確認し、国内規制等の対応方針を検討するための情報を提供すると共に、医療機器の製造販売業者及び医療施設等のユーザに向けて注意喚起することを目的として、医療機器のサイバーセキュリティについて考慮すべき事項を抽出した。

ー 15 ー

2. 医療機器規制の中でサイバーセキュリティを理解する上で重要な事項
2.1 概要
一般的に、ソフトウェアの初期構想、設計・開発段階から最終的な廃棄に至る過程では、資材調達、流通、運用、保守等の作業が発生するが、近年、その一連のつながりを悪用したサプ
ライチェーン攻撃による脅威が認識されるようになった。ソフトウェアの相互接続が進む中、
サイバーセキュリティのリスクと対応に要するコストは個人や組織に留まらず、公共の安全や国家の安全保障にまで影響を与えるため、包括的且つ横断的な施策を設けることが急務である。
サプライチェーンの透明性向上は、サイバーセキュリティの確保に直結することから、ソフト
ウェアのサプライヤ（供給者、契約又はライセンスに基づいて製品等を供給する業者）とプロバイダ（提供者、様々な製品・知的財産・技術・契約等を用いて、環境・サービスを提供する
組織・業者）及びユーザとの間の情報共有が重要視されている。すなわち、ソフトウェアを含む医療機器の製造販売業者においても、サプライチェーンも含めた医療機器製品のセキュリテ
ィへの対応強化が求められる時代が到来している。
米 国 商 務 省 下 の 機 関 で あ る 国 家 電 気 通 信 情 報 庁 （ National Telecommunications andInformation Administration：NTIA）は、ソフトウェアコンポーネント透明性（Software
Component Transparency：SCT）に関する委員会[3]における標準化及び規格化 WG の議論を踏まえて、ドラフトホワイトペーパー[4]を公開している（2019 年 9 月）。当該文書では、ソフ
トウェアライフサイクルにおいて、ソフトウェア製品の構成変更に関する事例を紹介している。
ソフトウェアの製品情報を一元化するソフトウェア部品表（Software Bill of Materials：SBOM）の概念においては、ソフトウェアライフサイクルの中で関連するサプライヤが供給する構成要素に関する情報を明示し、サプライヤとプロバイダが情報共有する仕組みが示されている（図 1）。
また、将来的な構想として、外部コンポーネント及び共有ライブラリ、商用又はオープンソー
ス等の情報について、機械的に読み取り可能な方法で利用できる仕組みの整備が進められている。また、SCT では、ヘルスケアの概念実証 WG（Healthcare Proof of Concept WG：H-PoC WG）
において、SBOM を用いた製品情報のマネジメントが進む医療機器業界を対象に、医療機器製造販売業者と医療機器の運用マネジメントとリスクマネジメントを行う必要がある病院等のヘ
ルスケア提供機関（Healthcare Delivery Organization：HDO）における SBOM の利用法[5]についても検討されている（2.5 項で詳述）。今後、SBOM は医療機器業界の国際標準として利用される可能性が高く、その動向に着目しておく必要がある。

ー 16 ー

図 1．根底のコード変更が生じるステージを複数有するソフトウェアライフサイクル
変更に伴い SBOM が更新される（出典：NTIA SCT, Survey of Existing SBOM Formats and Standards[4] Figure 1）

医療機器におけるサイバーセキュリティの考え方に関する基本事項は、以下の関連規格に規定されている。各規格の詳細については、「4. 国際規格」で解説する。

1) リスクマネジメント＜製造販売業者向け＞
ISO 14971[6]（JIS T 14971）[7] 医療機器 —— リスクマネジメントの医療機器への適用＜HDO 向け＞
IEC 80001 シリーズ[8] 医療機器を組込んだ IT ネットワークへのリスクマネジメントの適用

2) マネジメントシステム
ISO 13485[9]（JIS Q 13485）[10] 医療機器 —— 品質マネジメントシステム – 規制目的のための要求事項ISO/IEC 27000 シリーズ[11] 情報セキュリティマネジメントシステム

3) ソフトウェア開発ライフサイクル及び製品安全IEC 62304[12]（JIS T 2304）[13] 医療機器ソフトウェアのライフサイクル
IEC 82304-1[14]（JIS T 82304-1）[15] ヘルスソフトウェア —— 第 1 部：製品安全に関する一ー 17 ー

般要求事項【関連項目】・ セキュリティ技術導入ガイド（Security Technical Implementation Guide：STIG）[16]
ソフトウェア及びハードウェアのインストール及びメンテナンスに関して標準化されたセキュアの方法と具体的な要求事項を規定している。製品のライフサイクル全体（Total
Product Life Cycle：TPLC）にわたり推奨されるマネジメントプロセスやコーディング
ルールを含む、達成基準、チェックツール等を提供するための手引書である。
・ UL サイバーセキュリティ認証プログラム（Underwriters Laboratories Cybersecurity
Assurance Program：UL CAP）[17]
ネットワークデバイスのセキュリティに関するベストプラクティスをまとめた規格群である UL 2900 に基づいてセキュリティを保証するプログラムである。

4) 規制
IMDRF ガイダンス[2]は米国食品医薬品局（Food and Drug Administration：FDA）の市販
前及び市販後ガイダンスが基本となっている。
【関連項目】・ フ レ ー ム ワ ー ク ： NIST サ イ バ ー セ キ ュ リ テ ィ フ レ ー ム ワ ー ク （ Cyber Security
Framework：CSF）[18]
サイバーセキュリティに関する推奨ベースラインである。部門、規模にかかわらずいずれの組織でも使用できる。世界中で採用されている。
・ 脆弱性の管理 ID：共通脆弱性情報識別子（Common Vulnerabilities and Exposures：CVE）[19]、脆弱性情報データベース（National Vulnerability Database：NVD）[20]・ 評価基準：共通脆弱性評価システム（Common Vulnerability Scoring System：CVSS）[21]、共通弱点評価システム（Common Weakness Scoring System：CWSS）[22]・ 脆弱性のカテゴリ：共通脆弱性タイプ一覧（Common Weakness Enumeration：CWE）[23]

・ 攻撃パターンの分類：共通攻撃パターンタイプと分類（Common Attack Pattern
Enumeration and Classification：CAPEC）[24]

2.2 製品のライフサイクル全体
製造販売業者は、製品の初期構想、設計・開発段階から廃棄に至るライフサイクルを通じて、継続的にサイバーセキュリティのリスクマネジメントを行う必要がある。海外の規制関連文書で規定されている、TPLC における要求事項を以下に示す。

ー 18 ー1) IMDRF ガイダンス[2]サイバーセキュリティの脅威及び脆弱性に関するリスクは、初期構想段階からサポート終了（End of Support：EOS）に至る、医療機器の製品寿命（End Of Life：EOL）の全ての段階を通して考慮することが望ましい。サイバーセキュリティの動的な性質を考慮した場合、リスクマネジメントは TPLC に渡って適用されることが効果的であり、設計、製造、試験及び市販後監視の活動における一連の評価により、サイバーセキュリティに関するリスクが低減される。

2) 米国 FDATPLC を通じて、製品が安全且つ有効な状態を確実に維持するため、サイバーセキュリティに関するリスク評価の一助として、FDA の市販前[25]及び市販後ガイダンス[26]を用い、製品が信頼できることを文書によって示す必要がある。

3) 豪州 治療製品管理局（Therapeutic Goods Administration：TGA）[27]
医療機器のサイバーセキュリティのリスクマネジメントと品質マネジメントには、TPLC に渡って、適用可能な複数の環境要因を考慮した評価と対応する処置が必要である。

4) 加国 保健省（Health Canada）[28]
ISO 14971:2007 に規定する適切なリスクマネジメントの原則は、医療機器の TPLC を通して組み込まれることが望ましい。Health Canada は製造販売業者がこのリスクマネジメントの原則を考慮した上で、サイバーセキュリティに拡張することを推奨している。

5) 仏国 医薬品・保健製品安全庁（Agence Nationale de sécurité du Médicament et desproduits de santé：ANSM）[29]
CE マーキングの仕様を満たすために、製造販売業者は医療機器のライフサイクルを通じて、
セキュリティと性能に対する一般要求事項に見合うことを保証しなければならない。

2.3 共同責任
医療機器のサイバーセキュリティは、医療機器製造販売業者、医療施設、医療従事者等の医療供給者（ヘルスケアプロバイダ）、患者、規制当局及び脆弱性発見者等の共同責任である。
海外の規制関連文書で規定されている、医療機器のサイバーセキュリティにおける共同責任の内容を以下に示す。
1) IMDRF ガイダンス[2]ー 19 ー

医療機器のサイバーセキュリティは、製造販売業者、ヘルスケアプロバイダ、患者、規制当局及び脆弱性発見者等、全ての利害関係者の共同責任である。全ての利害関係者は、医療機器の TPLC を通して、潜在的なサイバーセキュリティリスク及び脅威を継続的に監視、評価及び低減すると共に、コミュニケーションを図る責任がある。

2) 米国 FDA[25]医療機器のセキュリティは、医療施設、医療従事者、患者及び医療機器製造販売業者の共同責任である。

3) 豪州 TGA[27]製造販売業者は、設計・開発プロセス中にサイバーセキュリティのリスクに対応する必要がある。製造販売業者及びスポンサー（豪州内で医療機器の安全性と品質が実証され、必須原則の遵守が維持されていることを確認し、医療機器の供給を担当する個人又は企業）は、継続的に医療機器のサイバーセキュリティリスクを評価し、適切に対応する必要がある。
豪州 TGA も、
サイバー関連の問題の影響を受ける医療機器の継続的な安全性、品質及び性能に責任を負う。

4) 加国 Health Canada[28]医療機器のサイバーセキュリティは、製造販売業者、規制当局、ユーザ及びヘルスケアプロ
バイダの共同責任である。

5) 仏国 ANSM[29]共同責任については、未記載と思われる。

2.4 情報共有
全ての責任関係者は、医療機器及び接続するヘルスケアインフラストラクチャーの安全性、有効性、完全性及びセキュリティに影響を及ぼす可能性のあるサイバーセキュリティのインシ
デント、脅威及び脆弱性に対する協力体制構築及びコミュニケーションを促進させるために、各国の、コンピュータ緊急対応組織（Computer Emergency Response Team：CERT）や、情報共有分析機関（Information Sharing Analysis Organization：ISAO）に参加することが求められる。
海外の規制関連文書で規定されている、医療機器のサイバーセキュリティに必要な情報共有の内容を以下に示す。
1) IMDRF ガイダンス[2]ー 20 ーサイバーセキュリティに関する情報の共有は、安全でセキュアな医療機器を実現するためのTPLC アプローチの基礎原則である。全ての利害関係者が市販前及び市販後のサイバーセキュリ
ティに対して積極的に対応することが奨励される。タイムリーに情報が得られることによって、全ての責任関係者が、脅威を特定し、関連するリスクを評価し、それに適宜対応するための能力が拡張される。全ての責任関係者は、医療機器及び接続するヘルスケアインフラストラクチ
ャーの安全性、有効性、完全性及びセキュリティに影響を及ぼす可能性のあるサイバーセキュ
リティのインシデント、脅威及び脆弱性に対する協力体制構築及びコミュニケーションを促進させるために、ISAO に積極的に参加することが奨励される。また、情報共有ポリシーを更に発展させ、ヘルスケアプロバイダ及び医療機器のユーザを含めることも推奨される。規制当局は、患者安全を国際的に保護し、維持するために、他の規制当局と情報共有することが奨励される。

2) 米国 FDA[25]サイバーセキュリティ対応にとって重要なことは、医療機器業界におけるサイバーリスクの情報共有であるため、FDA の医療機器・放射線保健センター (Center for Devices andRadiological Health：CDRH ) は ISAO の一つである国民保険情報共有分析センター（National
Health Information Sharing & Analysis Center：NH-ISAC、現在の H-ISAC）との合意書を締結した。

3) 豪州 TGA[27]
情報共有システムは、サプライチェーンに沿った関係者、特に製造販売業者とスポンサーに、脅威を識別し、関連するリスクを評価し、これらに対処するためのベストプラクティスアプロ
ーチを共有する能力を提供する。豪州では、一般的なサイバーセキュリティの脅威情報の共有と監視は、CERT Australia を通じて行うことができる。豪州 TGA は ISAO 等からの情報の価値も認識している。

4) 加国 Health Canada[28]セキュリティ脅威や脆弱性に関する更新情報の共有や、コミュニケーションの促進を ISAOs
や ISACs への参加によって行うことを検討する。

5) 仏国 ANSM[29]医療機器の認証の一環として、製造販売業者は脆弱性登録システムを提案しなければならな
い。

ー 21 ー2.5 部品表（SBOM/CBOM）
IEC 62304[30] で要求されている開発過程が不明なソフトウェア（Software of Unknown
Provenance：SOUP）のマネジメントをより効果的に行うことを目的として、ソフトウェアコ
ンポーネント、コンポーネントの情報、サプライチェーンの関係性等を示す一覧表である SBOM、又は脆弱性の影響を受け易いソフトウェア及びハードウェアコンポーネント（市販製品、オー
プンソース、未知の開発プロセスを含む製品等）の一覧表であるサイバーセキュリティ部品表（Cybersecurity Bill of Materials：CBOM）を利用したソフトウェア資産管理の仕組みを構築するための議論が進んでいる。各国の規制の中でも既に製造販売業者が SBOM 又は CBOM を提供することにより、医療機器をマネジメントする医療施設やユーザ等も脆弱性に関する情報を入手できることが示されており、製品セキュリティに対応する組織作りが求められている。
海外の規制関連文書及び国際規格で規定されている部品表の内容を以下に示す。
1) IMDRF ガイダンス[2]製造販売業者は取扱説明書に加えて、技術文書、技術的要求事項を作成する。この中には、SBOM を提供することも含まれる。管理者は資産管理の一環として SBOM を使用することで、
アプリケーション等の潜在的な脆弱性及び弱点に関する正確な見解を得られると共に、必要なソフトウェアパッチをタイムリーに特定することができる。また、SBOM は医療機器又は医療機器アプリケーションで使用されているコンポーネントを可視化し、潜在的セキュリティリス
ク及びライセンスの問題を特定できるため、購入見込み顧客の購入決定に必要な情報を提供できる。

2) 米国 FDA[25]
CBOM は、資産、脅威及び責任を特定する上で、重要事項となり得る。また、CBOM を活用
し、購入もしくは受領した全製品のサイバーセキュリティに関する要件の確立を促すことにより、購買管理の遵守を支援することも可能である。

3) 豪州 TGA[27]製造販売業者は相互参照する SBOM を維持する必要がある。監視活動を通じてサイバーセキ
ュリティの脆弱性が特定された場合、製造販売業者は問題を理解し、リスクアセスメントを実施するため、必要に応じて情報源と協力するべきである。サイバーセキュリティ監視に係る全ての結果は、特定されたリスクのレベルにかかわらず、継続的なリスクマネジメントの一環として文書化する必要がある。

4) IEC 62304[30]ー 22 ーソフトウェアリスクマネジメント計画の中で、製造販売業者に対し、標準ライブラリを含む
SOUP 構成アイテムについて、以下の事項を文書化することが要求されている。
a) 名称
b) 製造者c) SOUP を特定する識別子** SOUP を特定する識別子の例として、バージョン、リリース年月日、パッチ番号、アップグレ
ードの識別子等が考えられる。

5) 米国 NTIA[3]SCT の H-PoC WG は、医療機器製造販売業者が作成した SBOM を用いた HDO によるリス
クマネジメントの実施可能性について、以下の事項を実証した[5]。
・

医療機器製造販売業者が標準フォーマットに準じて作成した SBOM は、医療業界で活用可能であり、業界固有のフォーマットが不要であること・HDO は、製造販売業者から提供された SBOM をリスクスコアや医療機器セキュリティ
に関する製造販売業者開示書（2.6 項解説）等の外部の脆弱性評価手法と共に用いることで、ソフトウェアの脆弱性が評価できること

H-PoC WG は SBOM が医療機器のセキュアなエコシステム（ひとつの製品だけではなく業界の製品・サービスを取り巻く収益環境の中である目的のプロセスが回る仕組み）であることをFDA に通知する必要があるとしている。

2.6 製造販売業者開示書
米国電機工業会（National Electrical Manufacturers Association：NEMA）は医療機器セキ
ュリティに関する製造販売業者開示書（Manufacturer Disclosure Statement for Medical
Device Security：MDS2）[31,32]を提供している。MDS2 は、製造販売業者が医療機器のセキュ
リティ対応状況を自己宣言書として医療従事者に開示する文書である。医療機器の説明には、製造販売業者名・連絡先、機器の説明、機器モデル、文書識別コード、製造販売業者ネットワーク環境における機器の用途、文書公開日、脆弱性開示の協調状況、ISAO 加盟状況、ネットワ
ークアーキテクチャ（俯瞰）図、構成する医療機器プログラム（Software as a Medical Device：
SaMD）等の情報提示が求められる。セキュリティ機能の説明には各質問に対して「はい」、「いいえ」、又は「非該当」で記入する。表 1 に MDS2 のセキュリティ機能として回答が求められるカテゴリを示す。NEMA は、各組織のセキュリティコンプライアンスとリスクアセスメントの一環として、MDS2 形式の情報を使用することを推奨しており、2019 年 7 月に改訂版（MDS2
HN 1-2019）を発出した[32]。米国では、MDS2 の作成及び開示の義務が製造販売業者に課せらー 23 ーれており、豪州のガイダンスでも、その有用性が示されている。サイバーセキュリティのリス
クマネジメントは、製造販売業者、医療施設、医療従事者、患者等が相互に情報共有して対応する必要があるため、今後、日本でも MDS2 と同様の国際的なツールの導入が必須になると考えられる。

表 1. IEC TR80001-2-2 と MDS2 のカテゴリの比較

ー 24 ー2.7 製品セキュリティのための対応
2.7.1 部品表と情報共有
2.1 項及び 2.5 項で示したように、米国 NTIA は、2018 年 7 月に SCT に関する委員会[3]を構成し、4 つの WG を設立した。これらの WG は、脆弱性情報の理解と処理、成長するモノのイ
ンターネット（Internet of Things：IoT）マーケットへの対処、安全なソフトウェア開発ライ
フサイクルの促進に関して討議していると共に、主な議題となる SBOM について検討している。
部品表の公開は、販売競争上、開発者側にとって不利であると考えられてきた。しかし、医療行為に伴って発生するリスクをより低減するためには、製造販売業者と医療従事者との協力が必須であり、医療業界には他業界と比較して SBOM 公開に関する高いニーズがある。SCT における WG の一つでは、医療機器業界を対象として、SBOM フォーマットの試作、SBOM の活用
事例、利用方法の確立等について検討されている[4]。少なくとも米国では、別途進行しているソ
フトウェア資産管理の体制構築と融合することにより、SBOM を利用した脆弱性情報管理が効率的、網羅的、かつ自動的に進む時代となると予想される。

2.7.2 SBOM のフォーマット
米国 NTIA の SCT における標準化及び規格化 WG で検討されている SBOM の表示例[4]を表2 に示す。SBOM はコンポーネントを一意かつ明確に識別し、関連性を特定するために用いる。
SBOM のベースラインはサプライヤ名、コンポーネント名、ユニーク ID、バージョン、コンポーネントハッシュ、関連性、SBOM の作成者である。ソフトウェア資産管理に用いられる既存
フォーマットである Linux Foundation のソフトウェアパッケージデータ交換規格 ( Software
Package Data Exchange：SPDX）[33] 及び ISO/IEC 19770-2 によるソフトウェア識別タグ( Software identification：SWID）[34]での表示が紹介されている。

表 2. ベースラインコンポーネントの既存フォーマットへのマッピング（出典：NTIA の Survey of Existing SBOM Formats[4] Table 1）

ー 25 ー2.7.3 脆弱性情報の共有
米国国立標準技術研究所 ( National Institute Of Standards And Technology：NIST ) は、
NVD[35]を管理すると共に、CVE[23]で命名された脆弱性に関する詳細情報について、NVD を介して提供している。NVD には、CVE のほか共通プラットフォーム一覧（Common Platform
Enumeration：CPE）[36]辞書も含まれる。CVE は、個別製品中の脆弱性を対象として、米国の支援を受けた非営利団体である MITRE 社が割当している識別子であり、多くの脆弱性検査ツー
ルや脆弱性対策情報提供サービスにおいて利用されている。CPE は、ハードウェア、オペレー
ティングシステム、アプリケーション等の名称を容易にプログラム処理するための記述形式を定めた仕様である。この仕様に従ってプラットフォームに付与された名称一覧が CPE 辞書である。製品に含まれるソフトウェアを CPE 名で管理することにより、CPE に紐付けされた脆弱性
情報として CVE 識別番号が発番され、新たな脆弱性が NVD に登録される毎に情報共有される。
国内においては、一般社団法人 JPCERT コーディネーションセンター（Japan Computer
Emergency Response Team/Coordination Center ： JPCERT/CC ) と 情 報 処 理 推 進 機 構（Information-technology Promotion Agency：IPA）が、日本脆弱性情報データベース( Japan
Vulnerability Notes︓JVN)[20]を共同管理している。国際的に収集可能な脆弱性情報については、
NVD で登録されるが、JVN は、NVD が対応していない日本国内の脆弱性情報に重点を置いている。NVD と連携しており、JPCERT を通して脆弱性情報を登録することができる。

ー 26 ー3. 各国のガイダンス
3.1 近年の動向
サイバーセキュリティについては、米国が先行してフレームワーク[25, 26]を作成してきたが、規制上の国際協調を図る目的として、IMDRF ガイダンス案[2]が作成され、パブリックコメント
が 2019 年 10 月に募集された。豪州[27]、加国[28]は、これ以前に、自国のガイダンスを発表している。欧州では、欧州サイバーセキュリティ法[37]が 2019 年 6 月 27 日に施行され、医療機器指令（Medical Devices Directive：MDD）から欧州医療機器規則（Medical Devices Regulation：
MDR）への規制強化に伴い、新たな対応が急務である中、仏国が IMDRF ガイダンスと整合した考え方[29]をガイドラインとして発表した。各国の動向は、以下に示したとおりである。

3.2 米国 FDA
2016 年 12 月 27 日の「FDA voices」において、FDA アソシエイトディレクターであるシュ
ワルツ医師は次のように発言している。
【FDA voices】
医療機器が病院のネットワークや患者の自宅のインターネットサービスにも接続されている
今日の世界では、患者のケアのための技術的進歩が顕著になると共に、機器の性能や機能に影響を与えるサイバーセキュリティに係るリスクも増加した。これらの脅威と戦う最良の方法は、製造販売業者が機器の全製品ライフサイクルを通じてサイバーセキュリティを考慮することである。言い換えれば、製造販売業者は、サイバー脅威に直面しても機器の性能を適切に保証するため、設計・開発時にサイバーセキュリティ対応を考慮した上で上市し、患者が機器を使用している間、継続的にサイバーセキュリティに関する懸念事項を監視し、対処するべきである。
これは、米国 FDA が製造販売業者に対して要求するサイバーセキュリティに関する市販前後の対応を一言に集約した内容となっている。
米国 FDA は図 2 に示したロードマップに基づいて、市販前後を対象としたガイダンスの発
行・改訂を計画している。市販前ガイダンスは 2014 年に第 1 版が発行され、2018 年に改訂案[25]が公開されている。この改訂案は 2020 年に最終版として発行される予定である。市販後ガイダ
ンスは、2016 年に草案が公開され、2017 年に最終版[26]が発行された。両ガイダンスの主な内容については、それぞれ 3.2.1 項及び 3.2.2 項で解説する。

ー 27 ー

図 2．米国 FDA のサイバーセキュリティに関するガイダンスの発行計画（出典：米国 FDA CDRH Learn の資料[38]に基づいて再構成）
3.2.1 市販前ガイダンス2018 年 10 月 18 日に公開された市販前ガイダンス改訂案[25]の目次は表 3 のとおりである。米
国医療機器振興協会（Association for the Advancement of Medical Instrumentation：AAMI）
規格や実証実験等を通して、実施の効果等を確認すると共に、要求事項を再構築することが求められる。

表 3．米国 FDA サイバーセキュリティ（市販前ガイダンスの目次）[25]
目次
Ⅰ．はじめにⅡ．適用範囲・ IEC 62304 Ed.1.1 と同じ・ 患者の受ける危害のリスクを低減させる
Ⅲ．定義
Ⅳ．一般原則及びリスクアセスメント
・ ISO 14971 と AAMI TIR 57、Tier 1/2、記憶媒体、メディア、無線 LAN
Ⅴ．信頼できる機器の設計：NIST による CSF の適用
・ 設計
・ 不正アクセスの防止／完全性／機密性ー 28 ー・ セキュリティの検知／応答／回復
Ⅵ．サイバーセキュリティリスクを有する機器の表示に関する勧告（Labeling）
・ “意図する使用と適切な使用”、取説、手順書、システム構成図、CBOM、セキュリテ
ィに関するサポート終了情報
Ⅶ．サイバーセキュリティの文書化
・ 設計の文書化、リスクマネジメントの文書化
Ⅷ．認知規格Ⅳ項に記載されている共同責任の概念は以下のとおりである。
【共同責任の概念】
医療機器のセキュリティは、医療施設、患者、医療従事者及び医療機器製造販売業者間の共同責任である。サイバーセキュリティを維持できない場合、結果として、機器の機能性障害、医療上の又は個人的なデータの真正性、可用性や完全性の損失、あるいは他の接続機器又はネットワークをセキュリティの脅威へ曝露する可能性がある。これにより、患者の疾患、障害又は死亡に至る可能性がある。
これに関連し、FDA FACT SHEET では責任の概念について以下のとおりに解説されている。
【FDA FACT SHEET における責任の概念】
製造販売業者はサイバーセキュリティを理由に医療機器を随時更新することができるが、サイバーセキュリティの強化のみを理由とする場合、通常、FDA における審査は不要である。医療施設は内部のネットワークに医療機器を接続することに対して責任を負う。セキュリティリ
スクを低減するためには、パッチや変更やインフラストラクチャーのサポートが必要な場合がある。医療施設は、これらの変更に対するリスクアセスメントを実施する必要があることを認識した上で、医療機器製造販売業者と密接に協力・情報共有しつつ対応することを推奨する。
米国 FDA は、医療機器製造販売業者に確実なソフトウェアの構成マネジメントと設計マネジ
メント含む QMS を求めている。具体的事項は以下のとおりである。
・ 適切なサイバーセキュリティ対応を施した医療機器を設計・開発する上で、リスクベース
アプローチを採用すること
・ 包括的なサイバーセキュリティ対応を行うために、TPLC を通したリスクの選定とその低減策に関する評価を反復して実施すること
・ 他製品へ影響を与える可能性が高い重要な医療機器においては、その安全性と基本性能を確実に維持し、継続することー 29 ー

・ 医療機器の安全性及び有効性を継続的に確保するために、信頼性の高い機器の開発を促進すること

Ⅴ項に記載されている「信頼できる機器の設計」の概要は以下のとおりである。
【信頼できる機器の設計】
医療機器ソフトウェアについては、設計マネジメントに関連する文書、特に 21 CFR 820.30(g)に示される設計バリデーションとソフトウェアバリデーション及びリスク分析に関連する文書
が、市販前申請において安全性及び有効性を合理的に保証するために必要となる。サイバーセ
キュリティリスクを有する場合、FDA は、市販前審査に関する法令上の基準を満たすと共に、
TPLC を通した安全性及び有効性を検証することにより、信頼性の高い医療機器を設計するよう推奨している。信頼性の高い機器に求められる事項は以下のとおりである。
1） サイバーセキュリティへの脅威及び誤用に対して十分に安全である
2） 適切な水準の可用性、信頼性及び正確な動作を提供できる
3） その目的とする機能を遂行する上で十分に適切である
4） 一般に認知されているセキュリティ手順を遵守している
これらの信頼性を示す文書は、FDA がサイバーセキュリティに関して医療機器の安全性及び有効性を迅速かつ効果的に評価する一助となる。

3.2.2 市販後ガイダンス
医療機器に対するサイバーセキュリティのリスクは持続的に進化するため、市販前のマネジ
メントだけではリスクを完全に低減することは不可能である。サイバーセキュリティのリスク
マネジメントプログラムの重要な要素は以下のようなものがある。
・ サイバーセキュリティの脆弱性とリスクを発見、検知するためサイバーセキュリティ情報源をモニタリングする・ ソフトウェアの堅牢なライフサイクルプロセスを維持する
・ 脆弱性の存在と影響を理解し、評価し、検知する
・ 脆弱性の認知と処理のプロセスを確立し、通達する・ 機器の安全性と基本性能を維持する方法を規定するため、サイバーセキュリティリスクから保護、対応及び回復させる手段の策定にあたっては、脅威モデリング手法を使用する
・ 脆弱性に関する協調的な開示方針を採用し、対応策を確立する・ 悪用される前にサイバーセキュリティリスクを低減する

ー 30 ー

米国 FDA 市販後ガイダンスを理解する上でのポイントには下記 3 点があげられる。
1) 患者の受ける危害
市販後ガイダンスでは、患者への身体的危害をリスクマネジメント（ISO 14971）の対象とする。但し、保護対象保健情報（Protected Health Information：PHI）の喪失・漏洩等は対象としない*。患者の受ける危害に関する対応としては、以下の事項が挙げられる。
・ サイバーセキュリティ対応に関する定期的更新又はパッチ適用を行う（サイバーセキュリ
ティの強化のためだけになされる機器の変更については、米国 FDA は 21 CFR parts
806 下の事前通知や報告を要求しない）
・ 医療機器の安全性又は基本性能に悪影響を及ぼすリスク、並びに深刻な健康上の悪影響や死をもたらすリスクを通知する
・ 製造販売業者は ISAO の一つである H-ISAC に加盟する* PHI の守秘義務の保護は市販後ガイダンスの適用範囲を超えているが、製造販売業者や他の団体は、事実や状況に応じて、医療情報の相互運用性と説明責任に関する法律（Health
Information Portability and Accountability Act：HIPAA）を含め適用される連邦法及び州法に従い、製品の全ライフサイクルを通して PHI の機密性、完全性及び可用性を保護する義務があることに留意する。

2) リスクベースフレームワーク
効果的なサイバーセキュリティのリスクマネジメントのためには、米国 NIST の CSF（発見、保護、検知、対応、回復）を適用することが推奨される。サイバーセキュリティの脆弱性が、医療機器の安全性と基本性能に影響を与える可能性があり、機器の性能が阻害されると、患者被害が生じ、それを防ぐための介入が必要となる場合がある。製造販売業者は脆弱性を特徴化し、評価するプロセスを定め、文書化することが必要である。特に、患者被害のリスク評価に重点を置いたプロセスが望ましく、サイバーセキュリティの脆弱性に対する攻撃と、その際に生じる患者被害の重大度を検討すべきである。脆弱性が悪用される可能性、並びに悪用された
場合の患者被害の大きさについては、評価基準の一つである CVSS 等を用いて検討する。悪用可能性と患者被害の重大さを図 4 に例示したマトリックス等に示すことで、患者被害のリスクを容認できる残存リスクか、容認できない残存リスクかに分類できる。

3) コントロールできないリスク
21 CFR parts 803 又は 1004 に従った報告がない場合、
21 CFR parts 806 に準拠し、米国 FDAに「コントロールできないリスク」として脆弱性を報告する。製造販売業者は、サイバーセキ
ュリティの脆弱性に対する攻撃の際に、早急な対応が不可能な場合にあっても、悪用可能性をー 31 ー含めたリスクの推定が可能な状態を維持すべきである。サイバーセキュリティの悪用可能性を推定することは、攻撃パターンの複雑さ、悪用状況、利用されたツールキット等の要因により非常に困難である。被害発生の確率に関するデータがない場合、従来のリスクマネジメントでは、推定される合理的なワーストケースを用いるか、確率のデフォルト値を「1」に設定することを提案している。米国 FDA は、このような対応も容認するが、脆弱性の判定と対応の必要性や緊急性を判断するために、サイバーセキュリティの脆弱性の評価ツールや同様の判定システ
ムの使用を検討することを製造販売業者に提案している。

図 4. 米国 FDA による患者リスク被害の評価の考え方（出典：米国 FDA CDRH Learn の資料に基づいて再構成）[38]

3.3 豪州 TGA
豪州 TGA は、2019 年 7 月 18 日に「医療機器のサイバーセキュリティガイダンス」（Medical
device cyber security guidance for industry）[27]を発効した。米国 FDA ガイダンス同様、市販前後を含む総合的なガイダンスであり、医療機器の登録にあたって基本原則に従うことが要求されている。豪州 TGA は、TPLC に言及しており、基本原則として製造販売業者が設計、長期間の安全性及び医療機器の使用に関連したリスクを最小化することを求めている。最終版ではSBOM も採用されている。リスクマネジメントは ISO 14971:2019 に則っており、「harm（危害）」の考え方は、身体的危害のみならず、心理的危害も含んでいる。米国 FDA の市販後ガイ
ダンスにおいて患者の受ける危害から除外されている PHI も、「個人情報の開示によるプライ
バシーの侵害」として心理的危害に含まれている。また、豪州は、英国の影響も同時に受けてー 32 ーおり、基本要件（Essential Principles：EP）を挙げた上で、ISO/IEC 規格との対応を一覧表にまとめている。

3.3.1 市販前ガイダンス
市販前ガイダンスの基本要件とサイバーセキュリティの考慮事項、並びに基本要件と主要国
際規格との対応をそれぞれ表 4、表 5 に示した。
表 5 中の EP の番号は表 4 中の番号に対応する。

表 4. 基本要件とサイバーセキュリティの考慮事項（出典：豪州 TGA のガイドラインに基づいて再構成）[27]

ー 33 ー表 5. 基本要件と主要国際規格との対応（出典：豪州 TGA のガイドラインに基づいて再構成）[27]

3.3.2 市販後ガイダンス
サイバーセキュリティ対応は市販後のリスクマネジメントプロセスの一部と見なす必要がある。サイバーセキュリティに関するリスクは時間経過に伴い変化する性質を有しており、市販前の対応のみでは低減できないため、継続的な監視とマネジメントが求められる。
製造販売業者及びスポンサー（豪州における医療機器の供給責任者）は、基本原則を遵守するために、医療機器のライフサイクルを通して品質マネジメント及びリスクマネジメントシス
テムを確立、文書化、更新しなければならない。このプロセスには、サイバーセキュリティの脆弱性と脅威に関連するリスクの推定、評価、マネジメント、並びに必要に応じた是正処置等、医療機器の安全な使用に関連するリスクを特定するための継続的な作業が含まれる。
製造販売業者及びスポンサーは、サイバーセキュリティの脆弱性を評価し、対応の必要性と緊急性を判断するために、サイバーセキュリティの脆弱性評価ツール又は同様のスコアリング
システムの使用について検討する必要がある。また、製造販売業者及びスポンサーは、サイバーセキュリティの脆弱性が有害事象、医療機器の故障又は苦情に関連する潜在的なリスクの発生に繋がる可能性等、脆弱性が悪用された場合の患者の受ける危害の重大度を評価する必要がある。
豪州 TGA は米国 FDA のサイバーセキュリティに関する市販後ガイダンスを参考として、ー 34 ー

患者リスク被害の評価の考え方を図 5 のようにまとめている。

図 5. 豪州 TGA による患者リスク被害の評価の考え方（出典：豪州 TGA のガイダンスに基づいて再構成）[27]

3.4 加国 Health Canada
加国 Health Canada は市販前ガイダンスとして「医療機器サイバーセキュリティの市販前要求事項」（Pre-market Requirements for Medical Device Cybersecurity）[28]を 2019 年 6 月 26日に発出した。このガイダンスでは、加国の医療機器クラス分類に対して、米国 FDA ガイダンスとほぼ同一の要求事項を対応付けていることが特徴である。リスクマネジメントは ISO
14971: 2007 に基づいており、AAMI TIR 57 を考慮することで、セキュリティリスクへの拡張を図っている。そのため、ISO 14971：2019 の考え方とは異なることに留意する必要がある。
加国 Health Canada の市販前ガイダンスの目次とリスクの定義をそれぞれ図 6 及び表 6 に示した。加国 Health Canada におけるリスクの定義は AAMI TIR 57 に準じており、患者危害に関わるセキュリティリスク全般を対象としていることから、プライバシーに関する考慮も必要とされる。

ー 35 ー

図 6. セキュリティリスクを検討するために拡大されたリスクの定義（加国 Health Canada の市販前ガイダンスに基づいて再構成）[28]
表 6．加国 Health Canada の市販前ガイダンス（目次）[28]
2.3.1 機器ラベル、梱包ラベル及び文書（Device Labels, Package Label and Documentation）
Cybersecurity BOM (加国 Health Canada の解釈が含まれている)・ SBOM・ 指示書又は情報（抜粋）-サイバーセキュリティリスクを低減するための装置上のリスク低減策の操作方法-

インシデントへの対応と復旧方法-

リスク低減の一環として、装置のソフトウェアを更新する方法-

リスク低減のための IT 管理者向けの適切な IT 環境-

End of Life（装置の耐用年数、製品の生産終了、ソフトウェアのサポート終了）

2.3.2 市場履歴（Marketing History）
サイバーセキュリティインシデントに関連して報告された問題の概要とリコールの詳細（装置で発見された脆弱性に対処するためのリコール）
2.3.3 リスクアセスメント報告書（Risk Assessment）
リスクマネジメント報告書を含む（クラスⅢ、Ⅳの場合）
安全性と有効性の要件を満たすために採用されたリスク低減策（情報セキュリティの対応を含む）
2.3.4 品質計画（Device-Specific Quality Plan）
品質計画書を含む（クラスⅣの場合）

ー 36 ー

品質計画では、サイバーセキュリティの枠組みが製造されている医療機器の品質基準の一部であることを実証する
2.3.5 安全性と有効性（Safety and Effectiveness）
医療機器が安全性と有効性の要件を満たしていることを確認するために、製造販売業者が採用したサイバーセキュリティに関する試験の結果の詳細
2.3.5.1 規格
・ 規格のリスト
機器の設計及び製造におけるサイバーセキュリティに関して、全体的又は部分的に適用する全ての規格のリスト（規格は合否基準を定めていないことから、製造販売業者が安全性と有効性を実証するための試験の要約や報告書を提供するべきである）
2.3.5.2 サイバーセキュリティ試験
・ 医療機器のセキュリティの検証及びバリデーション（Verification and Validation：V&V）のために実施された試験の詳細な要約（クラスⅢ、Ⅳの場合）
・ サイバーセキュリティ試験の報告書（クラスⅣの場合）
2.3.5.3 トレーサビリティマトリクス
識別された全てのサイバーセキュリティリスクを以下にマッピングするトレーサビリティマ
トリクス
・ 要求仕様（設計インプット）
・ 設計仕様（設計アウトプット）・ 設計 V&V 試験
2.3.5.4 メンテナンス計画
医療機器のメンテナンス計画の要約を含む
・ 医療機器の安全性と有効性を維持するためのソフトウェアの更新方法
・ 製造販売業者がライフサイクルを通してデバイスの継続的な安全性と有効性を保証することを目的とした市販後プロセス

3.5 仏国 ASNM
仏国 ANSM は 2019 年 7 月にドラフト「ソフトウェアを組み込んだ医療機器に関するライフサイクルの中でのサイバーセキュリティ」（Cybersecurity of medical devices integrating
software during their life cycle）[29]を公開した。欧州医療機器規制におけるサイバーセキュリ
ティに関する最初のガイドラインである。当該ガイドラインにおいて、「サイバーセキュリテ
ィ」とは、「サイバー脅威に対する情報セキュリティ」と説明している。ASNM ガイドライン

ー 37 ーは、医療機器製造販売業者に医療機器に対する攻撃のリスクを最小限に抑えるために必要な処置を講じて、データ侵害又は医療機器の不適切な使用を防ぐための推奨事項について提供することを目的としている。医療機器の安全性評価、リスクマネジメント、MDR におけるサイバー
セキュリティ対応の意義、医療機器の運用終了（廃棄）時にデータを消去する要件等、EU 一般
データ保護規則（The EU's General Data Protection Regulation：GDPR）[39]との関連性を示している。
ソフトウェアのライフサイクルにおける 5 つのキーエリアを図 7 に示した。2.2 項に示したとおり、ソフトウェアのライフサイクルには、設計・開発から、サービス提供開始又は市販開始、並びに EOL までの過程が含まれる。しかし、EOL については、「ハードウェアコンポーネン
ト及び SOUP の寿命（サポート期間等）」及び「データ消去に対する GDPR 原則に基づく適切なデータの保存及び復帰（データの移植性）」を考慮する必要があるため、国際規格の作成にあたり議論が開始されたところである。
ASNM ガイダンスでは、ソフトウェアライフサイクルを通して、サイバーセキュリティリス
クを低減するための推奨事項がリスト化されている。当該リストは ISO 14971：2007 附属書 Cに相当するが、改定作業中の ISO 14971 で対応するものと考えられる。

図 7. ソフトウェアライフサイクルにおける 5 つのキーエリア

3.6 欧州ガイダンス
欧州会議及び欧州理事会は、MDD、体外診断用医療機器指令（In Vitro Diagnostic Medical
Devices Directive：IVDD）、能動埋込医療機器指令（Active Implantable Medical Devices
Directive：AIMD）を MDR と体外診断用医療機器規則（In Vitro Diagnostic Medical Devices
Regulation：IVDR）に改定し、2017 年 5 月 5 日に EU 官報（Official Journal）[40]に掲載した。
MDR 及び IVDR の施行日は EU 官報掲載後 20 日目であり、移行措置期間はそれぞれ 3 年、5ー 38 ー

年とされている。
MDR の 17 章に記載されている電子プログラマブルシステム（Electronic programmablesystems）とは、電子プログラマブルシステムを搭載した医療機器及びそれ自体が医療機器となるソフトウェアを指す。
MDD から MDR ヘの移行に伴い追記された項目は下記のとおりである。
【MDR 17.1 項】
ソフトウェアを含む電子プログラマブルシステムを搭載した医療機器又はそれ自体が医療機器となるソフトウェアは、その意図する使用の範囲内でシステムの再現性、信頼性及び性能が確保されるように設計されなければならない。また、単一故障状態の場合、その結果生じるリ
スク又は性能障害を可能な限り除去又は低減できるよう、適切な手段が講じられなければならない。
＜参考＞ 単一故障の安全性に関する要件は、医療機器分野以外で詳細かつ広範囲に確立されている。欧州では、現在の IEC 60601-1 シリーズに規定されている単一故障に関する安全性の範
囲は「最先端（state of art）」と見なさない動きがあり、それに伴った規格改訂が進行していると考えられる。

【MDR 17.2 項】
ソフトウェアを搭載した医療機器又はその自体が機器であるソフトウェアについては、開発のライフサイクル、情報セキュリティを含むリスクマネジメント、検証及びバリデーションの原則を考慮し、最新の技術に基づいてソフトウェアが開発、製造されなければならない。
＜参考＞ 製品の設計開発段階における情報セキュリティを含むリスクマネジメントの必要性
は、米国のみでなく、欧州においても同様に認識されている。

【MDR 17.3 項（新規追加）】
このセクションで参照するモバイル・コンピューティング・プラットフォームと併用することを意図するソフトウェアは、モバイルプラットフォームの特定の機能（画面サイズ、コント
ラスト比等）及びそれらの使用に関連する外部要因（光又はノイズレベルに関する様々な環境等）を考慮して設計、製造されなければならない。
＜参考＞ スマートフォン等を利用したアプリケーションへの適用については不明である。

【MDR 17.4 項（新規追加）】
製造販売業者は、ハードウェア、IT ネットワーク特性及び不正アクセスに対する保護を含む

ー 39 ーIT セキュリティへの対応について、ソフトウェアを意図するとおりに実行するために必要な最小要件を提示しなければならない。
＜参考＞ 使用環境及び動作環境に関する制限等の要件を添付文書又は添付資料に記載する。

【MDR 18.8 項（新規追加）】
医療機器は、意図したとおりに機能することを妨げる可能性のある不正アクセスから可能な限り保護するように設計、製造されなければならない。
＜参考＞
能動機器（Active devices）及びそれらに接続する医療機器に関する記述は、MDR の 18 章に新規追加された。

ー 40 ー

4. 国際規格4.1 近年の動向
2012 年頃、IEC 62304 Ed.1.1 の CDV 作成段階では、セキュリティリスクをリスクマネジメ
ントの対象として扱えない ISO 14971:2007[6]を引用するにあたり、IEC 62304 でもセキュリテ
ィを扱えないため、セキュリティについては次エディションでの審議事項とする方向で議論された。この状況を受けて、米国は ISO 14971:2007 におけるセキュリティの扱いを可能とするため、図 8 に示した 2 つの方向性について検討を開始した。一方は、Guide 51:1999[41]に基づいて現状の「harm」の定義等を維持しつつ、セキュリティリスクを扱えるように解釈を変えることであり、この一環として AAMI TIR 57:2016[42]が発行された。他方は、Guide 51 自体を改正し、「harm」の定義を見直すことにより、
ISO 14971 でもセキュリティリスクを扱えるようにした。
この成果として、ISO 14971:2019[6]が発行される予定であり、2019 年 7 月時点で AAMI TIR 57
も連動して改正することとなった。

図 8. 規格におけるリスクの考え方に関する 2 つの流れ

4.2 ISO 14971: 20191) スコープ
この規格は、SaMD 及び IVDD を含む医療機器の全てのライフサイクルに適用する。セキュリティの用語については、「security」ではなく、「data and system security」に統一されている。この規格では、「安全」に関するリスクを扱い、その他のビジネスリスク等は対象としていない。

ー 41 ー2) 用語の定義「harm」の定義は以下のとおりである。従来の定義に記載されていた、「physical injury」
から「physical」が削除されたことにより、身体的被害のほか、心理的被害等も含めた人の安全をより重視する内容に変更された。具体的には、疾病の偽陽性診断後に生じ得る過度の心理的ストレス、患者医療情報の漏洩等による心理的ストレス等を「人の受ける健康障害」の一部として捉えること等を意図している。

3.3 harm（危害）injury or damage to the health of people, or damage to property or the environment（人の受ける傷害若しくは健康障害、又は財産若しくは環境の受ける害）また、財産や環境への被害としては、医療機器の使用又は廃棄に伴って発生する危険な廃棄物に関するリスク等が挙げられる。患者情報を消去しないまま廃棄した医療機器を考えると、「人」及び「財産や環境」の両方に害を与えることを想定しなければならない。今回の改正により、データ及びシステムのセキュリティ侵害等のハザードは危害に繋がることが包括された。

3) リスクコントロール
リスクコントロールの選択肢が MDR に基づいて変更された。製造販売業者は以下の事項から一つ以上を選択し、リスクコントロールをしなければならない。

7.1 Risk control option analysisa) inherent safety by design; → inherently safe design and manufacture※ 設計のほか、製造も含めて本質的な安全を検討する。
b) protective measures in the medical device itself or in the manufacturing process;※ 医療機器自体又は製造プロセスにおける予防処置c) information for safety. → information for safety and, where appropriate, training tousers.
※ 安全対策及び必要に応じたユーザトレーニングの実施

7.4 項「Benefit-risk analysis」については、分析対象を個々の残留リスクとするか、製品全体で判断するか議論されたが、受容できない個々のリスクは 7.4 項「a risk」で取り扱い、製品全体は 8 項「Evaluation of overall residual risk」において評価する。

ー 42 ー4) セキュリティリスクとリスクマネジメントとの関係
ハザードの種類は ISO 14971[6] Table C.1 に例示されている（表 7）。Data communication
に関するハザードは、「性能に関連するハザード」として C（confidentiality：機密性）、I(integrity：完全性)、A（availability：可用性）等に分類された上で「Data」欄に示されている。

表 7. ハザードの例（出典：ISO 14971 [6]Table C.1 に基づいて再構成）

ー 43 ー5) セキュリティ等への対応
ISO/TR 24971[43] Annex Table F.1 には、リスクマネジメントにおける脆弱性の取り扱いについても記載されている。表 8 に健康被害に繋がるセキュリティハザードを例示した。データに関するハザードとしては、完全性、可用性及び機密性の喪失が挙げられる。これらの脆弱性
は、不正アクセス、分散型サービス妨害（Distributed Denial of Service：DDoS）攻撃、リモートアクセス、マルウェアの攻撃・感染及び拡散、マルウェアによる暗号化及び破壊等に悪用され、診断情報の不正な変更や個人情報の流出、医療機器の機能不全に至るソフトウェアの破損等の一連の事象を引き起こし、最終的に人への身体的及び心理的な被害に繋がり得ると解釈されている。
表 8. 健康被害につながるセキュリティハザードの例（出典：ISO/TR 24971[43] Annex Table F.1 に基づいて再構成）

図 9 に提示されているとおり、従来のリスクマネジメントにセキュリティコントロールを加えた場合、セキュリティコントロールが他のリスクに影響を与える可能性があると共に、他のリスクもセキュリティに影響を与え得るため、相互にリスク低減を図る必要がある。具体的な手順としては、リスク分析を行い、リスク評価とリスクコントロールを実施する一環として、セキュリティと他のリスクとが互いに与える影響について検討した後、同様の作業を繰り返す

ー 44 ーことにより、相互影響を低減する。
リスクマネジメントプロセスのみでは特定が難しい、使用エラー（Use error）に関するリス
ク評価は、IEC 62366-1:2015[44]におけるユーザビリティエンジニアリングプロセスを適用する
ことにより可能となる。

図 9. 他のリスクコントロール手段とセキュリティコントロール手段の考え得る相互作用（出典：ISO/TR 24971[43] Annex Figure F.2 に基づいて再構成）
4.3 AAMI TIR 57: 2016
1) 用語の定義
AAMI TIR 57 における主要ポイントである「harm」の定義は、ISO 14971:2007 及び IEC
80001 シリーズ[8]等のヘルスケア IT に関する規格に基づいて検討された。ISO 14971:2007[6]における定義である「physical injury or damage（身体的傷害又は被害）」に焦点を絞ったリス
クマネジメントでは、セキュリティリスクの低減範囲が制限される可能性があった。AAMI TIR
57 の定義では、IEC 80001 シリーズ[8]と同様、「リスクは従来の適用範囲である患者の身体的危害を越える影響があり、危険状態には有効性の低下とデータ及びシステムセキュリティの侵害が含まれる場合がある」と記載されており、より幅広い判断を取り入れている。図 10 に AAMI

ー 45 ーTIR 57 におけるセキュリティと安全性の関係を示した。ここでは、情報セキュリティや個人情報等についてもセキュリティリスクに包含されることに留意する必要がある。この考え方は、
加国 Health Canada のガイダンスにも反映されている。

図 10. AAMI TIR57 におけるセキュリティと安全性の関係図
出典：AAMI TIR 57[42] Figure 2 に基づいて再構成
2) リスクマネジメントプロセス
AAMI TIR 57 における安全に影響を及ぼすセキュリティリスクの考え方は ISO 14971 と同様であり、従来どおりのリスクマネジメントが適用できる。医療におけるセキュリティリスクは、人に間接的被害を与える可能性があることから、セキュリティの侵害に起因する事象を含む全てのハザードを ISO 14971 に則ったリスクマネジメントプロセスによりマネジメントする。この際、安全性のほか、セキュリティに関するリスク分析において特定された影響に着目したリ
スクマネジメントプロセスを別途作成することが推奨される。但し、危険状態に至る恐れのあ
るセキュリティリスクは、安全性に関するリスク分析においても評価する必要がある。また、それぞれのリスクレベルは、リスクマネジメントプロセスにより、受容可能なレベルまで低減させる。

3) 製造販売業者の義務
AAMI TIR 57 では、デバイスの動作環境を理解、評価、記録し、デバイスを操作する状況下でセキュリティリスクを評価することを製造販売業者に求めている。動作環境については、製造販売業者の取り扱い範囲外であるため、製造販売業者が直接的に保証することは難しい。しー 46 ーかし、ネットワーク医療機器のリスクをマネジメントする一環として、製造販売業者は、HDOが用いている方法やサイバーセキュリティのニーズ、リスク及びコントロールを利害関係者に開示する方法を理解する義務がある。また、製造販売業者は責任協定取決書（ISO 80001-1 に記載）の概念を理解し、MDS2（2.5 項で解説）等を用いて、医療機器のセキュリティ対応に関する具体的事項を HDO に伝達するべきである。また、製造販売業者は、医療機器の保証及び更新が不十分な場合、当該機器が直接又は共有ネットワークを介して接続される他のコンピュー
タシステム及び医療機器に対するセキュリティの脆弱性の発生源となり得ることも認識する必要がある。このような医療機器はネットワーク上の他のシステムを攻撃する起点になり得るた
め、HDO は、このようなリスクを考慮し、適切に低減する必要がある。

4.4 IEC/CD 80001-5-1
医療機器を組み込んだ IT ネットワークのリスクマネジメントに関する規格である IEC/CD
80001-5-1[45]は、ヘルスソフトウェア全体を適用範囲としていると共に、制御システムのセキュ
リティ規格である IEC 62443 シリーズを引用している。
IEC/CD 80001-5-1 の査読を ISO/TC215
及び TC210 に依頼した結果、主に日本及び米国 FDA から、規制下にある医療機器のセキュリ
ティを重視する意見を含めて総計 194 件のコメントが寄せられた。
この意見募集において、米国は、「IEC 62443 シリーズ[46]は産業用制御システムに関するセキュリティ規格であり、ISA 規格としても広く利用されている。米国 FDA の認知規格でもあるが、患者安全を基本とする医療機器の規格にそのまま引用することはできない。」とコメントした。米国 FDA は、IEC/CD 80001-5-1 が非医療機器を含むヘルスソフトウェアに関する規格であることに理解を示しつつも、規制下にある医療機器を基本としてセキュリティ対応を構築すべきであると考えている。IEC 80001-5-1 は、この指摘を受けて医療機器のセキュリティに関する要求事項を取りまとめる方向に転換し、今後、米国 FDA メンバが制定作業に参加する予定である。また、現在の CD に記載されている個人情報に関する要求事項の取り扱いも今後の課題になると考えられる。

4.5 IEC/DTR 60601-4-5
独国提案の文書である IEC/DTR 60601-4-5 [47]には、CBOM に関する定義の記載がある。
IEC 62304 は SOUP の存在の特定と記録に留まっており、セキュリティフレームワークでないことから、SBOM が国際規格に採用された。2.6 項に記載したとおり、医療業界では SBOMに基づいたセキュリティマネジメントを行っているが、SBOM は製造販売業者から提供される
部品表管理としての使用目的のほか、SOUP 及びレガシー機器をマネジメントする共同責任者
として、ステークホルダ間における共通ツールとなることが期待される。

ー 47 ー

5. 国際協調に向けた課題
上述のとおり、医療機器サイバーセキュリティの原則と実践については、IMDRF において、
各国規制当局の同意のもとにガイダンスが作成された。加国や豪州においても、米国 FDA の市
販前及び市販後ガイダンスとの整合を図りつつ、規制整備が進行している。仏国は 2019 年に欧州発の規制を発表した。各国の規制におけるサイバーセキュリティに関する要求事項は一致しており、製造販売業者には米国 FDA ガイダンスを参考として設計開発段階におけるリスクの考え方を補強すると共に、サイバーセキュリティ対応に必要な情報を文書化する努力が求められる。製造販売業者に対する主な要求事項は以下のとおりである。
1） 製造販売業者が設計・開発、市販前に行うべき事項① 設計時からの検討と継続的な運用
・ 米 国 連 邦 情 報 セ キ ュ リ テ ィ マ ネ ジ メ ン ト 法 （ Federal Information Security
Management：FISMA）、NIST、国土安全保障省（Department of Homeland Security：
DHS）及び国防総省（Department of Defense：DoD）の動向の収集と考え方の習得
・ IMDRF、各国規制要求事項、ガイドラインの習得とリスクアセスメント
・ 製品セキュリティポリシー（ベースライン）及び製品セキュリティ要求事項の決定
・ 基本設計（リスクマネジメントと防御手段の確立）の計画と導入-

ホワイトリスト型プロテクトツールの導入及びブラックリスト型プロテクトツールによる保守方法の確立-

SOUP の特定（戦略的選択）及び管理とセキュリティ確保（SBOM、ユニークデバイ
ス識別（Unique Device Identification：UDI）等）-

セキュリティの評価手法・手段の確立と継続的運用（悪用可能性：CVSS、脆弱性検出ツール：Nessus、侵入試験等）-

添付資料（MDS2 を含む）、設計文書の作成② 体制構築・ 企業の情報システムセキュリティマネジメントの適用-製造所、事業所は ISO/IEC 27001（情報セキュリティマネジメントシステム）認証の取得

・ 製品セキュリティのための対応組織の設置と継続的運営
製品セキュリティインシデント対応体制（Product Security Incident Response Team：PSIRT）を活用する＜PSIRT の役割例＞-

セキュリティ情報の収集先の決定（JPCERT/CC、IPA 及びサプライヤ等）

ー 48 ー-

セキュリティ情報の収集・検知、発見された問題の分類・分析-

製品のセキュリティに関連する情報の提供-

医療施設を含む社内外の多様なステークホルダとの連携-

製品特性に合わせたインシデント対応方針の立案-

製品インシデントを発見するための手段・プロセスの保守

・ 情報共有を目的とした組織である ISAO への参加と活動（米国の場合）

2） 製造販売業者が市販後に行うべき事項① 販売・保守のための技術活動
・ 市販後監視-オープンソースを含む OTS ソフトウェアの脆弱性管理（PSIRT を活用する）-

サイバーセキュリティに関連するインシデント等のモニタリング（JPCERT/CC、IPA
及びサプライヤ等から収集する）

・ サイバーセキュリティに関する対応-

セキュリティの評価手法・手段の確立と継続的運用（悪用可能性：CVSS、脆弱性検出ツール：Nessus 及び侵入試験等）-

MDS2 の提供-

サイバーセキュリティ認定（Approval to Operate：ATO）の取得及び取得後の月次報
告-OS 等のプラットフォームの更新技術の開発・評価② 体制構築・ 製品セキュリティのための対応組織の設置と継続的運営-

オープンソースを含む OTS ソフトウェアの脆弱性管理のための契約管理-

GDPR に基づく標準契約条項（Standard Contractual Clauses：SCC）の締結（欧州の場合）-セキュリティ情報の収集・検知、発見された問題の分類・分析-

製品のセキュリティに関連する情報の提供-

医療施設を含む社内外の多様なステークホルダとの連携-

製品特性に合わせたインシデント対応方針の立案-

製品インシデントを発見するための手段・プロセスの保守

・ 情報共有を目的とした組織である ISAO への参加と活動（米国の場合）

ー 49 ー6. まとめ
米国 FDA は、サイバーセキュリティに関する市販前及び市販後ガイダンスを発行し、医療機器の製造販売業者に対してサイバーセキュリティ対応を求めている。加国や豪州も米国 FDA ガ
イダンスに追随した規制整備を進めている。欧州では、MDR 附属書 I の要求事項に IT セキ
ュリティが記載されており、適合性評価に関する欧州整合規格とすることも視野に入れて、IEC/ISO 80001-5-1 の策定作業が進められている。また、IEC 62304 で要求されている SOUPの管理をより効果的に行うため、SBOM を利用したソフトウェア資産管理の体制構築に向けた議論が進んでいる。一方、ISO 14971 の改正に伴って発行される ISO/TR 24971 では、リスクマネジメントの視点でサイバーセキュリティの考え方が提示される予定である。IMDRF では、
各国規制当局の同意のもとにガイダンスが作成された。
サイバーセキュリティに関する国際動向との整合を図るためには、現在、日本国内の指針となっている平成 30 年 7 月 24 日付薬生機審発 0724 第 1 号厚生労働省医薬・生活衛生局医療機器審査管理課長通知、薬生安発 0724 第 1 号厚生労働省医薬・生活衛生局医薬安全対策課長通知「医療機器におけるサイバーセキュリティの確保に関するガイダンスについて」の内容を見直す必要があると考えられる。

ー 50 ー

7. 参考文献[1]「医療機器のサイバーセキュリティの確保に関するガイダンス」（平成 30 年７月 24 日付
薬生機参発 0724 第 1 号・薬生安発 0724 第 1 号厚生労働省医薬・生活衛生局医療機器審査
管理課・医薬安全対策課長通知別添）[2]「医療機器サイバーセキュリティの原則及び実践」（Principles and Practices for Medical
Device Cybersecurity）[3]

NTIA Software Transparency https://www.ntia.doc.gov/SoftwareTransparency（2019年 9 月 11 日確認）

[4]

NTIA Multistakeholder Process on Software Component Transparency Standards andFormats Working Group Survey of Existing SBOM Formats and Standards Draft, Sept
3 2019[5]

NTIA Software Component Transparency: Healthcare Proof of Concept Report[6]

ISO 14971[7]

JIS T 14971[8]

IEC 80001[9]

ISO 13485[10] JIS Q 13485[11] ISO/IEC 27000[12] IEC 62304[13] JIS T 2304
[14] IEC 82304-1[15] JIS T 82304-1[16] STIG[17] UL CAP[18] CSF https://www.nist.gov/cyberframework[19] CVE https://cve.mitre.org[20] JVN https://jvn.jp[21] CVSS https://www.first.org/cvss/[22] CWSS https://cwe.mitre.org/cwss/cwss_v1.0.1.html[23] CWE https://cwe.mitre.org[24] CAPEC https://capec.mitre.org[25] FDA 市販前[26] FDA 市販後

ー 51 ー[27] TGA
[28] Health Canada[29] ANSM[30] IEC 62304[31] HIMMS MDS2 https://www.himss.org/resourcelibrary/MDS2[32] NEMAMDS2
https://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-Medic
al-Device-Security.aspx[33] ISO/IEC 19770-2[34] NISTIR 8060
[35] NVD https://nvd.nist.gov[36] CPE https://cpe.mitre.org[37] 欧州サイバーセキュリティ法（The EU Cybersecurity Act ）https://ec.europa.eu/digital-single-market/en/eu-cybersecurity-act[38] Postmarket Management of Cybersecurity in Medical Devices Final Guidance, IT and
Software,Specialty

Technical

Topics,

CDRH

Learn,

https://www.fda.gov/training-and-continuing-education/cdrh-learn（2019.9.12 確認）[39] GDPR
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.0
1.ENG&toc=OJ:L:2016:119:TOC[40] MDR https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L:2017:117:TOC[41] ISO/IEC Guide 51[42] AAMI TIR 57[43] ISO/TR 24971[44] IEC 62366[45] ISO 80001-5-1 WD[46] IEC 62443[47] IEC TR 60601-4-5 CD

ー 52 ーⅢ

IMDRF 最終文書

IMDRF/CYBER WG/N60 FINAL:2020

最終文書

タイトル:

医療機器サイバーセキュリティの原則及び実践

作成グループ: 医療機器サイバーセキュリティワーキンググループ
日付:

2020 年 3 月 18 日

Dr Choong May Ling, Mimi, IMDRF 議長

本文書は、国際医療機器規制当局フォーラムによって作成された。本文書の複製又は使用に関する制限はない。ただし、本文書の一部又は全てを他の文書に組み込む場合、並びに本文書を英語以外の言語に翻訳する場合、国際医療機器規制当局フォーラムは、その責任を一切負わない。
Copyright © 2020 by the International Medical Device Regulators Forumー 55 ーIMDRF/CYBER WG/N60FINAL:2020

目次

1.0

はじめに .............................................................................................................................. 5

2.0

適用範囲 .............................................................................................................................. 6

3.0

定義 ...................................................................................................................................... 7

4.0

一般原則 .............................................................................................................................. 94.1

国際整合 ........................................................................................................................ 10

4.2

製品ライフサイクルの全体 ........................................................................................ 10

4.3

共同責任 ........................................................................................................................ 10

4.4

情報共有 ........................................................................................................................ 105.0

医療機器サイバーセキュリティの市販前考慮事項 .................................................... 11

5.1

セキュリティ要求事項及びアーキテクチャ設計 .................................................... 11

5.2

TPLC に関するリスクマネジメント原則 .................................................................. 14

5.3

セキュリティ試験 ........................................................................................................ 17

5.4

TPLC サイバーセキュリティマネジメント計画 ...................................................... 17

5.5

ラベリング及び顧客向けセキュリティ文書 ............................................................ 18

5.5.1 ラベリング ................................................................................................................. 18
5.5.2 顧客向けセキュリティ文書 ..................................................................................... 18
5.6

規制当局への申請に関する文書 ................................................................................ 20

5.6.1 設計文書 ..................................................................................................................... 20
5.6.2 リスクマネジメント文書 ......................................................................................... 20
5.6.3 セキュリティ試験の文書 ......................................................................................... 20
5.6.4 TPLC サイバーセキュリティマネジメント計画に関する文書 .......................... 21
5.6.5 ラベリング及び顧客向けセキュリティ文書 ......................................................... 216.0

医療機器サイバーセキュリティの市販後考慮事項 .................................................... 21

6.1

意図する使用環境における機器の運用 .................................................................... 21

6.1.1 ヘルスケアプロバイダ及び患者 ............................................................................. 21
6.1.2 医療機器製造業者 ..................................................................................................... 23
6.2

情報共有 ........................................................................................................................ 23

6.2.1 重要原則 ..................................................................................................................... 23
6.2.2 重要な責任関係者 ..................................................................................................... 24
2020/3/18

Page 2 of 51

ー 56 ーIMDRF/CYBER WG/N60FINAL:2020

6.2.3 情報の種類 ................................................................................................................. 25
6.2.4 信頼できるコミュニケーション ............................................................................. 26
6.3

協調的な脆弱性の開示 ................................................................................................ 26

6.3.1 医療機器製造業者 ..................................................................................................... 26
6.3.2 規制当局 ..................................................................................................................... 28
6.3.3 脆弱性の発見者(セキュリティ研究者及びその他の脆弱性発見者を含む) ...... 28
6.4

脆弱性の修正 ................................................................................................................ 28

6.4.1 医療機器製造業者 ..................................................................................................... 28
6.4.2 ヘルスケアプロバイダ及び患者 ............................................................................. 31
6.4.3 規制当局 ..................................................................................................................... 34
6.5

インシデントへの対応 ................................................................................................ 36

6.5.1 医療機器製造業者 ..................................................................................................... 36
6.5.2 ヘルスケアプロバイダ ............................................................................................. 37
6.5.3 規制当局 ..................................................................................................................... 38
6.6

レガシー医療機器 ........................................................................................................ 38

6.6.1 医療機器製造業者 ..................................................................................................... 40
6.6.2 ヘルスケアプロバイダ ............................................................................................. 42
7.0

参考文献 ............................................................................................................................ 43

7.1

IMDRF 文書 ................................................................................................................... 43

7.2

規格 ................................................................................................................................ 43

7.3

規制当局のガイダンス ................................................................................................ 447.4

その他の資料及び参考文献 ........................................................................................ 45

8.0

附属書 ................................................................................................................................ 47

8.1

附属書 A: インシデント対応の役割(ISO/IEC 27035 から引用) .............................. 48

8.2

附属書 B: 協調的な脆弱性の開示に関する各地域のリソース ............................... 50

2020/3/18

Page 3 of 51

ー 57 ーIMDRF/CYBER WG/N60FINAL:2020

序文

本文書は、世界各国の医療機器規制当局の団体である国際医療機器規制当局フォーラム
(International Medical Device Regulators Forum: IMDRF)が協議の上、作成されたものである。本文書は、自由に複製、配布、使用して構わない。
ただし、本文書の一部又は全てを他の文書に組み込む場合、並びに本文書を英語以外の言語に翻訳する場合、IMDRFは、その責任を一切負わない。

2020/3/18

Page 4 of 51

ー 58 ーIMDRF/CYBER WG/N60FINAL:2020

1.0 はじめに無線、インターネット及びネットワーク接続機器の使用の増加に伴い、医療機器の機能及び安全性を確保するために有効なサイバーセキュリティの重要性が増している。サイバーセキュリティのインシデントは、医療機器及び病院ネットワークを使用不能にすると共に、ヘルスケア施設における患者ケアの提供を中断させてきた経緯がある。これらのインシデントは、診断及び治療介入の遅延、誤診断又は不適切な治療介入等の発生により、患者危害に至る可能性がある。
ヘルスケア製品の製造業者、ヘルスケアプロバイダ、ユーザ、並びに規制当局及び脆弱性報告者を含む全ての関係者は、医療機器のサイバーセキュリティに関して共同責任を有する。本ガイダンスは、全関係者へ向けて、サイバーセキュリティを積極的に支援するための役割に関する理解を促し、将来起こり得るサイバー攻撃、問題又は事象を予測して、医療機器を保護してセキュアにするための情報を提供することを意図している。
ヘルスケアのサイバーセキュリティの原則及び実践に関する国際整合は、患者安全及び医療機器の性能を確実に維持するために必要である。しかし、現時点における医療機器のサイバーセキュリティに係る規制は国毎に異なっており、国際整合に至っていない。
本 IMDRF ガイダンスは、医療機器のサイバーセキュリティに関する国際整合を図るための一般原則とベストプラクティスを提供することを目的とする。本文書では、適用範
囲及び用語をそれぞれ 2 項及び 3 項において定義する。4 項では、医療機器のサイバー
セキュリティの一般原則について概説し、5 項及び 6 項では、医療機器のサイバーセキ
ュリティに関する市販前管理及び市販後管理におけるベストプラクティスについて多くの推奨事項を責任関係者に提供する。市販前管理については、主に医療機器製造業者に言及する。市販後管理については、全ての責任関係者に向けた推奨事項を記載する。
本文書は、IMDRF が作成した医療機器のサイバーセキュリティに特化した最初のガイダンスであるが、セキュリティについて幅広く検討する上で参照すべき IMDRF 文書として「IMDRF/GRRP WG/N47 FINAL: 2018」が挙げられる。当該文書は、医療機器及び体外診断用（In Vitro Diagnostic：IVD）医療機器1の設計及び製造において充足すべき基
本要件基準を提供している。これらの基本要件基準は、医療機器の全ライフサイクル（Total Product Life Cycle：TPLC）に渡って、本ガイダンスと共に参照することが望ましい。その他の関連文書である「IMDRF/SaMD WG/N12 FINAL: 2014」の 9.3 項では、安全を考慮する際の情報セキュリティの重要性について記載されており、医療機器ソフトウェア（Software as Medical Device：SaMD）の情報セキュリティに影響する幾つかの要因がまとめられている。
1

N47 の 5.8 項には、不正アクセスからの保護等、情報セキュリティ及びサイバーセキュリティの重要な要求事項が記載されており、医療機器の全ライフサイクルに渡って、本ガイダンスと共に参照することが望ましい。

2020/3/18

Page 5 of 51

ー 59 ーIMDRF/CYBER WG/N60FINAL:2020

2.0 適用範囲
本文書は、全ての責任関係者に向けて、医療機器（IVD 医療機器を含む）のサイバーセ
キュリティに対する一般原則に係る基本的考え方と検討事項、並びに推奨されるベスト
プラクティスを提供することを目的として作成された。本文書では、製造業者、ヘルス
ケアプロバイダ、規制当局及びユーザに向けて、意図する目的に対して医療機器を使用する際に起こり得るサイバーセキュリティリスクを最小化することにより、医療機器の安全性及び性能を維持し、継続使用を確保するための具体的な推奨事項を取りまとめている。本ガイダンスで述べるヘルスケアプロバイダには、医療機関が含まれる。
本文書では、ファームウェア及びプログラマブルロジックコントローラ等のソフトウェ
アを有する医療機器（例：ペースメーカ、輸液ポンプ）、又はソフトウェア単独で存在する医療機器（例：SaMD）に関するサイバーセキュリティについて概説されている。
ほとんどの規制当局は、その権限が医療機器の安全性及び性能に限定されているため、本文書の適用範囲は、患者への危害が発生する可能性に関する検討に限定されていることに留意する必要がある。例えば、医療機器の性能に影響を与える、臨床活動に悪影響を及ぼす、若しくは誤った診断又は治療に繋がるサイバーセキュリティリスクは、本文書の適用範囲とみなされる。データプライバシーの侵害等、その他の危害も重要であるが、本文書では適用範囲から除外する。さらに、本文書では、製造業者の企業活動に関するサイバーセキュリティを適用範囲から除外する。製造業者の企業活動のセキュリテ
ィに関するベストプラクティスについては、米国国立標準技術研究所（National Instituteof Standard and Technology：NIST）のサイバーセキュリティフレームワークが情報源としての重要な役割を果たしている。
本文書は以下の事項を意図している。
• 医療機器の設計及び開発に適切なサイバーセキュリティ対応を組み込むために、リスクベースアプローチを採用する。
•

医療機器及び接続されるヘルスケアインフラの安全性、性能及びセキュリティを確保する。

•

サイバーセキュリティは、製造業者、ヘルスケアプロバイダ、ユーザ、規制当局及び脆弱性発見者等を含む全ての関係者の共同責任であることを認識する。

•

それらの関係者に対して、製品ライフサイクルの全体に渡り、患者危害のリスクを最小化するために有益な推奨事項を提供する。

•

用語を定義すると共に、医療機器のサイバーセキュリティを確保するため、現時点のベストプラクティスを記載する。

2020/3/18

Page 6 of 51

ー 60 ーIMDRF/CYBER WG/N60FINAL:2020•

サイバーセキュリティのインシデント、脅威及び脆弱性について、透明性を向上させ対応を強化するために幅広い情報共有のポリシーを促進する。

なお、医療機器の種類や各国の規制に応じて、追加の検討事項が必要となり得ることに留意する必要がある。

3.0 定義本文書で用いる用語及び定義は、以下に示した各規格、並びに IMDRF/GRRP WG/N47
FINAL: 2018 に準ずる。
3.1

資産（Asset)：個人、組織又は政府にとって価値のある、物理的又はデジタル形式のエンティティ（ISO/IEC JTC 1/SC 41 N0317, 2017-11-12）

3.2

攻撃（Attack）：資産の破壊、暴露、改ざん、無効化、盗用、又は認可されていな
いアクセス若しくは使用の試み（ISO/IEC 27000:2018）

3.3

認 証 （ Authentication ） ： エ ン テ ィ テ ィ の 特 性 の 正 当 性 に 関 す る 保 証 の 提 供（ISO/IEC 27000:2018）

3.4

真正性（Authenticity）：エンティティの信憑性（ISO/IEC 27000:2018）

3.5

権限付与（Authorization）：特権の付与。データ及び機能にアクセスするための特権を付与することを含む。（SO 27789:2013）
注記：ISO 7498-2 の定義（権利の付与。アクセス権に基づきアクセスの権利を付与することを含める）に由来する。

3.6

可用性（Availability）：要求するエンティティへのアクセス及び使用の可能性（ISO/IEC 27000:2018）

3.7

補 完 的 リ ス ク コ ン ト ロ ー ル 手 段 （ 補 完 的 手 段 ） （ Compensating Risk Control
Measure (Compensating Control)）：機器設計の一部として実施されるリスクコント
ロール手段の代替として、又はそれが実施されない場合に適用される特定のリス
クコントロール手段（AAMI TIR97:2019）
注記:補完的リスクコントロール手段としては、製造業者が提供するアップデート
等、永続的又は一時的な対応があり得る。

3.8

機密性（Confidentiality）：認可されていない個人、エンティティ又はプロセスに対して、情報を開示せず、使用させない特性（ISO/IEC 27000:2018）2020/3/18

Page 7 of 51

ー 61 ーIMDRF/CYBER WG/N60FINAL:2020

3.9

協調的な脆弱性の開示（Coordinated Vulnerability Disclosure：CVD）：研究者及びその他の責任関係者が、脆弱性の開示に関連するリスクを低減するための解決策を見つけるために製造業者と協力して行うプロセス（AAMI TIR97:2019）
注記:このプロセスには、脆弱性とその解決策に関する情報の報告、調整、開示等の作業が含まれる。

3.10 サイバーセキュリティ：情報及びシステムが不正な活動（不正なアクセス、使用、開示、中断、改変、破壊等）から保護されており、機密性、完全性、可用性に関するリスクがライフサイクル全体に渡って受容可能なレベルに維持されている状態。（ISO 81001-1）
3.11 製品寿命終了（End of Life：EOL）：製品のライフサイクルにおいて、製造業者の定義に基づき有効期間を超えた製品の販売を終了する時点。EOL を迎えた製品については、正式な EOL プロセス（ユーザへの通知等）が実施される。
3.12 サポート終了（End of Support：EOS）：製品のライフサイクルにおいて、製造業
者が全てのサポート活動を中止する時点。サービスサポートは、この時点を超えない。
3.13 基本性能：基礎安全に関連する以外の臨床機能の性能において、製造業者の指定した限界を超えた低下又は欠如が生じた時に受容できないリスクを生じる性能（IEC 60601-1:2005+AMD1:2012）3.14 悪用（Exploit）：脆弱性を通じて情報システムのセキュリティを侵害するための明確な方法（ISO/IEC 27039:2015）
3.15 完全性（Integrity）：:データが作成、送信又は保存された後、不正な方法により変更されていない特性（SO/IEC 29167-19:2016）
3.16 レガシー医療機器（レガシー機器）（Legacy Medical Device (Legacy Device)）：現在のサイバーセキュリティの脅威に対して合理的に保護できない医療機器
3.17 否認防止（Non-Repudiation）：発生した事象又は行動、並びにそれらを引き起こしたエンティティを証明する能力（ISO/IEC 27000:2018）3.18 患者危害（Patient Harm）：患者の受ける身体的傷害又は健康障害(ISO/IEC Guide
51:2014 を一部変更)
3.19 プライバシー（Privacy）：個人に関するデータの過度又は違法な収集及び使用に起因する私生活又は個人的事柄に対する侵入がないこと（ISO/TS 27799:2009）2020/3/18

Page 8 of 51

ー 62 ーIMDRF/CYBER WG/N60FINAL:2020

3.20 脅威（Threat）：セキュリティを侵害し、危害を引き起こし得る状況、能力、行動
又は事象が存在する際のセキュリティ違反の可能性（ISO/IEC Guide 120）
3.21 脅威モデリング（Threat Modeling）：データの破壊、漏洩、改ざん又はサービス拒否の形でシステムに危害を及ぼす可能性のある状況又は事象を明らかにするための調査プロセス（ISO/IEC/IEEE 24765-2017 から変更）
3.22 アップデート（Update）：医療機器ソフトウェアを対象とした修正、予防、適応又は完全化に関する変更
注記 1: ISO/IEC 14764:2006 に規定するソフトウェア保守活動に由来する。
注記 2: アップデートには、パッチ及び設定変更が含まれる。
注記 3: 適応及び完全化に関する変更は設計仕様時になかったソフトウェアの改良である。
3.23 バリデーション（Validation）：客観的証拠を提示することによって、意図する使用 又 は 適 用 に 関 す る 要 求 事 項 が 満 た さ れ て い る こ と を 確 認 す る こ と （ ISO
9000:2015）
注記 1: "バリデート済み"とは、バリデーションが完了している状態を示す。
注記 2: バリデーションは、実環境又は模擬環境で実施される。
3.24 検証（Verification）：客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること（ISO/IEC Guide 63）
注記 1: 検証のために必要な客観的証拠としては、検査結果のほか、別法による計算又は文書のレビュー等の結果であることがある。
注記 2: 検証のために行われる活動は、適格性プロセスと呼ばれることがある。
注記 3: "検証済み"とは、検証が完了している状態を示す。
3.25 脆弱性（Vulnerability）：一つ以上の脅威によって悪用される可能性のある資産又は管理策の弱点（ISO/IEC 27000:2018）

4.0 一般原則
本項では、医療機器を開発、規制、使用、監視する際に責任関係者が検討すべき、医療機器のサイバーセキュリティに関する一般指針原則を示す。本ガイダンスの全体を通して述べられている当該原則は、医療機器の全体的なサイバーセキュリティを向上させる
2020/3/18

Page 9 of 51

ー 63 ーIMDRF/CYBER WG/N60FINAL:2020

ために重要であり、これに従うことで、患者の安全を確保する上で有益な効果を得られることが期待される。
4.1

国際整合

医療機器のサイバーセキュリティは、国際的に注目されている。セキュリティのインシ
デントは、診断若しくは治療の過失を引き起こす、機器の安全な性能を脅かす、臨床活動に影響を与える、患者の救急救命の利用を妨げること等によって、世界中のヘルスケ
アシステムの患者安全を脅かす可能性がある。サイバーセキュリティに対する取り組みの国際的整合は、イノベーションを促進し、安全で効果的な医療機器を遅滞なく患者の治療に使用可能とすると共に、患者安全の維持を確保するために必要である。全ての責
任関係者は、医療機器の全ライフサイクルに渡ったサイバーセキュリティ対応を国際整合させることが奨励される。これには、製品設計、医療機器の全ライフサイクルを通したリスクマネジメント、医療機器のラベリング、規制当局への申請に対する要求事項、情報共有、市販後活動に関する整合化が含まれる。
4.2

製品ライフサイクルの全体

サイバーセキュリティの脅威及び脆弱性に関するリスクは、初期構想段階から EOS に至る、医療機器の製品寿命に関する全ての段階を通して検討することが望ましい。サイバーセキュリティの動的特性を効果的に管理するためには、リスクマネジメントを製品の全ライフサイクルに渡って適用し、設計、製造、試験及び市販後監視等の各過程においてサイバーセキュリティリスクを評価及び緩和することが望ましい。
安全性とセキュリティとのバランスを図ることも必要である。製造業者は、サイバーセ
キュリティのコントロール及び緩和策を組み込む際、医療機器の安全性及び基本性能を維持することが重要である。
4.3

共同責任

医療機器のサイバーセキュリティは、製造業者、ヘルスケアプロバイダ、規制当局及び脆弱性発見者の共同責任である。全ての責任関係者は、医療機器の全ライフサイクルを通して、潜在的なサイバーセキュリティリスク及び脅威を継続的に監視、評価、緩和、情報共有、対応するため、自らの責任を理解し、他の責任関係者と密接に連携する必要
がある。
4.4

情報共有

サイバーセキュリティに関する情報の共有は、安全でセキュアな医療機器を実現するための TPLC アプローチの基礎原則である。サイバーセキュリティの情報を共有するため、全ての責任関係者が、市販前及び市販後に積極的に対応することが奨励される。遅滞なく情報が共有されることによって、全ての責任当事者が、脅威を特定し、関連するリス
クを評価し、それに適宜対応するための能力が最大化する。その一環として、全ての責
任関係者は、医療機器及び接続するヘルスケアインフラの安全性、性能、完全性及びセ2020/3/18

Page 10 of 51

ー 64 ーIMDRF/CYBER WG/N60FINAL:2020

キュリティに影響し得るサイバーセキュリティのインシデント、脅威及び脆弱性に対する 協 力 及 び コ ミ ュ ニ ケ ー シ ョ ン を 強 化 す る た め 、 情 報 共 有 分 析 機 関 （ Information
Sharing Analysis Organizations：ISAOs）に積極的に参加することが奨励される。このよ
うな取り組みを行うことで、透明性を向上させることができる。ベストプラクティスとして奨励されるもう一つの情報共有手法として、協調的な脆弱性の開示が挙げられる。
また、製造業者のみでなくヘルスケアプロバイダ及び医療機器ユーザにも当該ポリシーを適用することは、エコシステムにとっても有益となり得る。規制当局には、患者安全を国際的に保護し、維持するために、海外の規制当局と情報共有することが奨励される。

5.0 医療機器サイバーセキュリティの市販前考慮事項
医療機器のサイバーセキュリティは、製品の全ライフサイクルに渡って検討することが望ましく、製造業者が医療機器の市販前の設計段階及び開発中に対応すべき重要な要素がある。市販前の要素には、1) セキュリティ機能を製品に組み込むこと、2) 受容できるリスクマネジメント手法を適用すること、3) セキュリティ試験、医療機器をセキュアに運用するためのユーザに対する有益な情報提供及び市販後活動のための計画を立案することが含まれる。製造業者は、前述の市販前要素を検討する際、意図したとおりの利用環境に加え、合理的に予見可能な誤使用のシナリオを検討することが望ましい。以
下の各項では、これらの概念を概説すると共に、製品ライフサイクルの市販前段階における製造業者への推奨事項を例示する。なお、医療機器ソフトウェアのライフサイクル
活動は、 IEC 62304:2006/AMD 1:2015 に規定されている。
5.1

セキュリティ要求事項及びアーキテクチャ設計

脅威モデリング等、設計段階でサイバーセキュリティに積極的に対応することによって、受動的な市販後活動のみを行うよりも患者危害の可能性をより緩和することが可能である。このような設計インプットは、要求事項の捕捉、設計検証試験又は市販前及び市販後のリスクマネジメント対応等、製品のライフサイクルを通した様々な段階において実施される。
セキュリティ要求事項も、ライフサイクルの設計プロセスの要求事項取得の段階で特定することが望ましい。セキュリティ要求事項及びセキュリティリスクコントロール手段の情報源としては、AAMI TIR 57:2016、IEC TR 80001-2-2、IEC TR 80001-2-8、ISO
27000 シリーズ、NIST 刊行物（セキュアソフトウェア開発フレームワーク（Secure
Software Development Framework：SSDF）等）、OWASP 刊行物（設計原則に基づくセキ ュ リ テ ィ 等 ） 、 ENISA 刊 行 物 、 米 国 ヘ ル ス ケ ア 及 び 公 衆 衛 生 分 野 協 調 協 議 会（Healthcare and Public Health Sector Coordinating Council：HSCC）合同サイバーセキュ
リティワーキンググループ（Joint Cyber Security Working Group：JCWG）の刊行物（合同セキュリティ計画等）等がある。
製造業者が自社製品の設計で考慮することが望ましい設計原則を表 1 に示した。但し、
表 1 は完全なリストを意味するものではなく、あくまでも例示である。
2020/3/18

Page 11 of 51

ー 65 ーIMDRF/CYBER WG/N60FINAL:2020

設計原則

セキュアな通信

データ保護

機器の完全性

ユーザの認証説明
製造業者は、医療機器が併用機器又はネットワークと接続される方式について検討することが望ましい。接続方式には、
有線接続及び無線通信が含まれる。接続方式の例としては、
Wi-Fi、イーサネット、bluetooth、USB 等が挙げられる。
製造業者は、外部からの入力のみでなく、全ての入力の検証
機能を設計することについて検討し、安全性が低い通信以外サポートされていない医療機器や、家庭内ネットワーク又はレガシー医療機器と接続して通信する等、外部環境と通信す
る場合を考慮することが望ましい。
製造業者は、医療機器の送受信データ転送を不正アクセス、
不正な改変又は反射攻撃から保護する手法について検討する
ことが望ましい。例えば、製造業者は医療機器/システム間通信の相互認証方法、暗号化の要否、既に送信されたコマン
ド又はデータの不正再送を防ぐ方法、予め定めた時間設定後に通信を切断する適切性等について検討することが望ましい。
製造業者は、医療機器に保存される又は送受信される安全性
関連データを暗号化等により保護する要否について検討する
ことが望ましい。例えば、パスワードは暗号化によって保護されたハッシュとして保存することが望ましい。
製造業者は、通信プロトコルのメッセージ制御、シーケンス
領域を保護するため又は暗号鍵材料の内容が漏洩することを防ぐために、機密性に係るリスクコントロール手段の要否について検討することが望ましい。
製造業者は、データの否認防止を確保できる設計特性の要否を判断するために、監査ログ機能のサポート等、システムレ
ベルのアーキテクチャを評価することが望ましい。
製造業者は、機器のソフトウェアに対する不正な改変等、医療機器の完全性に関するリスクについて検討することが望ましい。
製造業者は、ウイルス、スパイウェア、ランサムウェア及びその他の悪意のあるコードが医療機器で実行されることを防
ぐため、マルウェア対策等のコントロールについて検討する
ことが望ましい。
製造業者は、医療機器の使用者の検証、様々なユーザの役割に応じたアクセス権付与又は緊急時のアクセス許可等、ユー
ザのアクセス制御について検討することが望ましい。また、複数の医療機器や顧客の間で同じ認証情報を共有しないことが望ましい。認証又はアクセス許可の例としては、パスワー
ド、ハードウェアキー、生体認証又は他の医療機器では生成

2020/3/18

Page 12 of 51

ー 66 ーIMDRF/CYBER WG/N60FINAL:2020

ソフトウェア保守

物理的アクセス

信頼性及び可用性

表 1.

できない認証信号等がある。
製造業者は、定期的なアップデートの実施プロセスと展開プ
ロセスを確立し、その情報を共有することが望ましい。
製造業者は、オペレーティングシステム、サードパーティ又はオープンソースのソフトウェアのアップデート手法及び管理方法について検討することが望ましい。また、製造業者
は、ソフトウェアのアップデートや、安全でないバージョンのオペレーティングシステム上で動作する医療機器ソフトウ
ェア等、管理対象外となった古いオペレーティングシステム
環境への対処方法計画を立案することが望ましい。
製造業者は、新たに発見されたサイバーセキュリティの脆弱性に対してセキュアであるために、医療機器のアップデート
手法について検討することが望ましい。例えば、アップデー
トにおけるユーザ介入の要否、医療機器による自動アップデートの要否、アップデートが医療機器の安全性と性能に悪影響を及ぼさないことを検証する方法等に関する検討が含まれる。
製造業者は、アップデートを実施するために必要な接続について検討すると共に、コードの署名等の方法を用いて接続又はアップデートの真正性を保証する方法について検討することが望ましい。
製造業者は、未許可者による医療機器へのアクセスを防止す
る手法について検討することが望ましい。例えば、ポートを物理的にロックする、ポートへのアクセスを物理的に制限す
る又は必要な認証なしに物理ケーブルを用いたアクセスを禁止する等の手法を検討することが望ましい。
製造業者は、医療機器の基本性能を維持するため、サイバー
セキュリティ攻撃を検出、防御、対応及び復旧する設計特性について検討することが望ましい。
医療機器の設計における検討事項に対する設計原則

セキュアな開発の原則は、セキュアな機器設計にとって必要不可欠である。現在の多くのソフトウェア開発ライフサイクルモデル又は関連規格は、この原則をはじめから組み込んでいるわけではない。医療機器ソフトウェアを開発する製造業者は、自社のソフト
ウェア開発にセキュリティの原則を組み込むことが重要である。製造業者には、製品の全ライフサイクルを通してリスク及び緩和策を評価することで、製品のサイバーセキュ
リティに関する全体的な対応が求められる。

2020/3/18

Page 13 of 51

ー 67 ーIMDRF/CYBER WG/N60FINAL:2020

5.2

TPLC に関するリスクマネジメント原則

セキュリティと安全性に関する健全なリスクマネジメント原則が、医療機器のライフサ
イクルを通して組み込まれていることが望ましい。医療機器の安全性と基本性能又は臨
床活動に影響を及ぼす、若しくは誤った診断又は治療に繋がるサイバーセキュリティリ
スクについても、リスクマネジメントプロセスにおいて検討されることが望ましい。製造業者は、ISO 14971:2019 に規定されているリスクマネジメント及び AAMI TIR57:2016
や AAMI TIR97:2019 等で規定されているサイバーセキュリティリスクマネジメントを使用して、リスクマネジメントプロセスの一環として以下のステップを踏むことが望ま
しい。
•
•
•
•
•

サイバーセキュリティの脆弱性を特定する
関連するリスクを推定し、評価するリスクを受容可能なレベルまでコントロールする
リスクコントロールの有効性を評価・監視する
重要な責任関係者に対する協調的な情報開示を通じて、リスクに関する情報を提供する

セキュリティリスクマネジメントプロセスを図 1 に示した（AAMI TIR57:2016 から引用）。これは、全体的なリスクマネジメントの一部を構成するリスクマネジメントプロ
セスとして実施できると共に、脆弱性、脅威及びその他のセキュリティ関連用語を対応させて、ISO 14971:2019 のリスクマネジメントプロセスに組み込むこともできる。対応付けについては ISO/TR 24971:2020 の附属書 F を参照すること。

2020/3/18

Page 14 of 51

ー 68 ーIMDRF/CYBER WG/N60FINAL:2020••

医療機器の意図する使用及び医療機器のセキュリ
ティに関する特質の明確化
脅威、脆弱性、資産、悪影響の特定該当する脅威と脆弱性の組み合わせに関するリス
クの推定

セキュリティリスク評価

セキュリティリスクコントロール
•
•
•
•
•
•

セキュリティリスクコントロー
ル手段の選択セキュリティリスクコントロー
ル手段の実施
残留リスクの評価
リスク・ベネフィットの分析
リスクコントロール手段によって生じるリスクリスクコントロールの完了

セキュリティリスクマネジメント•

セキュリティリスクアセスメント

セキュリティリスク分析

全体的な残留セキュリティリスクの受容可能性評価

セキュリティリスク
マネジメント報告書

製造及び製造後の情報

図 1.

セキュリティリスクマネジメントプロセスの図解(AAMI TIR57:2016 から許可を得て引用)

医療機器の規制に関するサイバーセキュリティのリスク分析は、サイバーセキュリティの脆弱性の悪用可能性、脆弱性が悪用された場合の患者危害の重大さを考慮して、患者危害のリスク評価に注力することが望ましい。この分析においては、補完的対策及びリ
スク緩和策についても検討することが望ましい。
リスク評価においては、設計を脅威モデリング、患者危害、緩和策及び検証試験と連結することにより、リスクが適切にマネジメントされるセキュアな設計アーキテクチャを確立することが重要である。この評価では、セキュリティリスク評価、脅威モデリング
及び脆弱性スコアリングやその他の手法等、様々なツール及びアプローチが利用できる。

2020/3/18

Page 15 of 51

ー 69 ーIMDRF/CYBER WG/N60FINAL:2020•

セキュリティリスクアセスメント：製造業者は、製品の全ライフサイクルを通して、サイバーセキュリティリスク、脅威及び対応について検討することが望ましい。特定されたハザードに対する緩和策の場合、サイバーセキュリティの要求事
項は、可能な限り、特定の医療機器のサイバーセキュリティの脅威及び脆弱性と相互参照することが望ましい。

•

脅威モデリング：脅威モデリングは、医療機器やシステムにおける潜在的な脅威によるリスクを特定、列挙、緩和するプロセスである。特に、脅威モデリングには、システムコンポーネント等のサプライチェーンに関連するリスクや、設計、製造、病院環境等への展開、保守に関連するリスク等の検討が含まれる。詳細なシステム設計図の作成は、サイバーセキュリティの設計要素を医療機器に組み込む手法を理解するために有益であると共に、脅威モデリングにとっても有用である。製造業者は、脅威モデルを作成する際、OWASP のガイダンスに基づいて、
サイバーセキュリティに関する基本的な 4 つの質問に対する回答について検討することが望ましい。
1) 何を構築しようとしているのか？
2) どのような問題が発生し得るか（どのような攻撃を受ける可能性があるか）？
3) その問題に対してどのように対処するか？
4) 十分な対策を行ったか？

•

必要に応じて、アプリケーションアーキテクチャ、運用データフロー又はより広範囲なシステムレベルの脅威モデリングのコンテキストにおいて、これらの質問を行うこと。医療機器に発生し得る問題を脅威モデリングにおいて判断する場合、製造業者は、ソフトウェア及びハードウェアに対する故意でない誤設定又はイン
ターネットに接続するよう設計されていない医療機器をインターネットに接続する等の悪意のある誤設定を考慮することが望ましい。

•

脆弱性スコアリング： 脆弱性スコアリングは、サイバーセキュリティ脆弱性の悪用可能性及び重大さを明確化して評価する方法である。設計開発において特定される既知の一般的脆弱性曝露（Common Vulnerabilities and Exposures：CVE）
については、共通脆弱性スコアリングシステム（Common Vulnerability Scoring
System：CVSS）又は今後広く採用される可能性が高い脆弱性スコアリングシス
テム等の一貫性のある脆弱性スコアリングの方法を用いて分析・評価することが望ましい。サイバーセキュリティリスク、脆弱性スコアリング及びコントロール
手段は新製品の脅威モデリング及びセキュリティリスクアセスメント、並びに故障モード影響解析（Failure Mode and Effects Analysis：FMEA）等、サイバーセキ
ュリティに特化していない他のリスク評価ツールに対して情報を提供するために使用される可能性がある。

2020/3/18

Page 16 of 51

ー 70 ーIMDRF/CYBER WG/N60FINAL:2020

既存の ISO 14971:2019 リスクマネジメントプロセスにセキュリティリスクマネジメン
トプロセスを組み込む場合、脅威モデリングや脆弱性スコアリング等のセキュリティ対応を考慮することが望ましい。
5.3

セキュリティ試験

製造業者は、設計開発プロセスの検証及びバリデーションの段階において様々な種類のセキュリティ試験を採用することにより、重大な既知の脆弱性がコードに含まれていな
いことを証明すると共に、セキュリティコントロールが効果的に実施されていることを証明することが望ましい。当該試験では、医療機器が使用される状況、並びに医療機器がその他の機器又はネットワークに接続される環境を考慮することが望ましい。ソフト
ウェアの仕様適合性を確保し、異常を最小化するために、ソフトウェアの検証技術を適用することが推奨される。医療機器が、悪用され得る既知の脆弱性に対して検証済みであることを明確化することも重要である。これを行うために、ソフトウェア試験や攻撃
シミュレーション等、セキュリティ評価プロセス又は受入確認を対象となる医療機器に適用することが望ましい。セキュリティ試験とは、セキュアな開発フレームワークを構成するコンポーネントの一つである。試験に関する検討事項の詳細は、5.1 項に示す規格及び情報源を参照すると良い。製造業者が考慮すべき上位レベルの考慮事項を以下に例示する。
•

開発時においても、既知の脆弱性又はソフトウェアの弱点について、ソフトウェア
コンポーネントとモジュールのターゲット検索を実施する。定期的なセキュリティ試験としては、静的コード解析、動的解析、堅牢性試験、脆弱性スキャン、ソフト
ウェアコンポジション解析等が挙げられる。

•

侵入テスト等の技術的なセキュリティ分析を実施する。技術的なセキュリティ分析
としては、ファズテスト等を用いた未知の脆弱性の特定又は隠しファイル、設定、データストリーム、若しくはハードウェアのレジスタの読み出し等による代替エン
トリポイントのチェック等が挙げられる。

•

脆弱性評価を行う。脆弱性評価としては、バリアント解析等、自社の他製品に対する脆弱性の影響分析、対抗手段の特定、脆弱性の修正又は緩和等が挙げられる。

5.4

TPLC サイバーセキュリティマネジメント計画

サイバーセキュリティの脅威が継続的に進化している中、製造業者は、製品ライフサイ
クルの全体を通じたサイバーセキュリティマネジメント計画の一環として、脆弱性及び悪用を積極的に監視、特定、対応することが望ましい。製品開発の市販前段階で計画を作成することが望ましい。また、理想的には、製造業者の組織全体でその計画を維持することが望ましい。この計画では以下に示した項目を取り扱う。
•

TPLC を通じた監視：新たに発見されたサイバーセキュリティの脆弱性を積極的に監視・特定すると共に、その脅威を評価して適切に対応するための計画

2020/3/18

Page 17 of 51

ー 71 ーIMDRF/CYBER WG/N60FINAL:2020•

脆弱性の開示：脆弱性発見者からの情報を集約した上で、緩和及び修正策を開発し、脆弱性の存在及び緩和又は修正方法を責任関係者に開示するための正式なプロセス•

アップデート及び脆弱性の修正：医療機器の安全性及び性能を継続的に維持するた
めの、定期的な、若しくは特定された脆弱性に対するソフトウェアのアップデート
又は修正作業の実施•

復旧：製造業者、ユーザのいずれか又は両者が、サイバーセキュリティのインシデント後に、医療機器を通常の運用状態に戻すための復旧計画•

情報共有：セキュリティの脅威及び脆弱性に関する更新した情報を共有する ISAO
又は情報共有分析センター（Information Sharing and Analysis Centers：ISAC）への参加

5.5

ラベリング及び顧客向けセキュリティ文書

5.5.1

ラベリング

ラベリングは、関連するサイバーセキュリティリスクを考慮して該当するセキュリティ
情報をエンドユーザに伝達するものである。ラベリングには、以下に示した項目を含めることが望ましい。
•

アンチマルウェアソフトウェア、ネットワーク接続設定、ファイアウォールの使用
等、意図する使用環境に適した推奨されるサイバーセキュリティコントロールに関連する医療機器の使用方法及び製品仕様•

正常な機能を回復するための、バックアップ並びに復元の機能及び手順の説明•

データを送受信するネットワークポート及びその他のインタフェースのリスト、並びにポート機能、着信・発信ポートの説明。但し、未使用ポートは無効化することが望ましいことに留意する。

•

エンドユーザ向けの詳細なシステム構成図

5.5.2

顧客向けセキュリティ文書

取扱説明書に加えて、製造業者が提供する医療機器のインストール及び設定に係る技術文書、並びに運用環境のための技術的要求事項は、ユーザが医療機器を安全でセキュアに使用する上で特に重要である。顧客向けセキュリティ文書については、以下に示した項目を含めることが望ましい。
•

意図したとおりの医療機器の動作を確保するための、支援インフラの要求事項に関するユーザへの具体的なガイダンス

2020/3/18

Page 18 of 51

ー 72 ーIMDRF/CYBER WG/N60FINAL:2020•

セキュアな設定を用いた機器の強化あるいは強化可能性に関する説明。セキュアな設定とはマルウェア対策、ファイアウォール/ファイアウォール規則、ホワイトリスト、セキュリティイベントパラメータ、ロギングパラメータ、物理的セキュリティ
検出等のエンドポイント保護を含む。

•

必要に応じて、セキュアなネットワーク接続の展開及びサービスを可能にするための技術的指示、並びにサイバーセキュリティ脆弱性又はインシデントが検知された際の対応方法に関するユーザへの指示•

セキュリティ事象が検出された場合に、医療機器又は支援システムがユーザに異常を通知する方法に関する説明。セキュリティ事象の種類としては、設定変更、ネッ
トワーク異常、ログイン試行、未知のエンティティに対する要求送信等の異常トラ
フィックが挙げられる。

•

認証された特権ユーザが、医療機器の設定を保存し、回復するための方法の説明•許可されたユーザが、製造業者からアップデートをダウンロードしてインストールするための体系的な手順の説明。必要に応じて、セキュリティ設定又は使用環境を変更することで生じるセキュリティリスクとその影響についても説明する。

•

医療機器のサイバーセキュリティサポート終了に関する情報（6.6 項「レガシー医療機器」参照）•

医療機器に実装される商用、オープンソース及び市販のソフトウェア部品のサイバ
ーセキュリティに関する情報及びサポートをオペレータに提供するためのソフトウ
ェア部品表（Software Bill of Materials：SBOM）。名前、作成元、バージョン、ビル
ド番号によって各ソフトウェア部品が特定されるため、SBOM を使用することで、必要とされる透明性が確保される。SBOM は、患者及びヘルスケアプロバイダを含む医療機器のオペレータが、その資産及び関連するリスクを効果的に管理し、医療機器及び接続されるシステムに対して特定された脆弱性の潜在的影響を理解し、医療機器の安全性及び基本性能を維持するための対応を可能にする。医療機器のオペ
レータは、SBOM を使用することにより、脆弱性が潜んでいる可能性があるソフト
ウェアの特定、要件の更新及び適切なセキュリティリスクマネジメントの実施を医療機器製造業者と協力して促進することができる。SBOM を使用することにより、
アプリケーションで使用されているコンポーネントを可視化して顧客に提示できると共に、潜在的セキュリティリスクを特定できるため、購入決定に必要な情報を提供することが可能となる。製造業者は、SBOM の展開で使用される形式、構文、マークアップに関する業界のベストプラクティスを活用することが望ましい。SBOMによって医療機器に関する機密情報が公開されるため、信頼できるコミュニケーシ
ョンチャネルを通じて SBOM を配布することが奨励される。オペレータへの SBOM
配布方法の信頼性は製造業者が決定する。

2020/3/18

Page 19 of 51

ー 73 ーIMDRF/CYBER WG/N60FINAL:2020

5.6

規制当局への申請に関する文書

製造業者は、上項に概説した対応に加えて、サイバーセキュリティに関する自社の活動を明確に文書化し、要約することが望ましい。規制当局は、医療機器のクラス分類に応じて、サイバーセキュリティ対応に関する文書を市販前又は市販後の段階で要求する可能性がある。規制当局が市販前承認のためにサイバーセキュリティ文書を要求する場合、製造業者は、サイバーセキュリティに関連して、医療機器の設計機能、リスクマネジメ
ント活動、検証試験、ラベリング及び製品の全ライフサイクルに渡って新たに発生する脅威を監視し、対応するための計画の根拠を明確に記載した文書を提出することが望ましい。これらの詳細については、下項で説明する。
5.6.1 設計文書
全てのインタフェース又は通信経路又はコンポーネント（ハードウェア及びソフトウェア）、患者危害に関するサイバーセキュリティのリスクを緩和するために、アクセスコ
ントロール、暗号化、セキュアなアップデート、ログ機能、物理的セキュリティ等に関する対策を選択した根拠及び推定を中心として、5.1 項で概説した全ての設計機能を記載した文書である。
5.6.2

リスクマネジメント文書

サイバーセキュリティの脅威及び脆弱性、関連するリスクの推定、リスクを緩和するために行うリスクコントロール、並びにリスクコントロールが適切に検証されたことを示す根拠を明確に説明する文書である。製造業者は、その他の安全性に過度な影響を与えることなく、医療機器のサイバーセキュリティを最大化するリスクコントロールについて検討することが望ましい。特に、規制当局に提出するサイバーセキュリティに関連するリスクマネジメント文書では、明確な説明を心掛けると共に、リスクマネジメント規格（AAMI TIR57:2016、AAMI TIR97:2019 等）をガイダンスとして利用することが望ましい。この成果文書を全体的なリスクマネジメントの入力として利用できるように、
ISO 14971:2019 で規定されている全体的な要件に従って成果文書を作成することが望ましい。サイバーセキュリティに関するリスクマネジメント文書には、以下のような文書がある。
•

リスクマネジメント報告書やセキュリティリスクマネジメント報告書等の包括的なリスクマネジメント文書。これらの文書には、脅威モデリング及び特定されたサイバーセキュリティの脅威について記載することが望ましい。

•

その他のリスクマネジメントに与えるセキュリティリスク緩和策の影響に関する考
察

5.6.3

セキュリティ試験の文書

医療機器のセキュリティ及び全てのセキュリティコントロールの有効性を検証するために実施した全ての試験を要約した試験報告書である。 5.3 項に記載したソフトウェアコ
2020/3/18

Page 20 of 51

ー 74 ーIMDRF/CYBER WG/N60FINAL:2020

ンポーネント又はサブシステムと既知の脆弱性データベースとの相互参照等、特定の試験に係る詳細のほか、試験報告書には、以下の事項を記載することが望ましい。
•

試験方法、結果及び結論の説明•

セキュリティリスク、セキュリティコントロール、並びにセキュリティコントロー
ルの検証試験のトレーサビリティマトリクス•使用した規格及び内部 SOP/文書の参照

5.6.4

TPLC サイバーセキュリティマネジメント計画に関する文書

医療機器の全ライフサイクルを通して安全性及び性能を継続的に保証するための市販後プロセスに係る保守計画の要約である。5.4 項に記載したとおり、このプロセスとしては、TPLC 監視、計画的又は修正のためのアップデート、協調的な脆弱性の開示ポリシー及び情報共有が挙げられる。
5.6.5 ラベリング及び顧客向けセキュリティ文書
5.5 項において概説した医療機器の意図する使用環境下でユーザがリスクを効果的に管理するための関連情報を含む、サイバーセキュリティに関する全ての情報を収載したユーザ文書である。

6.0 医療機器サイバーセキュリティの市販後考慮事項
脆弱性は時間経過に伴って変化するため、市販前の設計段階で実施したセキュリティ対
応は、リスクが受容可能な状態を適切に維持できない可能性がある。そのため、様々な責任関係者がそれぞれの役割を果たす市販後のアプローチが必要になる。市販後アプロ
ーチは、意図する使用環境における医療機器の運用、情報共有、協調的な脆弱性の開示、
脆弱性の修正、インシデントへの対応及びレガシー医療機器等を含む様々な要素に及んでいる。製品のライフサイクルの市販後プロセスに関与する全ての責任関係者へ向けた推奨事項として、これらの要素について下項で概説する。
6.1

意図する使用環境における機器の運用

6.1.1

ヘルスケアプロバイダ及び患者

a. ヘルスケアプロバイダが採用すべきサイバーセキュリティのベストプラクティ
ス
医療機器のサイバーセキュリティは共同責任であり、ヘルスケアプロバイダを含む全ての責任関係者の参画が必要である。ヘルスケアプロバイダは、自身の IT インフラに接続される医療機器の安全性、性能及びサイバーセキュリティに対応するために、リスク

2020/3/18

Page 21 of 51

ー 75 ーIMDRF/CYBER WG/N60FINAL:2020

マネジメントプロセスの採用について検討することが望ましい。このプロセスは、以下のステージで適用することが望ましい。
•••

IT インフラの初期開発時
既存 IT ネットワークへの新規医療機器の統合時
アップデート又は改良によるオペレーティングシステム、IT ネットワーク又は医療機器自体のソフトウェア及びファームウェアの変更時

ヘルスケアプロバイダがこれらのリスクマネジメントプロセスを実行する上で、IEC
80001-1 及び ISO 31000、並びに ISO 27799 を中心とした ISO 27000 シリーズ等の関連規格が参考となる。「医療産業のサイバーセキュリティ手法：脅威の管理と患者の保護」
も、参考文書として利用できる。
ヘルスケアプロバイダは、リスクマネジメントシステムの採用に加え、全体的なセキュリティ体制を維持するために、以下に示した一般的なサイバーセキュリティのベストプ
ラクティスを導入することが望ましい。但し、以下は完全なリストを意味するものではなく、あくまでも例示である。
•

医療機器又はネットワークアクセスポイントへの不正アクセスを防ぐための優れた
物理的セキュリティ

•ネットワークの各要素、保存情報、サービス及びアプリケーションへの確実なアクセス制御手段(例:役割ベース)•

現在の全ての資産を特定し、将来的な構成の変更を追跡するための、構成管理方法の採用•

製造業者が推奨する設定及び保護対策の適用•

医療機器の通信を制限するネットワークアクセスコントロール•

確実且つ遅滞なくセキュリティアップデートを適用するためのマネジメント•

攻撃を予防するためのマルウェア対策•

無人状態で長時間放置されている医療機器に対する不正アクセスを防ぐためのセッ
ションタイムアウト

これらのベストプラクティスは、医療機器の臨床使用状況を考慮して実施することが望ましい。例えば、救急時等では、これらのベストプラクティスの幾つかの実施が難しい
可能性がある。上記の手法の多くは、NIST のサイバーセキュリティフレームワークに記載されている。

2020/3/18

Page 22 of 51

ー 76 ーIMDRF/CYBER WG/N60FINAL:2020

b. 全てのユーザに対するトレーニング/教育
ヘルスケアプロバイダは、施設内におけるサイバーセキュリティのインシデントの発生を防止するため、包括的に対応することが望ましい。そのため、医師、看護師、臨床工学技士、臨床検査技師等、全てのユーザのセキュリティに対する意識を高め、サイバー
衛生管理を習慣付けるための基本的なサイバーセキュリティトレーニングを提供することが推奨される。このようなトレーニングとしては、セキュアなネットワークのみへの接続等、医療機器のセキュアな操作方法のトレーニング、並びにランダムなシャットダ
ウン/再起動、セキュリティソフトウェアの無効化等、医療機器の異常動作を特定して通知する方法等が挙げられる。グルコース連続監視モニター、ポータブル輸液ポンプ等の在宅医療機器等、患者自身が操作することを意図している医療機器については、このようなトレーニングを患者にも行うことが望ましい。
6.1.2 医療機器製造業者
製造業者は、製品ラベリング及び顧客向けセキュリティ文書に情報を記載するほか、可能な場合には、ヘルスケアプロバイダや自社製品の販売業者及び消費者と協力して、利用者がその製品を最適な状態で使用できるように努めることが望ましい。
6.2

情報共有

情報共有は、世界経済の複数分野に渡るサイバーセキュリティの脅威及び脆弱性を管理するための重要なツールである。ヘルスケア以外の分野では、情報と脅威の共有に関する規格やベストプラクティスが作成、実施されている。医療機器関係者は、医療機器エ
コシステムのセキュリティを国際的に強化するため、他分野で実績のあるツールを適用することが望ましい。
リソースへのアクセス方法や使用される手法は責任関係者間で異なると共に、責任関係者の成熟度レベルも一様ではないため、有効な情報共有にも様々な方法が存在する。
医療機器の種類、接続するインフラ、組織の規模及び成熟度、脅威のレベル等、幾つかの要因に係るサイバーセキュリティのベストプラクティスは、絶えず進化している。
ある特定のアプローチを優先することは適切ではないため、本項では、情報共有に関する原則を提示する。なお、以下に示す事項は例示であり、要求事項を規定するものでは
ない。
6.2.1
•

•

重要原則

医療機器のセキュリティに関する情報は、当該医療機器の安全な使用を確保するために、ユーザ、患者、他社の製造業者、販売業者、ヘルスケアプロバイダ、セキュリティ研究者、一般人等、その情報を必要とする全ての関係者と共有することが望ましい。
共有される情報は、各責任関係者にとって有意義且つ利用可能であり、対応可能なものであることが望ましい。例えば、よりセキュアなチップセットに関する情

2020/3/18

Page 23 of 51

ー 77 ーIMDRF/CYBER WG/N60FINAL:2020

•
•

6.2.2

報は、製造業者にとって重要と考えられるが、医療機器のエンドユーザには必ずしも特段の利益となり得ない。
共有される情報は、患者の安全性向上に繋がるため、商業的利益とは関係なく必要に応じて自由且つ確実に共有されることが望ましい。
様々な地域の責任関係者が適切に対応できるように、国際的に一貫性のある情報を必要に応じて各地域間で可能な限り同時に共有することが望ましい。
重要な責任関係者

現在、医療機器分野のグローバル化が進んでいるが、医療機器の製造販売については、
各国毎に規制されている。複数の市場に医療機器を供給する製造業者は、情報共有について国内又は地域内の推奨事項のみでは不十分な可能性があるため、医療機器のセキュリティに関するグローバルな情報共有戦略を設ける必要がある。責任関係者は複数のネットワークを使用する際、利用するネットワークが国際的なネットワークである可能性があることを認識する必要がある。
a. 規制当局● 医療機器のセキュリティに関する情報の重要な受信者であり、その情報の周知についても関与することが多い。
● 医療機器のサイバーセキュリティに関する情報を遅滞なく開示するプロセスの構築を目指すことが望ましい。このようなプロセスには、サイバーセキュリティ対応に関する国際調和を図るために規制当局間で相互に情報を共有すること等が含まれる。
b. 医療機器製造業者● 情報源を問わず、脆弱性に関する情報を特定、評価、共有することが望ましい。
製造業者は、規制当局が状況を把握し、適切に規制する上で役立つ情報を共有することが望ましい。
● 製造業者は、場所を問わず世界中に同じ情報を提供すると共に、可能であれば同一の対応を確保するため、影響を受ける製品が販売される地域の各規制当局による通知が一斉発出されるよう努めることが望ましい。
● 医療機器のサイバーセキュリティの脆弱性及び脅威に関する対応可能な情報を提供するため、対象ユーザの読解レベルに合わせて平易な言葉を使用することが望ましい。これにはアップデートの適用又はアップデート適用までの補完的対策に関連する臨床的なベネフィット・リスクに係る情報が含まれ得る。
c. ヘルスケアプロバイダ● 適切に行動する又は行動を促進する責任を有することが多い。そのため、ヘルス
ケアプロバイダは、推奨事項を実施し、患者安全を確保するために必要なあらゆる情報にアクセスすることが望ましい。
2020/3/18

Page 24 of 51

ー 78 ーIMDRF/CYBER WG/N60FINAL:2020● ヘルスケアプロバイダは、医療現場で医療機器を使用しているため、医療機器のサイバーセキュリティに関する情報の主要な生成者でもある。また、ヘルスケア
プロバイダは、影響を受けた医療機器に関するフィードバックや、現実世界の環境で実施する修正策や緩和策の難易度や効果に関するフィードバックを提供できる。
d. ユーザ（医師、患者、介護者、消費者等）● アップデート又はその他の修正の適用要否に係る最終選択を行う機会が多い。
ユーザが適切な判断を下すためには、明確で意味のある情報が必須である。
e. 行政及び情報共有機関を含むその他の責任関係者● 法の執行機関、セキュリティ機関及びその他の行政機関は、医療インフラ及びその他の重要なインフラを保護するため、必要に応じて医療機器のサイバーセキュ
リティの脅威と脆弱性に関する情報を政府機関の各部署間で共有する必要がある。
● 情報を収集又は共有する組織や、セキュリティに関する助言若しくは専門知識を提供する組織も、セキュリティ情報の重要な情報源及びサポートリソースとなる可能性がある。これらの組織としては、 ISAO、ISAC 等の情報共有ネットワー
ク、コンピュータ緊急対策チーム（Computer Emergency Response Teams:CERT）
等の啓発機関等の政府機関や民間機関が存在する。これらの責任関係者は、地域及び市場によって相違し得る。
6.2.3

情報の種類

サイバーセキュリティの脆弱性は、ソフトウェア及びハードウェア、自社製又はサードパーティ製の複数の製品コンポーネントに対して脅威を引き起こす可能性がある。患者危害を防ぐために共有すべき情報としては、以下に例示した事項等が挙げられる。
●

脆弱性の影響を受ける製品及びその影響の内容●

その他の製品に使用されているコンポーネントの脆弱性情報●

医療機器のセキュリティに影響し得る IT 機器の情報●

攻撃又は潜在的な攻撃に関する情報及び悪用コードの利用可能性に関する情報●

インシデントの確認●

パッチ及びその他の緩和策（補完的対策等）の利用可能性●

暫定措置としての医療機器の使用と統合に関する追加指示

2020/3/18

Page 25 of 51

ー 79 ーIMDRF/CYBER WG/N60FINAL:2020

共有する情報には、脅威の緩和策及び方法も含めることが望ましい。例えば、医療機器に影響する脆弱性を緩和するための IT 機器の構成、既知の悪用に対応する方法等を含めることが望ましい。
6.2.4

信頼できるコミュニケーション

情報共有の目的はセキュリティ及び患者安全の向上である。情報共有のネットワークは、共有された情報が商業的な優位性を得るために使用されないことを理解して、必要に応じて書面による合意をもって設定することが望ましい。情報共有を促進する方法の一つとして、共有される情報の匿名化が挙げられる。
6.3

協調的な脆弱性の開示 （CVD）

未知の脆弱性等を考慮してセキュアな状態とすることは難しいため、透明性は、サイバーセキュリティのインシデントへの準備及び対応において不可欠な構成要素となる。透明性を強化する一つの手法として、CVD が挙げられる。CVD は、サイバーセキュリテ
ィの脆弱性情報を入手、評価し、緩和策及び補完的対策を開発した上で、顧客、同業他
社、規制当局、サイバーセキュリティ情報共有組織及び一般人を含む様々な責任関係者に対して、当該情報を開示するための、正式なプロセスを確立する。
CVD のポリシー及び手順の採用は、影響を受ける技術のエンドユーザが、医療機器及びヘルス IT インフラをより適切に保護するための対応を情報に基づいて決定することを可能にする、積極的なアプローチである。
CVD への取り組みは、セキュリティ問題への意識向上に係る責任ある行動方針であり、その他の業界と同様、継続的な品質改善及びリスクマネジメントに関する製造業者の成熟度の判断基準になると考えることが望ましい。
前向きな CVD は、企業の積極的且つ責任ある対応を測る指標となるが、製造業者が当
該ベストプラクティスを採用した結果、ネガティブキャンペーンが展開される不幸な事
例が幾つか報告されている。ベストプラクティスとしては、CVD を例外なく規範として実施することが望ましい。また、医療機器の責任関係者は、CVD の導入をさらに促進させるため、CVD のポリシーについて製造業者に照会することを推奨する。
6.3.1 医療機器製造業者
医療機器のエコシステムが成熟することにより、透明性のある活動の利点が十分に認識されると考えられる。この種の情報開示は、同様の脆弱性によって影響を受ける可能性がある複数の市販製品による潜在的な危害から、一般の人々を事前に保護する点で極めて重要である。製造業者における透明性のある対応は、新規製品のセキュリティ設計の改善に関する直接的なベネフィットを得ることもできる。ヘルスケアプロバイダ及び患者は、製造業者、CERT やコンピュータセキュリティに係るインシデントに対処するための組織（Computer Security Incident Response Team：CSIRT）等のコンピュータ対応チ
ーム又は規制当局からの CVD が脆弱性に関する権威ある情報源であることを理解する
2020/3/18

Page 26 of 51

ー 80 ーIMDRF/CYBER WG/N60FINAL:2020

ことが望ましい。CVD の一環として、規制当局が情報提供する方法とタイミングは、地域によって異なる可能性がある。ただし、製造業者は、問題を評価した後、広報又は通知等を使用して、その情報を顧客に遅滞なく伝達することが望ましい。製造業者は、遅滞のない情報交換に関する各地域特有の法規制が存在することに留意することが望ましい。
ソフトウェアが搭載された医療機器を完全に脆弱性のない状態とすることは不可能であるため、CVD への取り組みを日常的な実践の一部とすることが望ましい。サイバーセ
キュリティに対する製造業者の評価指標は、脆弱性の開示数ではなく、その対応に係る一貫性及び適時性である。CVD は、患者の健康及び安全を改善する一助であり、医療機器のサイバーセキュリティに対する製造業者の積極的なアプローチの一部として実施されることが望ましい。積極的な CVD に関連して、製造業者は以下の事項を実施することが望ましい。
●

サイバーセキュリティの脆弱性及びリスクを特定及び検出するためのサイバーセキ
ュリティの情報源を監視する。

●

協調的な脆弱性開示のポリシー及びプラクティスを採用する（ISO/IEC 29147:2014:
情報技術 – セキュリティ手法 – 脆弱性の開示）。これには脆弱性報告の受領確認を
脆弱性発見者に対して指定された期間内に通知することが含まれる。

●

脆弱性の検出及び処理のためのプロセスを確立し伝達する（ISO/IEC 30111:2013:情報技術 − セキュリティ手法 − 脆弱性の処理プロセス）。このプロセスは、セキュリ
ティ研究者、ヘルスケアプロバイダ等、脆弱性報告の発生源に拘わらず、明確性且つ一貫性及び再現性が求められる。

●

CVSS 等の確立したセキュリティの方法論及び臨床的なリスクアセスメント手法（ISO 14971:2019 等）に従って、報告された脆弱性を評価する。

●

可能であれば、緩和策を作成する。改善が不可能な場合は、展開失敗時の報告方法
及び変更の初期化方法と共に、適切な脆弱性の緩和策又は補完的対策を講じる。

●

規制当局からの要求に応じて、脆弱性の開示予定に関する情報共有について規制当局と連携する。

●

責任関係者に対し、適用範囲、影響、製造業者の現時点の理解に基づくリスクアセ
スメントを含む脆弱性、脆弱性の緩和策又は補完的対策に関する情報を提供する。
状況が変化した場合、責任関係者にも最新情報を提供することが望ましい。

製造業者は、顧客に対する通知に加えて、自社製品の脆弱性を全世界に向けて協調的に開示することが奨励される。CERT 等の組織は、CVD プロセス全体を通して、脆弱性の発見者及び製造業者と共同で作業を行う機会が多い。特に CERT は、各地域の組織がそれぞれの言語に翻訳した勧告の発出を通じて世界的に開示する役割を果たしている。
2020/3/18

Page 27 of 51

ー 81 ーIMDRF/CYBER WG/N60FINAL:2020

CVD に関する詳細については、協調的な脆弱性の開示に関する CERT®ガイド（CERT®
Guide to Coordinated Vulnerability Disclosure）を参照すると良い。
6.3.2

規制当局

規制当局は、製造業者及び脆弱性の発見者と連携して、脆弱性の評価、影響分析、緩和策の作成と実施を支援すると共に、最終的に悪用のリスクを緩和するために公衆への遅滞のない情報共有を促進する。CVD はベストプラクティスの一部であるため、この情報共有には、必要に応じてグローバルコミュニケーションも含まれる。
6.3.3 脆弱性の発見者（セキュリティ研究者及びその他を含む）
脆弱性が発見された場合、関連する製造業者又は適切な行政機関等、調整を担う第三者機関に直接報告することが望ましい。その後、製造業者は脆弱性発見者と連携して、脆弱性の調査及び必要な対応を行った後、脆弱性の一般開示について相互に調整する。米
国商務省電気通信情報局（National Telecommunications and Information Administration：
NTIA ） の 「 脆 弱 性 開 示 に 関 す る 特 性 と 対 応 ： NTIA Awareness and Adoption Group（NTIA 認識・導入グループ）による調査報告書（2016 年 12 月）」において、開示の調整については、製造業者が脆弱性発見者の報告に対して速やかに対応し、且つ未対応の当該脆弱性を利用した攻撃の証拠がない場合、発見者は修正又はその他の緩和策が作成されるまで非開示とすることとなっている。発見者が修正以前に脆弱性を開示した場合、発見者と製造業者は、ヘルスケアプロバイダや患者等、自社製品を安全且つセキュアに運用する立場にあるユーザに向けて、可能性のある全ての緩和策について説明する。
6.4

脆弱性の修正脆弱性の修正に関連する対応は、患者危害のリスクを低減するために重要である。修正には、患者への通知を含む広範な対応を含んでも良い。そのため、幾つかの責任関係者
グループが、このプロセスにおいて極めて重要な役割を果たしている。これらの役割については以下に詳述する。
6.4.1

医療機器製造業者

a. リスクマネジメント
医療機器のサイバーセキュリティの脆弱性に関する第一の対応は、リスクアセスメントである。ISO 14971:2019 が規定するリスクマネジメントは、医療機器分野において確立・成熟した手法である。製造業者及び規制当局等は、リスクマネジメントの手法を適用して脆弱性によるサイバーセキュリティのリスクを評価し、リスクマネジメントに関連付けてサイバーセキュリティリスクマネジメントプロセスを確立することによって、脆弱性が患者の安全性に及ぼす影響を判断することが望ましい。患者安全の観点からは、十分な根拠を有する脆弱性修正戦略を開発することが合理的である。規制当局と製造業
者は、このアプローチの有効性を高めるため、認識したリスク及び対応の正当性に関する情報を必要に応じて共有することが望ましい。修正の優先順位とタイミングはリスク
2020/3/18

Page 28 of 51

ー 82 ーIMDRF/CYBER WG/N60FINAL:2020

評価によって決定されるが、リスクに対する認識に大きな乖離がある場合、適切な修正戦略について製造業者と規制当局が同意する可能性は低くなる。
製造業者及び規制当局は、リスクマネジメント、品質マネジメント及び規制に精通していない可能性があるその他の責任関係者が認識しているリスクについても考慮する必要がある。これに伴い、製造業者はセキュリティの脆弱性に対応する期限及び手法について、異なる期待が寄せられることになる。また、脆弱な医療機器を十分に保護し、患者危害のリスクを許容可能なレベルまで低減する補完的対策等のリスク低減メカニズムを理解しない責任関係者も存在する。患者へリスクを及ぼし得る不正確な情報が存在する
場合、医療技術の信頼性が大きく損なわれる可能性がある。
全ての責任関係者は、医療機器に関するその他のリスクと同様に、サイバーセキュリテ
ィの脆弱性が患者及びユーザに対するリスクと同等に管理されることを認識する必要がある。
b. サードパーティ製コンポーネント
サードパーティ製コンポーネントは、ソフトウェア又はハードウェアに拘わらず、医療機器のサプライチェーンの重要な構成要素の一つである。これらのコンポーネントは、
自らリスクを発生する可能性がある。当該リスクは、製造業者がリスクマネジメント、
品質マネジメント及び設計の選択によって管理する。製造業者は、自社のソフトウェア
及びハードウェアのコンポーネントがサイバーセキュリティに与える影響を管理することが望ましい。同様に製造業者は、サードパーティ製コンポーネントに由来する市販後の問題が医療機器のセキュリティに影響し得るリスクも管理する必要がある。ユーザは、
オペレーティングシステムやプロセッサ等のコンポーネントにおけるセキュリティの脆弱性が医療機器に及ぼす影響について、製造業者が理解していることを期待する。
製造業者は、サードパーティ製コンポーネントの脆弱性に関する対応として、自社製コ
ンポーネントの場合と同様、継続的なリスクマネジメント及び顧客やユーザとの継続的な情報共有を行うことが望ましい。製造業者がサードパーティ製品の脆弱性を解決するためのアップデートを適用するタイミングを管理することは難しいが、その場合でも製造業者は、患者及びユーザに対するリスクを低減するための対策を講じることが期待されている。
c. コミュニケーション
本文書のその他の項に記載したとおり、リスクを管理するための情報を必要とする人と明確且つ簡潔なコミュニケーションを図ることが不可欠である。このようなリスクを管理するために必要な技術的専門知識の水準を理解すべきである。コミュニケーションの内容には、脆弱性解決スケジュール、脆弱性解決方法、CVSS スコア等の脆弱性スコア、
悪用可能性指標、悪用方法、暫定的なリスク緩和手法等の重要な情報を含めることが望ましい。
2020/3/18

Page 29 of 51

ー 83 ーIMDRF/CYBER WG/N60FINAL:2020

d. 修正作業
責任関係者が行うべき対応は、医療機器の種類、地域の規制、ユーザ及び患者の安全性に対するリスク、意図する目的等、複数の要因によって異なる。本文書では、全ての医療機器に期待される特定の対応に関する詳細については言及しないが、全ての脆弱性修
正作業の基礎とすることが望ましい原則を以下に示す。
●

地域の規制要求に対する適合●安全性及び基本性能に対する要件の遵守●

患者及びユーザに対するリスクを低減するための責任関係者との情報共有●合意した修正策を達成するための責任関係者間の協力●リスクに対する遅滞のない修正

医療機器に搭載されている基本的又は固有の保護手段が十分でなく、且つアップデート
を適用できない場合、リスクを緩和する代替手段を補完的対策として適用することが望ましい。例えば、医療機器と医療 IT ネットワークとの間にファイアウォールをインストールする又は医療機器を医療 IT ネットワークから取り外す対策等が挙げられる。これらの補完的対策は、一般的には製造業者から提供される情報に基づいて、ヘルスケア
プロバイダが実施する。
規制当局は、地域の法令の下で運営されており、市場に存在する医療機器に修正策を適用する際、特定の要求事項を課す可能性がある。製造業者は、脆弱性修正策を計画する
際、規制当局の判断を考慮する必要がある。製造業者は修正作業を計画的に推進するため、早い段階で規制当局に情報を提供することが望ましい。これにより、暫定的な修正の支援や、責任関係者と連携してユーザ、メディア、公衆等における管理を支援しつつ、時間的に十分な余裕を持って規制に関するプロセスや必要とされる対応を開始できる。
セキュリティの脆弱性に関する情報は、世界経済の中で急速に拡散するため、脆弱性の悪用も世界中に瞬時に到達する可能性がある。これは、脆弱性を修正するグローバル且
つ協調的な戦略が必要であることを意味している。ある脆弱性が特定の規制地域のみで開示・修正され、その他の規制地域では無対応となっている場合、その脆弱性は、悪意のある者に有利な条件を与えることとなり、患者や広範囲に渡る医療分野が攻撃に晒されることになる。
複数市場に製品を供給する製造業者は、タイミングのずれを最小限とするために、情報及び修正の公表を調整することが期待される。製造業者は、調整範囲を拡大し、影響を受ける製品が販売される地域の各規制当局と積極的に連携することが望ましい。

2020/3/18

Page 30 of 51

ー 84 ーIMDRF/CYBER WG/N60FINAL:2020

全ての責任関係者は、アップデートの即時適用が不可能又は望ましくない場合があり、患者安全を確保する上で暫定措置が重要となり得ることを認識する必要がある。製造業者又は規制当局が直接管理することなく、責任関係者自身がこれらの対策を実施しなけ
ればならない場合は特に重要である。例えば、対策の内容によっては、病院の IT 部門
以外実施できない場合がある。正しい修正戦略の実行性は、効果的な情報共有とユーザやメディア等の責任関係者の管理に依存している。なお、理想的な修正であっても、必ずしも実施できない場合があることに留意する必要がある。その場合は、適切なリスク緩和策及び補完的対策を適用することが望ましい。
6.4.2

ヘルスケアプロバイダ及び患者

a. アップデート
患者は専門の医療機関及び在宅医療環境において医療を受けるが、アップデート適用については、使用環境毎に考慮すべき特有の事項がある。2 例えば、在宅医療環境においては、患者、介護者、信頼できる隣人又は家族の一員がユーザとなり得る。本項では、
アップデート適用に関する一般的な指針及び各使用環境に固有な考慮事項について概説する。
IEC 62304:2006+AMD1:2015 「医療機器ソフトウェア − ソフトウェアライフサイクルプ
ロセス」の 6.2.5 項では、リリースした医療機器ソフトウェアの問題、変更の入手及びインストール方法について、製造業者がユーザ及び規制当局に通知することを要求している。製造業者が指定し、規制当局が承認した医療機器の特定のユーザは、製造業者が提供するアップデートをインストール手順に従って適用することが期待される。この特定ユーザは、製造業者の指針に従って、Web ページで提供されるサービス報告書及びその他の情報にアクセスすることが望ましい。
妥当な期間内にアップデートが適用できない場合、製造業者は、医療 IT ネットワークのセグメント分け等の補完的対策又は医療機器のユーザ設定の変更を推奨する可能性がある。規制当局は、特定の種類の脆弱性に対する患者危害のリスクを低減するため、製造業者に対して医療機器、付属品又はソフトウェア更新サーバ等の支援システムにおける特定の機能の無効化を指示する可能性がある。いずれの場合も、ユーザは製造業者の指針に従い、必要に応じて使用環境に関連するリスクを評価することが望ましい。3

2

IEC 60601-1-11:2015 医用電気機器-第 1-11 部：基礎安全及び基本性能に関する一般要求事項 − 副通則：
在宅医療環境における医用電気機器及び医用電気システムに対する要求事項では、「在宅医療環境」を専門の医療施設を除く、患者の居住地又は患者がいるその他の場所と定義している。例として、「自動車、バス、列車、船、飛行機の中、車椅子及び屋外の歩行」が挙げられている。
3
特定の状況ではユーザがリスクを適切に評価できないことが認識されている。

2020/3/18

Page 31 of 51

ー 85 ーIMDRF/CYBER WG/N60FINAL:2020

HSCC が作成した「医療機器及びヘルス IT の合同セキュリティプラン」で文書化されているパッチ方法の修正版を表 2 に示した。4 表 2 では、医療機器製造業者が承認した
アップデートを実装するために特定したユーザの主な責任を右列に示している。
アップデート方法

要約製造業者から提供されるセキュアで認定さリモートアップデ れたリモートサービス及びサポートプラッ
トフォームを介して適用するアップデーート
ト。
製造業者が指定したソースから顧客自身が取得し、インストールする承認済みのアッ
ユーザ管理
プデート。製品あるいはコンポーネントを提供するサードパーティからの直接ダウン
ロードを含む。
地域のサービス施設が管理するサイバーセ
キュリティアップデート(オンサイトサービ
スを含む)。注記：誤ったアップデートの適サービス訪問用によって重大な危害が発生する可能性があり、現地でのサービスが必要となる場合にこの方法を適用する。
表 2.

ユーザの責任製造業者の指示に従って、
リモート接続を確保する。

製造業者の指示に従って、
アップデートを取得してインストールする。

アップデート適用のために医療機器をサービス施設に渡す、オンサイトサービス
訪問を受ける、アップデー
ト適用のために専門の医療施設に出向く。

アップデート方法及び実施におけるユーザの責任

注記:サービス訪問の場合、ユーザは、アップデートのインストールに関する資格を有する専門家と連携する責任がある。
b. 医療施設環境に対する考慮事項
医療施設において、患者は、規制上有効である免許の有無に拘わらず、医師や看護師等の資格を有する医療専門家による医療を受けている。患者は、医療機器の安全且つ効果的な使用を確保するために、セキュリティ関係者も含めたヘルスケアプロバイダの指示に従うことが期待される。
IEC 80001-1:2010「医療機器を組込んだ IT ネットワークへのリスクマネジメントの適用」
第 1 部「役割・責任・活動」の 3.2 項は、医療 IT ネットワークで運用されている医療機器の保守を含めて、「責任組織」が実施すべきリスクマネジメントについて規定している。責任組織は、患者を直接担当するヘルスケアプロバイダと異なる場合がある。アップデート適用は、リスクコントロール手段の一種であり、以下に示したとおり、具体的な指針が 4.4.4.3 項に記載されている。
4

医療機器及びヘルス IT の合同セキュリティプラン（HSCC、2019 年 1 月）。 注:リモートアップデート
及びユーザ管理については、明瞭さを向上するため、「アドホックな」パッチ適用方法を削除している。

2020/3/18

Page 32 of 51

ー 86 ーIMDRF/CYBER WG/N60FINAL:2020「医療機器自体に対するリスクコントロール手段は、取扱説明書又は医療機器製造業者の文書による許可に従って、医療機器製造業者又は責任組織が実施することが望ましい。
医療機器製造業者の文書による同意がない場合、責任組織が医療機器に行ういかなる変更も推奨されない。」
これらの推奨事項は、医療 IT ネットワークの効果的で安全な管理を確保するために作成された。一般人には、医療 IT ネットワークに接続される医療機器にアップデートをインストールする許可を与えるべきではない。
IEC 80001-1 に記載されているとおり、責任協定書は、医療 IT ネットワーク機器を管理する上で、全ての当事者が共有責任を有することを確実に理解するための選択肢の一つである。製造業者が、医療機器の特定の機能を無効にするように指示している場合、ヘルスケアプロバイダは、患者安全の維持を確保するために、臨床ワークフローを評価することが望ましい。
c. 在宅医療環境における考慮事項
FDA ガイダンス「家庭での使用を目的とした機器に関する設計上の検討事項」に記載されているとおり、在宅医療環境では、多様な潜在的ユーザに対応する必要がある（以下参照）。

「在宅医療機器のユーザは、専門の医療施設で医療機器を操作する医療専門家と異なる。
在宅医療機器のユーザは、身体的、感覚的及び認知的な能力及び障害、並びに感情的に幅広い違いを有する可能性があることを在宅医療機器の設計で考慮することが望ましい。」
在宅医療環境におけるアップデート適用については、医療機器のリスクのクラス分類、
高速インターネット通信等のリソース要求事項及びユーザビリティを含む多くの要因を考慮する必要がある。ユーザの能力が大きく異なるため、多くの在宅医療機器では、表2 に示した「サービス訪問」によるアップデート適用が必要となる。埋め込み型医療機器に対するアップデート適用については、患者のヘルスケアプロバイダとの直接的な連携が必要になる場合がある。
一部の在宅医療機器、特に SaMD に分類される製品等においては、リモートアップデ
ート又はユーザ管理によるパッチ適用に対応しているものがある。リモートアップデー
トは、ユーザとの最小限の連携をもって実施できるが、ヘルスケアプロバイダが確立したプロセスに従って、患者との合意形成を必要とすることが多い。いずれのアップデー
ト適用方法においても、患者は、ヘルスケアプロバイダ又は製造業者の指示に従うことが望ましい。

2020/3/18

Page 33 of 51

ー 87 ーIMDRF/CYBER WG/N60FINAL:2020

患者が海外旅行を計画している場合、患者は、医療機器のソフトウェア保守オプション
を理解するために、ヘルスケアプロバイダ又は医療機器製造業者と相談することが望ま
しい。
6.4.3

規制当局

市販後のアップデート

脅威アクターは、悪用のテクニックを状況に合わせて絶えず適応させて進化させている。
その結果として、医療機器のサイバーセキュリティの回復力を意味する「サイバー衛生管理」の向上、脆弱性の修正又は修正できない脆弱性のリスク緩和のために、頻繁なソフトウェア保守作業が必要になることが多い。「サイバーセキュリティの強化に特化」
した変更が、最高レベルの規制対象とされた場合、その審査にあたり、殆どの規制当局は直ちに過負荷を強いられることになると推測される。
規制当局は、ソフトウェアの変更にあたり、サイバーセキュリティの観点から、リリース前の承認の要否を判断するため、以下に示した基本的な二つの論点を整理することが望ましい。
1) 変更は、あくまでサイバーセキュリティを強化するために意図されたものであり、ソフトウェア又は医療機器にその他の影響を与えないことが確認されているか？
製造業者は、必要な分析、試験及びバリデーションを行うことによって、その変更が医療機器の安全性及び性能に影響を与えないことを担保するためのシステム評価を行うことが望ましい。製造業者が、ソフトウェア又は医療機器にその他の偶発的又は意図しない影響が及ぶことを認識した場合、規制当局は、ソフトウェアの変更を実施する前に、提案された修正に関して審査することが適切であると判断する可能性がある。
2) 変更は、患者危害に関する受容できない残留リスクに関連する脆弱性のリスクを修正又は低減するために意図されたものか？
市販後の脆弱性リスク評価は、悪用が成功する可能性及び患者危害の重大さに基づいて評価することが望ましい。また、市販後の脆弱性リスク評価を使用して、残留リスクの受容可否を判断することが望ましい。「患者危害」の定義は、 ISO 14971:2019「医療機器 − リスクマネジメントの医療機器への適用」において定義される「危害」のサブセットである。5 患者危害を狭く定義することにより、公衆衛生の保護に必要な変更に対す
る規制当局の審査を優先する効果が得られる。

5

ISO 14971:2019 は、「危害」を「人の受ける身体的傷害若しくは健康障害又は財産若しくは環境の受ける害」と定義しており、「患者危害」は、この定義の前半部分が該当する。

2020/3/18

Page 34 of 51

ー 88 ーIMDRF/CYBER WG/N60FINAL:2020

3

SaMD

SaMD

SaMD

A

6

B

7

6

FDA

2016

12

7

2020/3/18

Page 35 of 51

ー 89 ーIMDRF/CYBER WG/N60FINAL:2020

表 3.

ソフトウェアアップデート及び規制当局の監視に関する推奨レベル

提案されたソフトウェア変更が、複数の脆弱性に影響する又は「サイバー衛生管理」を改善し少なくとも一つの脆弱性に影響する場合、製造業者は、その後の対応を通知する
際、表 3 に示した最高レベルの項目の適用について検討することが望ましい。例えば、一つのソフトウェア変更によりシステムセキュリティを強化し、脆弱性 A のリスクを低減し、脆弱性 B を修正することがある。この場合、脆弱性 B に関連する「高」レベルの規制要求事項が適用される。
いかなるレベルにおいても、規制当局は、自らの判断で、製造業者が IEC 62304:2006/
AMD 1:2015 に規定されているソフトウェア保守のライフサイクルプロセス及びその他の規制要求事項に適合している科学的根拠を要求することがある。
6.5

インシデントへの対応

6.5.1 医療機器製造業者
製造業者は、製品及び患者を含む顧客に影響を及ぼす可能性があるサイバーセキュリテ
ィのインシデントやその他の事象に対応する準備を行う必要がある。製造業者は、自社製品に関するリスク管理対策を階層的に整理したポートフォリオに基づいて、拡張性のあるインシデント対応管理ポリシーを確立し、インシデント対応チームを組織しなければならない。インシデント対応チームは、サイバーセキュリティのインシデントについて評価、対応すると共に、その経験に基づいた適切な情報リスクマネジメント能力を共有し、次のインシデントが発生した際に遅滞なく適切に行動するために必要な調整、管理、フィードバック及び連携体制に関する情報を提供する。
サイバーセキュリティへの対応準備には、インシデント管理ポリシーの確立、詳細なインシデント対応計画の策定、インシデント対応チームの設立、インシデント対応の定期的な試験及び練習、並びに得られた教訓を通じて、インシデントへの対応能力を継続的に向上することが含まれる。
ISO/IEC 27035 が規定するインシデントマネジメントには、「計画及び準備」、「検知及び報告」、「評価及び決定」、「対応」及び「得られた教訓」が上位レベルとして含まれている（附属書 A 参照）。詳細は次項を参照すること。
a. 役割及び責任
インシデント対応チームは、マネージャ、計画作成グループ、監視グループ、対応グループ、実施グループ、分析グループ等の様々なグループに分割されることがあると共に、
外部専門家が参画する場合もある。各グループは、それぞれの役割及び責任を有しており、スキル及び知識に基づいて人員を適切に配置することが望ましい。役職によっては、複数のグループの人員が担当する場合もある。相互に関連するグループに配属された人
2020/3/18

Page 36 of 51

ー 90 ーIMDRF/CYBER WG/N60FINAL:2020

員は、同一又は類似の作業に対して責任を持つことが望ましい。これらのグループの役割に関する詳細情報は、附属書 A に示した。
b. コミュニケーションに対する期待製造業者は、サイバーセキュリティのインシデントやその他の事象を報告する連絡先情報を顧客に提供することが望ましい。通常の顧客サービス受付を通してサイバーセキュ
リティのインシデントやその他の事象を通知しても良い。インシデント対応チームは、インシデントの影響を受ける全ての責任関係者と最新情報を共有するための日常的な活動体制を確立し、最初の発見後、可能な限り早急に顧客へ適切な情報を提供する必要がある。製造業者は遅滞なく情報共有するための特定の管轄要件を策定しておくことが望ましい。インシデント発生直後における製造業者による報告書又は通知の発行可否については、顧客に対し遅滞なく正確な情報共有を実施可能であるかに依存する。
製造業者は、患者安全及びプライバシーに影響する医療機器のサイバーセキュリティのインシデントを規制当局に報告しなければならない。調査の過程で犯罪行為が特定された場合は、所管の適切な法執行機関に通知しなければならない。CERT 及び ISAO はグ
ローバルなサイバーセキュリティの攻撃及び事象に関して更なる連携強化を図るべきで
ある。
6.5.2

ヘルスケアプロバイダ

ヘルスケアプロバイダは、サイバーセキュリティのインシデントを処理するためのポリ
シー、インシデントを緩和又は解決し、内外の責任関係者に関連情報を開示するための方法を確立することが望ましい。その一環として、ヘルスケアプロバイダは、脆弱性の緩和に関する計画とリソース管理について検討することが望ましい。この措置には、インシデント対応中、必要に応じて代替機器を提供するための費用も含まれる可能性がある。
a. ポリシー及び役割
サイバーセキュリティの脆弱性又はインシデントを処理するためのポリシー及び役割は、ヘルスケアプロバイダの組織にも整備されていることが望ましい。ヘルスケアプロバイ
ダは、MDS2（Manufacturer Disclosure Statement for Medical Device Security：MDS2）、
SBOM、脆弱性及びアップデート情報等の製造業者の開示文書、情報共有機関又は参画している ISAO からの情報を受領し、広範に共有する方法を確立することが望ましい。
そのためには、情報提供先及び提供元の連絡先リストを定期的に管理・検証する必要がある。また、医療機器の納入前に締結し且つ定期的に見直すサービスレベル契約（Service Level Agreements：SLAs）には、インシデント対応中に製造業者及びその他のベンダーが遵守すべき事項を記載しなければならない。ヘルスケアプロバイダは、独自のインシデント対応チームを設立することが奨励される。

2020/3/18

Page 37 of 51

ー 91 ーIMDRF/CYBER WG/N60FINAL:2020

b. 役割毎のトレーニング
それぞれの関連する役割をトレーニングするための要求事項を確立し、更新の要否を定期的に見直すことが望ましい。サイバーセキュリティインシデントを評価する専門家は、実務経験に加えて、デジタル機器に残る記録を収集・解析し、法的な証拠性を明らかにするフォレンジック分析のトレーニングを受けることが望ましい。インシデント対応プ
ロセスに関与する人員は、実務経験に加えて、インシデント対応のプロセス及び理論に関するトレーニングを受けることが望ましい。トレーニングプロセスは定期的に評価することが望ましく、その一環として、インシデント対応演習が行われる可能性がある。
c. 分析及び対応
ヘルスケアプロバイダは、調査結果を記載した報告書の提供を通じて、インシデント又は報告された脆弱性の影響を評価し、医療機器製造業者等の責任関係者と協力して対応することが望ましい。問題解決にあたり作業が必要な場合は、調査の状況及び日程を結果に含めることが望ましい。ヘルスケアプロバイダは、ベストプラクティス及び緩和策を含む安全関連情報を患者に周知することが望ましい。解決策に修正が含まれている場
合は、その修正を施設全体に適用する前に、対象となる既存システムの機能が影響を受けないことを保証するためにレグレッション試験等のバリデーションを実施しなければならない。ヘルスケアプロバイダは、修正及び緩和策の情報を必要に応じて更新することが望ましい。
6.5.3 規制当局
医療機器のサイバーセキュリティインシデントとその対応には、規制当局も関与することが望ましい。6.5.1 項に記載したとおり、製造業者は、サイバーセキュリティのインシデントを規制当局が認識し、規制方針の決定に必要な詳細情報を規制当局が要求し、必要に応じて追加措置を実施できる環境を整備するため、インシデントについて規制当局に通知することが望ましい。必要に応じて規制当局が実施する追加措置としては、患者安全に対する影響評価、製造業者が提示した緩和策のリスク・ベネフィット評価、サイバーセキュリティ研究者等を含む責任関係者及びその他の政府機関や規制当局との連携等が挙げられる。
6.6

レガシー医療機器

本文書では、現在のサイバーセキュリティの脅威に対してアップデート又は補完的対策
等の合理的な手段で保護できない医療機器を「レガシー医療機器」と定義する。現在使用されている多くのレガシー医療機器は、初期設計及び保守においてサイバーセキュリ
ティについて検討されていなかった可能性があり、国際的なヘルスケアエコシステムにとって特に複雑な課題となっている。医療機器のデジタル化に伴って、古いアナログ装
置では決して実現できなかった様々な機能が開発されてきた。そのため、これらの医療機器については、その臨床的有用性がセキュリティ対応のサポート期間を超えることが多いことが問題を更に悪化させている。このような技術は患者ケアにとって有益であるが、ソフトウェア、ハードウェア及びネットワーク接続を組み合わせた使用に伴い、医2020/3/18

Page 38 of 51

ー 92 ーIMDRF/CYBER WG/N60FINAL:2020

療機器の寿命に関する新たな要求が発生した。このような組み合わせは、スキャナハー
ドウェア等の資本設備及び一般消費財に該当するサーバ、ワークステーション、データ
ベース及びオペレーティングシステム等のコンポーネントから構成されることが多い。
ただし、老朽化の理由のみでその製品がレガシー医療機器であると判断してはならない
ことも重要である。発売開始から 5 年以内の医療機器であっても、現在のサイバーセキ
ュリティの脅威に対して合理的な手段で保護できない場合は、発売以降の年数にかかわらずレガシー医療機器とみなされる。一方、発売から 15 年経過した医療機器であっても、現在のサイバーセキュリティの脅威に対して合理的な手段で保護できる場合は、レガシー医療機器に該当しない。
医療機器の設計開発ステージから始まる、サイバーセキュリティの TPLC に関する取り組みとして、医療機器のライフサイクル全体を通じてサイバーセキュリティの脅威に対する合理的な保護手段の効果を維持することの重要性が増している。このような取り組
みによって、医療現場で現在使用されている様々なレガシー医療機器に起因する不均衡（ヘルスケアプロバイダとそのネットワークに起因するセキュリティ上の脅威）が低減される。本文書の以下の項目では、医療機器サイバーセキュリティの理想的な将来像、
すなわち、事業継続計画の作成にあたり、ヘルスケアプロバイダに対して必要な情報を事前に通知し、サイバーセキュリティの脅威に対して合理的な手段で保護できないレガ
シー医療機器の使用を終了又は段階的に使用を終了するための概念フレームワークについて詳述する。（図 2 参照）。
サイバーセキュリティ及び製品ライフサイクルの全体

MDM の責任と期待

セキュアな開発フレームワークに基づき医療機器を設計する
製品開発

開発

MDM は、製品寿命終了
及びサポート終了までのスケジュールを顧客に通知する（サポート終了日
まではサポートが提供される）

製品寿命終了商用リリースサポート

顧客の責任と期待

商業的サポートの終了（レガシー状態の開始）

限定的なサポート

サポート終了顧客は、MDM から通知されたサポート終了に対する対応計画の作成
を開始する

MDM から顧客への責
任の完全な移転（以降、サポートは提供されない）*医療機器製造業者（MDM）は、医療機器の責任に関する各地域のガイダンスに従うが、サポートレベ
ルは顧客との契約に応じて異なる。

図 2.

サイバーセキュリティに関する製品ライフサイクルの機能として表現したレガ
シー医療機器の概念フレームワーク

2020/3/18

Page 39 of 51

ー 93 ーIMDRF/CYBER WG/N60FINAL:2020

6.6.1

医療機器製造業者

医療機器のサイバーセキュリティ対策は、図 2 に示したとおり、商用リリース前の医療機器の設計開発段階から開始される。医療機器の完全なサポート、すなわち現在のサイ
バーセキュリティの脅威に対する合理的な保護手段の提供は、TPLC のフレームワークに基づいて、製造業者が公開した製品寿命終了（EOL）まで継続することが望ましい。
製造業者が公表するサイバーセキュリティ EOL は、その期日以降、医療機器の総合的なサイバーセキュリティのサポートが大幅に縮小され、保証されなくなることを意味する。製造業者は、サイバーセキュリティ EOL が近づいた時点で顧客に対して、EOL 以降も限定的なサポートを提供することを通知すると共に、医療機器のサイバーセキュリ
ティのサポート終了日（EOS 日）を明示することが望ましい。医療機器のユーザは、製造業者が指定したサイバーセキュリティ EOS の期日以降、該当する医療機器に対する全てのサポートを受けることができないと考えることが望ましい。
サイバーセキュリティ EOS の期日に達した医療機器は、この概念フレームワークに基づいて、現在のサイバーセキュリティの脅威に対して合理的に保護できないレガシー医
療機器とみなし、使用を終了することが望ましい。医療機器のセキュリティを維持する責任及び EOS 日以降も機器を使用し続けたことによるリスクは、この時点でヘルスケ
アプロバイダ等の顧客に移転される。
なお、医療機器によっては、サポートが終了しておりセキュリティ上のパッチを適用できない古いオペレーティングシステムを使用している場合等、設計変更を行うことはできないが、補完的対策を実施することにより、相応に保護できる可能性がある。本フレームワークにおいて、利用可能且つ実績のある補完的対策が存在する医療機器について
は、レガシー医療機器とみなさない。規制当局は、ヘルスケアプロバイダが EOS 日以降の事業継続計画を作成するための十分な時間を確保できるように、必要に応じて、現在の医療機器において EOL 日以降に発生するセキュリティ上の課題に対応するための補完的対策を実施するよう製造業者に推奨する。医療機器の設計、脆弱性の管理及び顧客との情報共有は、医療機器のサイバーセキュリティに関する課題に取り組む上で全て重要な役割を果たす。製造業者へ向けた医療機器のライフサイクルステージの機能に関する推奨事項は、以下に示したとおりである。
●

開発:
a.

医療機器を構成するハードウェア及びソフトウェアコンポーネントのサポート
ライフサイクルを考慮する。製造業者は、医療機器のユーザを総合的にサポートするため、品質やパフォーマンス、セキュリティに関する問題を解決するためのソフトウェア及びファームウェアのアップデート適用に関して、該当する
ハードウェア及びソフトウェアベンダーからのサポートを受けることが望ましい。製造業者は、利用期間中の製品の安全性と有効性を維持するために必要なサポートを予測することが望ましい。製造業者は、ヘルスケアプロバイダが想定する医療機器ライフサイクル期間中にサードパーティーベンダーのサポート

2020/3/18

Page 40 of 51

ー 94 ーIMDRF/CYBER WG/N60FINAL:2020が終了する可能性を考慮すると共に、サポート終了によって医療機器のセキュアな運用に悪影響が及ぶ可能性を考慮することが望ましい。
b.

●

将来のレガシー医療機器の数を最小限に抑えることを目的としたセキュアな開発フレームワークに基づいて医療機器を設計開発する。このような医療機器については、少なくともセキュリティ基準に適合し、アップデート及びパッチの適用を可能とする環境を整備することが望ましい。

サポート:
a.

リスクマネジメントの一環として、医療機器における受容できないリスクのある脆弱性の存在可否を監視し、可能な限り最善の対応を行い、製品の全ライフサイクルの各段階に応じたリスク関連文書を継続的に更新する。

b.

医療機器の購入及び設置プロセスの一環として、各時点における顧客の責任と併せて、医療機器のサイバーセキュリティ EOL 日等、ライフサイクルの主要なマイルストーンを明確に通知する。

c.

顧客に対し、サードパーティによる機器部品のサポート終了を事前に通知する。

d.

サイバーセキュリティ EOS 日まで限定的なサポートを継続することを顧客に通知する。EOS 日以降、当該医療機器はサポート対象外となってレガシー状態となる。この情報は、EOL 日が近づいた時点で顧客に通知することが望ましい。
これにより、ヘルスケアプロバイダは、医療機器の使用終了又は段階的な使用
終了及び事業継続計画作成のための十分な時間を確保できる。このような情報を明確に通知することにより、医療機関は、自身の責任及び導入する医療機器のリスクを理解することが可能となり、医療機器の使用終了及び交換に関する計画と予算を作成することができる。

● 限定的なサポート（EOL 開始点)：
a. 顧客が EOS 及び関連する責任に備えるための十分な時間を確保できるように、
サイバーセキュリティ EOS 日に関するスケジュールを引き続き通知する。
b. 上記の「サポート」の項目に記載した作業「a」及び「c」を引き続き行う。
● サポート終了（レガシー状態開始点）：
a. 製造業者から顧客に責任が完全に移転される。当該医療機器に関する正式なサイバーセキュリティ EOS 日以降、そのユーザは、いかなるレベルのサポートも期
待しないことが望ましい。

2020/3/18

Page 41 of 51

ー 95 ーIMDRF/CYBER WG/N60FINAL:2020

6.6.2

ヘルスケアプロバイダ

ヘルスケアプロバイダは、公表されたサイバーセキュリティ EOL において製造業者が設定した医療機器の製品寿命より大幅に長い使用期間を設定することが多い。しかし、脅威の状況は時代の経過と伴に変化する。新しい脅威の出現により、時代遅れの技術を使用するリスク及び対応に要する経費が増加するが、製造業者及びヘルスケアプロバイ
ダは共同責任として対処しなければならない。医療機器のライフサイクル段階の機能として以下に示した推奨事項は、ヘルスケアプロバイダが医療機器の課題に取り組むための一助になり、既定のサイバーセキュリティ EOS 日以前に計画を作成する上で役立つと考えられる。
●

●

サポート:
a.

製品ライフサイクルの計画作成、サイバーセキュリティに関する理解及び透明性を確保するために、製造業者に明確な連絡窓口と情報伝達プロセスを要求する。

b.

サポートライフサイクルが最も短いソフトウェアコンポーネントが、最終的に医療機器のサポート及びサイバーセキュリティに影響を与えるため、SBOM を要求する。顧客は、SBOM を入手することにより、医療機器のライフサイクルに影響を与えるコンポーネントをより適切に理解することが可能となり、補完的対策等のリスクコントロール手段に用いられる追加のハードウェアに関する情報を把握することができる。

c.

製造業者、サードパーティのサービス業者又はプロバイダ自身のリソース及び管理を通じて、使用中の医療機器を適切にサポートし、正常な稼働を維持する。
例えば、ネットワークセキュリティ、資産セキュリティ、アイデンティティ/ア
クセスマネジメント、セキュリティ業務等が挙げられる。

d.

医療機器の使用環境における新たなリスクや進化するリスクを評価し、適切な緩和策によってリスクコントロールするために最大限努力する。この対応策としては、ネットワークのセグメンテーション、ユーザアクセスの制限、リスク
アセスメント、セキュリティ試験、ネットワーク監視等が挙げられる。

e.

サポート対象外となり、患者安全及び医療ネットワークセキュリティを脅かす可能性があるレガシー医療機器の使用を適切に段階的に終了し、セキュリティ対策で保護可能且つサポートを受けられる医療機器に置換するため、製造業者が定めるサイバーセキュリティ EOS 日以前に計画を作成する。

限定的なサポート:a.

上記の「サポート」の項目に記載した作業「c」、「d」及び「e」を引き続き行う。

2020/3/18

Page 42 of 51

ー 96 ーIMDRF/CYBER WG/N60FINAL:2020●

サポート終了:a.

医療業務の継続に影響を与えることなく医療機器の使用を終了できない場合、
当該医療機器のセキュリティを管理する責任及びセキュリティ EOS 日以降も使用を継続することによって発生し得るリスクを引き受ける。

7.0 参考文献
7.1

IMDRF 文書

1. Software as a Medical Device: Possible Framework for Risk Categorization andCorresponding Considerations IMDRF/SaMD WG/N12:2014 (September 2014)
2. Essential Principles of Safety and Performance of Medical Devices and IVD Medical
Devices IMDRF/GRRP WG/N47 FINAL:2018 (November 2018)
7.2

規格

3. AAMI TIR57:2016 Principles for medical device security—Risk management
4. AAMI TIR 97:2019, Principles for medical device security—Postmarket risk managementfor device manufacturers
5. IEC 60601-1:2005+AMD1:2012, Medical electrical equipment - Part 1: General
requirements for basic safety and essential performance
6. IEC 62304:2006/AMD 1:2015, Medical device software – Software life cycle processes
7. IEC 62366-1:2015, Medical devices - Part 1: Application of usability engineering to medical
devices
8. IEC 80001-1:2010, Application of risk management for IT-networks incorporating medical
devices - Part 1: Roles, responsibilities and activities
9. IEC TR 80001-2-2:2012, Application of risk management for IT-networks incorporating
medical devices - Part 2-2: Guidance for the disclosure and communication of medical
device security needs, risks and controls
10. IEC TR 80001-2-8:2016, Application of risk management for IT-networks incorporating
medical devices – Part 2-8: Application guidance – Guidance on standards for establishing
the security capabilities identified in IEC 80001-2-2
11. ISO 13485:2016, Medical devices – Quality management systems – Requirements forregulatory purposes
12. ISO 14971:2019, Medical devices – Application of risk management to medical devices

2020/3/18

Page 43 of 51

ー 97 ーIMDRF/CYBER WG/N60FINAL:2020

13. ISO/TR 80001-2-7:2015, Application of risk management for IT-networks incorporating
medical devices – Application guidance – Part 2-7: Guidance for Healthcare Delivery
Organizations (HDOs) on how to self-assess their conformance with IEC 80001-1
14. ISO/IEC 27000 family - Information security management systems
15. ISO/IEC 27035-1:2016, Information technology – Security techniques – Information security
incident management – Part 1: Principles of incident management
16. ISO/IEC 27035-2:2016, Information technology – Security techniques – Information security
incident management – Part 2: Guidelines to plan and prepare for incident response
17. ISO/IEC 29147:2018, Information Technology – Security Techniques – Vulnerability
Disclosure
18. ISO/IEC 30111:2013, Information Technology – Security Techniques – Vulnerability
Handling Processes
19. ISO/TR 24971:2020, Medical devices – Guidance on the application of ISO 14971
20. UL 2900-1:2017, Standard for Software Cybersecurity for Network-Connectable Products,
Part 1: General Requirements
21. UL 2900-2-1:2017, Software Cybersecurity for Network-Connectable Products, Part 2-1:
Particular Requirements for Network Connectable Components of Healthcare and Wellness
Systems
7.3

規制当局のガイダンス

22. ANSM (Draft): Cybersecurity of medical devices integrating software during their life cycle(July 2019)23. China: Medical Device Network Security Registration on Technical Review Guidance
Principle (January 2017)24. European Commission: REGULATION (EU) 2017/745 OF THE EUROPEANPARLIAMENT AND OF THE COUNCIL of 5 April 2017 on medical devices, amending
Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009
and repealing Council Directives 90/385/EEC and 93/42/EEC (May 2017)25. European Commission: REGULATION (EU) 2017/746 OF THE EUROPEANPARLIAMENT AND OF THE COUNCIL of 5 April 2017 on in vitro diagnostic medical
devices and repealing Directive 98/79/EC and Commission Decision 2010/227/EU (May2017)
26. FDA (Draft): Content of Premarket Submissions for Management of Cybersecurity in
Medical Devices (October 2018)2020/3/18

Page 44 of 51

ー 98 ーIMDRF/CYBER WG/N60FINAL:2020

27. FDA: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS)
Software (January 2005)
28. FDA: Design Considerations for Devices Intended for Home Use (November 2014)
29. FDA: Postmarket Management of Cybersecurity in Medical Devices (December 2016)
30. Germany: Cyber Security Requirements for Network-Connected Medical Devices(November 2018)31. Health Canada: Pre-market Requirements for Medical Device Cybersecurity (June 2019)32. 平成 27 年 4 月 28 日付薬食機参発 0428 第 1 号・薬食安発 0428 第 1 号：厚生労働省
大臣官房参事官・医薬食品局安全対策課長通知「医療機器におけるサイバーセキュ
リティの確保について」
33. 平成 30 年 7 月 24 日付薬生機審発 0724 第 1 号・薬生安発 0724 第 1 号：厚生労働省
医薬・生活衛生局医療機器審査管理課長・医薬安全対策課長通知「医療機器のサイ
バーセキュリティの確保に関するガイダンスについて」
34. Singapore Standards Council Technical Reference 67: Medical device cybersecurity (2018)35. TGA: Medical device cybersecurity - Consumer information (July 2019)36. TGA: Medical device cybersecurity guidance for industry (July 2019)37. TGA: Medical device cybersecurity information for users (July 2019)7.4

その他の資料及び参考文献

38. CERT® Guide to Coordinated Vulnerability Disclosure
https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
39. The NIST Cybersecurity Framework
https://www.nist.gov/cyberframework
40. NIST’s Secure Software Development Framework (SSDF)
https://csrc.nist.gov/CSRC/media/Publications/white-paper/2019/06/07/mitigating-risk-ofsoftware-vulnerabilities-with-ssdf/draft/documents/ssdf-for-mitigating-risk-of-softwarevulns-draft.pdf
41. Medical Device and Health IT Joint Security Plan (January 2019)https://healthsectorcouncil.org/wp-content/uploads/2019/01/HSCC-MEDTECH-JSP-v1.pdf
42. MITRE medical device cybersecurity playbook (October 2018)2020/3/18

Page 45 of 51

ー 99 ーIMDRF/CYBER WG/N60FINAL:2020

https://www.mitre.org/publications/technical-papers/medical-device-cybersecurity-regionalincident-preparedness-and
43. MITRE CVSS Healthcare Rubric
https://www.mitre.org/publications/technical-papers/rubric-for-applying-cvss-to-medicaldevices
44. Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients (HICP)
https://www.phe.gov/Preparedness/planning/405d/Pages/hic-practices.aspx
45. Open Web Application Security Project (OWASP)
https://www.owasp.org/index.php/Main_Page
46. Manufacturer Disclosure Statement for Medical Device Security (MDS2)
https://www.nema.org/Standards/Pages/Manufacturer-Disclosure-Statement-for-MedicalDevice-Security.aspx
47. ECRI approach to applying the NIST framework to MD
https://www.ecri.org/components/HDJournal/Pages/Cybersecurity-Risk-Assessment-forMedical-Devices.aspx
48. National Telecommunications and Information Administration (NTIA) / US Department ofCommerce, Vulnerability Disclosure Attitudes and Actions: A Research Report from the
NTIA Awareness and Adoption Grouphttps://www.ntia.doc.gov/files/ntia/publications/2016_ntia_a_a_vulnerability_disclosure_insi
ghts_report.pdf
49. https://republicans-energycommerce.house.gov/wp-content/uploads/2018/10/10-23-18CoDis-White-Paper.pdf
50. https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf

2020/3/18

Page 46 of 51

ー 100 ーIMDRF/CYBER WG/N60FINAL:2020

8.0 附属書2020/3/18

Page 47 of 51

ー 101 ーIMDRF/CYBER WG/N60FINAL:2020

8.1

附属書 A: インシデント対応の役割（ISO/IEC 27035 から引用）

インシデントマネジメント – ISO/IEC 27035
計画及び準備情報セキュリティのインシデントマネジメントポリシーを作成し、インシデント対応チーム等を設立する。
検知及び報告インシデントと考えられる又はインシデントになる可能性がある「事象」
を検知して報告する。
評価及び決断状況を評価し、実際のインシデントの有無を判断する。
対応
必要に応じて、インシデントの防御と解消、インシデントからの復旧、インシデントのフォレンジック分析を行う。
得られた教訓過去に経験したインシデントに基づいて、組織の情報リスクマネジメント
能力を体系的に改善する。
インシデント対応チーム
役割
マネージャ

責任
サイバーセキュリ
ティインシデント
対応に関する重大な問題について、対応の指揮と決定を行う

計画作成グループ

インシデント対応
を運用する監視グループ

リアルタイムのセキュリティ監視活動を行う

対応グループ

リアルタイム対応や技術サポート等

主なアクション
a) インシデント対応に積極的に関与してサポートする。
例えば、必要に応じて人的資源、金銭的資源、物的資源を提供する
b) インシデント対応のポリシーと計画を検証して承認し、その実施を指揮する
c) インシデント対応計画の見直しと改訂を行う
d) インシデント対応チームの内外において必要な調整を行う
a) セキュリティポリシーを確立し、その実施計画を作成
するb) セキュリティプロセスを実施する
c) リスクの優先順位を調整する
d) 上位組織及びその他のサードパーティとの連携体制を構築する
e) 経営陣をサポートする
f) 対象組織に関する脆弱性レポートを検討、登録、承認
するg) マネージャが指示したその他の活動を行う
a) 監視と運用に関する日常業務を行うb) 侵入を検知し、インシデントを登録し、初期対応を行うc) セキュリティ関連の更新を行うd) セキュリティポリシーを実施し、経営陣をバックアッ
プするe) ヘルプデスクf) 施設マネジメントg) マネージャが指示したその他の活動を行う
a) インシデントの周知と報告を行う
b) 監視システム間の相関分析を行う

2020/3/18

Page 48 of 51

ー 102 ーIMDRF/CYBER WG/N60FINAL:2020のサービスを提供する
実施グループ

インシデント対応に関する作業全般を実施する

分析グループ

インシデント分析を行う

c) インシデントを調査し、復旧作業をサポートするd) 対象インシデントの脆弱性分析を行う
e) マネージャが指示したその他の活動を行う
a) インシデント対応の要求事項を分析するb) インシデント対応のポリシーとレベルを決定する
c) インシデント対応のポリシーと計画を実施する
d) インシデント対応計画を提案する
e) インシデント対応作業の内容と報告を要約する
f) インシデント対応に必要な資源を展開して利用する
g) マネージャが指示したその他の活動を行う
a) チームと製造業者のための脆弱性分析を計画する
b) セキュリティ分析のためのツールとチェックリストを改善する
c) 監視規則を改善するd) ニュースレターを発行する
e) マネージャが指示したその他の活動を行う

2020/3/18

Page 49 of 51

ー 103 ーIMDRF/CYBER WG/N60FINAL:2020

8.2

附属書 B：協調的な脆弱性の開示に関する各地域のリソース

オーストラリア
CERT Australiac (CERT オーストラリア)
https://www.cert.gov.au/

AusCERT
https://www.auscert.org.au/
ブラジル
All Certs in Brazil(ブラジル国内の CERT 一覧)
https://www.cert.br/csirts/brazil/
カナダ
Canadian Centre for Cyber Security(カナダサイバーセキュリティセンター)https://www.cyber.gc.ca/
欧州
CERT European Union(CERT 欧州連合)
https://cert.europa.eu
フランス
ANSM
https://ansm.sante.fr/

https://www.ansm.sante.fr/Declarer-un-effet-indesirable/Votre-declaration-concerne-undispositif-medical/Votre-declaration-concerne-un-dispositif-medical/(offset)/0
French Ministry of Health and Solidarity(フランス厚生省)
https://solidarites-sante.gouv.fr/soins-et-maladies/signalement-sante-gouv-fr/
Shared Health Information Systems Agency(共有医療情報システム庁)
https://www.cyberveille-sante.gouv.fr/
ANSSI - National Agency for Information Systems Security(国家情報システムセキュリティ
庁)
https://www.ssi.gouv.fr/en/
ドイツ
CERT Germany(CERT ドイツ)
https://www.cert-bund.de/イタリアhttps://www.csirt-ita.it/

2020/3/18

Page 50 of 51

ー 104 ーIMDRF/CYBER WG/N60FINAL:2020

日本
Japan Computer Emergency Response Team/Coordination Center(JPCERT コーディネーショ
ンセンター:JPCERT/CC)
https://www.jpcert.or.jp/vh/top.html or https://www.jpcert.or.jp/english/
シンガポール
SingCERT
https://www.csa.gov.sg/singcert/news/advisories-alerts
米国
Industrial Control Systems CERT(産業制御システム CERT:ICS-CERT)
https://www.us-cert.gov/ics

US CERT(CERT 米国)
https://www.us-cert.gov/

2020/3/18

Page 51 of 51

ー 105 ー

Ⅳ 医療機器のサイバーセキュリティに関する IMDRF と日本のガイダンス比較表

ʞʡʙʥʛ
̫̲̔͑
'ĄǮ
̫̔̿
ƥȃĺ
|
ǈɆǔǧ

cƤť̣̹̩̜̰̔͗͌͐̓˷jRo˻¼ɀ
cƤť̣̹̩̜̰͔̜͕̟̟̔͗͌͐̓͗͑͗̿
̳͏̲̽ʍʋʌʔʊʓʊʌʑ
ǋˏ̧̙̲͗͏͐̒ˏ̾͏̦͑ˏ̴̬̚ˏ ˏʚʨˏĺŐˏ͓̥̒ˏ̛̥͕̈́͗͑ˏɸ
ɭcƤťȏQæÍ̘̽͗͏͇

ƪŧʌʉʋʃ˸˥̄˶

EÁIɿ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˸ˏcƤťo˻ƣɨ̶̮̲͔̞͗̏)ƚǵ˶ˤ˱ˏ̧̠̀͑̒ĶȚ˶˘˕˱úǮ ͙ǴŅ͚̣̹̞́̔͗͐˳˸ˏ˩˖ˤ˫·Aø̆2ɽø˚Ġ˵̎̌ˏg¿͙ʲʫʺʶ͚͙ˊ͚͠˚Ƙ˥̧̞̋͐˳ǭ˗̉̌̋ː
̠̒˷ĝ+̏ ĳˢ˨˱˛˫ː˩˖ˤ˫͕̥̱͕̲̔˸ˏȝĳo˻͞n˸ŰƤ˷ɒ̌ˏȝĳo˻͞n˸ŰƤ˷̗͏͗˵˴˶
̈ˮ˱ˏúǮg¿˶ǻ̋˙̅ˤ̌˵˕ː

C{ȶ
ÆȱǮ

̧̠̀͑̒Iɞ˷O¿ɤ/Ǯ˸ˏcƤť˷̣̹̩̜̰̔͗͌͐̓˶ɤˤ˱C{ȶ̏ĕ˯ːȘɄ˵ˤˠ˷̧̛̬͕̔˸ˏA˱˷O¿ɤ/Ǯ˚ˏ̣̹̩̜̰̔͗͌͐̓̏ƿŞƦ˶Ħğ˦̋˫̄˷èT̏Ɩȓ˦̋˫̄˷Ħğ̏ ͙͠ʉƪƦ͚Ơ̧̬͕̋̔˷ƪƦ˸ˏ̣̹̩̜̰̔͗͌͐̓ɍƲ˶̈̊Ƹˢ̌˫ȋɏȴ¥ŝǮ˚ȃ˖˾˛̣̹̩̜̰̔͗͌͐̓
ȃ˕ˏÉœ˷ĨĤˏɾn˸ȱ̏ ōˤ˱ˏcƤť̏1Ȱˤ˱̩̜͌̒˶˦̋˫̄˷Ħğ̏ĝ+˦̋ː˽˷rǔ˶˯˕˱ˏcƤť˽˷ɢƥ͖Țȕ͙ÓȴS͚o˻Óȴë˷Æó̏̈̊D$Ʀ˶˦̋˫̄˷ü ̏ĝ+˦̋ˠ˳˲˔̋ː̧̠̀͑̒˷̣̹̩̜̰̔͗͌͐̓˷jRo˻¼ɀ̏ɭƦ˶įzˢ˨̋ˠ˳˸ˏúǮ·Ao˻cƤť˷øǵ̏ǝĕ ȘɄ˵ˤ˦̋ˠ˳̏ƶ¼˶˦̋˫̄˶òȍ˲˔̋ːˤ˙ˤˏƕłƆ˷ȏQ˸ĩÝ˶̈ˮ˱Ƣ˵ˮ˱˕˱ˏcƤť˷̣̹̩̜̔͗͌
̰͐̓̏ƶ¼˶˦̋˫̄˶òȍ˵ɭįz̏ĝ+˦̋˶ǻˮ˱˕˵˕ː
ˠ˷ʞʡʙʥʛ̧̛̬͕̔İŇ˷ƪƦ˸ˏǼjR˶Æ˦̋ƷƦ˵ǭ˗ĵo˻ŜȖɺ˻˶cƤť˷̣̹̩̜̔͗͌ ȘɄ˵ˤ̰͐̓˶ɤ˦̋ɭįz̏ÁĿ˶˦̋˫̄˷̧̲́̿͏̧̞̰̓̏ĝ+˦̋ˠ˳˲˔̋ː
ˠ˷İŇ˸ˏcƤť˷̣̹̩̜̰̔͗͌͐̓˶Əbˤ˫ŉL˷ʞʡʙʥʛ̧̛̬͕̔İŇˬ˚ˏØÛ˜̩̜̰͌͐̓̏ŜȖ˦ ȘɄ˵ˤ̋ɭ˶ŵþ˦̋ˠ˳˚Ṓˤ˕˩˷˷ɤɐ˦̋ʞʡʙʥʛİŇ˚˔̋ːʃʞʡʙʥʛʊʜʥʥʤʃʪʜʊʢʏʒʃʛʞʢʖʠʕʃʍʋʌʓ˸ˏcƤťo˻$§ȝĳƚ͙ʳʷʃʾʳʼʺʸʃʮʳʫʱʷʸʻʼʳʭʕʃʞʩʙ͚cƤť˷Țȕo˻ȋɏ˶˘˕˱ƀȾ˦˾˛ŐȍƂ̏ĝ+ˤ˱˕̋ʃʃː
ˠ̌˸ˏcƤť˷A͏̣̞̔̽̔͑˶̎˫ˮ˱ˏˠ˷̧̛̬͕̔İŇ˳ǟ˶ŜȖ˦̋ˠ˳˚Ṓˤ˕ːʞʡʙʥʛʊʦʫʡʙ
ʪʜʊʢʌʍʃʛʞʢʖʠʕʃʍʋʌʏ̅ŵþ˦̋-5˚˔̋ːˠ̌˸ˏ̩̞̥͎͕ʔʉʎ˶˘˕˱ˏ·Ȁǭă˦̋ɭ˷ü ̩̜̰͌͐̓˷ɝ
ȍø˶˯˕˱ȘɄˤ˱˘̊ˏcƤť˳ˤ˱˷̪̲̖͙̽̒̕ʦʸʰʼʿʫʺʯʃʫʻʃʡʯʮʳʭʫʵʃʙʯʾʳʭʯʕʃʦʫʡʙ͚˷ü ̩̜̰͌͐̓˶çɹ˦̋˕˜˯˙˷ȍ̏Ȩľˤ˱˕̋ː

ɭįz̏ÁĿ˶˦̋˫̄˷ü
ɤɐİŇ

İŇ˷ȩǮ

 IMDRFIII   

̢͈͕̲͖Ȩľ

úǮg¿ɭįz˷òȍø

ʍʉʋʃɗƚǉĺŐcƤť˷̣̹̩̜̰̔͗͌͐̓˷ƶ1˶ɤ˦̧̛̬͕̋̔
ȁƘťÅƥʋʒʍʏǄʌx͖ȁƘ·ƥʋʒʍʏǄʌxɍƲʍʋʌʓʊʒʊʍʏ
ĺŐiƘ[;ƭˠ˷İŇ˸ˏcƤť͙$§ȝĳƚ͙ʳʷʃʾʳʼʺʸʃʮʳʫʱʷʸʻʼʳʭʕʃʞʩʙ͚cƤť̏͚̃˷̣̹̩̜̰̔͗͌͐̓˶Æ˦̋ǼjR ͙ǴŃ͚ȋɏȴ¥ŝǮ˸cƤť˽˷ûþ̏ĕˮ˫̣̹̔͗ĨĤ˶Æˤ˱̅ˏ)ƚƗ¢̏̄˫cƤť˷Əð˶ó˥
o˻̧̲́̿͏̧̞̰̓˶˯˕˱ˏA˱˷ȶɤ/Ǯ˶Æˤ˱¸A˵ě¬ɺ̏ĝ+˦̋ƪƦ˲'Ąˢ̌˱˕̋ːA$˳ˤ ˱ˏ̣̹̩̜̰̔͗͌͐̓Æó˶̅r̊ǔ̐˲˕˜òȍ˚˔̋ː˱˸ˏȋɏŝǮˏ̧̠͓̹̬̀͑̒̿̔ˏȏQæÍo˻͍̤͗˶Æˤ˱ˏɗJ˵̣̹̩̜̰̔͗͌͐̓1Ȱ̏ŋ˦̋cƤť˷Țȕɢƥ˶̧̧̞͓̭͐́͗̒̿͗̏)ƚˤˏþ˦̋ƪƦ˶Æˤ˱cƤť̏)ƚ˦̋ɭ˶ȼˠ̊˖̧̞̋͐̏ŉËbˤˏɝȍ˵cƤť˷·Ao˻ŋ\ø˚ǝĕˢ̌Ǜǜˤ˱)ƚ˦̋ˠ˳̏ƶ¼˶˦̋˫̄˷ě¬ɺ̏Ȩľˤ˱˕̋ː

ʞʡʙʥʛ˲˸O¿ɤ/ǮA˱˚Æȱːi[ƭ˷̧̛̬͕̔˸ȋɏȴ¥ŝǮ˚Æȱː˒̧̠̀͑̒˷˓˔̋˚ˏÆȱ˸cƤťː̧̠̀͑̒ȋ̈̊̅kˤ˕ȏQ˚Ȫˢ̌̋ǉːEÁ˸Ƣ˵̋˚ˏmǭmǭȹĲ˃ʃ˒cƤť͓̟̿͏͇˷ĊȤƜȬ˶ɤ˦̧̛̬͕̋̔˷BȆ˶˯˕˱˓͙ÙĄʍʓʃÚʎʃŊʎʌʃĺ˞iƘ[;ƭcȁ͖ƘŷȅƘÍcƤť͖FƘcƤǅ
ȋďæm¹¾^ɐǗ͚˃ʃcƤü ̧̥̰͇˷·AǈƖ˶ɤ˦̛̳̋̔͏͕̔Ǆʐʃƌ͙iƘ[;ƭʃÙĄʍʔʃÚʐʃŊ͚˃ʃ˒cƤü ̧̥̰͇˷·AǈƖ˶ɤ˦̛̳̋̔͏͕̔Ǆʐʃƌ˓˶ɤ˦̋ͯ͘
ͪʃ͙iƘ[;ƭʃÙĄʍʔʃÚʐʃŊ͚˃ʃͮͪͬͭͱŢƂʃʌʒʈʋʋʑʃ˒ȋɏŝǮ˶̈̋cƤü ̩̜̰͌͐̓ɢƸŇ˓̛̳̔ʩʯʺʉʎʉʋʫ͙Ǽƹų16cƤƻƺü ̧̥̰͇ÑŝʃʍʋʌʒʃÚʒʃŊ͚˃ʃͮͫͱͰͪʃͲͰͧ͜͟͟͢ʅʗ͜ʍʋʌʓʃ˒ȋɏŝǮ˶̈̋cƤü ̩̜̰͌͐̓ɢ
ƸŇ˓̛̳̔ʩʯʺʉʎʉʋʫ͙ǼƹųĺŐƝ<cƤ̧̥̰͇ÑŝʃʍʋʌʓʃÚʎʃŊ͚EÁ˸Ƣ˵̋˚ˏɿ!
͙͢ʉʃ̣̹̩̜̰̔͗͌͐̓Æó͚cƤť˶/̣̹̩̜̰̋̔͗͌͐̓˽˷
Æó˶˯˕˱˸ˏȋɏȴ¥ŝǮ˶̈̋Æó˸̅˭̍̐˷ˠ˳ˏ)ƚǮ7˶˘˞̋æȢcƤť˷ɗJ˵)ƚˏǝĕǈƖˏ˒·AǈƖ̛̳̔͏͕̔˓˶˰˜ü ̧̥̰͇˷ǝĕǈƖǅĺ×˷ɗJ˵ǈƖ˚ɝȍ˲˔̋ːi[ƭ˷¡zˏ)ƚǮ˷ǉ˸ľƶː͙͢ʉ͡ʃ)ƚǮ˶̣̹̩̈̋̔͗
̜̰͌͐̓Æó͚˶˒cƤťɤǅ˷)ƚǮ˓˳Ƹˢ̌˱˕̋ː

ɗƚť˷ǉˠ˷İŇ˲˸ˏŧ˷cƤť˶ɤ˦̣̹̩̜̰̋̔͗͌͐̓˶˯˕˱ŜȖˢ̌˱˕̋ͨʌʄ͇̖̽̑͗̒̕o˻͓̟̿͏̾ͅ
̢͓̦̮̞͕̲͓͑͗͏̏̃ˏ̪̲̖̽̒̏̕ŋ˦̋cƤť͙*̧͈ͨ͂͗͗̚ˏɅŻ͕͚̈́̿ˏʍ͚̪̲̖̽̒̕fƒ˲³˦̋cƤť͙*ͨcƤť˳ˤ˱˷̪̲̖͙̽̒̕ʻʸʰʼʿʫʺʯʃʫʻʃʫʃʶʯʮʳʭʫʵʃʮʯʾʳʭʯʕʃʦʫʡʙ͚͚ː

g¿˷vǵø˷ŜȖˠ˷cƤť̧̛̣̹̩̜̰̬͕̔͗͌͐̓̔˷ɗƚǉ˸ˏúǮg¿˷vǵø̏ŜȖ˦̋ˠ˳˶ɧºˢ̌˱˕̋ˠ˳˶ŵ ͙ǴŃ͚ˠ̌̉˷ȍǏ̏ƀ˫˦˾˜ˏ̧̣̹̞̔͗͐˶Æ˦̶̧̞̦͈͕̲̋͐̏ͅǭ˗̋ɭ˶˸ˏìœȃ̎̌˱˛˫ˏŧĪ ̣̹̩̜̰̔͗͌͐̓˶̈̋g¿˚ìœ˳Ƣ˵̋Ɔ˶˯˕˱˷Ȕo˸˔̋þ˦̋ˠ˳˚ɝȍ˲˔̋ːɮ̆ȧĥ'ǅ̧̞̏͐ȍ˳ˤ˱ė˗̶̧̞̦͈͕̲̋͐ͅ˶W˗˱ˏûþ̏ĕˮ˫ĨĤǮ˷³ǅ̧̞̅͐ȍ˳ˤ˱ė˗ ˚ˏúǮg¿˷vǵø̏˴˷̈˖˶ŜȖ˦̌˹̈˕˙˶˯˕˱˷ü ˸˵˱ŜȖ˦̋ˠ˳˚òȍ˳˵̋ː˕ː͙͡ʉŜȖ˚òȍ˳˵̋cƤťo˻)ƚƗ¢˷Əº͚cƤť˶˘˞̧̣̹̞̋̔͗͐˷˖˭ˏcƤť̏ƚ˕˫ȝƤ̏s˞̋Ǯ͙úǮ͚o˻cƤť˷)ƚǮ˶Æ˦̋ɮ¿˶/̧̞̋͐˸ˏ=?Ʀ˶Æó˦̋ˠ˳˚òȍ˲˔̋ː̿͏̹̥̔͗

̱̫͗̿͏̹̥̔͗˷.¿˶ɤ/˦̋̈˖˵˩˷˷g¿̅ɝȍ˲˸˔̋˚ˏˠ˷İŇ˷ɗƚǉ˲˸ǭăˤ˵˕ː͙ǴŃ͚͙ˊʌʃcƤť˷̶̧̞̦͈͕̲͐ͅ˷ȏŘ˲˔̋ʟʞʦʃʧʃʌʏʔʒʌʕʍʋʌʍʃ˲˸ˏg¿͙ʲʫʺʶ͚̏˒˷s˞̋ɂ$Ʀ:¿Ǿˤ˜˸6àɮ¿ˏn˸ȳƙǾˤ˜˸Ɨ¢˷s˞̋¿˓˳ºǪˤ˱˕̋ːƠ̧̬͕̋̔˲˸ˏúǮ̆cƤť˷)ƚǮ˶Æ˦
̋·Aø˶/̋g¿̏Ǆ˶ýºˤ˱˕̋˚ˏcƤť˷ȋɏȴ¥ŝǮ˸4ü ˷ƃŶǅ˷g¿˶˯˕˱̅dI˵Æó̏˦̋ˠ˳˚ƹƦ˶Ů̄̉̌˱˕̋ˠ˳˶dI˶Ɵþ˦˾˛˲˔̋ː͚

ŵɜ̩̞̥͎͕ʐʉʓ˶˸ˏũ̧̞̩̒˙̉˷1Ȱ˷̈˖˵ˏü ̩̜̰͌͐̓o˻̣̹̩̜̰̔͗͌͐̓˷ɝȍ˵ȍŮɺ̏ȘɄˤ˱˕̋ːˠ̌˸ˏcƤť˷A͏̣̞̔̽̔͑˶̎˫ˮ˱ˏˠ˷̧̛̬͕̔İŇ˳ǟ˶ŜȖ˦̋ˠ˳˚Ṓˤ˕ːȘɄ˵ˤʎʉʋʃºǪƚȥ˷ºǪȹƙˏĨĤˏȤȞˏƯũøˏŤɧˏvƚøˏCɍǷãø̧̢̧͕̟̥̰͇̒͐ˏȊ¸Ʀ̧̢̞͕̲͓͐͗͑Ĉū͙Ȋ¸Ʀ ͙ǴŃ͚ǼƦ˶ˏü ̩̜̰͌͐̓˶˸ˏü ˷ťÃøˏ¸Aøo˻vƚø˷͢˯˷ȍǏ̏ƶ1˦̋ˠ˳˚Ů̄̉̌̋ː
Ĉū͚ˏťÃøˏeȫƦ˵Ƿãø˷ɢƸˏ̣̹̩̜̰̔͗͌͐̓ˏȋÇǓ ˏ̣̲̈́͗Ǔ ˏûƚˏ¸Aøˏ̛̥͒͗c ťÃø͙ʘʸʷʰʳʮʯʷʼʳʫʵʳʼˀ͚˳˸ˏũæ˵Ťɧ̏̅˯ɧ̉̌˫Ǯ˷̂˚ˏțvˢ̌˫ǉE˲ü ˶̧̞̩̒˲˛̋̈˖ˏ1Ȱ͖Ƥťˏ~ȤɥŨˏ̺̮̭ˏúǮg¿ˏ̿͏̹̥̔͗ˏ̩̜̰͌͐̓ˏǶ²ˏǶ²͉̱͕̟͐ˏ̮̱̲̒̿͗ˏ̹̱̥͎͕͐͗ˏ ǈƖˢ̌˱˕̋ˠ˳̏Ė˦ː¸Aø͙ʞʷʼʯʱʺʳʼˀ͚˳˸ˏ̱̫͗˷ũæøˏũƶøo˻ȵø˚ǝĕˢ̌ˏɗJ˵¦ņ˚ȃŜȞˏǷãø
̎̌˱˕˵˕ˠ˳̏þˤˏþˢ̌˫)ƚĵų˷˲cƤť˷ťǵ̆øǵ˚ƶ1ˢ̌ˏúǮü ̆ȝĳǖŕǅ˷ũƶø˚1˫̌˱˕̋ˠ˳̏Ė˦ː˩ˤ˱vƚø͙ʖʾʫʳʵʫʬʳʵʳʼˀ͚˳˸ˏòȍ˵˳˛˶̧̥̰͇˚ũƶ˵̧̣̻͗̏ĝ+˲˛̋ƑĀ˚ǝĕˢ̌˱˕̋ˠ˳̏Ė˦ːʏʉʋʃǼjR

·Aøo˻ŋ\øȟ-˷˫̄˷ ˠ˷̩̞̥͎͕˲˸ˏ̶̧̞̦͈͕̲͙͐ͅʞʦʣʃʌʏʔʒʌ͚o˻Ⱥ̶̧̦͈͕̲̥̰͇͙ͅʞʦʣʃʌʎʏʓʐ͚˶˰˕˱ˏɤɐ˦̋O¿ ͙͠ʉƪƦ͚ȋɏȴ¥ŝǮ˚Ơ̧̬͕̋̔̏mǭ˶ɗJ˵Æó̏¼Ķ˦̋ˠ˳˶̈ˮ˱ˏ̣̹̩̜̰̔͗͌͐̓˶ɤ˦̧̞̋͐
jR
ɤ/Ǯ˚cƤť˷·Ao˻ŋ\ø̏ƶ¼˶˦̋˫̄˷ǼjȐƸ˦ː
˷#žˏcƤťŐœ˷ŋ\øo˻·Aø˷ƶ1˚̉̌ˏúǮ˽˷̧̞͐˷#ž˶Ǧ˚̋ːʧʤʠʘ˲̶̧̞̦͈͕̲͐ͅ˦̋òȍ ̣̹̩̜̰̔͗͌͐̓˷Ƕ²o˻Ƿãø˶ɤ˦̧̞̋͐˸ˏLōŠýūɫ˙̣̲̉̈́͗Ǔ ͙ʯʷʮʃʸʰʃʻʽʹʹʸʺʼʕʃʚʣʦ͚˶ǻ͏̣̞̔̽̔͑˳˸ˏɢƥ˙̉)ƚ̏Ǔ ˤƵŚˢ̌̋́˲˚Őœ˷ōɣ˲˸˔̋˚ˏˠ̌˳˸N˶cƤť˷Țȕ͖ȋɏø̋ˏcƤť˷ȋÇ˷A˱˷ūɫ̏ɍˤ˱ŜȖ˦̋ˠ˳˚Ṓˤ˕ː̣̹̩̜̰̔͗͌͐̓˷̴̬̮̞̔͆˵øȺ̏\ ł˶˸ǯƚōɣ˚Əºˢ̌˱˕̋ːycƤť˷ǯƚōɣ˶˯˕˱˸ˏɍ×ˏżİŇ˶˒1ǈĵųo˻ŋ\ōɣǅ˓˳ŕƦ˶ǈƖ˦̋˫̄˶˸ˏ̶̧̞̦͈͕̲͐ͅ˸̲̫͗͑ȋ͏̣̞͙̔̽̔͑ʼʸʼʫʵʃʹʺʸʮʽʭʼʃʵʳʰʯʃʭˀʭʵʯʕʃʧʤʠʘ͚˶̎˫ˮ˱ɗ ˤ˱ȘɄˢ̌˱˘̊ˏȋɏȴ¥ŝǮ˸ˏÌ˵˜˳̅ˠ˷ōɣ˸ˏæȢcƤť˶˯˕˱̣̹̩̜̰̔͗͌͐̓˽˷Æó̏ȃ˖ƚˢ̌̋ˠ˳˚Ṓˤ˜ˏ̣̹̩̜̰̔͗͌͐̓˷̧̞͐˸ˏȚȕˏȋɏˏȠʁo˻ÓȴëƨȐ˷ŷ]˶˘˕˱ˏȟ-ˢ̌ˏ ˠ˳˚òȍ˳˵̋ː́˫ˏĹHǿȋ˶˯˕˱ɗJ˵ǷãøǈƖ˚˲˛˵˕¡zˏȋɏȴ¥ŝǮ˸ˏȋ˷ĉ˕˶ɤ˦̋Ǣ ˢ̌̋ːü ̏)ƚǮ˽Ɏ̆˙˙˯ɗJ˶˗̋˳˳̅˶ˏ)ƚǮ˳ɐĢˤ˱Æó˦̋ˠ˳̅òȍ˳˵̋ː͚

ʏʉʌʃȋ͏̣̞̔̽̔͑˷A$

͙͡ʉ͠ʃÆȱ˳˵̋cƤť͚Ơ̧̬͕̋̔˷Æȱ˸ˏcƤť˷˖˭͓̟̿͏͇̏)ƚˤ˫̅˷͙cƤť͓̟̿͏͇̏
̃ː͚o˻Ðǅ˶͓̟̿͏͇̏̃̅˷˲˔̋ːcƤť˷̞͏̧Iɿ͙ˋͳˌ͚̏̎˵˕ː
ŐƦ˶ˏcƤť˳Ěǜˤ˱)ƚ˦̋n˸(ƚˢ̌̋ʞʧʃťǅ͙f$˲cƤť˶Ȣæˤ˵˕̅˷˲ˏ͓̟̿͏͇f$˷¡z̏̃ː͚̏cƤť˷ŠĄ͙Ðǅ͚˳ˤ˱ĝ+˦̋¡z˸ˏƠ̧̬͕̋̔˷Æȱ˳˵̋ː̧̣̹̩̜̰̞̔͗͌͐̓͐˷ȟ- ť˷·Aø˳Őøǵ˶çɹ̏ò˦ˏǹÜĈċ˶ûçɹ̏ò˦ˏn˸ˏȝĳǾˤ˜˸ŰƤ˷̗͏͗˶˯˵˚̣̋̔ ȘɄ˵ˤ˷ĵ̹̩̜̰͗͌͐̓˷̧̞͐˶˯˕˱̅ˏcƤť˷̶̧̧̞̦͈͕̲͓̩͐̿ͅ˶˘˕˱ŜȖˢ̌̋ˠ˳˚Ṓˤ˕ːˠ˷ǭăɺ˸ˏʖʖʡʞʃʧʞʥʐʒʕʍʋʌʑʃ͙cƤť̩̜̰͌͐̓˷jRˍ̶̧̞̦͈͕̲͚͐̏ͅpŀˤ˫̅˷˲˔̋ːʖʖʡʞʃʧʞʥʐʒ˲˸ˏ
cƤť˷̣̹̩̜̰̔͗͌͐̓˶ɤ˦̧̞̋͐˸ˏ͙ʞʦʣʃʌʏʔʒʌ˶ȏº˦͚̋úǮ·A˶Æ˦̋g¿̏̂ˏ̣̹̩̔͗
̜̰͌͐̓˷̧̞͐˶̈̋ɣĚƦ˵úǮ˽˷g¿˶̅ɤɐˤ˱˕̋ˠ˳̏Ƹˤ˱˕̋ː̶̧̧̞̦͈͕̲͓̩͐̿ͅ˷ɚ˳
ˤ˱ˏȋɏŝǮ˸ŧ̏ȃ˖ˠ˳˚Ṓˤ˕ːˉ̣̹̩̜̰̔͗͌͐̓˷Ƿãø̏Əº˦̋ˉɤɐ˦̧̞̋͐̏ěºˤˏȟ-˦̋ˉ̧̞͐̏sÁvǵ˵͒́͑́˲̢͕̲͓͗͑˦̋
ˉ̧̢̞͕̲͓͐͗͑˷ŋ\ø̏ƨȐ˦͙̋͢ʉ͠ʃȋɏȴ¥ŝǮ˶̣̹̩̜̰̈̋̔͗͌͐̓Æó͚ȋɏȴ¥ŝǮ˸ˏþˢ̌̋)ƚƗ¢˶˘˞̧̣̹̞̋̔͗͐˶Æ˦̶̧̞̦͈͕̲̋͐̏ͅ¼Ķˤˏòȍ˵ÆǇ̏ȃ˕ˏ˩˷ǖŗ̞́͐˚sÁvǵ˶˵̋ˠ˳̏Ȩľ˲˛̋̈˖˶˦̋ˠ˳ː̶̧̞̦͈͕̲͐̏ͅȃ˖˶æ˫ˮ˱˸ˏcƤť˷þˢ̌̋)ƚĵųˏ)ƚǮˏ)ƚƗ¢ǅ̏ǭăˤ˫̧́͗͏͕̔̏º̄˱¼ĶˏŜȞ˦̋ˠ˳˚Ṓˤ˕ːʏʉʍʃC{ȶO¿ɤ/ǮA$˷ȶʏʉʎʃü CŋüʏʉʏʃȮNˏɥȅˏŜƲˏÆóo˻ïĻ˷ǵUʢʞʦʧ˷̣̹̩̜̰̔͗͌͐̓̽
͇͔̞͒͗͗

Cŋ˳˩̌˪̌˷èTcƤť˷̣̹̩̜̰̔͗͌͐̓˸ˏO¿ɤ/Ǯˏ˦˵̎˭ˏȋɏŝǮˏ̧̠͓̹̬̀͑̒̿̔ˏȏQæÍo˻Ƿãøƥ ȘɄ˵ˤȎǮ˷C{ȶ˲˔̋ːA˱˷O¿ɤ/Ǯ˸ˏcƤť˷͏̣̞̔̽̔͑A$̏ɍˤ˱ˏƅƦ˵̣̹̩̜̰̔͗͌͐̓͐
̧̞o˻Ƕ²̏ǛǜƦ˶ƨȐˤˏȟ-ˤˏǢ ˤˏ̵̢̠̥͎͕͆͌͗̏ȃ˖ȶ˚˔̋ː̣̹̩̜̰̔͗͌͐̓˶ɤ˦̋ü ˷Cŋ˸ˏ·A˲̩̜͌̒˵cƤť̏¼ƕ˦̋˫̄˷̲̫͗͑ȋ͏̣̞̔̽̔͑ ȘɄ˵ˤ͙ʼʸʼʫʵʃʹʺʸʮʽʭʼʃʵʳʰʯʃʭˀʭʵʯʕʃʧʤʠʘ͚͓̭̒̿͗˷ƷjR˲˔̋ːA˱˷O¿ɤ/Ǯ˚ˏÓȴSo˻Óȴë˷̣̹̩̔͗
̜̰͌͐̓˶Æˤ˱ƿŞƦ˵͓̭̒̿͗̏r̋ˠ˳˚¬Zˢ̌̋ː̫͇̔͐͗˶ü ˚í̉̌̋ˠ˳˶̈ˮ˱ˏA˱˷ȶæǮ˚ˏǶ²̏Əºˤˏɤɐ˦̧̞̋͐̏ȟ-ˤˏ˩̌˶ɗ»˶Æó˦̋˫̄˷ǵU˚ēäˢ̌̋ː˩˷˫̄ˏA˱˷ȶɤ/Ǯ˸ˏcƤťo˻Ěǜ˦̧̠͕̋̀͑̒̔̽͏˷·Aøˏŋ\øˏ¸Aøo˻̩̜̰͌͐̓˶çɹ˦̋˙̅ˤ̌˵˕̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔ˏǶ²o˻Ƿãø˶Æ˦̋eUo˻̵̢̠̥͎͕͆͌͗̏ƥÏˢ˨̋˫̄˶ˏü C
ŋIŔťɤ͙ʞʷʰʸʺʶʫʼʳʸʷʃʦʲʫʺʳʷʱʃʖʷʫʵˀʻʳʻʃʣʺʱʫʷʳˁʫʼʳʸʷʻʕʃʞʦʖʣʻ͚˶ƿŞƦ˶mW˦̋ˠ˳˚¬Zˢ̌̋ː˩˷̈˖˵r̊ǔ̂̏ȃ˖ˠ˳˲ˏɌľø̏}ˢ˨̋ˠ˳˚˲˛̋ː́˫ˏˠ˷ü Cŋ̥̈́͐͗̏ņ˶ƥÏˢ˨ˏȋɏŝǮˬ˞˲˵˜̧̠͓̹̬̀͑̒̿̔o˻cƤť͍̤͗˶̅ˠ˷̥̈́͐͗̏ɗƚ˦̌˹ˏˠ˷̢̧̗̥̰͇˶ŋƧ˳˵̋ːȏQæÍ˶˸ˏ
úǮ·ȀɭƦ˶1Ȱˤˏǝĕ˦̋˫̄˶ˏ˷ȏQæÍ˳ü Cŋ˦̋ˠ˳˚¬Zˢ̌̋ː

ǋǂŢƂċȄƴǀć͙ʢʫʼʳʸʷʫʵʃʞʷʻʼʳʼʽʼʯʃʸʰʃʦʼʫʷʮʫʺʮʃʫʷʮʃʧʯʭʲʷʸʵʸʱˀʕʃʢʞʦʧ͚˸ˏɝȍ͕̔̽͏˶ɗƚvǵ˵ǼƦ˵ ȘɄ˵ˤ͇͔̞̽͒͗͗˲˔̋ˇɝȍ͕̔̽͏˷̣̹̩̜̰̔͗͌͐̓̏ħ˦̋˫̄˷͇͔̞̽͒͗͗ˈ̏'Ąˤ˱˕̋ːʢʞʦʧ˷̽
͇͔̞͒͗͗˸ˏˠ˷İŇ˶ȘɄ˦̢͕̩̲̋̿˳eȫ˦̧̲̋́̿͏̧̞̰̓̏̐˲˕̋ːˠ˷͇͔̞̽͒͗͗˷ʐ˯˷
ñƦťǵ˸ˏȮNˏɥîˏŜƲˏÆóo˻ïĻ˲˔̊ˏcƤť˶ɗƚ˦̋ˠ˳˲cƤť˷̣̹̩̜̰̔͗͌͐̓̏ƫ˭˶åb˲˛̋ːȶɤ/Ǯ˸ˏŧ̏ŜȖ˦̋ˠ˳˚Ṓˤ˕ːˉť˷Țȕo˻)ƚƗ¢˶˘˞̣̹̩̜̰̋̔͗͌͐̓˷̧̞͐̏ȮN˦̋ˉšˑ˵̧̞͐Ǣ Ǉ˶̈ˮ˱̧̞͐̏#žˤ˱ˏť̏ɥȰ˦̋ˉ̣̹̩̜̰̔͗͌͐̓˷ȱ˶̈ˮ˱ť˚.¿ˢ̌˱˕̋˙̏ŜƲ˦̋ˉ̣̹̩̜̰̔͗͌͐̓˷ȱ˶Æó˦̋˫̄˶ ̄º̄˫̧͓̩̿̏ƚ˕˱Æó˦̋ˉ̣̹̩̜̰̔͗͌͐̓˷ȱ˷ë˲ť̏ɍ×˷ɓƚ˶Ć˦˫̄˶ˏ ̄º̄˫̧͓̩̿̏ƚ˕˱ïĻ˦̋ʏʉʐʃɭįzʐʉʋʃcƤťȋɏŝǮ˷˫̄˷ÓȴS˷ǭăɺ̣̹̩̜̰̔͗͌͐̓˷Æó˶ɤ˦̋ɭįz˷òȍøcƤť˷̣̹̩̜̰̔͗͌͐̓˸ˏɭƦ˵ɤñ˲˔̋ː̩̜̰͌͐̓˷͕̥̱͕̲̔˸ˏȝĳǾˤ˜˸ŰƤ˷̗͏͗̏ ȘɄ˵ˤâ˛ȼˠ˦ˏť˷·A˵øǵ̏Ƕ˙˦ˏǹÜ˷Ĉċ˶çɹ̏˗̋ˏ˔̋˕˸úǮ˷̞̰̠͐̓͑̒̚˽˷̧̞̩̒̏Đ~˦̋˵˴˶̈ˮ˱ˏƞ ˷̧̧̠̥̰͇̀͑̒˷úǮ·ȀǶ˙˦vǵø˚˔̋ːʃ̣̹̩̜̰̔͗͌͐̓˶Æ˦̋r̊ǔ̂̏ɭƦ˶įzˢ˨̋ˠ˳˸ˏ̷̥͎͕̔́͗̏0ɑˤˏ·A˲\ŕƦ˵cƤť̫͇̏̔͐͗˶úǮ˚Oƚvǵ˶ˤ˯˯ˏúǮ·Ȁǝĕ˦̋ˠ˳̏ƶ¼˶˦̋˫̄˶òȍ˲˔̋ːA˱˷O¿ɤ/Ǯ˸ˏcƤť˷͏̣̞̔̽̔͑A$˶Æ˦̣̹̩̜̰̋̔͗͌͐̓˷͓̭̒̿͗̏ɭįzˢ˨̋ˠ˳˚¬Zˢ̌̋ːˠ̌˶˸ˏȋȚȕˏcƤť˷͏̣̔̽
̞̔͑A$̏ɍˤ˫̶̧̞̦͈͕̲͐ͅŷ]ˏcƤť˷͏͕̟́͐ˏȏQæÍ˽˷ƜȬ˶Æ˦̋ȍŮɺˏü CŋˏÓȴëŷ]˶˯˕˱˷įzb˚́̌̋ː

Țȕɢƥūɫ˲ǭă˦̋ˠ˳cƤť˷̣̹̩̜̰̔͗͌͐̓˸ˏȋ˷͏̣̞̔̽̔͑A$˶̎˫ˮ˱ŜȖ˦̋ˠ˳˚Ṓˤ˕˚ˏȋɏŝǮ˚cƤ ȘɄ˵ˤť˷ÓȴS˷Țȕo˻ɢƥ ˶Æó˦̋ˠ˳˚Ṓˤ˕ɝȍ˵ȍǏ˚˔̋ːʃˠ˖ˤ˫ÓȴS˷ȍǏ˶˸ˏ̩̜̰͌͐̓
ťǵ̏ȋ˶'̊ˠ̃ˠ˳ˏsÁˢ̌˫̶̧̞̦͈͕̲͐ͅąƠ̏ɗƚ˦̋ˠ˳ˏ̩̜̰͌͐̓Ƞʁˏť̩̜̏͌̒˶ɓƚ˦̋˫̄˷͍̤͗˶Æ˦̋ŋƧ˵ü ĝ+o˻Óȴëŷ]˷˫̄˷ȕƝ̏ǂ˱̋ˠ˳˷ŜȖ˚́̌̋ː˷̩̞̥͎
͕˸ˏˠ̌̉˷̢͕̩̲̿̏ǒˤˏȋ˷͏̣̞̔̽̔͑˷ÓȴSūɫ˶˘˞̋ȋɏŝǮ˽˷ě¬ɺ̏ĝ+˦̋ːʐʉʌʃ̩̜̰͌͐̓ȍŮɺo˻̜̰̞̭̒͗͊ȚȕȚȕ͕̮̲̔̿

ʐʉʍʃ̶̧̞̦͈͕̲͐ͅ

ʐʉʎʃ̩̜̰͌͐̓ȠʁʐʉʏʃÓȴëǈƖ˷ąƠ̧̢̞͕̲͓͐͗͑

Țȕɢƥūɫ˲̩̜̰͌͐̓ťǵ̏'̊ɇ̃ˠ˳˶˯˕˱˸ȘɄ˵ˤȚȕūɫ˲̣̹̩̜̰̔͗͌͐̓˶ƿŞƦ˶Æó˦̋ˠ˳˶̈ˮ˱ˏs]Ʀ˵Óȴëŷ]ˬ˞̏ȃ˖̈̊̅úǮg¿̏̈̊ ȘɄ˵ˤǢ ˦̋ˠ˳˚vǵ˲˔̋ːʃˠ˖ˤ˫Țȕ͕̮̲̔̿˸ˏȋ˷͏̣̞̔̽̔͑̏ɍˤ˱šˑ˵ūɫˏ*˗˹ˏȍŮɺ˷ĘėˏȚȕŜȞȠʁn˸ÓȴSo˻Óȴë˷̶̧̞̦͈͕̲͐ͅŷ]˵˴˙͕̮̲̉̔̿ˢ̌̋ː
ʞʦʣʃʌʏʔʒʌʕʍʋʋʒ˒cƤťˍ̶̧̞̦͈͕̲͐ͅ˷ɗƚ˓˶ȏº˦̋ˏˤˮ˙̊ˤ˫̶̧̞̦͈͕̲͐ͅ˷jR˚ˏcƤť˷ ͙͢ʉʃ̣̹̩̜̰̔͗͌͐̓Æó͚˵˘ˏ̣̹̩̜̰̔͗͌͐̓˽˷Æó˶æ˫ˮ˱˸ˏɤɐ˷̧̛̬͕̔ˏȏŘˏċȄİŇˏ ˒ɤɐ˷̧̛̬͕̔ˏȏŘˏċȄİŇˏ˩˷˷ĵųǅ˷ŉĴ˷ü ̏m͏̣̞̔̽̔͑A$̏ɍˤ˱ǔ̂ɇ́̌˱˕̋ˠ˳˚Ṓˤ˕ːȋɏŝǮ˸ˏSɉ˷̩̞̥͎͕ʏʉʌ˷ʌ˷̈˖˶ˏȋɏo˻ ˩˷˷ĵųǅ˷ŉĴ˷ü ̏mǭ˶ˤ˵˚̉ˏcƤť˷)ƚƗ¢̏Ɂ́˗¼Ķ˦̋òȍ˚˔̋ː͙Òŏ˷˒mǭȹĲ ǭ˓˚˴ˠ́˲̏Ė˦˷˙ľːʞʦʣʃʌʏʔʒʌʃʚʮʉʎ˚ƥȃˢ̌̌˹¦̎̋˙̅ȋɏë˷ūɫ˶˘˕˱ˏ̧̞͐̏Əºˤˏěºˤˏ̢͕̲͓͗͑˦̧̰̮̋̿̏r̋ˠ˳˚Ṓˤ˕ːǅ˓o˻˒ȏŘˏȏŘİŇǅ˓̏mƊː͚ˤ̌˵˕˚ˏ˷˳ˠ̍ĺŐE˲˷Ėɟ˸˵˕ː

̣̹̩̜̰̔͗͌͐̓˷̧̞͐IŔ ̣̹̩̜̰̔͗͌͐̓˶ɤˤ˱ˏ̧̞͐IŔ˸ˏŧ̏ǭăˤ˱úǮg¿˷̧̞͐ȟ-˶ŵU˦̋ˠ˳˚Ṓˤ˕ːʌʄ̣̹̔͗ ȘɄ˵ˤ̩̜̰͌͐̓˷Ƿãø˷ûƚvǵøˏʍ͚Ƿãø˚ûƚˢ̌˫¡z˷úǮg¿˷ɝ©ˢːˠ˷IŔ˶˘˕˱˸ˏȊ¸ƦÆ
Ǉo˻̧̞͐Ǣ Ǉ˷ŜȖ̏ȃ˖ˠ˳˚Ṓˤ˕ː̧̧̞̩͈͕̲͐̒
̧̧̞̩͈͕̲͐̒˸ˏȚȕ̏Ƕ²͉̱͑ˏǹÜ˷̸̤̳͗ˏǢ Ǉo˻Ƞʁ˳ǖ˻˯˞̋ː̧̞͐˚ɗJ˶̶̦͈͕̲ͅ ȘɄ˵ˤˢ̌̋̈˖˵̩̜͌̒˵Țȕ̜̰̞̭̒͗͊̏ƶǂ˦̋ˠ˳˚ɝȍ˲˔̋ːˠ˷̧̩͈͕̲̒˲˸ˏšˑ˵̯͗͑o˻͓̭̒̿͗˚Oƚ˲˛̋ːˠ̌˶˸ˏ̧̧̩̜̰̞̩͈͕̲͌͐̓͐̒ˏǶ²͉̱͕̟͐o˻Ƿãø̧̢͕̟̒͐˵˴̏̃˚ˠ̌˶ɧºˤ˵˕ː

ʛʙʖ˷ÓȴŞ̛̬͕̔˚mǭ˳˵̋ː̩̜̰͌͐̓Ƞʁ˷şȍcƤť˷Țȕūɫ˷̹̱̥͎͕͐͗˶˘˕˱˸ˏ̩̜̰͌͐̓Ƞʁ˚ȍŮˢ̌̋ːȠʁ˲˸ˏcƤť˚)ƚˢ̌̋Ƒ ȘɄ˵ˤŲˏo˻cƤť˚Ïɢˢ̌̋Ɨ¢̏ǭă˦̋ˠ˳˚Ṓˤ˕ːƢ×˷̧̞͐̏ŉËɧ˶ˤ˱ˏ̪̲̖̽̒̕˚š˶ɗzˤ˱˕̋ˠ˳̏ƶ¼˶˦̋˫̄˶ˏ̪̲̖̽̒̕˷ŜȞċȄ̏ɗƚ˦̋ˠ˳˚ě¬ˢ̌̋ːʃcƤť˚ˏûƚvǵø˷˔̋ĹƲ˷Ƿãø˶Æˤ˱Ƞʁˢ̌˱˕̋ˠ˳̏ƶ¼˶˦̋ˠ˳̅ɝȍ˲˔̋ːˠ̌̏ȃ˖˫̄˶ˏcƤť˸̩̜̰͌͐̓ȟ-̧͓̩̿n˸s@ƶȤ̏s˞̋ˠ˳˚Ṓˤ˕ː͙*˗˹ˏ̪̲̖̽̒̕˷ȠʁˏĨĤ̥̥͎͕͆͌͒͗˵˴͚̩̜̰͌͐̓Ƞʁ˳˸ˏ̩̜͌̒˵ɢƥ͇͔̞̽͒͗͗̏ŠĄ˦̶̢͕͕̲̋̈́͗˷˺˳˯˲˔̋ːȠʁ˶ɤ˦̋ŜȖɺ˷ȣǑ˸ˏ̩̞̥͎͕
ʐʉʌ˶Ƹ˦ȏŘo˻ü Ɓ̏mƊːcƤťȋɏŝǮ˚ǭă˦˾˛"͒́͑˷ǭăɺ˷*̏˶Ƹ˦ː.@̧̰̲ǅ˚Ů̄̉̌̋˳ǭ˗̉̌̋˚ˏ˴ˠ˲˲˛̋˷˙ǅ̅ŜȖ˦̋˾˛ːD$Ʀ˵EÁ

ˉĹƲ˷Ƿãøn˸̪̲̖̽̒̕˷ãƆ˶˯˕˱ˏ̶̢̪̲̖͕͕̲͉̦̽̒̈́͗͌͗͑̕͞˷̡̫̮̲͗Ŝǐ̏ȃ˖ˠ˳ː*˗ ȘɄ˵ˤ˹ˏ̩̜̰͌͐̓Ƞʁ˶˸ˏɶƦ̢̳͗ȓŔˏ]ƦȓŔˏƍøȠʁˏǷãø̧̜͕͊ˏ̢̪̲̖͕̦̥͎͕̽̒̈́̕ȓŔ˚́̌̋ːˉċȄƦ˵̩̜̰͌͐̓IŔ͙.@̧̰̲˵˴͚̏ȃ˖ːċȄƦ˵̩̜̰͌͐̓IŔ˶˸ˏ*˗˹ˏ̨̧̰̲̽̑ˏn˸ˏɯˤ̽̑
̔͑ˏȚºˏ̧̱̫̲͇͗͐͗Ǿˤ˜˸̸̳̖͗̒̕˷̧̦̫͒˷ȩ̂Hˤ˵˴˶̈̋ň̗͕̲͕̲͐̈́̔ƶȤ˶̈̋ˏŎƲ˷Ƿãø˷ȮNo˻̭̖̮̞˚́̌̋ː
ˉǷãøȟ-̏ȃ˖ːǷãøȟ-˶˸ˏ˷Ǻƹȋ˶Æ˦̋Ƿãø˷çɹIŔ͙̹͕̲͐̒ȓŔ˵˴͚ˏÆčĈū˷ƏºˏǷãø˷3ũn˸Ǣ ˵˴˚́̌̋ː

{Ƿãø˶ɤ˦̋ǛǜƦ˵ƨṚ̹̩̜̰̏̔͗͌͐̓˷Ƕ²˚ǛǜƦ˶ɑbˤ˱˕̋˷˲ˏȋɏŝǮ˸ˏÓȴëǈƖąƠ˷Ɨ˳ˤ˱ˏǷãøo˻ûƚ ͙ͣʉÓȴë˷·Aøƶ1˶˯˕˱͚ȋɏȴ¥ŝǮ˸ˏʜʩʤʃƭ˶˰˛ˏcƤť˷Óȴë·AÆǇ˳ˤ˱cƤť˷ ɿ!˷EÁ˷ȘɄ˸˔̋˚ã˕˙̅ː˶Æˤ˱ƿŞƦ˶ƨȐˏƏºˏÆó˦̋ˠ˳˚Ṓˤ˕ːcƤť̏Ó¡˶Č@˦̋S˶ˏȋɏŝǮ˸ˏĴ˫˶ƥƘ˦̋ Dzü ̆İƔǅ̏qɱ͖ȫŖˤˏ˩˷ü ̏IŔˤ˱ˏòȍ˶ó˥˱ÆǇ̏ȃ˖ˠ˳˚òȍ˳˵̋ː̧̣̹̞̔͗͐˶
̣̹̩̜̰̔͗͌͐̓˷Ƕ²̏ǛǜƦ˶ƨȐˤ˱Æó˦̋˫̄˷ȕƝ̏'Ą˦̋ˠ˳˚Ṓˤ˕ːˠ˷ȕƝ˸ˏť˷͏̔ ˰˜Dzǅ˶˯˕˱̅ˏʜʩʤʃƭ˶˘˞̋·Aøü ˳ˤ˱r̊ĉ˕ˏȴ¥ŝǮ͖ȷŝǮ̆3ƖŝǮ˷eU˷̅˳ˏc̣̞̽̔͑A$̏ɍˤ˱ɗƚ˦̋ˠ˳˚Ṓˤ˕ːʃÓ¡Č@S˶'Ą˦̋ˏˠ˷ȕƝ˷ɚ˳ˤ˱ŜȖ˦˾˛ɺƪ˸ˏŧ Ƥťɤ˳ɐĢ̏r̊ˏɗJ˵Óȴë˷·Aƶ1̏ȃ˖òȍ˚˔̋ː̏̃ːˉÓȴëƨȐͨĴ˫˶Ȏ˯˙ˮ˫̣̹̩̜̰̔͗͌͐̓˷Ƿãø̏ƿŞƦ˶ƨȐˤˏƏºˤˏ˩˷Ƕ²̏ȟ-ˤˏÆó˦̋˫ ͙͢ʉ͡ʃ)ƚǮ˶̣̹̩̜̰̈̋̔͗͌͐̓Æó͚́˫ˏƒǂȃĩųü GƖěɑťŠ͙ʞʤʖ͚̩̜̰̩͕̫͌͐̓͗˲˸ˏ˒̢
̄˷ȕƝ̧͕̼̫͌͗̔͑̕ÆǇƂ˓͙ÙĄͥÚɍƙŝƭƸǄʏʍʔʃx͚ˏ˒̢͕̼̫͌͗ũ̧̞̩̒ÆǇƂ˓͙ÙĄͦÚɍˉǷãø˷BɢͨǷãøƥȎǮ˙̉˷ü ̏ɱǍˤˏǢ o˻3ũǇ̏ɢƥˤˏǷãø˷³o˻Ǣ n˸3ũĵų̏O ƙŝƭƸǄʎʑʍʃx͚o˻˒̪̲̖̽̒̕ȋǅ˷Ƿãøɤɐü ˶ɤ˦̋rĉȏº˓͙ÙĄʍʔʃÚǕŽƙŝƭƸǄʌʔ¿ɤ/Ǯ˶Bɢ˦̋˫̄˷ũá˵̧͓̩̿
x͚ˏ˶˰˛ˏ̢̧͕̼̫͖͌͗̔͑̕ũ̧̞̩͖̒Ƿãøü ˶ɤ˦̋ƥȎ͖ȇ¿˷ÎH̆ü ĝ+̏s˞˞ˏĝ+ˉ̺̮̭o˻̮̱̲̒̿͗ͨť˷·Ao˻øǵ̏ǛǜƦ˶ǝĕ˦̋˫̄˶ˏºōƦ˶n˸Əºˢ̌˫Ƿãø˶Æóˤ˱ˏ ̏s˞˫ü ˸ˏȇ¿˷ē©͖Fƥ˷ɥŨˏü ̩̜̰͌͐̓ÆǇ˷}˶èǂ˱̉̌˱˕̋ːȋɏȴ¥ŝǮ˸ˠ̌̉˷
̪̲̖̽̒̏̕˴˷̈˖˶̮̱̲̒̿͗˦̋˙̏şȨ˦̋ȕƝü ̏mǭ˶˦̋˳˳̅˶ˏƒǂȃĩųü GƖěɑťŠ͙ʞʤʖ͚̩̜̰̩͕̫͌͐̓͗˶Æˤ˱cƤť˷̧̣̹̔͗͐
ˉïĻͨȋɏŝǮˏ͍̤͗˷˕˧̌˙n˸ĵ˚ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˷ë˲ˏť̏ɍ×˷ɓƚƑĀ˶ ̞˶ɤ/˦̋ü ̏ɗJ˶ĝ+ˤ˱˕˜ˠ˳˚Ṓˤ˕ːĆ˦˫̄˷ïĻȕƝˉü Cŋ̩̜̰ͨ͌͐̓˷Ƕ²o˻Ƿãø˶˯˕˱˷ņĴˤ˫ü ˷̵̢̠̥͎͕͆͌͗o˻Cŋ̏0ɑ˦̋ˏü CŋIŔťɤ͙ʞʷʰʸʺʶʫʼʳʸʷʃʦʲʫʺʳʷʱʃʖʷʫʵˀʻʳʻʃʣʺʱʫʷʳˁʫʼʳʸʷʻʕʃʞʦʖʣ͚n˸ü CŋIŔ̩͕̫͙͗ʞʷʰʸʺʶʫʼʳʸʷʃʦʲʫʺʳʷʱʃʫʷʮ
ʖʷʫʵˀʻʳʻʃʘʯʷʼʯʺʻʕʃʞʦʖʘ͚˽˷mW

ʛʙʖ˷ÓȴŞ̛̬͕̔˚mǭ˳˵̋ːʐʉʐʃ͏͕̟́͐n˸ʀ½}˞̩̜̰͌͐̓İŇrĉȨľŇˏċȄİŇˏċȄƦȍ rĉȨľŇ˶W˗˱ˏȋɏŝǮ˚'Ą˦̋ˏ̧͕̲̔͗͑o˻ť˷ŠĄ̏ȃ˖˫̄˷ċȄİŇ˻˶ť˷ɓƚƗ¢ ̧̣̹̞̔͗͐˚ýºˢ̌̋cƤť˶˯˕˱˸ˏ̣̹̩̜̰̔͗͌͐̓˶ɤ˦̋ü ̏ȋɏȴ¥ŝǮ˙̉)ƚǮ˶ĝ+ ĺŐE˲˴˷̈˖˵ċȄİŇ˚òȍ˳ˢ̌̋˷˙ľƸ˦̋òȍ˚˔̋˳Ůɺˏʦʗʣʡˏʀ½}˞̩̜͌͐ ˷˫̄˷ċȄƦȍŮɺ˸ˏ͍̤͗˚·A˲̩̜͌̒˶)ƚ˦̋˲Ə˶ɝȍ˲˔̋ːˠ̌˶˸ˏɗJ˵Ɍľø͒́͑ ˦̋˚Ů̄̉̌̋ː$Eśɇ̂cƤťǅ˶˯˕˱˸ȈưǮ˽˷ĝ+̅òȍ˲˔̋ːǭ˗̉̌̋ː
̰̓İŇ̏ƶ¼˶˦̋˫̄˶̪̲̖̽̒̕ŠĄȆ͙ʦʸʰʼʿʫʺʯʃʗʳʵʵʃʸʰʃʡʫʼʯʺʳʫʵʕʃʦʗʣʡ͚̏ĝ+˦̋ˠ˳̅́̌̋ːˠˠ˲ɝȍ˵ˠ˳́˫ˏ§ɚ˳˷Ěǜ˚˵˕ˠ˳˚ľƶ˲˔̋ǅ˷Ɩƛ˙̧̣̹̞̉̔͗͐˚ýºˢ̌˵˕¡z˲˔ˮ˱̅ˏ͓̟̿͏͇˚)˸ˏǈƖǮ˚ȹƙ̶̦͈͕̲ͅ˷Ɨ˳ˤ˱ʦʗʣʡ̏)ƚ˦̋ˠ˳˲ˏ̣̿͏̔͋˙̉˷̠̥͎͕̒̿͐͗o˻͓̟̿͏͇
ƚˢ̌˱˕̋ˠ˳˚ľ̉˙˵cƤť˷¡z˶˸ˏ̧̣̹̞̔͗͐˚ýºˢ̌˵˕ļ˷ü ̏)ƚǮ˶Æˤĝ+̏ȃ˖ˠ˳̢̳͗̏ȫ˾˱ƅƦ˵Ƿãøo˻ãƆ˶˯˕˱˷ũƶ˵Ȏȓ̏í̉̌̋˳˳̅˶ˏòȍ˵̪̲̖̺̮̭̫͇̽̒̏̔͐͗̕ ˚Ṓˤ˕ː˶Əº˦̋ˠ˳˚˲˛̋˳˕˖Ɔ˲˔̋ː́˫ˏʦʗʣʡ̏)ƚ˦̋ˠ˳˲ˏ̠̥͎͕̒̿͐͗˲)ƚˢ̌˱˕̶̢͕͕̲̋̈́͗̏ ĝ+˦˾˛ü ˳ˤ˱˸ˏŧ˷ɺ˚Ő˳˵̋˚ˏ̧̣̹̞̔͗͐˷ƽÞ˶ó˥˱ɗJ˶Æó˦̋ˠ˳ː˵˘ˏBɢ˦̋vȐbˤ˱Ȏɇ̂½˶ĝƸ˲˛̋˳˳̅˶ˏƅƦ̧̩̜̰̞͌͐̓͐o˻͏̧̩͕̔˷ɾ̏Əº˲˛̋˫̄ˏȻ@ůº˶ ˠ˳˶̈̊ˏ̧̣̹̞̔͗͐˚£©˦̋ˠ˳˚ýºˢ̌̋ü ˶˯˕˱˸ˏ˩˷ĝ+ĵų˶˯˕˱˷ɛă˚òȍ˲˔̋ːòȍ˵ü ̏ĝ+˦̋ˠ˳˚vǵ˳˵̋ːˠ˷͏͕̟́͐˸ˏʀ½}˞̩̜̰͌͐̓İŇ˳̅˹̌̋ːɤɐ˦̩̜̋͌͐
͚͠ʃżİŇ˽˷ȘɄɺ̰̓ü ̗͕̳͍̤̏͗˶Ʋ̉˨̋˫̄˷͏͕̟́͐˶˸ˏɤɐ˦̋ěºˤ˫̧̣̹̩̜̰̞̔͗͌͐̓͐̏ǭăˤ˱ˏŧ˷ þ˦̋)ƚƗ¢ɺƪ̏̄̋ˠ˳˚ě¬ˢ̌̋ːˠ˖ˤ˫ü ̏ĝ+˦̋ɭ˶˸ˏɗJ˶ɢƸˢ̌˫¡z˶˸̣̹̩̜̰̔͗͌͐̓˷͐ )ƚǮ7˚ɘ¶˦˾˛ɺ͙şȍ̧͚̞̏£̆˦vǵø˚˔̋ˠ˳˶ŵþ˦̋ˠ˳˚Ṓˤ˕ːȍŮˢ̌˫Ɨ¢§˲)ƚˤ˫¡z˷̧̧̞͙̞͐͐˷ɝȍø˶̈̊òȍ˶ó˥ȘɄ͚͚͡ʃċȄȹĲǅċȄü ̶͙̮̲͔̞͗Ɨ¢˽˷Ěǜ˶òȍ˵ü ǅ͚ˠ̌̉˷ü ˸ˏcƤťɤǅ˙̉˷Ů̄˶ó˥ĝ+˲˛̋ˠ˳ː́˫ˏcƤťɤ˲˷)ƚ̏þ˦̋cƤť˷¡zˏ˒·AǈƖ̛̳̔͏͕̔˓˶űˮ˫ü ĝ+˚Ṓˤ˕ː
͚͢ʃ˩˷
͖ʃcƤť˷Óȴë˷͏̣̞̔̽̔͑˶ó˥˫Æó˷ĵų͖ʃȋɏȴ¥ŝǮ˳ˤ˱˷̣̹̩̜̰̔͗͌͐̓Æó˽˷rǔ̂ǅ˶ɤ˦̋ü͖ʃ̣̹̩̜̰̔͗͌͐̓˶ɤɐ˦̋z˨ǁto˻̣̹̩̜̰̔͗͌͐̓˶ɤɐ˦̋
̧̣̻͗˷Ɗ?
̧̣̹̞̔͗͐Æó˶ɤ˦̋ü ĝ+˶˯˕˱ˏ*˗˹ˏȋɏȴ¥ŝǮ˷͇̦̓͗͂͗ǅ̏Oƚˤ˱ĝ+˦̋ļ̏żİŇ˶ȘɄˤˏòȍ˵ł˶Ɏ̆˙˶ü ̏@Ĉ˲˛̋̈˖˶˦̋ˠ˳̅˯˷ĵų˲˔̋ːİŇ˷D$ƦEÁ

ˉþ˦̋)ƚƗ¢˶ɗˤ˫ˏě¬ˢ̢̣̹̩̜̰͕̲͓̌̋̔͗͌͐̓͗͑˶ɤɐ˦̋ˏť˷)ƚĵųo˻ȋš͙* ȘɄ˵ˤ˗˹ˏ̧͕̭̪̲̖̒̓͑̽̒̕̕ˏ̘̽̑̔̒͗͑̕˷)ƚ͚ˉŠĄ̏ï˦̋˫̄˷ˏ̹̮̞̮̒̿˻˶ï>˷ťǵo˻Ĉɻ˷ȨľˉcƤť˚þ˦̋ɍ̊˶]'˲˛̋̈˖˶˦̋˫̄˷ˏĦğ͕̔̽͏˷ȍŮɺ˶ɤ˦͍̤̋͗˽˷D$Ʀ˵̛̬͕̔
̧ˉ̩̜͌̒˵ŠĄ̏)ƚˤ˱cƤť˚˴˷̈˖˶åbˢ̌̋˙n˸åb˲˛̋˙˶˯˕˱˷Ȩľː̩̜͌̒˵ŠĄ˶˸ˏ̖͑̒̕ͅÆǇˏ̘̘̽̑̔̒͗͑̽̑̔̒͗͑̕̕͞ȏRˏ̧͔̲̲̓̔͐ˏ̩̜̰͕̲̺͌͐̓̔́͏͈̫͗ˏ͓̝͕̟̺͏
͈̫͗ˏƎƖƦ̩̜̰͌͐̓ŜH˵˴˷̗͕̳͕̲̈́̔1Ȱ˚́̌̋ˠ˳˚˔̋ːˉ̱̫͗̏ɋs2˦̶̮̲͔̞̲̋͗̈́͗o˻˩˷˷̧͕̫̖̔̽͗˷̧̲͐ˏ˻˶ˏ̲̈́͗˷ťǵˏ̲̈́͗˚ư2˙ƥ2˙˷Ȩľ͙Ŏ)ƚ̲̈́͗˸ƈ\˶˦̋ˠ˳˚Ṓˤ˕ˠ˳˶ŵþ͚ˉ̗͕̳͍̤͗}˞˷dI˶ȣǑ˵̧̥̰͇
ˉòȍ˶ó˥˱ˏ̩̜͌̒˵̶̮̲͔̞͙͗Ěǜ͚˷Ïɢo˻̧̣̻͗̏vǵ˶˦̋˫̄˷ċȄƦĖƸˏ˻˶ˏ̣̹̩̔͗
̜̰͌͐̓Ƿãøn˸͕̥̱͕̲̔˚ŜƲˢ̌˫ɭ˷Æóĵų˶˯˕˱˷͍̤͗˽˷ĖƸˉvǵ˵¡zˏƢ×˵ƑĀ͙˦˵̎˭̩̜̰͌͐̓ȱ͚˚ŜHˢ̌˫¡z˶ˏťn˸Ħģ̥̰͇̆˚˴˷̈˖˶͍̤͗˶
ɍƲ˦̋˙˶˯˕˱˷Ȩľː̩̜̰͌͐̓ȱ˷ƾɿ˳ˤ˱˸ˏŠĄ˷¦ņˏ̶̮̲͔̞͗Ƣ×ˏ͓̟͕̔ȠȃˏƢ×̲͏̮̞͙̽̓*˗˹ˏŎƲ˷̗͕̰̰̓̓˶Æ˦̋ȍŮɋ2͚˷vǵø˚˔̋ːˉȤȞˢ̌˫ƏŤ͍̤͗˚ˏť˷ŠĄ̏1³ˤï˦̋˫̄˷ĵų˷Ȩľˉòȍ˶ó˥˱ˏþ˦̋)ƚƗ¢§˲cƤť̏)ƚ˦̧̞̋͐
ˉțvˢ̌˫͍̤͗˚ˏȋɏŝǮ˙̮̱̲̬͕͓̳̉̒̿͗̏͗̕ˤ˱̧͕̲̔͗͑˦̋˫̄˷$ǌƦ˵Ĉɻ˷ȨľˉĹƲ˷¡zˏť˷̣̹̩̜̰̣̲̔͗͌͐̓̈́͗Ǔ ˶ɤ˦̋ü ͙̩̞̥͎͕ʑʉʑ˷̛̥͒͗cƤť̏mƊ͚ˉʦʗʣʡ˸ˏ̹̦͎͕͗o˻̻̳͑ơx̏̃ƚˏ̧̙͕̪͗̿͗o˻Óȴ˷̪̲̖̽̒̕ɚ˷̧̲͐̏̃˚˩̌˶ɧºˤ˵˕ːˠ̌˸ˏť˷͍̤͙͗úǮo˻̧̠͓̹̬̀͑̒̿̔̏͚̃˚ˏ˩˷ȹƙ̏\ŕƦ˶ǈƖˤˏť͙o˻Ěǜˢ̧̥̰͇͚̌̋˶Æˤ˱ȮNˢ̌˫Ƿãø˷ƅƦçɹ̏Ɩȓˤˏť˷·Ao˻øǵ̏ǝĕ˦̋˫̄˷ÆčĈū˷Ïɢ̏vǵ˶˦̋ːȋɏŝǮ˸ˏʦʗʣʡ˷Ïɢ˶ŝƞŢƂ̏ŷƚ˦̋ˠ˳˚Ṓˤ˕ːİŇb˷ɝȍøȏQæÍ˙̉˷ȍŮˠ̌́˲˷̩̞̥͎͕˶şȨˤ˫ŷ]˶W˗˱ˏcƤť˷ȋɏŝǮ˸ˏ̣̹̩̜̰̔͗͌͐̓˶ɤ˦̋Ǻɂ˷ŷ]̏ľ ȘɄ˵ˤƶ˶İŇbˤˏȍǍ˦̋ˠ˳˚¬Zˢ̌̋ːť˷̧̞̞͐͏̧˶ó˥˱ˏȏQæÍ˸ˏˠ˷ƾ˷cƤť̏ȟ-˦̋˫̄˷İŇ̏ˏÓȴSn˸ȋ˷͏̣̞̔̽̔͑˷Óȴë˷ūɫ˲ȍŮ˦̋˙̅ˤ̌˵˕ːȏQæÍ˚ÓȴSĊȤ˷˫̄˶̣̹̩̜̰̔͗͌͐̓˷İŇ̏ȍŮ˦̋¡z˸ˏȋɏŝǮ˸ˏ̣̹̩̜̰̔͗͌͐̓˶ɤɐˤ˱ˏť˷Țȕťǵˏ̶̧̞̦͈͕̲͐ͅŷ]ˏȠʁˏ͏͕̟́͐o˻Ĵ˫˶ƥƘ˦̋Ƕ²̏ƨȐˤÆó˦̋˫̄˷ÓȴëȕƝ˷ȞĒ̏ȘɄˤ˫ˏľƶ˵İŇ̏ĝH˦̋ˠ˳˚¬Zˢ̌̋ː˷ūȀ˲ˏȘ˷˩̌˪̌˶˯˕˱˷ˢ̉˶ȣˤ˕Ȩľ̏ȃ˖ːʐʉʑʉʌʃȚȕİŇD$Ʀ˵EÁ

ʐʉʑʉʍʃ̶̧̞̦͈͕̲͐ͅİŇʞʦʣʃʌʏʔʒʌo˻ʖʖʡʞʃʧʞʥʃʐʒ˷mƊ

A˱˷̧͕̫̖̔̽͗n˸ɍ2Ǖȿo˻̣̹̩̜̰̔͗͌͐̓˷̧̞͐o˻Ƕ²̏Ǣ ˦̋˫̄˷ˏȘ˷̩̞̥͎͕ʐʉʌ˶ ȘɄ˵ˤĹ˶şȨˤ˱˕̋̈˖˵A˱˷Țȕťǵ͙*˗˹ˏ̧̢̞̩͕̲͓̒͗͑ˏńxbˏ̩̜͌̒˵̮̱̲̒̿͗ˏ͓̟ťǵˏƎƖƦ̩̜̰͌͐̓˵˴͚̏ȘɄˤ˫İŇː̣̹̩̜̰̔͗͌͐̓˷Ƕ²o˻Ƿãøˏɤɐ˦̧̞̋͐˷ěºˏ̧̞͐̏Ǣ ˦̋˫̄˶ȃ˖̧̢̞͕̲͓͐͗͑ˏo˻͐ ȘɄ˵ˤ̧̢̞͕̲͓͗͑˚ɗJ˶Ƞʁˢ̌˫ˠ˳̏Ƹ˦ȞĒ̏ľƶ˶Ȩľ˦̋İŇːȋɏŝǮ˸ˏ˷·A̢͕̲͓͗͑˶ɔÞ˶çɹ̏˗˧˶ˏcƤť˷̣̹̩̜̰̔͗͌͐̓̏ŉ©b˦̧̢̞͕̲͓̋͐͗͑̏ŜȖ˦̋ˠ˳˚Ṓˤ˕ːƏ˶ˏȏQæÍ˶ĝH˦̣̹̩̜̰̋̔͗͌͐̓˶ɤɐ˦̶̧̞̦͈͕̲̋͐ͅİŇ˸ˏľô˲˔̊ˏʞʦʣʃʌʏʔʒʌo˻ʖʖʡʞʃʧʞʥʃʐʒ˷ȍŮɺ˶ìˮ˱˕˱ˏŧ̏̃ˠ˳˚Ṓˤ˕ːʐʉʑʃȏQæÍ˽˷ƜȬ˶˯˕˱˷ȍŮɺʐʉʑʉʎʃ̩̜̰͌͐̓Ƞʁ˷İŇ

D$Ʀ˵EÁ

ˉ̶̶̧̧̞̦͈͕̲̲̩̜̰̞̦͈͕̲̲͐͒̈́͗̆͌͐̓͐͒̈́͗ͅͅ˳˕ˮ˫aĔƦ˵̶̧̞̦͈͕̲͐ͅİŇ˶˸ˏǶ²͉ ȘɄ˵ˤ̱͕̟͐o˻Əºvǵ˵̣̹̩̜̰̔͗͌͐̓Ƕ²˶˯˕˱ȘɄ˦̋ˠ˳˚Ṓˤ˕ːˉ˩˷˷̧̞͐˷̶̦͈͕̲ͅ˶˗̧̩̜̰̞̋͌͐̓͐Ǣ Ǉ˷çɹ˶˯˕˱˷ǭÄˉȋ˷͏̣̞̔̽̔͑A$̏ɍˤ˱cƤť˷̣̹̩̜̰̔͗͌͐̓˷ïȔǝĕ˦̋˫̄˷ȋɏŝǮ˷ȕƝ˷ȍǍ̩̜̰͌͐̓Ƞʁť˷̩̜̰͌͐̓o˻A˱˷Ǣ ̢͕̲͓͗͑˷ŋ\ø̏ŜȞ˦̋˫̄˶¼Ķˤ˫A˱˷Ƞʁ̏ȍǍ˦̋Ƞʁ Ňː ȘɄ˵ˤ̶̢̪̲̖͕͕̲̽̒̈́͗̕n˸̧̣̥̰͇̾˳ĹƲ˷Ƿãø̧̱̫͗́͗˳˷ƬmƊ˵˴˷̈˖˵ˏƏº˷Ƞʁ˷ȣǑ
˸ˏ*˗˹Ș˷̩̞̥͎͕ʐʉʎ˶ȘɄˤ˱˕̋˚ˏA˱˷ȠʁİŇ˸ˏŧ̏̃ˠ˳˚Ṓˤ˕ːˉȠʁĵųˏǖŕˏǖȭ˷ȨľȘɄ˵ˤˉ̧̩̜̰̞͌͐̓͐ˏ̢̩̜̰͕̲͓͌͐̓͗͑o˻̢͕̲͓͗͑˷ŜȞȠʁ˷̧̲̣̻̰̲̞͒͗͐̓͐ͅˉ)ƚˤ˫ȏŘ˷mƊȋɏŝǮ˚ˏť˷͏̣̞̔̽̔͑A$̏ɍˤ˱·Ao˻øǵ̏ǛǜƦ˶1Ȟ˦̋ˠ˳̏þ˦̋Óȴȩ͓̩̈̿̏ȘɄ ȘɄ˵ˤˤ˫ť˷1¶ȕƝ˷ȍǍː̩̞̥͎͕ʐʉʏ˶ȘɄ˦̋ɍ̊ˏˠ˷ȕƝˤ˫̧͓̩̿˶˸ˏÓȴëƨȐˏȕƝƦ˵̮̱̒̿͗
̲ˏ̺̮̭ˏǷãø˷Bɢ̥̈́͐͗o˻ü Cŋ˚́̌̋ː
Ș˷̩̞̥͎͕ʐʉʐ˶şȨˤ˫ˏť˷þ˦̋Ɨ¢˲͍̤͗˚̧̞͐̏\ŕƦ˶ǈƖ˦̋˫̄˷ɤɐü ̏̃ˏA ȘɄ˵ˤ
˱˷ɊW͍̤͗İŇː

D$Ʀ˵EÁ

ʐʉʑʉʏʃÓȴëǈƖȕƝ

1¶ȕƝ˷ȍǍ

ʐʉʑʉʐʃ͏͕̟́͐n˸ʀ½}˞̩̜̰͌͐̓ ͍̤͗}˞˷İŇİŇ˒̣̹̩̜̰̔͗͌͐̓˶ɤɐˤ˱ˏť˷Țȕťǵˏ̶̧̞̦͈͕̲͐ͅŷ]ˏȠʁˏ͏͕̟́͐o˻Ĵ˫˶ƥƘ˦̋Ƕ²̏ƨȐˤÆó˦̋˫̄˷ÓȴëȕƝ˷ȞĒ̏ȘɄˤ˫ˏľƶ˵İŇ˓˳ˤ˱E˲˸%̏˴˷̈˖˶ĝH˦˾˛˙˷ȘɄ˸˵˕ʑʉʋʃcƤť̣̹̩̜̰̔͗͌͐̓˷Óȴëǭăɺ şȍǷãø˸ł˚˫˯˶˯̌¦b˦̋˫̄ˏÓȴS˶Țȕˤ˱¼Ķˤ˫̢͕̲͓͗͑˸ˏ̧̞͐˚sÁvǵ˵ƑĀ̏ǝĕ˦̋ ȘɄ˵ˤ˫̄˶ɗJ˲˵˕˙̅ˤ̌˵˕ː˩˷˫̄ˏšˑ˵O¿ɤ/Ǯ˚˩̌˪̌˷èT̏ŕ˫˦Óȴë˷͓̭̒̿͗˚òȍ˶˵̋ːʃˠ˷Óȴë˷͓̭̒̿͗˶˸ˏšˑ˵ȍǏ˚́̌˱˘̊ˏþ˦̋Ɨ¢˶˘˞̋ť˷ɓƚˏü CŋˏeȫƦ˵Ƿãø˷BɢˏǷãø˷3ũˏ͕̥̱͕̲̔˶Æ˦̋Æóo˻̛̥͒͗ť̏̃ː˷̩̞̥͎͕˸ˏˠ̌̉˷̢͕
̩̲̿̏ǒˤˏȋ˷͏̣̞̔̽̔͑˷Óȴëūɫ˶ɤɐ˦̋ˏA˱˷ ȍ˵O¿ɤ/Ǯ˶Æ˦̋ě¬ɺ̏ĝ+˦̋ˠ˳̏þˤ˱˕̋ː

ʑʉʌʃþ˦̋)ƚƗ¢˶˘˞̋ť˷ɓƚʑʉʌʉʌʃ̧̠͓̹̬̀͑̒̿̔o˻úǮ͙͡ʉ͡ʉ͠ʃcƤťɤ˲˷)ƚƗ¢͚cƤťɤ˷cƤü ̧̥̰͇˶ɤˤ˱˸˒·AǈƖ̛̳̔͏͕̔˓̏Ɂ́˗
˫·AÆǇo˻ǈƖ˚Ů̄̉̌˱˕̋ː
͙͡ʉ͡ʉ͡ʃcƤťɤ˷ǈƖ˚o˹˵˕)ƚƗ¢͚*˗˹ˏµcƤ˲)ƚˢ̌̋cƤť˷¡zˏcƤťɤ˶̈̋ǈƖ˚dI˶o˹˵˕Ɨ¢˲)̎̌̋ˠ˳˶Ɵþ˦̋òȍ˚˔̋ː͙͡ʉ͡ʉ͢ʃ˩˷˷)ƚƗ¢͙Əº˚ɴ͚͚$Eśɇ̂ť̆Ȉưťǅ˷¨˜˸ˏúǮ˷Ƽ]˶ ˕šˑ˵¡ć˶Ƽ]˦̋ːˠ˷˫̄ˏýºˢ̌̋¨š˵Ɨ¢˲˷)ƚł˶˘˞̣̹̋̔͗͐
̧̞ǅ̏ȟ-ˤˏ˩˷gɪøǅ˶˯˕˱̅Ɵþ˦̋ˠ˳ː
ʝʗʣ}˞˷üʫʉ̧̠͓̹̬̀͑̒̿̔˚ęƚ˦˾˛̣̹̩̜̰̔͗͌͐̓˷̧̲́̿͏̧̞̰̓
ȘɄ˵ˤcƤť˷̣̹̩̜̰̔͗͌͐̓˸C{ȶ˲˔̊ˏ̧̠͓̹̬̀͑̒̿̔̏̃A˱˷O¿ɤ/Ǯ˷mƝ˚òȍ˲˔̋ˠ˳̏ȤȮ˦̋ˠ˳˚ɝȍ˲˔̋ː̧̠͓̹̬̀͑̒̿̔˸ˏǺɂ˷ʞʧ͕̔̽͏˶Ěǜˢ̌̋cƤť˷·Aˏŋ\øo˻̣̹̩̜̰̔͗͌͐̓˷7ɷ˶Æó˦̋˫̄˶ˏ̶̧̧̞̦͈͕̲͓̩͐̿̏ͅęƚ˦̋ˠ˳̏ŜȖ˦̋ˠ˳˚Ṓˤ˕ːˠ˷
̧͓̩̿˸ˏ͙ʳ͚ʞʧ͕̔̽͏˷Lōɢƥ˷ɭˏ͙ʳʳ͚Ĺ³˷ʞʧ̶̮̲͔̞͗˶Ĵˤ˕cƤť̏Ǚz˦̋ɭˏ͙ʳʳʳ͚̮̱̲̒̿͗n˸ħǽ˶̈̋ˏ̧̙̰͕̟̥̰͇͂͒͗̓ˏʞʧ̶̮̲͔̞͗n˸cƤťǺ$˷͙̪̲̖̽̒̕o˻͇̖̽̑͗̒̕˷͚¦ņ˷ɭ˶ɗƚ˦̋ˠ˳˚Ṓˤ˕ːȘ˶ɉ˾˫̶̧̧̞̦͈͕̲͓̩͐̿̏ͅ¼ȃ˦̋˫̄˶ˏ̧̠͓̹̬̀͑̒̿̔˸ˏʞʚʘ
ʓʋʋʋʌʈʌˏʞʦʣʃʎʌʋʋʋo˻ʞʦʣʃʍʒʋʋʋ̨̥͐͗˷Ə˶ʞʦʣʃʍʒʒʔʔ˵˴˷ɤɐȏŘ̏mƊˤ˱̅ǽ˕ːʝʗʣ˚ȃ˖˾˛Æó̶̧̧̞̦͈͕̲̥̰͇͐ͅ˷ęƚ˶W˗ˏ̧̠͓̹̬̀͑̒̿̔˸ˏ˩˷A$Ʀ˵̩̜̰͌͐̓±_̏ǝĕ˦̋˫̄˶ˏŧ ȘɄ˵ˤ˷ǼƦ˵̣̹̩̜̰̔͗͌͐̓˷̧̲́̿͏̧̞̰̓˶̅ì˖ˠ˳˚Ṓˤ˕ːˉcƤťn˸̶̧̮̲͔̞̞̩͕̲͗̒̈́̔˽˷ũ˵ƎƖƦ̧̞̩̒̏ɥ˝˫̄˷=̌˫ƎƖƦ̩̜̰͌͐̓
ˉțvˢ̌˫ȍˬ˞˚̶̮̲͔̞͗˷ȍǏˏ1³ˤ˫ü ˏ̧̣̻͗o˻̠̥͎͕̒̿͐͗˶̧̞̩̒˦̋ˠ˳˚țˢ̌̋ˠ˳̏ƶ¼˶˦̋˫̄˷̧̞̩̒QîĈū͙*˗˹ˏèŢ͚́͗ˉcƤť˷ɍ2̏Qɧ˦̶̧̢̮̲͔̞̞̩͕̲͓̋͗̒͗͑
ˉ̫͇̔͐͗˵̩̜̰̺̮̭͌͐̓˷̮̱̲̒̿͗̏ƶ¼˶˦̋˫̄˷̶̺̮̭̦͈͕̲ͅ
ˉĨĤ̏ ɥ˦̋˫̄˷̖͑̒̕ͅÆǇˉɠłɣƈ˷́́˶ˢ̌˱˕̋ť˶Æ˦̋ũ̧̞̩̒̏ɥ˝˫̄˷̩̮̥͎͕̫͇̲̔̒̕
ˠ̌̉˷̧̲́̿͏̧̞̰̓˷¼Ķ˸ˏť˷ǹÜ)ƚ˷ƑŲ̏ǭăˤ˱ȃ˖ˠ˳˚Ṓˤ˕ː*˗˹ˏˠ̌̉˷̧̲́̿͏
̧̞̰̓˶ì˖ˠ˳˸ˏī÷ł˶˸vǵ˲˵˕˙̅ˤ̌˵˕ːʝʗʣ˚ȃ˖ĭǳ

ʬʉA˱˷͍̤͗˶Æ˦̵̲͕̟̋͒͗͞ĭǳȘɄ˵ˤŉǓƦ˶ˏ̧̠͓̹̬̀͑̒̿̔˸̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˚ĶȚE˲ƥƘ˦̋ˠ˳̏ɥ˝˫̄˷A$Ʀ˵͓̭̒̿͗̏˳̋ˠ˳˚Ṓˤ˕ː˩˷˫̄ˏ̧̠͓̹̬̀͑̒̿̔˸ˏŧ˷̵̣̹̩̜̰̲͕̟̔͗͌͐̓͒͗̏ĝ+˦̋ˠ˳˚ě¬ˢ̌̋ː

cƤìǮ}˞

ˉA˱˷͍̤͙͗*˗˹ˏcÕˏƮȰÕˏǹÜÑ´ċ¤ˏǹÜŜŖċÕ˵˴͚˷̩̜̰͌͐̓˶Æ˦̋þȮ̏ʂ̄ˏ̣̹̔͗ ȘɄ˵ˤȅƘǈƖ̏ǫĂƦ˶ȃ˖̈˖˶˦̋ƷƦ˵̵̲͕̟͒͗
ˉĚǜ˦̋cƤť͙*˗˹ˏ̢̧̟͑͗ɐǜƨȐ̵͉̫͗ˏ̫̈́͗̾͑ɅŻ͕̈́̿˵˴˷µcƤť͚̏úǮǺɂ˚ĥ'˦̋ˠ˳̏þˤ˱˕̋¡z˸ˏ̵̲͕̟͒͗˸úǮ˶̅ȃ˖ˠ˳˚Ṓˤ˕ː̵̲͕̟͒͗˸ŧ˙̉ŠĄ˦̋ˠ˳˚ōéˢ
̌̋ː

úǮ}˞

ʑʉʌʉʍʃcƤťȋɏŝǮʑʉʍʃü Cŋ͙͡ʉ͡ʃcƤť˷)ƚƗ¢˷Əº͚ycƤť˶/̧̣̹̞̋̔͗͐̏ýº˦̋˫̄˶˸ˏæȢcƤť˷)ƚƗ¢̏Əº˦̋ˠ˳˚òȍ˳˵̋ː́˫ˏ)ƚƗ¢ˬ˞˲˵˜ˏcƤť̏ŠĄ˦̵͍̮̲̋ɣn˸ȌĮ˷cƤť˲ŠĄˢ̧̥̰͇̌̋˶˘˕˱ˏcƤťɣ˲̶͕̫̮̲̔͗ǅ͙ƈǠǅ͚̃̏OƚˤˏQî2x˔̋˕˸̱̫͗Ğ̏ȃ˖¡z˶˯˕˱̅ǭă˦̋ˠ˳˚òȍ˳˵̋ːcƤťɤǅ˶˘˕˱˸ˏ˒·AǈƖ̛̳̔͏͕̔˓̏Ɂ́˗˫·AǈƖ˚Ů̄̉̌˱˕̋ˠ˳˶Ɵþ˦̋ˠ˳͙*˗˹ˏ̧̞̩̒ǈƖˏɍ2˷ńxbǅː͚ː˵˘ˏƏºˤ˫)ƚƗ¢˶ɤ˦̋ü ˸ˏ)ƚǮǅ˽ü ĝ+˦̋òȍ˚˔͙̋ͤ͝mƊ͚ːĭǳ˳ˤ˱ȃ˖˾˛EÁʸcƤť̩̜̏͌̒˵ĵų˲ĥ'˲˛̋̈˖˶˦͙̋*˗˹ˏť̩̜̏͌̒˵̶̮̲͔̞͗˶˷̂Ěǜ˦͚̋ʸť˷Ƣ×˵]'˶ŭ˛ˏ̧̠͓̹̬̀͑̒̿̔n˸cÕ˶˦˝˶ ˲˛̋̈˖˶˦̋

ȋɏȴ¥ŝǮ˚ȃ˖ˠ˳ȋɏŝǮ˸ˏȋ˷͏́͑˶ü ̏ȘɄ˦̋ˬ˞˲˵˜ˏvǵ˵̉˹ˏcƤ̧̣̻͗ĝ+ťɤ̆Ǻƹȋ˷FȴŝǮˏǺ ͙͢ʉ͠ʃȋɏȴ¥ŝǮ˶̣̹̩̜̰̈̋̔͗͌͐̓Æó͚˵˘ˏȋɏȴ¥ŝǮ˸ˏ+ǘ˦̋ȋ˷̣̹̩̜̰̔͗͌͐̓Æóƹȋ˷źȸǮ˳eUˤ˱ˏǺƹȋ˷OƚǮ˚˩˷ȋ̏ŉɗ˵ƑĀ˲Ïɢ͖ŠĄ˲˛̋̈˖˶˦̋ˠ˳̏¬Z˦̋ː ˶ɤ˦̋ƹE˷ĵɟ͖$Q̏Ⱥ̧̥̰͇ǅ˷ɚ˳ˤ˱ƶǂ˦̋ˠ˳˚Ů̄̉̌̋ː́˫ˏ̣̹̩̜̰̔͗͌͐̓˶ɤɐ
˦̋z˨ǁto˻̧̣̻͗˶/̋rǔ˶˯˕˱ˏ)ƚǮ˽ɢƸ˦̋ˠ˳˚Ṓˤ˕ːü Cŋ˸ˏƞǕŽ˷ȌĮIɞ˶ſ̣̹̩̜̰̋̔͗͌͐̓˷Ƕ²o˻Ƿãø̏ǈƖ˦̋˫̄˷ɝȍ˵̯͗͑˲˔
ȘɄ˵ˤ̋ː̧̠̀͑̒§˷Iɞ˶˘˕˱ˏü ˳Ƕ²̏Cŋ˦̋˫̄˷ȏŖ̲̌̆́̿͏̧̞̰̓˚'Ąˢ̌˱¼Ķˢ̌˱˕̋ːcƤťɤ/Ǯ˸ˏcƤť̢̧̗̥̰͇˷̩̜̰͌͐̓̏åb˦̋˫̄ˏ˷Iɞ˲¼Ǥ˔̯̋͗͑̏ɗƚ˦̋ˠ˳˚¬Zˢ̌̋ː

üCŋ˷˫̄˷̯͗͑˷ɗƚüCŋ˶ɤ˦̋şȍȘɄ˵ˤO¿ɤ/Ǯɣ˲̧̪͐͗˽˷̧̞̩̒ĵų̆)ƚˢ̌̋Ĉų˸šˑ˲˔̊ˏ́˫ˏO¿ɤ/Ǯ˷ĄƋÞ͒́͑̅́˭́˭ ȘɄ˵ˤ˲˔̋˫̄ˏü Cŋ˷ĵų˳ˤ˱ŋ\˵͓̭̒̿͗˶̅šˑ˵̅˷˚³˦̋ːˢ̉˶ˏ̣̹̩̜̰̔͗͌͐̓˷̧̲́̿
͏̧̞̰̓˸ǚ˗˧ɑbˤ˱˘̊ˏˠ˷̧̲́̿͏̧̞̰̓˸ˏť˷ƾɿˏĚǜ˦͕̋̔̽͏ˏǔǧ˷ȏţo˻ĄƋÞˏǶ
²˷͒́͑˵˴˕˜˯˙˷ȍ˶̈ˮ˱Əð˰˞̉̌̋ːˤ˫˚ˮ˱ˏˠ˷İŇ˲˸ˏ˔̋Əº˷͓̭̒̿͗̏˷̒̿
͓̭͗̈̊=?˦̋ˠ˳˸ˤ˵˕ː˩˷̎̊ˏˠ˷İŇ˲˸ˏü Cŋ˶ɤˤ˱ì˖ˠ˳˚Ṓˤ˕jȐĝƸ˦̋ː˵˘ˏˠˠ˲Ƹ˦*˸ˏ˔˜́˲Ȩľ˷˫̄˷̅˷˲˔̊ˏȍŮɺ̏ȏº˦̋˫̄˷̅˷˲˸˵˕ː

Ȩ̛̬͕̔˷mǭü ˶˸˔̋˚ˏȣǑ˸Ƹˢ̌˱˕˵˕
͙ȏŘˏċȄİŇǅ͚ʞʚʘʃʓʋʋʋʌʈʌʕʍʋʌʋʃʖʹʹʵʳʭʫʼʳʸʷʃʸʰʃʺʳʻʴʃʶʫʷʫʱʯʶʯʷʼʃʰʸʺʞʧʈʷʯʼʿʸʺʴʻʃʳʷʭʸʺʹʸʺʫʼʳʷʱʃʶʯʮʳʭʫʵʮʯʾʳʭʯʻʃʈʃʤʫʺʼʃʌʕʃʥʸʵʯʻʇʃʺʯʻʹʸʷʻʳʬʳʵʳʼʳʯʻʃʫʷʮʃʫʭʼʳʾʳʼʳʯʻ
˃ʃʞʚʘʃʧʥʃʓʋʋʋʌʈʍʈʍʕʍʋʌʍʃʖʹʹʵʳʭʫʼʳʸʷʃʸʰʃʺʳʻʴʃʶʫʷʫʱʯʶʯʷʼʃʰʸʺʃʞʧʈʷʯʼʿʸʺʴʻʳʷʭʸʺʹʸʺʫʼʳʷʱ
ʶʯʮʳʭʫʵʃʮʯʾʳʭʯʻʃʈʤʫʺʼʃʍʈʍʕʃʜʽʳʮʫʷʭʯʃʰʸʺʃʼʲʯʃʭʸʶʶʽʷʳʭʫʼʳʸʷʃʸʰʃʶʯʮʳʭʫʵʮʯʾʳʭʯʃʻʯʭʽʺʳʼˀʷʯʯʮʻʇʃʺʳʻʴʻʃʫʷʮʃʭʸʷʼʺʸʵʻ˃ʃʞʚʘʃʧʥʃʓʋʋʋʌʈʍʈʓʕʍʋʌʑʃʖʹʹʵʳʭʫʼʳʸʷʃʸʰʃʺʳʻʴʃʶʫʷʫʱʯʶʯʷʼʃʰʸʺʃʞʧʃʷʯʼʿʸʺʴʻʳʷʭʸʺʹʸʺʫʼʳʷʱ
ʶʯʮʳʭʫʵʃʮʯʾʳʭʯʻʃ˄ʃʤʫʺʼʃʍʈʓʕʃʖʹʹʵʳʭʫʼʳʸʷʃʱʽʳʮʫʷʭʯʃ˄ʃʜʽʳʮʫʷʭʯʃʸʷ
ʻʼʫʷʮʫʺʮʻʃʰʸʺʃʯʻʼʫʬʵʳʻʲʳʷʱ
ʼʲʯʃʻʯʭʽʺʳʼˀʃʭʫʹʫʬʳʵʳʼʳʯʻʃʳʮʯʷʼʳʰʳʯʮʃʳʷʃʞʚʘʃʓʋʋʋʌʈʍʈʍ

EÁ˸Ƣ˵̋˚ˏɿ!
͙͡ʉ͡ʉ͡ʃcƤťɤ˷ǈƖ˚o˹˵˕)ƚƗ¢͚*˗˹ˏµcƤ˲)ƚˢ̌̋cƤť˷¡zˏcƤťɤ˶̈̋ǈƖ˚dI˶o˹˵˕Ɨ¢˲)̎
̌̋ˠ˳˶Ɵþ˦̋òȍ˚˔̋ːµcƤ˲)ƚ˦̋cƤť̆Àßƚ˷cƤť˷ɢƥ˶˘˕˱˸ˏæȢcƤť˷)ƚƗ¢̏ľƶbˤˏcƤťɤ˷ǈƖ˚o˹˵˕)ƚƗ¢˲˷)ƚ̏þˤ˫¡z˸ˏ˒·AǈƖ̛̳̔͏͕̔˓̏Ɂ́˗˫ǈƖ˷o˹˵˕Ɨ¢˲˔̋ˠ˳̏ǭă˦̋òȍ˚˔̋ː͙͡ʉ͡ʉ͢ʃ˩˷˷)ƚƗ¢͙Əº˚ɴ͚͚$Eśɇ̂ť̆Ȉưťǅ˷¨˜˸ˏúǮ˷Ƽ]˶ ˕šˑ˵¡ć˶Ƽ]˦̋ːˠ˷˫̄ˏýºˢ̌̋¨š˵Ɨ¢˲˷)ƚł˶˘˞̧̣̹̞̋̔͗͐ǅ̏ȟ-ˤˏ˩˷gɪøǅ˶˯˕˱̅Ɵþ˦̋ˠ˳ː
EÁ˸Ƣ˵̋˚ˏɿ!
͙͢ʉ͡ʃ)ƚǮ˶̣̹̩̜̰̈̋̔͗͌͐̓Æó͚ȋɏȴ¥ŝǮ˙̉Hǿˢ̌˫cƤť˸ˏȴ¥ŝǮ͖ȷŝǮ̏Ǖ˱ˏcƤťɤǅ˷)ƚǮ˶ǎ@ˢ̌̋ːǎ@ë˷cƤť˷̣̹̩̜̰̔͗͌͐̓˶ɤ˦̋ĺ×˷ǈƖ˸ˏcƤťɤǅ˷)ƚǮ˶˱¼Ķ˦̋òȍ˚˔̋ˠ˳˙̉ˏȋɏȴ¥ŝǮ˸ˏòȍ˶ó˥˱cƤťɤ˳ɐĢ̏r̊ˏ1¶«Ǎǅ˶˰˛̣̹̩̜̔͗͌͐
̰̓˷ƶ1̏Ħğ˦̋ˠ˳˚ɝȍ˲˔̋ː˵˘ˏcƤť˙̉cƤťɤǅ˷ü ̧̥̰͇˽Ƀɋˢ̌˫̱̫͗˶ɤ˦̧̣̹̞̋̔͗͐˶˯˕˱˸ˏ̧̥
̰͇˷ǈƖǮ˲˔̋cƤťɤ˶̈̋Æó˚òȍ˲˔̋ː
Ȩ̛̬͕̔˲˸ɤ/Ǯ˳˷eU˶˯˕˱˸ȘɄ˚˵˕˚ˏɿ!˷EÁȨ̛̬͕̔˲˸̯͗͑˶ɤ˦̋D$Ʀ˵EÁ˸˵˕cƤˬ˞˲˵˜Iɞ˷̣̹̔͗ ȋɏŝǮˏcƤťɤˏcƤť͍̤͗o˻˩˷˷O¿ɤ/Ǯ˸ˏ˷Ƭ'ƚ˦̋Iɞ˙̉˷̣̹̩̜̰̔͗͌͐̓ ȘɄ˵ˤ̩̜̰͌͐̓˷ȏQ˶̅ƪ̏}˞̋ ȍŮɺ˶˯˕˱̅ǭă˦̋ˠ˳˚Ṓˤ˕ː̣̹̩̜̰̔͗͌͐̓˸ˏǕŽA$˶ɤ̎̋ɾ˲˔̋˫̄ˏ¨˜˷¡zˏ̛òȍø̧̬͕̔ˏȏŘo˻ȏQ˚ȌĮ˔̋Ɨ¢˲̶̧̻̦˚ȃ̎̌˱˕̋ːʃˠ˷İŇ˸ˏcƤť˷̣̹̩̜̰̔͗͌͐̓˶Əŋ˷̧̛̬͕̔̏ĝ+˦̋ˠ˳̏þˤ˱˕̋˚ˏ˷ȍŮɺo˻̧̲́̿͏̧̞̰̓˶˯˕˱̅ŜȖ˦̋ˠ˳˚Ṓˤ˕ːʑʉʍʉʌʃɝȍ˵O¿ɤ/Ǯ̟͓̹͗͑˵üCŋ˷òȍø

cƤťIɞ˸ˏȏQˢ̌˱˘̊ˏ̟͓̹͗͑˲˔̋ːˤ˫˚ˮ˱ˏȌĮ˷Ó¡˶ť̏+ǘ˦̋ȋɏŝǮ˶˳ˮ˱˸ˏü ȘɄ˵ˤCŋ˶ɤˤ˱ˏn˸ųƦ˵ě¬ɺˬ˞˲˸dI˲˵˕˙̅ˤ̌˵˕ːcƤť˷̩̜̰͌͐̓˶ɤ˦̋ü ̏Cŋ˦̋˫̄˷ąƠ˸ˏ̟͓̹͗͑˲˔̋òȍ˚˔̋ː˩˷˫̄ˏO¿ɤ/Ǯ˸ȌĮ˷̶̮̲͔̞͗̏Oƚ˦̋òȍ˚˔̋˚ˏ˩˷ɭˏ¡z˶̈ˮ˱˸Oƚ˦̶̮̲͔̞̋͗˚ɭƦ˵̶̮̲͔̞͗˲˔̋vǵø˚˔̋ˠ˳̏ȤȮ˦̋òȍ˚˔̋ːʷʯʯʮʃʼʸʃʴʷʸʿcƤť˷̩̜̰͌͐̓˶ɤ˦̋ü ˸ˏæȢcƤť̏·A˶)ƚ˦̋ˠ˳˚˲˛̋ˠ˳̏ƶ¼˶˦̋˫̄˶ˏ˩˷ü ȘɄ˵ˤ̏òȍ˳˦̋A˱˷˳Cŋ˦̋ˠ˳˚Ṓˤ˕ːˠ̌˶˸ˏ͍̤͗ˏúǮˏ˷ȋɏŝǮˏȴ¥ŝǮˏcƤťɤˏ̩̜͌
̰͐̓ƴǀǮˏo˻Ǽ˷˚́̌̋˙̅ˤ̌˵˕ːˤ˙ˤˏšˑ˵O¿ɤ/Ǯ˶˳ˮ˱˩˷ü ˚ŋþǪ˙˯Æóvǵ˵̅˷˳˵̋̈˖˶ˏü ˷ƾɿ˷̹͏̧͕̏r̋ˠ˳˚ɝȍ˲˔̋ːŋƚ˵͓̭̒̿͗˷˯˸ˏ˅ʷʯʯʮʃʼʸʃʴʷʸʿ˷jRˆˏ˦˵̎˭ˏúǮ·Ȁƶ¼˶˦̋˫̄˶ˏ˩˷O¿ɤ/Ǯ˸ˠ˷ü ̏Ʋ̋òȍ˚˔̋˙ˏ˳˖ˠ˳˲˔̍˖ːʃ*˗˹ˏ̩̜̈̊͌̒˵̭̮̩̮̲̿˶ɤ˦̋ü ˸ˏȋɏŝǮ˶˳ˮ˱˸ɝȍ˙̅ˤ̌˵˕˚ˏť˷̗͕̳͍̤͗˶˸̶́
̮̲̽̓̏̅˫̉ˢ˵˕˙̅ˤ̌˵˕ː˩̌˶Æˤˏ̺̮̭˚́ˬɢƥ ˲˔̊ˏÏɢˢ̌̋S˶˸ˏť̏ʂ˕̧̞͐˷Ƿãø˙̉1Ȱ˦̋ĵų̏Ʋ̋ˠ˳˸ˏ˘˩̉˜A˱˷O¿ɤ/Ǯ˶˳ˮ˱ɝȍ˲˔̋ːȏQæÍ˷èT

ʫʉȏQæÍ
ȘɄ˵ˤcƤť˷ȏQæÍ˸ˏɍ×ˏBȂȅƘ˷1Ȱ˳}˚Ǫ^˞̉̌˱˘̊ˏü ˷Cŋ˶ɤˤ˱ɝȍ˵èT̏ŕ˫ˤ˱˕̋ːȏQæÍ˸ˏcƤť˷̩̜̰͌͐̓˶ɤ˦̋ü ˷ɝȍ˵s2Ǯ˲˔̋˚ˏ˩˷ü ˷Ʋ˶˯˕˱̅ɤ˦̋ˠ˳˚¨˕ːʃņ˶ˏȏQæÍ˸ŝƞA$˶˯˕˱˷Ȏȓ̏ĕ˭ˏɍ×ˏ̧̀͑IɞE§˷˷ťɤ˳ɤ̎̊z˖ː¨˜˷n˸˲˸ˏ˴˷ü ̏ȏQæÍ˳Cŋˤ˵˞̌˹˵̉˵˕˙˶˯˕˱ˏųƦȍ˚˔̋ːˤ˙ˤˏȏQæÍ˚ˏȎɇ̂̏ǈƖˤˏȏQȍŮɺ̏ÁĿ˶˦̋˷˶èǂ˯ü ̏Cŋ˦̋ˠ˳˚ˏO¿ɤ/Ǯ˶˸¬Zˢ̌̋ːɝȍ˵ˠ˳˸ˏ¨˜˷cƤť˚ȌĮ˷Ó¡ˏ˦˵̎˭ȌĮ˷ȏQ˲ȴ¥ˢ̌˱˕̋˳˕˖ˠ˳˲˔̋ːƞ˷˴˷¡ć˲̅{˥ü˚ĝ+ˢ̌ˏ́˫ˏvǵ˲˔̌˹ƞ˷˴˷¡ć˲̅{˥Æó˚ȃ̎̌̋̈˖˶ˏȋɏŝǮ˸ˏçɹ̏s˞̋ȋ˚ȴ¥ˢ̌̋˷yȏQæÍ˶̈̋ɍƲ̏ıɍƲ˦̋̈˖Ȳ̋ˠ˳˚Ṓˤ˕ːʃ{š˶ˏȏQæÍ˸ˏɭƦ˶ȫ ˤ˫Æó̏r̋ˠ˳̏ÁĿ˶˦̋˫̄˶ˏ˕˶ü Cŋ˦̋ˠ˳˚Ṓˤ˕ːcƤťɤ˷èT

ʬʉcƤťɤ
ȘɄ˵ˤcƤť˷̩̜̰͌͐̓˶ɤ˦̋ü ˷ ˵źȸǮ˳ˤ˱ˏcƤťɤ˸ȃ]̏ȼˠ˦ȶn˸ȃ]̏0ɑ˦̋ȶ˚˔̋ˠ˳˚¨˕ː˩˷˫̄ˏcƤťɤ˸ˏě¬ɺ̏¼ĶˤˏúǮ˷1Ȱ̏ƶ¼˶˦̋˫̄˶òȍ˵˔̉̇̋ü ˶̧̞̩̒˲˛̋ˠ˳˚Ṓˤ˕ː˴˷̫͕̟̔͆˲Ƿãø˶ɤ˦̋ü ̏Ʋ̉˨̋˷˙ːÆó˚˲˛˱˙̉Bɢ˦˾˛˲˔̋˚ˏü ˷̹͏̧͕̏r̋òȍ˚˔̋ːcƤťɤ˸ˏƕ¡˲cƤť̏ƚ˕˱ŝ^̏ȃ˖˷˲ˏü ˷ ȍ˵ƘĄǮ˲̅˔̋ːü ˸ˏŜȞ˷˫̄˷ɝȍ˵̧̪͗˲̅˔̋ːņ˶ˏǷãøn˸Ƕ²̏ħ˦̋˫̄˷¨˜˷̞̥͎͕̒̏ĶȚE˲ȃ˖vǵø˚¨˕˷˲ˏcƤťɤ˸Ƿãø˽˷Æó̏Țȕ˦̋˲˷ɝȍ˵̳̹̤̒̔͗˲˔̋ː
͍̤͗˷èTʭʉ͍̤͗ȘɄ˵ˤcƤť˷̗͕̳͍̤͗˶˸ˏcÕˏúǮˏȰǮo˻źȸǮ˚́̌̋ː̺̮̭n˸˩˷˷3ũ̏ɗƚ˦̋˙˴˖˙˶˯˕˱ˏ͍̤͗˚ŉǓəĎ̏ȃ˖ˠ˳̅̈˜˔̋ːˤ˫˚ˮ˱ˏ͍̤͗˚ü ˶˰˕˱ůº̏ȃ˖ˠ˳˚˲˛̋̈˖˶ˏľƶ˲þ˷˔̋ü ˚͍̤͗˶˸òȍ˲˔̋ːˠ˖ˤ˫˫˭˶˳ˮ˱˸ˏċȄƦ˵Èɡƚȥ˸ǼƦ˶ɗJ˲˸˵˕ː
ˠ̌˶˸̺̮̭̏Ïɢ˦̋ˠ˳ˏn˸̺̮̭˚Oƚ˲˛̋́˲˷ɣˏȊ¸ƦÆǇ̏˳̋ˠ˳˶ɤɐ˦̋ǹÜƦ˵̶̮́̽̓
̧̲͖̞͐˶˯˕˱˷ü ˚́̌̋˙̅ˤ̌˵˕ːǹÜ˷̵̢̰͆͌̓˶ÆˤˏúǮ˳˷ɣ˲ˠ̌̉˷̶̧̞͖̮̲͐́̽̓˶
˯˕˱ȡˤz˖ĵų˶˯˕˱ĭǳ̏ȃ˖ˠ˳˸ˏ-5˚˔̋ː̗͕̳͍̤͗˶Æ˦̋ĭǳ̣̹̩̜̰̔͗͌͐̓˸ˏcƤť˶˘˞̋Ĵ˫˵Ȫɾ˲˔̋˷˲ˏcÕ˷ĭǳ˷ǉ§˲˔̋ˠ˳˚¨˕ːˤ˫˚ˮ˱ˏǹṴ̵̢̈͆͌̓˷þȮ̏ʂ̄ˏĭǳ̏ȃ˖ˠ˳˸ˏcÕ˚ˏúǮ˳̶̧̞͖̮̲͐́̽̓˶˯˕˱ȡˤzˮ˱ˏ̣̹̩̜̔͗͌
̰͐̓˷ǭăɺ˶çɹ̏s˞̋ǹÜƦ˵ůº̏˦ˠ˳˚˲˛̋˫̄˶ɝȍ˲˔̋ː˩˷˷èTʑʉʍʉʍʃü˷ƾɿúǮ˷g¿̏1Ȱ˦̋˫̄˶òȍ ̣̹̩̜̰̔͗͌͐̓˷Ƿãø˸ˏ̪̲̖̽̒̕o˻̸̳̖͗̒̕ˏǺƹȋn˸̣̳̺̰͗͗̓ȋ˷̶̢͕͕̲̈́͗̏̃ˏ ȘɄ˵ˤ˵üȌĮ˷ȋ̶̢͕͕̲̈́͗˶Æˤ˱Ƕ²̏â˛ȼˠ˦vǵø˚˔̋ː*˗˹ˏCŋ͏̔̾͏͐ˏ̧̙̰͕̟̥̰͇͂͒͗̓n˸̭̮̿˷Ƿãø˸ˏ{˥̶̢͕͕̲̈́͗̏)ƚˤ˱˕̋A˱˷ȋ˶çɹ˦̋ːˢ̉˶ˏǷãø˷øȺ˳ˤ˱ˏȋ͏̫͇̔̽̔˷ɣˏǷãø˸ǛǜƦ˶ƥȎˢ̌̋̅˷˲˔̋ˏ˳˕˖ˠ˳˚˔̋ːcƤť˷ƑŲ˶˘˞̋ü Cŋ˷ƪƦ˸ˏúǮ̏g¿˙̉1Ȱ˦̋ˠ˳˲˔̋ːˤ˫˚ˮ˱ˏCŋˢ̌˫¡z˶ˏúǮg¿˷̧̞͐̏žÌ˦̋n˸̧̠̀͑̒˷ĝ+˷Ǜǜø̏ƶ¼˶˦̋̈˖˵A˱˷ü ˸ˏCŋˢ̌̋ˠ˳˚Ṓˤ˕ːˠ̌˶˸ˏŧ˷ü ̏Cŋ˦̋ˠ˳˚́̌̋˳ǭ˗̉̌̋˚ˏˠ̌˶ɧºˤ˵˕ːD$Ʀ˵EÁ

Ƕ²Ǣȍʑʉʍʉʎʃ2ɽ˲˛̵̢̠̥͎͕̋͆͌͗

ʮʉȃĩo˻ü Cŋťɤ̏̃ˏ˩˷˷O¿ɤ/ǮȘɄ˵ˤ̧̠̀͑̒Iɞ§˷ɝȍ˵O¿ɤ/Ǯ̅́˫ɝȍ˵èT̏̅˯ːų˷ȃťɤˏ̩̜̰͌͐̓ťɤo˻˷ȃĩťɤ˸ˏcƤť˷̣̹̩̜̰̔͗͌͐̓˷ɝȍ˵O¿ɤ/Ǯ˲˔̋ː̧̠̀͑̒ĶȚ˸ˏɝȍ˵͕̔̽͏˲˔̋˳̂˵ˢ̌̋
˫̄ˏȃĩ˚ƅƦ˵Ƕ²˶ɤ˦̋ɝȍ˙˯̫͇̔͐͗˵ü ̏̅˯˫̄˶ɝȍ˲˔̋ːy˷ųȏQ˶̈ˮ˱Ƣ˵̋˚ˏȋɏŝǮ͙o˻ȏQæÍ͚˸ˏæȢȋ˶ɤ˦̩̜̰̋͌͐̓ü ̏ȃĩ˶Æˤ˱Û˜Cŋ˦̋òȍ˚˔̋˙̏ŜȖ˦̋ˠ˳˚Ṓˤ˕ːʃųȏQ˶̈ˮ˱˸ˏ̩̜̰͌͐̓˷Ƿãøn˸͕̥̱͕̲͙̔*˗˹ˏ̱̫͗ƃŶ͚˷ ˶˯˕˱ˏȌĮ˷ȍŮɺ˚˔̋ːü ̏qɱǾˤ˜˸Cŋ˦̋ˏn˸ˏ̩̜̰͌͐̓˶˯˕˱˷XȔǾˤ˜˸ÈɡƲȮ̏ĝ+˦̋ǔǧ̅́˫ˏ̩̜̰͌͐̓ü˷ɝȍ˵ü Ɓo˻̧̣̲̪̈́͗͐͗˳˵̋vǵø˚˔̋ːˠ̌˶˸ˏĩÝťɤn˸Ŭɣťɤ˷˴˭̉̅˔̋ː*˳ˤ˱˸ˏü Cŋ̶̮̲͔̞͙͗*˗˹ˏʞʦʖʣʇʃʞʦʖʘ͚ˏƥťɤ͙*˗˹ˏʘʚʥʧ͚o˻˩˷˚˔̋ːˠ˖ˤ˫O¿ɤ/Ǯ˸ˏųo˻Ó¡˶̈ˮ˱Ƣ˵̋ˬ̍˖ː

ˉȋ˶Æ˦̋Ƿãøüˉ˩˷˷ȋ˶)ƚˢ̌˱˕̶̢͕͕̲̋̈́͗˷ǷãøüˉcƤť˷̩̜̰͌͐̓˶çɹ˦̋˙̅ˤ̌˵˕ʞʧť˷üˉĨĤˏƅøo˻ûƚ˷ɢƥ˶ɤ˦̋üˉ͕̥̱͕̲̔˷ƶȤ͙*˗˹ˏˇˠ̌̅ƶȤˤ˱˕̋˙ͩˈ͚ˉ̺̮̭n˸̩̜̈̊͌̒˵ňĈū˷@ĈvǵøȘɄ˵ˤˏ̿͏̧̞̰̓ˏĵų̅ò ü Cŋ˚Ƿãøo˻Ƕ²˶ɧºˢ̌̋˷˲˸˵˜ˏǶ²̏Ǣ ˦̋̿͏̧̞̰̓o˻ĵų˶˯˕˱̅ȃ̎̌̋ˠ˳˚ˏɝ ȘɄ˵ˤ
ȍ˵jR˲˔̋ː*˗˹ˏcƤť˶çɹ˦̋Ƿãø̏Ǣ ˦̋˫̄˶ˏʞʧť̏˴˷̈˖˶ŠĄ˲˛̋˙ˏĹƲ˷ûƚ˶Æó˦̋ĵų˵˴˲˔̋ː

̢̧̗̥̰͇͙˺˳˯˷ȋˬ˞˲ ̩̜̰͌͐̓˷Ƿãøo˻Ƕ²˶ɤ˦̋ü ˸ˏťÃü ˲˔̋ˠ˳̅˔̋˚ˏúǮ·ȀǈƖ˦̋˲vŦ˵̅˷˲ ȘɄ˵ˤ˸˵˜ŝƞ˷ȋ̧͖̣̻͗̏r̊ ̅˔̋ːˤ˫˚ˮ˱ˏúǮ·Ȁ}˦̋ƪƦ˲ˏü ˚Ǻƛ˙˯Ȧ¼˶Cŋˢ̌̋ˠ˳˚ɝȍ˲˔̋ːˠ˷¡zˏŝƦÒ˜qƧƗ¢˷ ˲˔̋ƪƦ˷̿ OƧ˶˯˕˱˸Ǹ˶ǩ˜òȍ˚˔̋ːü Cŋ˷̶̮̲͔̞͗˸ˏü ˚̩̜̰͌͐̓o˻úǮ·Ȁ}˦̋˫̄˶Cŋ̧͓̩˚̋ǔ̧͙̥̰͇͚͚̂ ˢ̌ˏCŋˢ̌˫ü ˚ŝƦ˵="ø̏í̋˫̄˶˸)ƚˢ̌˵˕ˠ˳̏Ɩȓˤ˱ˏòȍ˵¡z˸Ňɷ˶̈̋zþ̏˷òȍøĕˮ˱Țº˦̋ˠ˳˚Ṓˤ˕ːˠ˷̢̧̗̥̰͇˶˘˕˱˸ˏȏQæÍ̅ɝȍ˵eUǮ˲˔̋ˠ˳̅ȤȮ˦̋òȍ˚˔̋˚ˏȃ]̏ȼˠ˦ɭ˶ˏƏº˷¡z˶˸ųê˶đőˢ̌̋˙̅ˤ̌˵˕ː˳˸˕˗ˏȏQæÍ˸ˏcƤť˷̣̹̩̜̰̔͗͌͐̓˶ɤ˦̋ü ̏ˏ̫͇̔͐͗˶ɢƸ˦̧͓̩̋̿̏ŠǊ˦̋ˠ˳̏ƪĖ˦ˠ˳˚Ṓˤ˕ːȃĩťɤˏʞʦʖʣˏʞʦʖʘˏʘʚʥʧǅ˷èTʑʉʎʃeȫƦ˵Ƿãø˷Bɢ

ʑʉʎʉʌʃcƤťȋɏŝǮʘʩʙ˷Oƚ

ŎƲ˷̅˷˸̩̜͌̒˶˦̋˷˚ɴˤ˕˷˲ˏɌľø˸ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˽˷Ƃ9o˻Æó˶˘˕˱ ȘɄ˵ˤvŦ˵ŠĄȍǏ˲˔̋ːɌľø̏åb˦̋˺˳˯˷̵̨͈͇̚˸ˏeȫƦ˵Ƿãø˷Bɢ͙ʭʸʸʺʮʳʷʫʼʯʮʃʾʽʵʷʯʺʫʬʳʵʳʼˀ
ʮʳʻʭʵʸʻʽʺʯʕʃʘʩʙ͚˲˔̋ːʘʩʙ˸ˏ̣̹̩̜̰̔͗͌͐̓˷Ƿãøü ̏@ĈˤˏǷãø̏ȟ-ˤˏǢ Ǉo˻Ȋ¸ƦÆǇ̏ɢƥˤˏʀ½ˏ{ŝƹˏȏQæÍˏ̣̹̩̜̰̔͗͌͐̓ü Cŋǔǧo˻Ǽ̏̃ˢ́ˣ́˵O¿ɤ/Ǯ˶Æˤ˱ˏˠ˷ü ̏ɢƸ˦̋˫̄˷ˏũá˵̧͓̩̿̏ƶǂ˦̋ːʘʩʙ˷̥̈́͐͗o˻Ĉɻ̏ęƚ˦̋ˠ˳˸ˏçɹ̏s˞̋ċȄ˷̗͕̳͍̤͗˚ˏcƤťo˻̧̀͑ʞʧ͕̔̽͏̏̈̊ɗ
J˶1Ȱ˦̋˫̄˶˳̋ˠ˳˚˲˛̞̥͎͕̋̒˶˯˕˱ˏ̈̊ü ˶˰˕˫ůº̏ȃ˖ˠ˳̏vǵ˶˦̋ˏƿŞƦ˵͓̭̒̿͗˲˔̋ː

ʘʩʙ˷Ȩľ

ʘʩʙ˽˷r̊ǔ̂˸ˏ̩̜̰͌͐̓ɾ˽˷þȮ̏ʂ̄̋˫̄˷ȶ˔̋ȃ]ĵɟ˲˔̊ˏ˷ŝƞ˲̅Ėģˢ̌˱˕̋ ȘɄ˵ˤ̈˖˶ˏǛǜƦ˵Ⱥħo˻̶̧̞̦͈͕̲͐ͅ˶ɤɐ˦̋ȋɏŝǮ˷ĄƋ˷ˤ̋ˤ˲˔̋˳ǭ˗̋ˠ˳˚Ṓˤ˕ːǋ̶̗̝͖͑͗ŝ°͙ʚʷʯʺʱˀʃʫʷʮʃʘʸʶʶʯʺʭʯʃʘʸʶʶʳʼʼʯʯ͚˷˒̣̹̩̜̰̔͗͌͐̓˶˘˞̋eȫƦ˵Ƿãø˷Bɢ˷ɝȍø͙ʧʲʯʃʘʺʳʼʳʭʫʵʳʼˀʃʸʰʃʘʸʸʺʮʳʷʫʼʯʮʃʩʽʵʷʯʺʫʬʳʵʳʼˀʃʙʳʻʭʵʸʻʽʺʯʃʳʷʃʘˀʬʯʺʻʯʭʽʺʳʼˀ͚˓˳˕˖̫̲̔͑˷ Ň˶˸ŧ˷̈˖˶ɉ˾̉̌˱˕̋ːŇ˙̉˷âƚ

ˇĺ˷ü ̧̥̰͇o˻̶̮̲͔̞͗˸Ȍɲ˲˔̋˷˲ˏǔǧ˷A$Ʀ˵̣̹̩̜̰̔͗͌͐̓ąƠ˷ɚ˳ˤ˱˷əĎ ȘɄ˵ˤ
Ʀ˵Bɢ˲˸˵˜ˏeȫƦ˵Bɢ˚vŦ˵̅˷˶˵ˮ˱˕̋ˠ˳˚ˏ°˷'ŝ˲Ƹˢ̌˱˕̋ːˠ˷¼˸ˏɝ©˵
eȫƦ˵Bɢ˷Įo˻ɼÞ˚£Wˤ˱˕̋ˠ˳˶̈ˮ˱¼Ȟˢ̌˱˕̋ːˠ̌˸ˏ̢͕̼̫̭̮͌͗̿˶,³˦̋ĺ˷˿
̀A˱˷̷̰̞͓̦͗˶çɹ˦̧̞̫͙̋͂͗ʦʹʯʭʼʺʯ͚o˻͈̲̬͕͙͑̕ʡʯʵʼʮʸʿʷ͚˷Ƿãø˷ɢƸ˶̈ˮ˱̅åȫˢ̌˫˳ˠ̍˲˔̋ː˩˷Bɢ˶Æ˦̋°˷ȫŖ˶̈ˮ˱ˏeȫƦ˵Bɢ˚Ş̄˱ɝȍ˵ˬ˞˲˸˵˜ˏƹ˚ˏeȫƦ˵Bɢ˚ǽ˕˙û˕˙˳˕˖ɔl˷ȯȭ̏Ƚ˗ˏ˩˷̎̊˶Bɢ̧͓̩̿˚˴˷̈˖˶þ˔̋̈˖˶ħ˲˛̋˙˶ƉƆ̏˔˱̋˫̄˶ˏ˩˷ɝȍø˚òȍ˶˵ˮ˱˕̋ˠ˳˚Ƹˢ̌˱˕̋ːˈ

̶̛̰̜͕͕̓̾͊͂͗

ʘʩʙ˶ɤ˦̋S}˛˷±_˸ˏŝ˷ƿŞƦ˲ȶ˔̋ȃ]˷ˤ̋ˤ˲˔̋˚ˏcƤťȋɏŝǮ˚ˏˠ˷̧̲́̿͏̞ ȘɄ˵ˤ̧̰̓̏ęƚˤ˫ǖŕˏ̶̛̰̜͕͕̓̾͊͂͗˶ƫɷˤ˱˕̋˳˕˖Ūõ˵*˚˕˜˯˙˔̋ːcƤť˷̢̧̗̥̰͇˚ĄƋˤǜ˞˱̇˞˹ˏɌľø˷˔̋ȃ]˷̶̮̲́̽̓˚dI˶ȤȮˢ̌̋ˬ̍˖ːˠ˷ƾ˷B ȘɄ˵ˤ
ɢ˸ˏ{š˷Ƿãø˶̈ˮ˱çɹ̏s˞̋˙̅ˤ̌˵˕ȌĮ˷Óȴ˷ȋ˶̈̋ƅƦ˵g¿˙̉ˏǼ˷ˑ̏?QƦ˶¶̋˳˕˖Ɔ˲Ş̄˱ɝȍ˲˔̋ːȋɏŝǮ˸ˏɌľø˷˔̋ȃ]˚Ĵˤ˕ȋ˷̩̜̰͌͐̓Țȕ̏ħ˦̋ˠ˳˚˲˛̋˷˲ˏ˩ˠ˙̉ƫĚ˷̶̮̲́̽̓̅í̋ːȋɏŝǮˏʘʚʥʧ̆ʘʦʞʥʧ͙ʘʸʶʹʽʼʯʺʃʦʯʭʽʺʳʼˀʃʞʷʭʳʮʯʷʼʃʥʯʻʹʸʷʻʯʃʧʯʫʶͨ
ʘʦʞʥʧ͚˷̈˖˵̢͕̼̫͌͗Æó̭͇͗n˸ȏQæÍ˙̉˷ʘʩʙ˚ˏǷãø˶ɤ˦̋˷Ť²˔̋ü Ɓ˲˔̋ˠ˳
˶ˏ̧̠͓̹̬̀͑̒̿̔o˻úǮ˚ŭ˜̈˖˶˦̋ˠ˳˚Ṓˤ˕ːcƤť˚¸A˶Ƿãø˷˵˕ƑĀ˶˸˵̉˵˕
˷˲ˏʘʩʙ˶r̊ǔ̃ˠ˳˸ˏĺ×Ʀ˵¼ɀ˷ɚ˲˔̋ˠ˳˚Ṓˤ˕ːȋɏŝǮ˷̣̹̩̜̰̔͗͌͐̓˶Æ˦̋±_̏Ƹ˦ĖŢ˸ˏǷãø˷Į˲˸˵˜ˏǷãø˶Æó˦̋ɭ˷ȵøo˻ɗłø˲˔̋ː̢̧̗̥̰͇˷\ŕy˷ųȏQ˽˷Æó˷òȍøʘʩʙ˷òȍø
D$Ʀ˵EÁ

ʑʉʎʉʍʃȏQæÍAƞ˽˷BɢǺƹ˷ʀ½˶Æ˦̋ɍƲ˶W˗˱ˏȋɏŝǮ˸ˏǺƹȋ˷Ƿãø̏Aƞ˶Æˤ˱eȫƦ˶Bɢ˦̋ˠ˳˚¬Zˢ̌ ȘɄ˵ˤ̋ː̢͕̼̫͌͗Ǟ÷ÆǇ̭͇͙͗ʘʸʶʹʽʼʯʺʃʚʶʯʺʱʯʷʭˀʃʥʯʻʹʸʷʻʯʃʧʯʫʶʻʕʃʘʚʥʧ͚˷̈˖˵ǔǧ˸ˏʘʩʙ̧͓̩̿A$̏ɍˤ˱ˏǷãø˷ƥȎǮo˻ȋɏŝǮ˳C{˲'ŝ̏ȃ˖ˠ˳˚¨˕ːƏ˶ˏʘʚʥʧ˸ˏƞƦ˶o˻˷ʘʚʥʧ˚˩̌˪̌˷˷Ȕȥ˶ǬȜˤ˫`̏ɍ˥˱Bɢ˷èT̏ŕ˫˦ˠ˳˚¨˕ːʘʩʙ˶ɤ˦̋ȣǑ˸ˏeȫƦ˵Ƿãø˷Bɢ
˶ɤ˦̋ʘʚʥʧ˂˷̛̳͙̔ʘʚʥʧ˂ʃʜʽʳʮʯʃʼʸʃʘʸʸʺʮʳʷʫʼʯʮʃʩʽʵʷʯʺʫʬʳʵʳʼˀʃʙʳʻʭʵʸʻʽʺʯ͚̏mƊːȏQæÍ˷èT

ȏQæÍ˸ˏȋɏŝǮ˳Ƿãø˷ƥȎǮ˳˷ɣ˲ˏǷãø˷̧̩͈͕̲̒͞ȟ-ˏçɹIŔˏǢ ͞3ũ̧͓̩̿˷ȫį ȘɄ˵ˤ̏Ħğ˦̋ˠ˳˚˲˛ˏŉǓƦ˶˸ûƚ˷̧̞͐̏Ǣ ˦̋˫̄˷BȂ˽˷̫͇̔͐͗˵̵̢̠̥͎͕͆͌͗̏0ɑ˲˛̋ːʘʩʙ˸̧̲́̿͏̧̞̰̓˳Ȏ˵ˢ̌˱˕̋˫̄ˏˠ˷̵̢̠̥͎͕͆͌͗˶˸ˏòȍ˶ó˥˱{ł̵̢̟͓̹̠͗͑͆͌͗
̥͎͕̅́̌̋ː

ʑʉʎʉʎʃǷãø˷ Ǯ͙̩̜̰͌͐̓˷ƴǀ Ƿãø˷Ǯo˻˩˷˷ǷãøƥȎǮ̏͚̃ʑʉʏʃǷãø˷3ũʑʉʏʉʌʃcƤťȋɏŝǮȋɏŝǮ˸ˏɾ̏ȟ-ˤ˫ë˶ˏʀ½˽˷Û ˏɍƲˏn˸˩˷˷Ĉū̏)ƚˤ˱ˏ˩˷ü ̫͇̏̔͐͗˶'Ąˤɛ ȘɄ˵ˤÔ˦̋ˠ˳˚ōéˢ̌̋ːʃȋɏŝǮ˸ˏ̫͇̔͐͗˵̵̢̠̥͎͕͆͌͗˶˯˕˱ˏy˲Əº˷ųȏQ˚˔̋ˠ˳˶ŵþ˦̋ˠ˳˚Ṓˤ˕ːʘʩʙ˸ˏúǮ˷6ào˻·Ȁħ˦̋X˞˶˵̋˷˲ˏcƤť˷̣̹̩̜̰̔͗͌͐̓˶Æ˦̋ˏȋɏŝǮ˷ƿŞƦ ȘɄ˵ˤ˵͓̭̒̿͗˷ɚ˲˔̋ˠ˳˚Ṓˤ˕ːƿŞƦ˵ʘʩʙ˶ɤɐˤ˱ˏȋɏŝǮ˸ŧ̏ȃ˖ˠ˳˚Ṓˤ˕ːˉ̣̹̩̜̰̔͗͌͐̓˷Ƿãøo˻̧̞͐̏ˏƏºo˻ŜH˦̋˫̄˷̣̹̩̜̰̔͗͌͐̓˷ü Ɓ̏ƨȐ˦̋ːȘɄ˵ˤˉeȫƦ˵ǷãøBɢ˷̥̈́͐͗o˻̿͏̧̞̰̓̏ęƚ˦͙̋ʞʦʣʊʞʚʘʃʍʔʌʏʒʕʍʋʌʏͨü ċȄʃ˄ʃ̩̜̰͌͐̓Ĉųʃ˄ʃǷãø˷Bɢ͚ːˠ̌˶˸Ƿãø ̏s˞rˮ˫ˠ˳̏ˏǷãø ˷ĝHǮ˶Æˤ˱Ėºˤ˫ōɣE˶ɍƲ˦̋ˠ˳˚́̌̋ːˉǷãø˷r̊ɇ̂o˻GƖ˷˫̄˷̧͓̩̿̏ƶǂˤɕ˦͙̋ʞʦʣʊʞʚʘʃʎʋʌʌʌʕʍʋʌʎͨü ċȄʃ˄ʃ̩̜̰͌͐̓Ĉųʃ˄ʃǷãø˷r̊ɇ̧͓̩͚̂̿ːˠ˷̧͓̩̿˸ˏǷãø˷ƥƘƁ͙*̩̜̰ͨ͌͐̓ƴǀǮˏ̧̠͓̹̬̀͑̒̿̔˵˴͚˶˙˙̎̉˧ˏľƶ˲ȵø˚˔̊Fƕø˚˔̋ːˉƶǂˤ˫̩̜̰͌͐̓˷ĵųȭ͙*ͨʘʩʦʦ͚o˻ǹÜƦ˵̧̧̞̩͈͕̲͐̒˷ĵųȭ͙ʞʦʣʃʌʏʔʒʌ͚˶ˤ˫˚ˮ˱ˏ ˢ̌˫Ƿãø̏ȟ-˦̋ːˉvǵ˵̉3ũǇ̏Ǉº˦̋ːħ˚vǵ˲˵˕¡z˸ˏÏɢ˷ªĬ̏ ˤˏ¦ņ̏>˶Ć˦˫̄˷ƶǂˤ˫Ĉū˳˳̅
˶ˏɗJ˵Ƿãø˷Ǣ Ǉo˻͞n˸Ȋ¸ƦÆǇ̏Ǉº˦̋ːˉɈˑǷãø˷Bɢ˚˔̋ˠ˳̏ȤȮ˲˛̋̈˖˶ˏȏQæÍ̏ɤˢ˨̋ːˉO¿ɤ/Ǯ˶ÆˤˏɗƚǉˏçɹˏȋɏŝǮ˷ƕłƆ˷Ɩȓ˶˰˜̧̧̞̩͈͕̲͐̒̏̃Ƿãø˷Ȩľ̏˗ˏǷãø˷Ǣ o˻͞n˸Ȋ¸ƦÆǇ̏Ȩľ˦̋ːƑŲ˚¦bˤ˫¡zˏO¿ɤ/Ǯ˶̅ŉĴü ̏ĝ+˦̋ˠ˳˚Ṓˤ˕ːˉvǵ˵¡zˏ3ũǇ̏Ïɢ˦̋ː3ũ˚vǵ˲˵˕¡z˸ˏÏɢ˷ªĬ̏ ˤˏ¦ņ̏>˶Ć˦˫̄˷ƶǂˤ˫Ĉū˳˳̅˶ˏǢ Ǉo˻͞n˸Ȋ¸ƦÆǇ̏Ïɢ˦̋ːǷãø˚ƥȎˢ̌˫¡zˏɤɐ˦̋ȋɏŝǮn˸ȫį̏ȃ˖̣̳̺̰͙͗͗̓ˤ˙̋˾˛ȃĩťɤ˵˴͚˶˩˷Ƿãø̏ƫ ȘɄ˵ˤĚ ˦̋ˠ˳˚Ṓˤ˕ː˩˷ëˏȋɏŝǮ˸ˏǷãø˷ȫŖ˘̈˻3ũ˷A$̏ɍˤ˱ˏǷãø˷ Ǯ˳ȫįˤˏɐǗ̏r̊z˖ːŉë˶ˏǷãø˷ Ǯ˳ȋɏŝǮ˸ˏǷãø̏Ǽ˶Bɢ˦̋ˠ˳˲ȫį˦̋ːǋ^ƭɵŭɍ2ü Í͙ʢʫʼʳʸʷʫʵʃʧʯʵʯʭʸʶʶʽʷʳʭʫʼʳʸʷʻʃʫʷʮʃʞʷʰʸʺʶʫʼʳʸʷʃʖʮʶʳʷʳʻʼʺʫʼʳʸʷʕʃʢʧʞʖ͚˷˒ǷãøBɢ˶ɤ˦̋Əø˳Æóͨʢʧʞʖ
ʖʿʫʺʯʷʯʻʻʃʫʷʮʃʖʮʸʹʼʳʸʷʃʜʺʸʽʹ͙ʢʧʞʖȤȮ͖Ê@̟͚͑͗̿˶̈̋ȫŖ Ň͙ʍʋʌʑÚʌʍŊ͚˓˶̈̌˹ˏȋɏŝǮ˚ Ǯ˶ÆóˤˏHˮ˫Ƿãø̏Oƚˤ˫ĨĤ˷ȞĒ˚˵˕ɧ̊ˏBɢ˷ȫį˸ˏǷãø˷ Ǯ˚3ṹ˫˸˩˷˷Ǣ Ǉ˚Ǉºˢ̌̋́˲˩̌̏Bɢˤ˵˕ˠ˳̏þ˦̋ː Ǯ˚3ũ˷S˶Ƿãø̏Bɢˤ˫¡zˏ Ǯ˳ȋɏŝǮ˳˸ˏÌ˵˜˳̅vǵø˷˔̋˦˾˱˷Ǣ Ǉ˶˯˕˱ȨľˤˏǺƹ˷ť̏·A˙˯̩̜͌̒˶ɓƚ˦̋˫̄˷ŉ̅Ťɧ˷˔̋ǂ¡˶̧͍̤͙̠͓̹̬͗̀͑̒̿̔̆úǮ˵˴͚̏ǩ˜ˠ˳̏ȫį˦̋ːǷãø˷3ũ

Ƿãø˷3ũ˶ɤɐ˦̋ȃ]˸ˏúǮg¿˷̧̞͐̏#ž˦̋˫̄˶ɝȍ˲˔̋ːʃ3ũ˶˸ˏúǮɍƲ̏̃Û˕ǉ ȘɄ˵ˤ˷ȃ]̏̐˲̅̈˕ː˩˷˫̄ˏ˕˜˯˙˷O¿ɤ/Ǯ̟͑͗̿˚ˠ˷̧͓̩̿˶˘˕˱Ş̄˱ɝȍ˵èT̏ŕ˫ˤ˱˘̊ˏˠ̌̉˷èT˶˯˕˱ŧ˶ȣˤ˜Ȩľ˦̋ːʫʉ̶̧̞̦͈͕̲͐ͅ
ȘɄ˵ˤcƤť˷̣̹̩̜̰̔͗͌͐̓˷Ƿãø˽˷Æó˷ŉL˸ˏ̧̧̞̩͈͕̲͐̒˲˔̋ː̶̧̞̦͈͕̲͐ͅ˸ˏcƤť
Iɞ˲˸ƶǂˢ̌ĄƋˤ˫̿͏̧̞̰̓˲˔̋ːȋɏŝǮo˻ȏQæÍ˵˴˸ˏ̣̹̩̜̰̔͗͌͐̓˷Ƿãø˚úǮ˷·Aø˶˴˷̈˖˵çɹ̏˗̋˙̏ȟ-˦̋ɭˏˠ˷̧̲́̿͏̧̞̰̓̏ɗƚ˦̋ˠ˳˚Ṓˤ˕ːúǮ·A˷ȒƆ˙
̉ˏdI˵ŗĒ˚˔̋Ƿãø3ũąƠ̏ɢƥˤˏzþ˦̋ˠ˳˚˲˛̋ːˠ˷͓̭̒̿͗˷ŋ\ø̏ʂ̄̋˶˸ˏƏ˶ȤȮˤ˫̧̞͐o˻ȃ]˷ũæø˶˯˕˱˷ü ̏ˏȏQæÍ˳ȋɏŝǮ˳˷ɣ˲Cŋ˦̋ˠ˳˚Ṓˤ˕ː̧̞͐ȟ-˶̈ˮ˱3ũ˷=?ɻ"˳̫͕̟̔͆˚ůºˢ̌̋˚ˏ̧̞͐˶Æ˦̋ȤȮ˶©˛˵ɬ˫̊˚˔̋¡zˏȋɏŝǮ˳ȏQæÍ˚ˤ˙̋˾˛3ũąƠ˶{þ˦̋vǵø˸#˜˵̋ːȋɏŝǮo˻ȏQæÍ˸ˏ̶̧͙̞̦͈͕̲͐ͅˏȺ̶̦͈͕̲ͅˏȏQ˶˔́̊˵˥̂˚˵˕vǵø˚˔͚̋˷O¿ɤ ȘɄ˵ˤ/Ǯ˶ȤȮˢ̌˱˕̧̞̋͐̅ǭă˦̋òȍ˚˔̋ːˠ˷ˠ˳˸ˏȋɏŝǮ˚̩̜̰͌͐̓˷Ƿãø˶Æˤ˱˕˯́˲˶˴˖
pó˦˾˛˙˶˯˕˱ˏƢ˵̋ōé˚Â˨̉̌̋ˠ˳˶˵̋ː{š˶ˏǷã˵ť̏1Ȱˤˏ̧̞͐̏#ž˦̧̞̋͐#ž̵̨͈͇͙̚Ƿã˵ť̏dI1Ȱ˲˛̋̈˖˶Ïɢ˲˛ˏúǮg¿˷̧̞͐̏țÁvǵ˵͒́͑́˲Ǣ vǵ˵Ȋ¸ƦÆ
Ǉ˵˴͚̏Ɩȓˤ˵˕O¿ɤ/Ǯ̅˕̋ːúǮ̏gɪ˶ˢ̉˦vǵø˚˔̋ũƶ˵ü ˚³˦̋˳ˏcƤċȄ˷2ɽø˚©˛˜Ġ˵̎̌̋vǵø˚˔̋ːA˱˷O¿ɤ/Ǯ˸ˏcƤť˶ɤ˦̋˷̧̞͐˳{š˶ˏ̣̹̩̜̰̔͗͌͐̓˷Ƿãø˚úǮo˻͍̤͗˶Æ˦̧̞̋͐˶ɤˤ˱ǈƖˢ̌˱˕̋ˠ˳̏ȤȮ˦̋òȍ˚˔̋ːcƤťȋɏȴ¥ŝǮ§˷O¿ɤ/Ǯ˶Æˤ˱̅ˏƖȓ̏0˦˾˛˲˔̋ˠ˳˚Ƹˢ̌˱˕̋ːĺŐ˷Ȩ̛̬͕̔˲˸˩ˠ́˲˷ü ĝ+˸˵˕ːʬʉ̣̳̺̰͗͗̓ȋ˷̶̢͕͕̲̈́͗
ȘɄ˵ˤ̣̳̺̰͗͗̓ȋ˷̶̢͕͕̲̈́͗˸ˏ˩̌˚̪̲̖̽̒̕˙̸̳̖͗̒̕˙˶˙˙̎̉˧ˏcƤť˷̣̿͏̭̖͕̔͗˷
ɝȍ˵ɚI˲˔̋ːˠ˖ˤ˫̶̢͕͕̲̈́͗˸ˏ˩̌̉Ǻɂ˷̧̞͐̏ƥƘ˦̋vǵø˚˔̊ˏ˩˷̧̞͐˸ˏȋɏŝǮ˚̶̧̞̦͈͕̲͐ͅˏȺ̶̦͈͕̲ͅo˻Țȕ˷əĎ˶̈ˮ˱ǈƖ˦̋ːȋɏŝǮ˸ˏǺƹ˷ȋ˷ɚ˲˔̪̲̖̋̽̒̕
o˻̸̳̖͗̒̕˷̶̢͕͕̲̈́͗˚̣̹̩̜̰̔͗͌͐̓˶˗̋çɹ̏ǈƖ˦̋ˠ˳˚Ṓˤ˕ːʃ{š˶ˏ̣̳̺͗͗
̰̓ȋ˷̶̢͕͕̲̈́͗˶̈̋Óȴë˷ɾ˚ˏcƤť˷̩̜̰͌͐̓˶çɹ˦̋ˠ˳̅˔̊ˏȋɏŝǮ˸ˠ˷̧̞͐̏ǈƖ˦̋òȍ˚˔̋ː͍̤͗˸ˏƩ˳˵̶̢̧͕͕̲͙̙̰͕̟̥̰͇͓̩̮̣̋̈́͗͂͒͗̓̆̿˵˴͚˶˘˞̩̜̰̋͌͐̓˷Ƿãø˚˴˷̈˖˶cƤť˶çɹ̏ò˦˙˶˯˕˱ˏȋɏŝǮ˚Ɩȓˤ˱˕̋ˠ˳̏ōé˦̋ːȏQæÍ˸ˏ˩̌̏ȍŮ˦̋ˬ̍˖ː

EÁ˸Ƣ˵̋˚ɿ!
͙͢ʉ͠ʃȋɏȴ¥ŝǮ˶̣̹̩̜̰̈̋̔͗͌͐̓Æó͚Ə˶ˏcƤť˷ɢƥ͖ȟ-ł˶)ƚˢ̧̱̫̌̋͗́͗̆ˏ¼)ƚł˶Oƚˢ̌̋ʣʦǅ˷Ĺȋ̪̲̖̽̒̕˶˯˕˱̅ˏcƤť˷͏̣̞͙̔̽̔͑ˊ͚̏͡ɍ˥ǭă˦̋òȍ˚˔̋ː˵˘ˏˠ̌̉Ĺȋ̪̲̖̽̒̏̕ƚ˕˫cƤť˷͏̣̔̽
̞̔͑˳ġɄˤ˫æȢĹȋ̪̲̖̽̒̕˷͏̣̞̔̽̔͑˶˯˕˱˸ˏįzˢ˨̋ˠ˳˚Ṓˤ˕˚ˏɴ˲˔̋¡z˶˸ˏ˩˷Æó˶˯˕˱ŜȖ̏ȃ˕ˏòȍ˶ó˥˱)ƚǮ˽òȍ˵ü ̏ĝ+˦͙̋ͤɺmƊ͚ː̣̳̺̰͗͗̓ȋ˷̶̢͕͕̲̈́͗˷Ƿãø˶Æ˦̋ȋɏŝǮ˷Æó˸ˏǺƹȋ̶̢͕͕̲̈́͗˷Ƿãø˶Æ˦̋̅˷˳ ȘɄ˵ˤ{š˲˔̋ˠ˳˚Ṓˤ˕ː˦˵̎˭ˏǺƹȋ̶̢͕͕̲̈́͗˳{š˶ˏǛǜƦ˵̶̧̞̦͈͕̲͐ͅˏo˻ʀ½͍̤̆͗˳
˷ǛǜƦ˵ü Cŋ̏ȃ˖ˠ˳˚Ṓˤ˕ːȋɏŝǮ˚̣̳̺̰͗͗̓ȋ˷Ƿãø̏ȓů˦̫͕̟͙̺̮̭̋̔͆̆ņĴ˚ɗƚvǵ˳˵̫͕̟͚̋̔͆̏ǈƖ˲˛̋vǵø˸#˕˚ˏ˩̌˲̅ȋɏŝǮ˸ˏúǮo˻͍̤͗˶Æ˦̧̞̋͐̏#ž˦̋˫̄˷ÆǇ̏r̋ˠ˳˚ōéˢ̌˱˕̋ː
ʭʉ̵̢̠̥͎͕͆͌͗
ȘɄ˵ˤˠ˷İŇ˷˷̩̞̥͎͕˶ȘɄˤ˱˕̋˳˘̊ˏúǮ˽˷̧̞͐̏ǈƖ˦̋˫̄˶ü ̏òȍ˳˦̋˳̵̢̠̥͎͆͌͗
͕̏˳̋ˠ˳˸vŦ˲˔̋ːˠ˷̵̢̠̥͎͕͆͌͗˷EÁ˶˸ˏŧ˷ɝȍ˵ü ˏ˦˵̎˭ˏǷãøȓů̧̠̦͌͗͑
͙˕˯3ũ˲˛̋˙˵˴͚ˏǷãøȓų̵͈͇͙̺̮̭̊̏̚˴˷̈˖˶Ïɢ˦̋˙˵˴͚ˏŅºƦ˵̧̞͐Ǣ Ĉū͙˴˷̈˖
˵̞̥͎͕̒̏˳̋˷˚Ṓˤ˕˙˵˴ː*˗˹ˏ̈̊ù Ʀ˵ȓůǇ˚Ȏ˕ˬˢ̌̋́˲˷ɣˏȊ¸ƦÆǇ̏¼Ķ˦̋ǅ͚̏̄̋ˠ˳˚Ṓˤ˕ːʮʉ3ũ˷̞̥͎͕̒
ȘɄ˵ˤO¿ɤ/Ǯ˚˴̐˵ȃ]̏˳̋˙˸ˏť˷ƾɿˏ˷ȏQˏ͍̤͗˶Æ˦̧̞̋͐o˻þ˦̋ƪƦ˵˴˷ȌĮ˷ȍ˶̈ˮ˱Ƣ˵̋ːˤ˫˚ˮ˱ˏˠ˷İŇ˲˸ˏA˱˷ť˶Æˤ˱ōéˢ̌̋Əº˷ȃ]˶˯˕˱ȣˤ˜ɉ˾̋ˠ˳˸ˤ˵˕ːˤ˙ˤˏA˱˷Ƿãø3ũ̞̥͎͕̒˷Ʒ˳˵̋ˠ˳˚Ṓˤ˕jR˚˔̋ːˉ˷ȏQȍŮ˶Æ˦̋ɗz
ˉ·Ao˻øǵ˶Æ˦̋Őȍ˷ɘ¶ˉúǮo˻͍̤͗˶Æ˦̧̞̋͐̏#ž˦̋˫̄˷O¿ɤ/Ǯ˳˷üˉzþˤ˫3ũǇ̏ɕĄ˦̋˫̄˷O¿ɤ/Ǯɣ˷eUˉ̧̞͐˶ɤˤ˱ˏ̫͇̔͐͗˵3ũ

ȘɄ˵ˤ
Cŋ

Əº˷̛̥͒͗ť˷̈˖˶ˏť˶9̎ˮ˱˕̋ŐƦ˵͙n˸ŋ˷͚1ȰĈū˚dI˲˵˜ˏ˵˘˙˯ņĴ̏¼ȃ˲ ȘɄ˵ˤ˛˵˕¡zˏ̧̞͐̏Ǣ ˦̋˩˷˷əĎǱ̏Ȋ¸ƦÆǇ˳ˤ˱ɗƚ˦̋ˠ˳˚Ṓˤ˕ː*˗˹ˏť˳cƤʞʧ̶̮̲
͔̞͗˳˷ɣ˶̘̽̑̔̒͗͑̕Ȉķ͕̲̌̏̔͗͑˦̋ˏn˸ˏť̏cƤʞʧ̶̮̲͔̞͗˙̉r̊ɩ˜ːˠ˖ˤ˫Ȋ¸ƦÆ
Ǉ˸ˏǼƦ˶˸ȋɏŝǮ˙̉ĝ+ˢ̌̋ü ˶˰˕˱ˏ̧̠͓̹̬̀͑̒̿̔˚¼Ķ˦̋ːȏQæÍ˸ˏ˷ų˷˲ɓˢ̌˱˘̊ˏˠ̌˸ˏÓ¡˷cƤť˶3ũǇ̏ɗƚ˦̋ɭ˶Əº˷ȍŮɺ˚Ȫ ȘɄ˵ˤˢ̌̋˙̅ˤ̌˵˕ˠ˳̏þˤ˱˕̋ːȋɏŝǮ˸ˏǷãø3ũ̞̥͎͕̒̏ȕƝ˦̋ɭˏˠ˷ˠ˳̏ǭă˦̋òȍ˚˔̋ːȋɏŝǮ˷3ũ̞̥͎͕̒˚®˟̉̌˫̊ɒ̌˫̊ˤ˵˕̈˖˶ˏĽ˕ūɫ˲ȏQæÍ˶ü ̏ĝ+˦̋ˠ˳˚Ṓˤ˕ːĽ˕ūɫ˲ȏQæÍ˶ü ̏ĝ+˦̋ˠ˳˲ˏŅºƦ˵3ũ˷Ħğ̆ˏO¿ɤ/Ǯ˳˩˷ōé͙͍̤͗ˏ͈̱̓̒ˏBȂ˵˴͚˷ǈƖ˷Ħğ̏ȃ˕˵˚̉ˏłɣƦ˶dI˵&ȉ̏ĕˮ˱ȏQ˶ɤ˦̧͓̩̋̿̆òȍ˳ˢ̞̥͎͕̌̋̒̏ɢ¯˲˛̋ː̩̜̰͌͐̓˷Ƿãø˶˯˕˱˷ü ˸ˏƞǕŽ˷ ˲÷Ɏ˶Û́̊ˏ̩̜̰͌͐̓˷Ƿãø˷ûƚ˸ˏƱ˷˖˭˶ ȘɄ˵ˤƞ ˶Pɕ˦̋vǵø˚˔̋ːˠ˷ˠ˳˙̉ˏǷãø̏3ũ˦̟͓̹̋͗͑˙˯eȫƦ˵ąƠ˚òȍ˲˔̋ː˔̋Ƿãø˚ˏ˔̋ʌ˯˷ȏQ˲ˤ˙3ũ͖Bɢˢ̌˧ˏ˷ȏQ˲˸ÆǇˢ̌˵˕́́˳˵ˮ˱˕̋¡zˏ˩˷Ƿãø˸ˏûþ˷˔̋Ǯ˶ŋO˵Œ̏˗̋ˠ˳˳˵̊ˏúǮ̆Ûǉ˶̎˫̋cƤIɞ˚ĨĤ˶ˢ̉ˢ̌̋ˠ˳˶˵̋ː
ȌĮ˷Ó¡˶+ǘ˦̋ȋɏŝǮ˸ˏ̫͕̟̔͆˷˧̌̏ŉËɧ˳˦̋˫̄˶ˏü o˻3ũ˷BȆ̏ȫįˤ˱ȃ˖ˠ˳˚ōéˢ̌̋ːȋɏŝǮ˸ˏȫį˷ǉ̏ē©ˤˏçɹ̏s˞̋ȋ˚ȴ¥ˢ̌̋˷yȏQæÍ˳ƿŞƦ˶̵̢͆͌
̠̥͎͕͗˦̋ˠ˳˚Ṓˤ˕ːȘɄ˵ˤ

A˱˷O¿ɤ/Ǯ˸ˏhł˷̺̮̭ɗƚ˚vǵ˲˔̋ˠ˳˚˔̊ˏ́˫Ṓˤ˜˵˕vǵø̅˔̊ˏúǮ·Ȁƶ¼˶˦ ȘɄ˵ˤ̋˫̄˶˸ŅºĜǩ˚ɝȍ˲˔̋˙̅ˤ̌˵˕ˠ˳̏ȤȮ˦̋òȍ˚˔̋ːʃˠ̌˸ˏȋɏŝǮn˸ȏQæÍ˷ƫĚ˷ǈƖ˷§˲ˏO¿ɤ/Ǯ˚ˠ̌̉˷ÆǇ̏¼Ķˤ˵˞̌˹˵̉˵˕¡z˸ˏƏ˶ɝȍ˲˔̋ː*˗˹ˏÆǇ˷EÁ˶̈ˮ˱˸ˏƣɨ˷ʞʧɚɡˤ˙¼Ķ˲˛˵˕¡z˚˔̋ː3ũąƠ˚ũˤ˜¼ȃˢ̌̋˙˴˖˙˸ˏü ˚\ŕƦ˶Cŋˢ̌ˏO¿
ɤ/Ǯ͙͍̤͈̱͗̆̓̒˵˴͚˚\ŕƦ˶ǈƖˢ̌̋˙˴˖˙˶˙˙ˮ˱˕̋ː˵˘ˏƖýƦ˵3ũ˲˔ˮ˱̅ˏ˩˷3ũ̏ò˧ˤ̅¼Ķ˲˛˵˕¡z˚˔̋Ɔ˶ŵþ˦̋òȍ˚˔̋ː˩˷¡z˸ˏɗJ˵̧̞͐Ǣ o˻Ȋ¸ƦÆǇ̏ɗƚ˦̋ˠ˳˚Ṓˤ˕ː
ʑʉʏʉʍʃ̧̠͓̹̬̀͑̒̿̔o˻úǮ

ʫʉ̺̮̭
ȘɄ˵ˤ
úǮ˸ˏÈɡ˷cƤťɤo˻µcƤƗ¢˶˘˕˱cƤ̏s˞̋˚ˏ)ƚƗ¢ˡ˳˶̺̮̭ɗƚ˶˯˕˱˷ƒǺ˷ǭăɺ˚˔̋ː*˗˹ˏµcƤƗ¢˶˘˕˱˸ˏ͍̤͗˸ˏúǮˏȰǮˏ2ɽ˲˛̋ɰn˸Àĸ˷˲˔̋vǵø˚˔̋ːˠ˷̩̞̥͎͕˲˸ˏ̺̮̭ɗƚ˶˯˕˱˷ǼƦ˵Ėɟ̏ĝ+ˤˏǜ˜̩̞̥͎͕˲˸ˏy)ƚƗ¢˶ŋ˵ǭăɺ̏Ȩľ˦̋ː
̣̹̩̜̰̔͗͌͐̓˷ƑŲ˶˘˕˱˸ˏ3ũ¦ņo˻ ɥ¦ņ̧͕̲̏̔͗͑˦̋ˠ˳̏ˇ̺̮̭ɗƚˈ˳ǼƦ˶̐˲ ȘɄ˵ˤ˕̋˚ˏɗó3ũo˻¸Ab3ũ̅vǵ˲˔̋ːʞʚʘʃʑʍʎʋʏʕʍʋʋʑʆʖʡʙʌʕʍʋʌʐʃcƤť̪̲̖̪̲̖̽̒̽̒̕̕͜͏̔̽
̧̣̞͓̩̔͑̿˷ʑʉʍʉʐ˲˸ˏ̧͐͐͗ˤ˫cƤť̪̲̖̽̒̕˷ɾ˻˶¦ņ˷@Ĉo˻̧͕̲̔͗͑ĵų˶˯˕˱ˏȋɏŝǮ˚͍̤͗o˻ȏQæÍ˶ɍƲ˦̋ˠ˳̏ȍŮˤ˱˕̋ːȋɏŝǮ˚Əºˤˏ˷ȏQæÍ˚ĊȤ˦̋cƤť˷Əº˷͍̤͗˚ˏɤɐ˦̧͕̲̋̔͗͑Ĉɻ˶ˤ˫˚ˮ˱ȋɏŝǮ˚ĝ+˦̺̮̭̋̏ɗƚ˦̋ˠ˳˚ōéˢ̌˱˕̋ːˠ˷Əº͍̤͗˸ˏȋɏŝǮ˷Ėɟ˶ìˮ˱ˏɍ×˸ʪʯʬ̦͂͗˲ĝ+ˢ̧̣̻̌̋͗ Ňo˻˩˷˷ü˶̧̞̩̒˦̋ˠ˳˚Ṓˤ˕ː­æ˵ōɣE˶̺̮̭˚ɗƚ˲˛˵˕¡z˸ˏȋɏŝǮ˸ˏȊ¸ƦÆǇ͙*˗˹ˏcƤʞʧ̶̮̲͔̞͗˷̩̟͈͕̲I˞͚n ȘɄ˵ˤ˸cƤť˷͍̤͗Țº˷¦ņ̏ě¬˦̋˙̅ˤ̌˵˕ːƏº˷ƾɿ˷Ƿãø˶Æ˦̋úǮg¿˷̧̞͐̏#ž˦̋˫̄ˏ˷ȏQæÍ˸ˏȋɏŝǮ˶Æˤ˱ˏcƤťˏÐn˸Ħģ̥̰͇͙̆*˗˹ˏ̪̲̖̽̒̕ņĴ̣̹͚͗͗˷
Əº˷ťǵ̏ƈ\˶˦̋̈˖ĖƸ˦̋˙̅ˤ̌˵˕ː˕˧̌˷¡z̅ˏ͍̤͗˸ȋɏŝǮ˷Ėɟ˶ì˕ˏòȍ˶ó˥˱ˏ)ƚƗ¢˶ɤɐ˦̧̞̋͐̏ȟ-˦̋ˠ˳˚Ṓˤ˕ːȆʍ˸ˏz{̩̜̰͌͐̓̿͏͕ʃ˲İŇbˢ̌˱˕̺̮̭̋ĵų̏3ũˤ˫̅˷˲˔̋ːwǃ˷K˸ˏȋɏŝǮ˚ŜȞˤ˫ ȘɄ˵ˤ̺̮̭̏¼Ȉ˦̋˫̄˶Əºˤ˫͍̤͗˷ ˵ȶ̏Ƹˤ˱˕̋ː
Ȇʍʕ̺̮̭ĵųo˻¼Ķ˶˘˞͍̤̋͗˷ȶȘɄ˵ˤ͉̲̮̱̲͐͗̒̿͗ˏ͍̤͗ǈƖˏ̧̣̻͗șʬʉÈɡ˷cƤĶȚƗ¢˶Æ˦̋ǭăɺȘɄ˵ˤÈɡ˷cƤĶȚ˲˸ˏúǮ˸ˏ˷ȏQæÍ˷ȍ˲˔̋͏̧̩͕̔˷ŋƈ˶˙˙̎̉˧ˏȹŘ˷˔̋cƤÈɡÀ͙*˗˹ˏƮȰÕˏcÕ͚˶̈ˮ˱̠̒̏s˞˱˕̋ːúǮ˸ˏcƤť˷·A˲\ŕƦ˵)ƚ̏ƶ¼˶˦̋˫̄˶ˏ̩̜͌͐
̰̓˶ɤ˦̋Ǯ̅̄ˏcƤÈɡÀ˷ĖƸ˶ì˖ˠ˳˚ōéˢ̌̋ːʞʚʘʃʓʋʋʋʌʈʌʕʍʋʌʋʃcƤť̏ǔɇ̐ˬʞʧ̶̮̲͔̞͗˽˷̶̧̞̦͈͕̲͐ͅ˷ɗƚǄʌɚͨèT͖ȶ͖ŷ]˷ʎʉʍ˲˸ˏc ȘɄ˵ˤƤʞʧ̶̮̲͔̞͗˲ɓƚˢ̌˱˕̋cƤť˷1¶̏̃ˏˇȶǔǧˈ˷̶̧̞̦͈͕̲͐ͅ˷ȶ˶˯˕˱ȏºˤ˱˕̋ːȶǔǧ˸ˏúǮ˷ƫĚ˷̧̠̀͑̒ĝ+Ǯ˳˸Ƣ˵̋¡z˚˔̋ː̺̮̭ɗƚ˸ˏ̧̢̞͕̲͓͐͗͑Ĉū˷ƾ˲
˔̊ˏD$Ʀ˵Ėɟ˚ʏʉʏʉʏʉʎ˶ȘɄˢ̌˱˕̋ː
ˇcƤťEɚ˶˘˞̧̢̞͕̲͓̋͐͗͑Ĉū˸ˏrĉȨľŇn˸cƤťȋɏŝǮ˷İŇ˶̈̋țv˶ìˮ˱ˏcƤ ȘɄ˵ˤťȋɏŝǮn˸ȶǔǧˬ˞˚¼Ķ˦̋ˠ˳˚Ṓˤ˕ːcƤťȋɏŝǮ˷İŇ˶̈̋{þ˚˵˕¡z͛ȶǔǧ˚cƤť˶ȃ˖˕˙˵̋¦ņ̅͛ě¬ˢ̌˵˕ːˈ
ˠ̌̉˷ě¬ɺ˸ˏcƤʞʧ̶̮̲͔̞͗˷\ŕƦ˲·A˵ǈƖ̏ƶ¼˶˦̋˫̄˶'Ąˢ̌˫ːǼ˷˶˸ˏcƤʞʧ ȘɄ˵ˤ̶̮̲͔̞͗˶Ěǜˢ̌̋cƤť˶̧̺̮̭͕̲̏̔͗͑˦̋țv̏˗˵˕˿˖˚̈˕ːʞʚʘʃʓʋʋʋʌʈʌ˶åȫˢ̌˱˕̋̈˖˶ˏȶeºrůŇ˸ˏA˱˷æǮ˚ˏcƤʞʧ̶̮̲͔̞͗˷ť̏ǈƖ˦̋Cŋȶ ȘɄ˵ˤ̏Ɩȓ˦̋ˠ˳̏ƶ¼˶˦̋˫̄˷ˏ˺˳˯˷əĎǱ˲˔̋ːȋɏŝǮ˚ˏcƤť˷Əº˷ťǵ̏ƈ\˶˦̋̈˖˶
ĖƸˢ̌˱˕̋¡z˶˸ˏ̧̠͓̹̬̀͑̒̿̔˸ˏúǮ·A˚ǝĕˢ̌̋ˠ˳̏ƶ¼˶˦̋˫̄˶ˏǹÜ͔̞͓͗̽͗̏
ȟ-˦̋ˠ˳˚Ṓˤ˕ːʭʉµcƤƗ¢˶˘˞̋ǭăɺȘɄ˵ˤɤɐ˦̋ʛʙʖ̧̛̬͕̔˒Àß˲˷)ƚ̏ƪƦ˳ˤ˫ť˶ɤ˦̋Țȕ˷ŜȖɺ˓˶ȘɄˢ̌˱˕̋̈˖˶ˏµcƤƗ¢˸ˏ¨š˵ƅƦ͍̤͗˶Æó˦̋ːˇµcƤť˷͍̤͗˸ˏÈɡ˷cƤĶȚ˲ɍ×cƤť̏ĥ'˦̋cƤÈɡÀ˳˸Ƣ˵̋ːµ˷͍̤͗˸ˏɂ$ ȘɄ˵ˤƦˏÿȑƦo˻ȤƲƦ˵ǵUo˻ɮ¿ˏ˻˶ÿüƦ˶ØÛ˕ɖ˕̏ŋ˦̋vǵø˚˔̊ˏˠ̌̏µcƤť˷Țȕ˲ǭă˦̋ˠ˳˚Ṓˤ˕ːˈ
µcƤƗ¢˶Æ˦̺̮̭̋ĵų˷ɗƚvǵø˸ˏcƤť˷̞͏̧Iɿˏ̧̪͐͗ȍŮɺ͙*˗˹ˏʂɎ͕̫̔͗
ȘɄ˵ˤ̶̮̲ɍ2͚o˻͍̤̻̰͗͐̓̏̃¨˜˷ȍ˷ɤĮ˲˔̋ː͍̤͗˷ǵU˷ɖ˕˚ØÛ˕˫̄ˏ¨˜˷µcƤť˲˸ˏȆʍ˶Ƹˤ˫ˇ̧̣̻͗șˈ˷̺̮̭ɗƚų˚òȍ˳˵̋ː̄ɇ̂cƤť˶Æ˦̺̮̭̋˷̧͕̲̔͗͑˶
˸ˏúǮ˷̧̠͓̹̬̀͑̒̿̔˳˷ƫĚ˷̆̊r̊˚òȍ˶˵̋¡z˚˔̋ːƏ˶ʦʫʡʙ˶Iɿˢ̌̋̅˷˵˴˷ɚ˷µť˸ˏ͉̲̮̱̲͐͗̒̿͗n˸͍̤͗ǈƖ̺̮̭ɗƚĵų˶Æóˤ˱ ȘɄ˵ˤ˕̋ː͉̲̮̱̲͐͗̒̿͗˸ˏ͍̤͗˳˷̆̊r̊˸ŉËɧ˲Ž̃˚ˏ̧̠͓̹̬̀͑̒̿̔˚ƶǂˤ˫̧͓̩̿˶ˤ˫˚ˮ˱ˏúǮ˳˷zþ̏òȍ˳˦̋ˠ˳˚¨˕ː˕˧̌˷̺̮̭ɗƚĵų˶˘˕˱̅ˏúǮ˸ˏ̧̠͓̹̬̀͑̒̿̔˚ĝ+˦̋ĖƸˏo˻Ȣæ˦̋¡z˶˸ˏcƤťȋɏŝǮ˚ĝ+˦̋ĖƸ˶ì˖ˠ˳˚Ṓˤ˕ːʑʉʏʉʎʃȏQæÍúǮ˚Ź§ķȃ̏ȕƝˤ˱˕̋¡z˶˸ˏúǮ˸ˏť˷̪̲̖̽̒̕1¶̙̥͎͕̿̏Ɩȓ˦̋˫̄˶ˏ̧̠͓̀͑̒̿ ȘɄ˵ˤ̹̬̔˳ȡ̏˦̋ˠ˳˚Ṓˤ˕ːʫʉÓȴë˷̺̮̭ɗƚȘɄ˵ˤǶ²̞̫̒͗˸ˏûƚ˷̵̰̞̮̞̏ƑŲ˶z̎˨˱ǚ˗˧ɗóˢ˨˱ɑbˢ˨˱˕̋ːʃ˩˷ǖŕ˳ˤ˱ˏť˷̣̹̔͗
̩̜̰͌͐̓˷ïU͙ˇ̣̹̔͗ȅƘǈƖˈ͚˷}ˏǷãø˷3ũˏn˸3ũ˲˛˵˕Ƿãø˷̧̞͐Ǣ ˷˫̄˶ˏɼ
ǥ˵̪̲̖̽̒̕1¶̞̰̻̰̒̓̓˚òȍ˶˵̋ˠ˳˚¨˕ːˇ̣̹̩̜̰̔͗͌͐̓̏åb˦̋˫̄ˬ˞˶ˈȃ˖¦ņ˚ˏŉ̅ʂ˕͒́͑˷ȏQ̻͒͌͗˷Æȱ˳ˢ̌˫¡zˏǖŕ˳ˤ˱Ƙ˥̻̋͒͌͗˷Ȳǿ˶̈ˮ˱ˏ˿˳̐˴˷ȏQæÍ˸˦˝˶ɔȲǿ˶˵̋ˬ̍˖ː
̣̹̩̜̰̔͗͌͐̓˷ƑŲ˶˘˕˱˸ˏȏQæÍ˸ˏ̪̲̖̽̒̕˷¦ņ˶̧͐͐͗S˷ĊȤ˚òȍ˙˴˖˙̏Mĳ˦̋ ȘɄ˵ˤ˫̄˶ˏ˯˷ŐƦ˵Ⱥ̏ȃ˖ˠ˳˚Ṓˤ˕ːʌʉ¦ņ˸ˏ˔˜́˲̣̹̩̜̰̔͗͌͐̓̏åb˦̋˫̄˶ĝřˢ̌˫̅˷˲˔̊ˏ̪̲̖̽̒̕n˸ť˶˩˷˷çɹ̏ ȘɄ˵ˤ˗˵˕ˠ˳˚ƶȤˢ̌˱˕̋˙ͩȋɏŝǮ˸ˏòȍ˵IŔˏŜȞo˻͞n˸̹̱̥͎͕͐͗̏ȃ˖ˠ˳˶̈ˮ˱ˏ˩˷¦ņ˚ť˷·Ao˻ŋ\ø˶çɹ ȘɄ˵ˤ̏˗˵˕ˠ˳̏ƶ¼˶˦̋˫̄˷̧̥̰͇ȟ-̏ȃ˖ˠ˳˚Ṓˤ˕ːȋɏŝǮ˚ˏ̪̲̖̽̒̕n˸ť˷˷7ɷ˶
Æ˦̋ˏ8ƥƦn˸þˤ˵˕çɹ̏ȤȮˤ˫¡zˏȏQæÍ˸ˏÏɢ̏¼Ķ˦̋S˶ˏĝřˢ̌˫3ũ˶ɤ˦̋͒
̻͌͗̏ȃ˖˷˚ɗJ˲˔̋˳Mĳ˦̋vǵø˚˔̋ːʍʉ¦ņ˸ˏúǮg¿˶ɤ˦̋sÁ˲˛˵˕ŪƟ̧̞͐˶ɤɐ˦̋Ƿãø˷̧̞͐̏3ũn˸#ž˦̋˫̄˶ĝřˢ̌˫̅ ȘɄ˵ˤ˷˙ͩÓȴë˷Ƿãø̧̞͐ȟ-˸ˏûƚ˚ĄV˦̋vǵøo˻úǮg¿˷ɝ©ˢ˶˰˕˱ȟ-˦̋ˠ˳˚Ṓˤ˕ːʃŵȘͨ ȘɄ˵ˤˇúǮg¿ˈ˷ºǪ˸ˏʞʦʣʃʌʏʔʒʌʕʍʋʋʒcƤť̶̧̞̦͈͕̲͐͜ͅ˷cƤť˽˷ɗƚ˲ºǪ˦̋ˇg¿ˈ˷̣̩̮̲̾
˲˔̋ːúǮg¿̏Ɠ˜ºǪ˦̋ˠ˳˸ˏBȂȅƘ̏1Ȱ˦̋˫̄˶òȍ˵¦ņ˶Æ˦̋ȏQæÍ˷̻͒͌͗̏=?˦̋˳
˕˖ũ˷\ŕ˚˔̋ːȆʎ˸ˏ̪̲̖̽̒̕n˸ť˶˩˷˷çɹ̏˗̣̹̩̜̰̋̔͗͌͐̓̏åb˦̋˫̄ˬ˞˶ȃ̎̌˫¦ņ͙˦˵̎ ȘɄ˵ˤ˭ˏˠ˷̩̞̥͎͕˶Ƹˤ˫ŉL˷Ⱥ˽˷ǲºƦ˵ǆ͚˶ɗƚvǵ˲˔̋ː˩˷˷¡z˸ˏ̣̹̩̜̰̔͗͌͐̓
§˷̪̲̖̽̒̕¦ņ˶ɤ˦̋ɍ×˷̧͓̩̿̏ɗƚ˦̋ːȆʎ̪̲̖ͨ̽̒̕1¶o˻ȏQæÍ˷ƨȐ˶˯˕˱˷ě¬͒́͑ȘɄ˵ˤ̩̜̰͌͐̓åbˏǷãø˷3ũn˸̧̞͐#žĝřˢ̌˫̪̲̖̽̒̕¦ņ˚ˏȌĮ˷Ƿãø˶çɹ˦̋ˏn˸ˏˇ̣̹̔͗ȅƘǈƖˈ̏ħˤÌ˵˜˳̅˯˷Ƿãø˶ ȘɄ˵ˤçɹ˦̋¡zˏȋɏŝǮ˸ˏ˩˷ë˷̞̥͎͕̒̏ɍƲ˦̋ɭˏȆʎ˲Ȣæ˦̋ɺƪ˷˖˭ŉʂ͒́͑˷ɺƪ˷ɗƚ̏ŜȖ˦̋ˠ˳˚Ṓˤ˕ː*˗˹ˏ˺˳˯˷̪̲̖̽̒̕¦ņ˲ˏ̧̥̰͇̩̜̰͌͐̓̏åbˤˏǷãøʖ͙úǮg¿˷ŪƟ̧̞͐˚sÁvǵ͚˷̧̞͐̏#žˤˏǷãøʗ͙úǮg¿˷ŪƟ̧̞͐˚sÁ˲˛˵˕͚̏3ũ˦̋ˠ˳˚˔̋ːˠ˷¡zˏǷãøʗ˶ɤɐ˦̋ˇʂˈ͒́͑˷ȏQȍŮɺ˚ɗƚˢ̌̋ː˕˙˵̋͒́͑˶˘˕˱̅ˏȏQæÍ˸ˏǺ̉˷Mĳ˲ˏȋɏŝǮ˚ʞʚʘʃʑʍʎʋʏˎcƤť̪̲̖̽̒̕͜͏̣̞̔̽̔͑˶ ȘɄ˵ˤȏºˤ˱˕̪̲̖̋̽̒̕1¶˷͏̧̣̞͓̩̔̽̔͑̿o˻˩˷˷ȏQȍŮ˶ɗz˦̋ȞĒ̏ȍŮ˦̋ˠ˳˚˔̋ːʑʉʐʃ͕̥̱͕̲̔˽˷ÆóʑʉʐʉʌʃcƤťȋɏŝǮcƤťȋɏŝǮ˸ˏȋo˻úǮ̏̃ʀ½˶çɹ̏ò˦˙̅ˤ̌˵˕ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔o˻ ȘɄ˵ˤȱ˶Æˤ˱ˏÆó˷Ƃ9̏ȃ̎˵˞̌˹˵̉˵˕ː˩˷˫̄ˏȋɏŝǮ˸ˏǺƹ˷ȋ̲̘̙̈́͗̽͐˶˰˕˱ˏ͕̔
̥̱͕̲ÆóǈƖ̥̈́͐͗̏ƶǂˤˏ͕̥̱͕̲̔Æó̭͇͗̏ǔǧˤ˵˞̌˹˵̉˵˕ːʃ͕̥̱͕̲̔Æó̭͇͗˷ƪƦ˸ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔̏ȟ-ˤˏÆóˤˏ˩ˠ˙̉´˼˫̄˷ɗJ˵ǵȔĝ+ˤˏŧ˶͕̥̱͕̲̔˚ȼˠˮ˫¡z˶̫͇̔͐͗˲ɗJ˵ȃ]̏˳̋˫̄˶òȍ˵ˏȫįˏǈƖˏ̳̹̮̞̽̓͗o˻̵̢̠̥͎͕͆͌͗̏ĝ+˦̋ˠ˳˲˔̋ː
Ƃ9˶˸ˏ͕̥̱͕̲̔ǈƖ̥̈́͐͗˷ƶǂˏȣǑ˵͕̥̱͕̲̔ÆóȕƝ˷Ǉºˏ͕̥̱͕̲̔Æó̭͇͗˷ǔǧˏ͕̥̔ ȘɄ˵ˤ̱͕̲Æó˷ºōƦ˵Ƞʁo˻ǣǫˏ˻˶í̉̌˫ĭȗ̏ɍ˥˱ˠ˷ǵȔǛǜƦ˶}˦̋ˠ˳˚́̌̋ː
ʞʦʣʊʞʚʘʃʍʒʋʎʐ˶ȏº˦̶͕̥̱͕̲̦͈͕̲̋̔ͅ˶˸ˏŧ˷"͒́͑˚́̌˱˕̋ː͙ȣǑ˸èT˳ȶ˷̩̞̥͎ ȘɄ˵ˤ͕̏mƊː͚ͨȕƝo˻Ƃ9ˏŜƲo˻ ˏȟ-o˻ůºˏÆóo˻í̉̌˫ĭȗː͙yɺƪ˷Ȩľ˸ˏɦÐŇ̏mƊ͚ːʫʉʃèTo˻ȶȘɄ˵ˤ͕̥̱͕̲̔Æó̭͇͗˸ˏ̶̦͗͊ͅˏȕƝ'Ą̟͑͗̿ˏƨȐ̟͑͗̿ˏÆó̟͑͗̿ˏ¼Ķ̟͑͗̿ˏIŔ̟͑͗̿˵˴˷ˢ́ˣ́˵̟͑͗̿˶ITˢ̌̋ˠ˳˚˔̊ˏł˶˸§ɚ˷ÈɡÀ̏̃ːy̟͑͗̿˶˸ˏ˩̌˪̌˷èTo˻ȶ˚˔̋ː̭͇͗˸ˏ̧̜͑o˻ƲȮ˶˰˕˱͈͕̹̟͗̏͑͗̿˶T̊æ˱̋ˠ˳˚Ṓˤ˕ːèǰ˶̈ˮ˱˸ˏȌĮ˷̭͇͈͕̹͗͗˚ďæˤ˱˕̋̅˷̅˔̋˙̅ˤ̌˵˕ːɤɐ˦̟̋͑͗̿˶T̊æ˱̉̌˫͈͕̹͗˸ˏ{˥n˸ɿ!˷'ŝ˶Æˤ˱ȶ̏ĕ˯ˠ˳˚Ṓˤ˕ː̶̦͗͊ͅˏȕƝ'Ą̟͑͗̿ˏƨȐ̟͑͗̿ˏÆó̟͑͗̿ˏ¼Ķ̟͑͗̿ˏIŔ̟͑͗̿˷èT˶˯˕˱˷ȣǑü ˸ˏɦÐŇʖ˶Ƹˤ˱˕̋ː

ʤʦʞʥʧ˷òȍøʬʉ̵̢̠̥͎͕͆͌͗˶Æ˦̋ōéȘɄ˵ˤ
ʀ½˶Æˤˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔o˻ȱ̏ ˦̋˫̄˷cƤťȋɏŝǮ˷ɐǗ?ü ̏ĝ+˦̋ˠ˳˚Ṓˤ˕ː˔̋˕˸ˏɍ×˷ʀ½̶̣̲̭̈́͗͊͑̏ɍˤ˱̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔o˻ȱ̏ɍƲ˦̋˷˚Ṓˤ˕ː͕̥̱͕̲̔Æó̭͇͗˷ƪƦ˸ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔̏ȟ-ˤˏÆóˤˏ˩ˠ˙̉´˼˫̄˷ɗJ˵ǵȔĝ+ˤˏŧ˶͕̥̱͕̲̔˚ȼˠˮ˫¡z˶̫͇̔͐͗˲ɗJ˵ȃ]̏˳̋˫̄˶òȍ˵ˏȫįˏǈƖˏ̳̹̮̞̽̓͗o˻̵̢̠̥͎͕͆͌͗̏ĝ+˦̋ˠ˳˲˔̋ː͕̥̱͕̲̔Æó̭͇͗˸ˏ͕̥̱͕̲̔˷çɹ̏s˞̋A˱˷O¿ɤ/Ǯ˶ŉĴü ̏ĝ+˦̋˫̄˷ĺ×ŷ]˷Ÿ̌̏ƶǂˤˏŉL˷ƥȎë˲˛̋ˬ˞Ľ˜ʀ½}˞˷̵̢͆͌
̠̥͎͕͗̏ĝ+˦͙̋ȋɏŝǮ˸̫͇̔͐͗˵̵̢̠̥͎͕͆͌͗˶ɤ˦̋Əº˷ǈɆȍ̏Ʋˮ˱˘˜ˠ˳˚Ṓˤ˕͚ː
͕̥̱͕̲̔ ˶͕̬́͗˶̈̋ Ňn˸ɍƲ̏Sɉ˷̫͕̟̔͆˲ƥȃ˲˛̋˙˴˖˙˸ˏʀ½˳˷̫͇̔͐͗˲ũƶ˵̵̢̠̥͎͕͆͌͗˶,³˦̋˙̅ˤ̌˵˕ː
úǮ·Ao˻̿͏̹̥̔͗˶çɹ˦̋cƤť˷̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˸ˏȢæ˦̋ȏQæÍ˶Æˤ˱ȏ ȘɄ˵ˤQ˷ȍŮ˶ìˮ˱ ˤ˵˞̌˹˵̉˵˕ːȫŖ˷ɔƽ˲ƐǨȃƇ˚Əºˢ̌˫¡z˸ˏƕ˷ɗƚvǵ˵ųȃťɤ˶ɍƲˤ˵˞̌˹˵̉˵˕ː̟͓̹͗͑˵̣̹̩̜̰̔͗͌͐̓˷ĨĤo˻ȱ˶ɤ˦̋ņ˵̋ȫį˶˯˕˱˸ˏ̣̔
̹̩̜̰͗͌͐̓Ǟ÷Æó̭͇͙͗ʘˀʬʯʺʃʚʶʯʺʱʯʷʭˀʃʥʯʻʹʸʷʻʯʃʧʯʫʶʕʃʘʚʥʧ͚o˻ü CŋIŔťɤ͙ʞʷʰʸʺʶʫʼʳʸʷ
ʦʲʫʺʳʷʱʃʫʷʮʃʖʷʫʵˀʻʳʻʃʣʺʱʫʷʳˁʫʼʳʸʷʕʃʞʦʖʣ͚˶ɐǗˤ˵˞̌˹˵̉˵˕ː
ʑʉʐʉʍʃ̧̠͓̹̬̀͑̒̿̔

̧̠͓̹̬̀͑̒̿̔˸ˏ̩̜̰͕̥̱͕̲͌͐̓̔̏GƖ˦̋˫̄˷̥̈́͐͗ˏ̩̜̰͕̥̱͕̲͌͐̓̔̏Ǣ n˸ȓů ȘɄ˵ˤ
ˤˏE§˷O¿ɤ/Ǯ˶Æˤ˱ɤɐ˦̋ü ̏ɢƸ˦̋˫̄˷̵̨͈͇̏̚ƶǂ˦̋ˠ˳˚Ṓˤ˕ː˩˷ƪƦ˷˫̄˶ˏ
̧̠͓̹̬̀͑̒̿̔˸ˏť˷Ȼ@o˻͞n˸1¶ȸƚ˶ť˷Ƿãø̏Ǣ ˦̋˫̄˷̢̧̲̏ǔ̂ɇ̃ˠ˳̏ŜȖ˦̋ˠ˳˚Ṓˤ˕ːˠ̌˶˸ˏ͕̥̱͕̲̔ ˶ˏòȍ˶ó˥˱ 9n˸ɊW˷ť̏)ƚ˲˛̋̈˖˶˦̋ˠ˳˚́̌̋vǵø˚˔̋ːʫʉ̥̈́͐͗o˻èTȘɄ˵ˤǷãøn˸̩̜̰͕̥̱͕̲͌͐̓̔˷GƖ̥̈́͐͗o˻èT˚ˏ̧̠͓̹̬̀͑̒̿̔˷ǔǧ˶Țºˢ̌˱˕̋ˠ˳˚Ṓˤ˕ːˠ˷̥̈́͐͗˸ˏ̧̠͓̹̬̀͑̒̿̔˚ˏȋɏŝǮ˷ɢƸİŇ͙*˗˹ˏʡʙʦʍˏʦʗʣʡˏǷãø̺̮̭͞ü ͚ˏü Cŋťɤn˸mWˤ˱˕̋ü CŋIŔťɤ͙ʞʷʰʸʺʶʫʼʳʸʷʃʦʲʫʺʳʷʱʃʖʷʫʵˀʻʳʻʃʣʺʱʫʷʳˁʫʼʳʸʷʻʕʃʞʦʖʣʻ͚˙̉˷ü ̏s˞r̊ˏÛ̄̋ĵų̏ƶǂ˦̋ˠ˳˚Ṓˤ˕ː˩˷˫̄˶˸ˏü ĝ+?o˻ĝ+>˷ɐǗ?̧̲͐̏ºōƦ˶1¶ˤƶȞˤ˵˞̌˹˵̉˵˕˳ˢ̌˱˕̋ː{š˶ˏ̧͕̲̔͗͑S˶ǡǖˢ̌˱ºōƦ˶Ȏƫˢ̧̣̻̌̋͗͒́͑«Ǎ͙ʻʯʺʾʳʭʯʃʵʯʾʯʵʃʫʱʺʯʯʶʯʷʼʻʕʃʦʠʖʻ͚˶˘˕˱ˏ͕̥̱͕̲̔Æó ˶ȋɏŝǮo˻˩˷˷͕̬́͗˚ì˖˾˛ȍļ˳Œɺ̏ȘɄˤ˵˞̌˹˵̉˵˕˳ˢ̌˱˕̋ː̧̠͓̹̬̀͑̒̿̔˸ˏƒǺ˷̩̜̰͕̥̱͕̲͌͐̓̔Æó̭͇͗n˸{š˷ǔǧ̏ǂ˭˟̋ˠ˳˚Ṓˤ˕ːʬʉèTˡ˳˷̵̲͕̟͒͗
ȘɄ˵ˤ˩̌˪̌˷ɤɐ˦̋èT̵̲͕̟̏͒͗˦̋˫̄˷ȍŮɺ̏ƶǂˤˏņĴ˦̋òȍ˚˔̋˙˴˖˙̏ºōƦ˶Ȏƫˤ˦̋ˠ˳˚Ṓˤ˕ː̩̜̰͕̥̱͕̲͌͐̓̔˷ȞĒ̏ȟ-˦̩̜̰̋͌͐̓˷ÈɡÀ˸ˏ¼^Ǖʁ˶W˗˱ˏ̩̜̰͌͐̓˷
̘͕̦̮̞̽͒IŔ˷̵̲͕̟͒͗̏s˞̋ˠ˳˚Ṓˤ˕ː̩̜̰͕̥̱͕̲͌͐̓̔Æó̧͓̩̿˶ɤ˦̋˸ˏ¼^Ǖʁ˶W˗˱ˏ͕̥̱͕̲̔Æó˷̧͓̩̿o˻Ɩȭ˶˯˕˱̵̲͕̟͒͗̏s˞̋ˠ˳˚Ṓˤ˕ː̵̧̲͕̟͓̩͒͗̿˸ºōƦ˶ȟ-˦̋ˠ˳˚Ṓˤ˕ː˩˷ȟ-̏ȃ˖˫̄˶ˏ͕̥̱͕̲̔ÆóƄǫ˚ȃ̎̌̋˙̅ˤ̌˵˕ː
ʭʉIŔo˻ÆóȘɄ˵ˤ̧̠͓̹̬̀͑̒̿̔˸ˏE§˷ɤ/Ǯ˙̉˷ n˸̵̢̠̥͎͕͆͌͗˙̉Ƿãøn˸͕̥̱͕̲̔̏ƏºˤˏŜȞ˦̋ˠ˳˚Ṓˤ˕ː̧̠͓̹̬̀͑̒̿̔˸ˏȫŖǖŕ̏ȘɄˤ˫ü ̏ĝ+˦̋ˠ˳˶̈ˮ˱ˏçɹ̏ȟ-ˤˏO¿ɤ/Ǯ˳eU˦̋ˠ˳˚Ṓˤ˕ːȓů˷˫̄˷̞̥͎͕̒˚òȍ˵¡z˸ˏȫŖ˷ƑŲo˻ȫŖ˷ĺƽ̏ǖŕ˶̄̋ˠ˳˚Ṓˤ˕ː̧̠͓̹̬̀͑̒̿̔˸ˏúǮ˚ˏ̧̲́̿͏̧̞̰̓o˻Ǣ Ǉ̏̃·Aɤɐü ̏Ʋ̉ˢ̌̋̈˖˶˦̋ˠ˳˚Ṓˤ˕ːȓůǇ˶3ũ˚́̌˱˕̋¡z˸ˏ˩˷3ũ̏ĶȚA$˶ɗƚ˦̋S˶ˏ̹̱̥͎͕͐͗o˻̟̮͒͒
̥͎͕Ƞʁ̏¼ȃˤ˵˞̌˹˵̉˵˕˳ˢ̌˱˕̋ːˠ̌̉˷̧̰̲˸ˏ3ũ˶̈ˮ˱Ĺ³˷̧̥̰͇ťǵ˚ ĳˢ̌˵˕ˠ
˳̏1Ȟ˦̋ˠ˳˚Ṓˤ˕ː̧̠͓̹̬̀͑̒̿̔˸ˏ3ũo˻Ǣ ˷ü ̏òȍ˶ó˥˱ņĴ˦̋˚Ṓˤ˕ːʑʉʐʉʎʃȏQæÍcƤť˷̣̹̩̜̰͕̥̱͕̲̔͗͌͐̓̔˳˩˷Æó˲˸ˏcƤťȏQæÍ̅ɤ˦̋ːSɉ˷̩̞̥͎͕͙ȋɏŝ ȘɄ˵ˤǮ˶̈̋Æó˷̩̞̥͎͕͚˲ɉ˾˫̈˖˶ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˶˯˕˱ȏQæÍ˚ȤȮˤˏȏQ˶ɤ˦̋þöůº̏ȃ˖˷˶òȍ˵ȣǑü ̏ȏQæÍ˚ȍŮˤˏòȍ˶ó˥˱ȏQæÍ˚ɊW˷̞̥͎͕̒̏¼ȃ˲˛̋̈˖˶ˏ̣̹̩̜̰̔͗͌͐̓˷͕̥̱͕̲̔˶˯˕˱ȏQæÍ˶ɍƲ˦̋˷˚Ṓˤ˕ːòȍ˶ó˥˱ȃ˖ɊW˷̞̥͎͕̒˶
˸ˏ*˗˹ˏúǮ˷·Aø˶Æ˦̋çɹ˷ȟ-ˏȋɏŝǮ˶̈ˮ˱ĝřˢ̌˫Ǣ Ǉ˷̶̮̲́̽̓˳̧̞͐˷ȟ-ˏO¿
ɤ/Ǯ˳˷̵̢̠̥͎͕͙̣̹̩̜̰͆͌͗̔͗͌͐̓ƴǀǮ˳˕ˮ˫ˏìœ˸O¿ɤ/Ǯ˶́̌˵˙ˮ˫ɤ/Ǯ˳˷̵̢̠̥͎͕͆͌͗̅͚̃ˏ˷ĩÝťɤ̆ȏQæÍ˳˷ɐĢ˵˴˚́̌̋˚ˏ˩̌˶ɧºˤ˵˕ːʑʉʑʃ̛̥͒͗cƤťʑʉʑʉʌʃcƤťȋɏŝǮ̛̥͒͗ťˏ˔̋˕˸ƕ˷̣̹̩̜̰̔͗͌͐̓˷Ƕ²˶Æˤ˱zƖƦ˶1Ȱ˲˛˵˕cƤť˸ˏ˩˷ť˷̣̔ ͙ͣʉ͠ʃ ucƤť˽˷Æó˶˯˕˱͚͓̟̿͏͇̏)ƚˤ˫cƤť˷¨˜˸ǯƚōɣ˚ɠ˜ˏƏº1¶ǈƖcƤť̹̩̜̰͗͌͐̓˚Țȕo˻1¶˶˘˕˱ŜȖˢ̌˱˕˵˙ˮ˫vǵø˚˔̋˷˲ˏ̧̠̀͑̒ɤ/Ǯ˶˳ˮ˱˷Ȫɾ˲ ˶Ėºˢ̌˱˕̋ːˠ̌̉˷cƤť̏ u˲ȴ¥˦̋¡zˏcƤťɤ˙̉â˛rˮ˫ȴ¥ŝǮo˻ ucƤť̏c˔̋ːˠ˷Ȫɾ˸ˏ˩˷ť˷ǹÜƦŋƚø˚ˏ̩̜̰͌͐̓˷̣̲̈́͗vǵø̈̊ɠ˜ǜ˜ˠ˳˚¨˕˳˕˖¼˶̈ˮ˱ˏ Ƥťɤ˽ȴ¥˦̋ȴ¥ŝǮ˸ˏcƤť˷į9ǅ˶ɤˤȋɏȴ¥ŝǮ˽Ɗˤˏ˩˷ĖƸ˶˰˕˱į9̏ȃ˖ˠ˳˚ņ˶ûb˦̋ː̛̥͒͗ť˸ˏť˷Țȕ¦ņ˶̈ˮ˱1Ȱ˦̋ˠ˳˸˲˛˵˕˚ˏȊ¸ƦÆǇ̏¼Ķ˦̋ˠ˳˲ˏ˔̋ Ů̄̉̌˱˕͙̋cȁˏcƤťǅ˷Ⱥˏŋ\øo˻·Aø˷ƶ1ǅ˶ɤ˦̋ųêĶȃȏR͙Ł ʎʑʃÚiƘƭǄƽÞ˸1Ȱ˲˛̋vǵø˚˔̋ː͠x͚ǄʌʒʋʃŒ͚ːˠ˷˫̄ˏ ucƤť˶˯˕˱̅ˏȋɏȴ¥ŝǮ˸æȢcƤť˷ȴ¥ŝǮ˶ÆˤɗJ˵ĖƸ̏ȃ˕ˏ̧̣̹̞̔͗͐˽˷Æó̏¼Ķˢ˨̋òȍ˚˔̋ː́˫ˏȴ¥ŝǮ˸ˏcƤťɤ˶Æˤˏȴ¥˦̋ ucƤť˷̧̣̹̞̔͗͐˽˷ÆóƑŲǅ˶˯˕˱ɗJ˶Ȩľ˦̋òȍ˚˔̋ː

ȏQæÍ˸ˏòȍ˲˔̌˹ˏȊ¸ƦÆǇ̏¼Ķˤ˱̛̥͒͗ť˷ɾ̏ȓů˦̋̈˖cƤťȋɏŝǮ˶0˦ːť ȘɄ˵ˤ˷ȚȕˏǷãø˷ǈƖo˻ʀ½˳˷̵̢̠̥͎͕͆͌͗˸ˏA˱̛̥͒͗ť˷̣̹̩̜̰̔͗͌͐̓˷Ȫɾ˶r̊ǔ̃˲ɝȍ˵èT̏ŕ˫˦ːȋɏŝǮ˶Æ˦̋ě¬ɺ˸ˏŧ̏̃ːˉ̩̜͌̒˵ɢƥ͇͔̞̽͒͗͗˷>˲ť̏Țȕɢƥˤˏť˚ˏÌ˵˜˳̅ˏ̩̜̰͌͐̓Ƃ˶ɗzˤˏ̮̱̲̒̿͗o ȘɄ˵ˤ˻̺̮̭˷̵̨͈͇̏̚̃̈˖˶˦̋ː͙˦˵̎˭ˏǹÜƦ˶ŋ\˵ōɣ̏ɍˤ˱1¶˦̋ː͚ˉ̶̧̞̦͈͕̲͐ͅ˷Ɨ˳ˤ˱ˏ̛̥͒͗ť˶ɝ©˵Ƿãø˚³ˤ˵˕˙ƨȐˤˏ˲˛̋ɧ̊ŉ˷Æó̏ȃ˕ˏť˷ȋ͏̣̞̔̽̔͑A$˷ěƼ˶z̎˨˱̧̞͐ɤɐİŇ̏ǛǜƦ˶̴̧͈͕̰͕˦̋ː
ˉȋÇǓ ͙ʯʷʮʃʸʰʃʵʳʰʯʕʃʚʣʠ͚o˻̣̲̈́͗Ǔ ͙ʯʷʮʃʸʰʃʻʽʹʹʸʺʼʕʃʚʣʦ͚˶ɤˤ˱ˏȻ@˳Țǩ˷̧͓̩̿˷ɚ˳ˤ˱ˏ
˩˷łƆ˲˷ʀ½˷ȶ˶˯˕˱̅̄˱ˏľƶ˶ɍƲ˦̋ːˠ̌˸ˏcƤťɤ˚ˏǺɂ˷ȶo˻ť˷̧̞͐̏Ɩȓ˦̋ĈX˞˶˵̋ː
ʑʉʑʉʍʃ̧̠͓̹̬̀͑̒̿̔

ǹÜƦ˶ŋ\˵ōɣ˳ˤ˱ˏȋɏŝǮ˚Țºˤ˫ť˷ȋÇ̈̊©Ø˶ɠ˕ōɣ̏ȕƝ˦̧̠͓̹̬̋̀͑̒̿̔˚ ȘɄ˵ˤ¨˕ːˤ˙ˤˏł˷Ǖɔ˳˳̅˶Ƕ²˷ƑŲ˚¦bˤˏĴˤ˕Ƕ²˚Hƕ˦̋˶˯̌ˏłɒ̌˷̷̰̞͓̦͗̏)ƚ˦̧̞̋͐o˻̢̧̲˸£WˤˏcƤťȋɏŝǮo˻̧̠͓̹̬̀͑̒̿̔˷C{ȶ˳ˤ˱ÆGˤ˵˞̌˹˵̉˵˕˳ˢ̌˱˕̋ːŧ˷ě¬ɺ˸ˏ̧̠͓̹̬̀͑̒̿̔˚̛̥͒͗˷Ȫɾ˶r̊ǔ̃˫̄˷X˞˶˵̋˳ōéˢ̌̋ːʡʙʦʍˏʦʗʣʡˏǷãø̺̮̭͞üˉɗJ˵͏̣̞̔̽̔͑˷ȕƝ'ĄˏƖȓo˻Ɍľø̏ƶ¼˶˦̋˫̄˶ˏcƤťȋɏŝǮ˳̧̠͓̹̬̀͑̒̿̔˳˷ ȘɄ˵ˤɣ˷̈̊ǽ˕̵̢̠̥͎͕͆͌͗˚òȍ˲˔̋ːˉȌɲ˵cƤť˶˸ˏ¨˜˷̸̳̖͗̒̕o˻̪̲̖̽̒̕˚́̌˱˕̋ˠ˳˚¨˕ː˩̌˶˸ˏcÕ˚úǮ̏ȝĳˤŰƤ˦̋˫̄˶òȍ˵ü ̏ĝ+˦̋˫̄ˏɐĢˤ˱]'˦̋̈˖Țȕˢ̌˫ˏ̧͔̞̰̥͎͕͗͗ˏ̣̹͗͗ˏ̙̰͂͒͗̓
̧͕̟̥̰͇o˻˩˷˷̣̳̺̰̪̲̖͗͗̓̽̒̕˚́̌̋ːʃ˩˷̪̲̖̽̒̕ŠĄȆ͙ʻʸʰʼʿʫʺʯʃʗʳʵʵʃʸʰʃʡʫʼʯʺʳʫʵʻʕʦʗʣʡ͚˶˘˕˱ˏ̣̲̈́͗͏̣̞̔̽̔͑˚ŉ̅Ƴ˕̶̢͕͕̲̈́͗˚ˏŉǓƦ˶ť˷̣̲̈́͗øo˻̩̜̰͌͐̓˶çɹ̏˗̋ːʃɌľø̏ƶ1˦̋˫̄ˏcƤť˷ȋɏŝǮ˸ʀ½˶Æˤ˱̪̲̖̽̒̕ŠĄȆ̏ĝ+ˤ˱ˏʀ½˚ť˷͏̣̞̔̽̔͑˶çɹ̏˗̶̢͕͕̲̋̈́͗̏̈̊̈˜Ɩȓ˲˛̋̈˖˶ˤ˵˞̌˹˵̉˵˕ːʃˠ˷ŠĄȆ˶˸ˏȊ¸ƦÆ
Ǉ˷̈˖˵̧̢̞͕̲͓͐͗͑Ĉū˶ƚ˕̉̌̋ɊW˷̸̳̖͗̒̕ü ̏̄̋ˠ˳̅˔̋ː
ˉcƤť˷ȋɏŝǮ˸ˏ̪̲̖̽̒̏̕̃A˱˷ȋ˶˯˕˱ˏ̣̲̈́͗Ǔ ĺ̏̃͏̣̞̔̽̔͑˷ɝȍ˵̧̲͕̔͑͗̏ͅľƶ˶˗̋ˠ˳˚Ṓˤ˕ːʃ̧̣̲̲͕̈́͗̔͑͗ͅ˻˶ť˷̮̱̲̒̿͗o˻̮̟̳̒̿͒͗˷̙̥͎̿
͕̏̃cƤť˷͏̣̞̔̽̔͑ǈƖ˸ˏcƤťȋɏŝǮ˷ȶ˲˔̋ːˉ̧̠͓̹̬̀͑̒̿̔˸ˏcƤťȋɏŝǮˏ̣̳̺̰͗͗̓˷̧̣̻͗ŝǮn˸͓̹̬̿̔Ǻɂ˷̧̪͐͗o˻ǈƖ̏ɍ˥˱ˏ)ƚ ˷cƤť̏ɗJ˶̣̲̈́͗ˤǝĕ˲˛̋̈˖˶˦̋ȶ˚˔̋ːˉ̧̠͓̹̬̀͑̒̿̔˸ˏǺ̉˷Ɨ¢˶˘˞̧̞̋͐̏â˛ǜ˛ƖȓˤˏɗJ˵Ǣ Ǉ˶̈ˮ˱̧̢̞͕̲͓͐̏͗͑˦̋˫
̄˷ŉ©ɧ˷YȔȃ˖ˠ˳˚Ṓˤ˕ːˠ̌˶˸ˏ̶̮̲͔̞͗˷̩̟͈͕̰̥͎͕͗ˏ̧͍̤̞̩͗̒˷èTˏ̧̞̩͐̒
̧͈͕̲ˏ̩̜̰͌͐̓Ƞʁˏ̶̮̲͔̞͗ƨȐ˵˴˚́̌̋˚ˏˠ̌˶˸ɧºˤ˵˕ːɍƲ˶˷̂ȘɄˢ̌˱˕̋ɺƪcƤť˷̶̮̲͔̞͗ǅ˽˷ĚǜȘɄ˵ˤ̶̮̲͔̞͗ǅ˽˷ĚǜťȘɄ˵ˤƈǠɍ2ǅOƚ˷cƤťȘɄ˵ˤ͙͡ʉ͢ʉ͡ʃƈǠɍ2ǅOƚ˷cƤť͚ɍƲ˶˷̂ȘɄˢ̌˱˕̋ɺƪƈǠɍ2͙cƤƚƈǠŴĮÖˏʗʵʽʯʼʸʸʼʲˏʪʳʈʛʳʃǅ͚̏OƚˤˏcƤť˷̵͍̮̲ɣn˸cƤťɣ˲Qî2x̆ü Ğ̏˦̋ťǵ̏ŋ˦̋ť˶ɤˤ˱˸ˏOƚˤ˱˕̋ċȄo˻)ƚ˦̋ť˷ƾɿ˶˘˞̧̞̋͐˶ó˥˫ɛă˚òȍ˳˵̋ː

ʨʦʗʃǅ˷§ɚ@HǗ̲͗ȘɄ˵ˤ͙͡ʉ͢ʉ͢ʃʨʦʗʃǅ˷§ɚ@HǗ̲͚͗ʨʦʗʃ̲̈́͗̆ʘʙʊʙʩʙʃ̳͏̔̾ǅ̏9˗ˏ)ƚvǵ˵ƑĀ˶˔̋cƤť˶ɤˤ˱˸ˏˠ̌̉̏)ƚˤ˫¡z˷̧̞͐˽˷Æó˚òȍ˳˵̋ː͙͡ʉ͢ʃcƤť˷̶̮̲͔̞͗ǅ˽˷Ěǜ͚ɍƲ˶˷̂ȘɄˢ̌˱˕̋ɺƪcƤť˶˘˞̋ɍ2ťǵ̶͖̮̲͔̞͗˽˷Ěǜ̆ʨʦʗʃǅ˷̲̈́͗˷Oƚ˶ó˥˫̧̣̹̞̔͗͐˷ŜȖ˚òȍ˳˵̋ː͙͡ʉ͢ʉ͠ʃ̶̮̲͔̞͗ǅ˽˷Ěǜť͚ɍƲ˶˷̂ȘɄˢ̌˱˕̋ɺƪcƤť˚Ěǜˢ̶̮̲͔̞̌̋͗̏Ɂ́˗˫ŜȖ˚òȍ˲˔̋ːcƤťɤE˶ɧºˢ̌ˏ̶͕̫̮̲̔͗Ǡ˳Iɳˢ̌˫Ɨ¢˲)ƚˢ̌̋ť˳ˏ̶͕̫̮̲̔͗Ǡ˽˷Ěǜ̏þ˦̋ť˲˸ˏ)ƚƗ¢˚Ƣ˵ˮ˱˘̊ˏĚǜƗ¢˶ó˥˫Æó˚òȍ˳˵̋ː̶̮̲͔̞͗ɍ2˶̈̊cƤťE˷ü ̏ɋs2ˤ˫̊ˏĥ'ˤ˫̊˦̋ˠ˳˚vǵ˵cƤť˶˯˕˱˸ˏ̈̊āɝ˶̣̹̩̜̰̔͗͌͐̓Æó̏ǭă˦˾˛˲˔̋ː˵˘ˏ̶̮̲͔̞͗Ěǜ̏Oƚ˦̴̧͉̲͈͕̰͕̋͐͗ǅ˷1¶ťǵ̏ĕ˯cƤť˶˯˕˱̅{š˲˔̋ːɍƲ˶˷̂ȘɄˢ̌˱˕̋ɺƪ