JP2002539564A - 取引サポート・システム - Google Patents

Abstract

(57)【要約】 財産上の取引きをサポートする中央データベース・システム。中央データベースは、インターネットのような公共ネットワークを介してシステム・ユーザによってアクセスされる。中央データベースは、定められたグループであるユーザの資格を記録するタイトル・レジストリを形成し、電子的に作成されたレコードに関して所定のアクションを起こす。電子的に作成されたレコードは、基礎的財産に関連する厳密に定義された一連の権利および義務を表し、１つの取引きをサポートするために１つのレコードが作成される。ユーザは、以前に権限が付与されたユーザにより所定の役割に指定されることにより、権限を獲得する。レコードにおける所定の役割へのユーザの指定は、システム・ユーザがデータベースへ電子命令を送信するによって行われ、これらの電子命令はレジストリ命令またはタイトル・レジストリ命令と呼ばれる。

Description

【発明の詳細な説明】

【０００１】 発明の背景 本発明は商取引をサポートするためのコンピュータ・システムに関し、限定さ
れるものではないが特に、輸送(shipping)による商品の取引をサポートするため
のコンピュータ・システムに関する。この場合、輸送とは、例えば、航洋船、航
空貨物、鉄道貨物、および道路運輸による商品の輸送を含むものと理解されたい
。

【０００２】 数百年にわたって、積荷証券（船荷証券）の使用に基づいての商品の国際貿易
のための手続きが確立されてきた。船荷証券とは、輸送業者を介して売手（もし
くは出荷させるその他の当事者）から買手（もしくはその他の荷受け当事者）へ
の商品の輸送に関連して使用される書類である。船荷証券は、発送元から着地へ
出荷するために売手が輸送業者に商品を引き渡す際に輸送業者によって作成され
る。

【０００３】 船荷証券には、輸送業者が受領する商品目録（inventry）と、輸送業者が交付
する商品の状態が良好であることの確認（verification）とが含まれる。船荷証
券にはさらに、輸送業者が商品を着地で船荷証券を作成した者にだけ引き渡すこ
との保証を含む、輸送業者と売手との契約も含まれる。

【０００４】 船荷証券が輸送業者によって作成された後、この船荷証券は最初は売手が所有
する。輸送業者による商品の輸送中、船荷証券は売手から買手に渡されるが、こ
れは売手側の銀行や買手側の銀行のような様々な仲介者を介して行われる場合が
多い。最終的には、船荷証券は着地で商品と引換えに輸送業者に提示された段階
で使用済みとなる。

【０００５】 ここで買手と売手の間のそれぞれの銀行を介した標準的な取引の詳細をある程
度説明する。商品は発送元で輸送業者に引き渡される。輸送業者は船荷証券を作
成し、商品が完全なものであり、良好な状態にあることを認証する。売手は船荷
証券を受け取り、それを取引銀行に送る。売手側の銀行はそこで、この取引に信
用状および為替手形も介在する場合には、商品に関連する販売額を売手の口座に
記帳する。次に売手側の銀行は船荷証券を買手の取引銀行に送付する。船荷証券
を受領した買手側の銀行は、販売額だけ売手側の銀行へ入金し、販売額だけ買手
の口座から引き落とす。次に買手側の銀行は買手へ船荷証券を送付し、買手はそ
こで船荷証券を所有し、着地で輸送業者から商品を引き取ることができる。実際
には、様々な当事者による船荷証券の取扱いは、取引に含まれるその他の書類の
存在と項目によって影響されることが多いが、このような付随的な書類は説明を
簡略にするために、ここでは説明しない。その上、船荷証券それ自体は支払手形
ではなく、対応する支払手形は為替手形または小切手の形式をとることが多い。
これらの書類の性質と役割についても同様にここでは説明しない。

【０００６】 船荷証券は、指定された買手を変更できない、譲渡禁止（すなわち第三者に譲
渡できない）の証券である。この場合、輸送業者は発送元で輸送業者が作成した
時点で船荷証券に記載されている買手に商品を着地で引き渡す義務だけを負う。
譲渡禁止の船荷証券の指定の買手は受託者（荷受人）と呼ばれる。譲渡禁止の船
荷証券は記名式船荷証券(Straight Bill of Landing)と称される。

【０００７】 しかし、船荷証券が譲渡可能な証券となることも実際には広く行われているこ
とであり、この場合は、指定の買手を商品の輸送中に変更可能である。このよう
な場合、指定の買手は実際には商品の最終的な受取人ではなく、船荷証券の中間
の被譲渡人であるに過ぎない。譲渡可能な船荷証券の被譲渡人は指図側（To Ord
er Party）と呼ばれる。船荷証券が輸送業者によって作成される時点で、それが
譲渡可能であるか否かが既に指定されている。作成時に船荷証券が譲渡可能であ
る場合は、輸送業者は指図側、すなわち指定の買手を輸送中に変更できることを
承知している。船荷証券が譲渡可能な船荷証券として作成され、輸送中に買手が
変更された場合は、明らかに、輸送業者は着地で、船荷証券を作成する何れかの
当事者に商品を引き渡す。

【０００８】 譲渡可能な船荷証券に記載されている指図側を、船荷証券を所有しているいず
れかの当事者が変更することは物理的に可能である。しかし、その当事者が例え
ば船荷証券を銀行に対して裏書き(endorse)しないことは通常行われており、従
って、銀行は船荷証券を受領し、保持し、譲渡した場合でも指図側とはならない
。一般に、銀行は、取引に関与する別の当事者に対する銀行の立場を保証するた
めに、船荷証券を物理的に所有することに頼るだけである。

【０００９】 譲渡可能な船荷証券はさらに、それが無記名裏書（白地裏書）であれば、物理
的にこれを所有している人（持参人（bearer））に譲渡されてもよい。このよう
な船荷証券には白地裏書の間は指図側がない。指図側は着地で商品が輸送業者か
ら引き取られる前のある段階で後に付け加えてもよい。この場合も、一般に銀行
は明示された一連の裏書に現れることを望まず、従って、船荷証券を銀行の信用
貸しの副担保として所有することを利用するものの、銀行自体が指図側として加
わることなく無記名裏書きされた船荷証券を受領し、保持し、譲渡する。しかし
、商業上の仲介者はその所有権を示すために指図側として加わることを希望する
。

【００１０】 このように、無記名裏書きされた船荷証券、または指定された指図側を裏書き
された船荷証券のいずれでも、船荷証券は、これに変更を加えない当事者へと渡
されてもよく、その当事者は利益を確立または保全するために、船荷証券の物理
的所有にのみ頼る。このことは、仲介銀行のような当事者が、船荷証券の取引履
歴で明らかにされないので機密性が保持されるという利点を有している。何故な
らば、ある段階で指図側として入れない限り、船荷証券の以前のホールダーを再
追跡する証拠がないからである。

【００１１】 このように、特に譲渡可能な船荷証券の場合、従来の船荷証券取引システムは
、広く、船荷証券の記録されない物理的所有に依存するものであるということが
理解されるであろう。その上、船荷証券によって明示される輸送中の商品の見か
けの法定的な一連の裏書きと、船荷証券の所有による商品の推定的な実際の一連
の所有との間には相違があることが一般的である。このように、従来の船荷証券
システムは船荷証券の独特の性質に依存している。システム全体が、船荷証券、
すなわち船荷証券の商品目録部分に記載されている商品の１回の輸送に特定的な
一意的な書類によりに権利を譲渡することに基づいているので、船荷証券は１部
だけでなければならない。

【００１２】 しかし、従来の船荷証券システムの有効性を損なう様々な行為が展開されてき
ている。 不正行為の１つは輸送業者によって同じ商品に複数の船荷証券が交付されるこ
とである。輸送業者は売手に複数部の証書原本を渡す。２部の証書原本が作成さ
れた場合を例にとると、売手は輸送中の商品の迅速な支払いを得るために取引銀
行に１部を渡すことができる。次に売手はもう１部を買手に渡し、買手は、売手
側と買手側の銀行との船荷証券の処理が遅れたとしても、輸送業者から商品を引
き取ることができる。輸送業者、買手および売手は全てこのようにして共謀する
ことに関心がある。しかし、同じ商品に複数部の船荷証券が存在すると、複数部
の船荷証券を交付することの元々の動機が詐欺的なものではなくても、システム
全体が不正行為にあい易い。不正行為の余地は、特に譲渡可能な船荷証券の場合
に大きく、無記名裏書きの船荷証券の場合に最も大きい。例えば、船荷証券を債
券または抵当証書の担保手段として受け取ることができ、これは不正に入手可能
である。このように、担保として商品の１つの積送品を利用して例えば多重の融
資を得ることが可能である。

【００１３】 別の不正行為は船荷証券の偽造である。船荷証券が偽造されると、輸送業者は
荷受人（荷受側）または指図側の代表者を詐称した偽のアイデンティティと共に
偽造船荷証券を作成した者に、着地で商品を引き渡すことがある。偽造の余地は
、例えば船荷証券のコピーを入手することによって、偽造者が出荷の特性に関す
る情報を得た場合に発生する。航洋船による輸送の場合、最短の輸送期間は数週
間であり、このような場合は偽造者には偽造証書を完成する時間がかなりある。

【００１４】 従来の船荷証券の手順は不完全なものであるが、国際貿易を支援する主要な取
引システムとしてこれが継続して利用されていることは、現在まで成熟した優れ
た代替手段が確立されていないという事実に因るものである。銀行取引および商
業などの他の分野では電子取引システムは十分に確立されており、従来の紙によ
る取引書類がほとんど排除されている場合もある。注目すべき例は、電子支払取
引を支援するためのコンピュータ・システムである。

【００１５】 以前から電子的に船荷証券の作業を行うためのｅメールによるアプローチが提
案されてきたが、従来形の船荷証券システムは唯一の船荷証券原本に依存すると
いう事実を充分に斟酌しないために成功していない。船荷証券を表すためにコン
ピュータ・レコードが作成され、それが送信側から受信側に伝送される場合、シ
ステムが受信側での船荷証券レコードのコピーと送信側での船荷証券レコードの
コピーとを識別できないと、船荷証券レコードは船荷証券としての機能性を失っ
てしまう。その上、船荷証券は幾つかのコンピュータ・システムを通過するコン
ピュータ・レコードであるに過ぎず、ひいては一連の取引の何れの当事者によっ
ても複製され易いので、このような電子システムは依然として前述のような複数
部の船荷証券に基づく種類の不正行為を受け易い。

【００１６】 発明の概要 本発明の特定の且つ好適な特徴は添付の独立クレームおよび従属クレームに開
示されている。独立クレームの特徴は適切な従属クレームの特徴と組合わせても
よく、またクレームに明示的に開示された特徴以外の特徴と組合わせてもよい。

【００１７】 本発明に基づいて、ネットワークを経て、メッセージ・ハンドリング・ユニッ
トを介してシステム・ユーザがアクセスする中央（集中）データベース・システ
ムが備えられる。データベースは電子的に作成されたレコード（記録）に関連す
る規定の行いを実行するために、限定されたグループであるユーザの権利をレコ
ードするレジストリを形成する。電子的に作成されたレコードは基礎財産(under
lying property)に関連する厳密に規定された一連の権利および義務を表す。ユ
ーザは、それまで権利を有していたユーザにより規定の役割へと指定されること
によって権利を獲得する。レコードにおける所定の役割へのユーザの指定は、デ
ータベースへ電子的命令を送るシステム・ユーザによって行われ、これらの電子
命令はレジストリ命令、もしくはタイトル・レジストリ命令と称される。

【００１８】 データベースは、全てのユーザが参加する共通の契約協定に従って実行される
。ユーザになるには、加入意思を持つユーザはシステム・サービス・プロバイダ
とのサービス契約に加盟する必要があり、この契約では加入意思を持つユーザは
規定の規則集合に合意し、かつ遵守する義務を負う。すなわち、各ユーザはシス
テムのユーザになる条件として、規則の条項によって拘束されることに合意する
。ルール・ブック（規則書）に記載されている規則は、サービス契約と共に、財
産の取引のためのサポート・システムとしてのデータベース・システムの機能を
支援し、利用可能にする法的枠組みを提供する。

【００１９】 その結果、集中(central、中央)データベース内の各々の取引レコードは、全
面的にユーザの管理下で作成、変更および破棄の完全なライフサイクルを辿る。
集中データベースの完全性は、規則書に規定された閉鎖的な論理的規則集合に一
致することのみを根拠に、ｅメールまたはその他のメッセージで受信されるユー
ザ命令を承認または拒否するシステムによって完全に自動的に維持することがで
きる。全てのユーザは規則書によって契約上の拘束を受けることに合意している
ので、電子レコードを作成、変更および破棄するための電子命令の形のユーザの
行為は、命令自体が規則書に合致していることのみを条件として、契約上、影響
が及ぶ全てのユーザを拘束する。その上、取引レコードのコンテンツおよび変更
の法的重要性も自動的に共通の契約協定に従う。このように、集中データベース
は、これもまた共通の契約協定に規定されている、合意された規則と命令との合
致のチエックをすることおよび影響を受ける当事者へ通知することを通じてサー
ビスプロバイダによって、完全に自動的に保持することができる。さらに、船荷
証券の機能と重要性の変更は、ユーザの発意(initiation)によってのみ、取引レ
コードの変更を通じて、自動的に行われる。集中データベースに保持されている
何れの個別のレコードのコンテンツも主観的評価は必要ない。すなわち、取引レ
コードの日毎の処理には人間のシステム・スーパーバイザまたは管理者の役割は
存在しない。

【００２０】 各々の個別の電子レコードは規定されたユーザ・グループに所属するユーザに
よってデータベース内に作成される。レコードは、特定の財産権に関して命令す
るユーザ（命令側ユーザ）により送信されるレジストリ命令によって作成され、
このような財産権は命令側ユーザに帰属する。各々のレコードは、命令側ユーザ
の命令に従って、他のユーザに対して完全に譲渡可能であるか、または他の特定
のユーザに対して限定的に譲渡可能であるように作成してよい。

【００２１】 各々のレコードには、システムのユーザである一人のホールダー（holder）が
いる。ホールダーシップはレコードの領域内のホールダー／ユーザのユーザ識別
子の存在によって規定される。ホールダーはレコードの独占的な所有権、および
ホールダーの資格を他のユーザに譲渡する独占的な資格を有している。ホールダ
ーの資格の譲渡は、指定された他のユーザを対象のレコードのホールダー・フィ
ールドにおいて置換することを命令するレジストリ命令を送信する現ホールダー
／ユーザによって遂行される。

【００２２】 各電子レコードは、かかる電子レコードのホールダーのレジストリ命令によっ
て物理的な文書レコード（ハード・コピー）へと変換することができる。 基礎財産におけるある種の権利および義務に対するホールダーの権利は、権利
があるユーザによって指定された別の役割の前またはその役割と同時の達成に依
存するものである。その他の指定された役割には偶発的または自由裁量の役割が
含まれ、その場合、しかるべく指定された（および同時にレコードのホールダー
でもある）ユーザにはレジストリ命令によって自らを別の役割に指定する権利が
与えられる。このような異なる役割には異なる権利および／または義務が与えら
れる。

【００２３】 基礎財産を処分すること又は処分を指示する権利は、規定の一致する役割へと
指定された一人のユーザ、およびレジストリ命令をレコードを作成したユーザへ
通信するよう所有されたユーザ次第である。その後は上記レコードに関連する取
引は完了し、それ以上の指定は許容されず、レコードは終了する。

【００２４】 各電子レコードは、データベースに保存されている特定の監査追跡に加えて、
権利および義務の法的に重要な推移をレコードする一連の裏書（裏書きの連鎖）
に関連している。裏書き連鎖は、指定されたユーザとしての役割に従って、デー
タベースからのメッセージと共に新規の被指定人に分配される。

【００２５】 各電子レコードは、レコードのホールダーによって以前に送信されたレジスト
リ命令に従ってレコードを作成したユーザによる変更が可能である。レコードを
作成したユーザは、規定の規則に基づいて新規の電子レコード（１または複数）
を変更し、変更を断り、または作成する権利を有する。

【００２６】 各々の電子レコードはレコードのホールダーによって送信された規定のレジス
トリ命令の結果として、暫定的に停止することができる。 このようにして取引支援を取り扱う能力により、特に長期にわたって確立され
てきた伝統的な紙を使用したシステムおよび以前から企画されてきた他の電子シ
ステムと比較して、多くのさらなる利点を得ることができる。

【００２７】 （１）書類はホールダーからホールダーへと異なる国、および多くの場合、異
なる大陸へと移動するので、ペーパー（紙）形式で移動するオリジナルのシステ
ムは時間がかかる。場合によっては、特に積み荷が多数回取引される場合（例え
ば石油およびドライバルク貨物）、元の書類を着地で入手できることは稀である
。新たな問題点をもたらす補償の書類(letters of indemnity)の複雑なシステム
が、上記の問題点に挑戦して解消するように成長してきた。リスクの軽減に加え
て、速度を高めたことによって、国際貿易に関与する人々は、商品を取得し、在
庫を減らすことがより確実に可能になる。

【００２８】 （２）船荷証券に含まれる情報の多くは副次的書類で繰り返される。副次的書
類と船荷証券の完成に失敗する可能性は高く、書類のかなりの部分を修正のため
に返却しなければならない。電子書類は、書類を完成するために同じ情報が再使
用されるので、キー入力ミスの危険性が減る。

【００２９】 （３）集中データベースを使用することによって電子レコードの「改ざん封じ
」が可能になる。このようにして真正性が保証され、同時に、例えばインターネ
ットのような公共ネットワークを経たアクセスを介してユーザに対する融通性が
可能になる。対照となるペーパー書類とは異なり、集中データベースに保存され
ている適正に作成された電子レコードのコンテンツを変更しようとするあらゆる
企ては即座にレコードを混乱させ、完全にそのレコードを使用不能にする。ペー
パー書類は些細な変更を受けやすく、それが重大な意味を生ずることがある。そ
の上、船荷証券が電子レコードとして添付された連鎖ベースの電子メール・シス
テムはペーパー書類と同じ問題点にさらされることがあものの、その程度は大幅
に少ない。

【００３０】 （４）デジタル式サイン（デジタル署名）技術と電子証書（サーティフィケー
ト）を使用することは、メッセージの受信者が、メッセージが特定の当事者から
発されたことが確認できることを意味する。このようにして、否認の可能性が制
限され、その上、入念に限定される。それによって、特定のユーザ否認行為を組
入れることができ、これらは以下ではビジネス拒否（取引拒否）と称される。

【００３１】 （５）商業上の秘密情報に無認可でアクセスすることを防止するため、電子書
類を暗号化できるので、機密性が保持される。 （６）上記の要因は全て電子レコードの精度を高め、かつ機械による電子レコ
ードの確認を可能にする。再キーイングおよび人間による確認に要する相当の経
費が節減される。システムがより安全で正確である程、ユーザに、コストがかか
り且つ処理プロセスを遅延される再処理の必要なく処理プロセスが機能すること
を、一層確信させる。

【００３２】 本発明のその他の態様と特徴は添付の特許請求の範囲に例示されている。 詳細な説明 本発明をより明解に理解し、本発明をいかに実施するかを示すために、例示的
に添付図面を参照する。

【００３３】 ここで本発明を実施する最良の実施形態を添付図面を参照して説明する。 １．システムの概要 本システムは電子手段を介して貿易の取引を容易にする技術的および法的なイ
ンフラストラクチャである。これは、メッセージを転送し、ある種の情報を記憶
するための情報技術と、ある種のメッセージの効力を判断し、以下にさらに記載
する規則書に規定されているとおりに、記憶された情報を更新する規則および契
約の法的体系を利用する。以下のテキストでは上記技術とそのオペレーションの
動作手順を説明する。動作手順の機能性のビジネス効果は、添付の規則書に大き
く左右される。規則書の運用規則も、関連する運用手順と共に記載する。運用規
則は強制的なものであり、この規則書に従って契約法によりシステムのユーザを
拘束し、かつ自動取引サポート・システムを実施するために使用されるコンピュ
ータ・システムの多くの設計上の側面にも反映される。

【００３４】 本文書で特定の意味を付与されている用語は規則書（ルールブック）で定義さ
れている。 １．１．基本的運用構造およびプロセス 本システムの構造はメッセージ・ハンドリング・ユニットと、タイトル・レジ
ストリと、ユーザ・データベースと、ユーザ・サポート・リソースと、ユーザ・
システムとから構成されている。

【００３５】 メッセージ・ハンドリング・ユニットは、システム・ユーザの相互間、および
システム・サービス・プロバイダとの間で特定の電子メッセージを送り、一旦送
信されたこれらのメッセージの追跡を行うためのシステムである。本システムで
使用されるメッセージ・ハンドリング・ユニットは、一旦送信されたメッセージ
をロギングおよび記憶するためにデータベースと結合された、メッセージ転送の
ための特定のメール・サーバである。これはユーザ・データベースと密接に関連
して動作し、ユーザ識別子をチェックする。メッセージ・ハンドリング・ユニッ
トはさらに、特定のインターフェースを介してタイトル・レジストリとユーザ・
サポート・リソースとに情報を送信する。メッセージは、送信者（送信側）のオ
プションで、文書またはメッセージに含まれる他のデジタル情報ユニットである
「添付物」を含んでいてもよい。

【００３６】 タイトル・レジストリは、特定の取引に関連する権利および義務に関するメッ
セージから作成され、かつこのメッセージによって維持される情報のデータベー
スである。タイトル・リジストリは本システムの法的規則および契約と関連して
使用される情報を記録して、電子船荷証券に関するシステム・ユーザの変更の権
利を示す。

【００３７】 ユーザ・データベースはシステム・ユーザに関する情報のデータベースであり
、適正かつ認可されたユーザを識別し、本システムへのアクセスを制限し、かつ
メッセージ・ハンドリング・ユニットによってユーザから受信したメッセージの
真正性を判定するために使用される。

【００３８】 ユーザ・サポート・リソースは、システム・ユーザ、本システムの使用のヘル
プ、掲示板とアラート、ユーザ口座状態、およびそれに類する情報に関するオン
ライン情報の集合、および電話またはｅメールによるライブ・サポートのための
ヘルプ・デスクを備える。所望ならばさらなるサポート・リソースを追加しても
よい。オンライン・ユーザ・サポート・リソースはワールドワイドウェブのブラ
ウザを介して使用できる。メッセージをメッセージ・ハンドリング・ユニットへ
送信することはできず、また、タイトル・レジストリをユーザ・サポート・リソ
ースを介して修正することはできない。これらは単に、ユーザが必要な情報を探
索し、かつユーザ自身に関する情報を更新できるようにするだけである。

【００３９】 ユーザ・システムはメッセージ・ハンドリング・ユニットに接続されたネット
ワークへの通信リンク、かかる通信リンクに接続されたデスクトップ・コンピュ
ータ・ハードウェア、およびメッセージ・ハンドリング・ユニットを使用してメ
ッセージを作成、送信、受信するためのソフトウェアを含むユーザのコンピュー
タ装置である。

【００４０】 上記に列挙した構成要素のうちの最初の４つは、システム・サービス・プロバ
イダによって全てのユーザに提供される中央サービスである。５番目の構成要素
、すなわちユーザ・システムは、第三者の販売業者およびサービス局によって提
供され、メッセージ・ハンドリング・ユニットとインターフェースするためにサ
ービス・プロバイダによって規定される仕様と合致する必要がある。

【００４１】 図１はシステム構造を示し、構成要素間の情報および取引の流れを示す。タイ
トル・レジストリのさらなる内部構造は図１Ａに示す。より重要な情報の流れの
幾つかは、ユーザ間のメッセージ伝達、ユーザ・サポート・サービスのブラウジ
ング、ユーザ・サポート・リソースおよびユーザ・データベースの情報の変更、
およびタイトル・レジストリとの対話である。

【００４２】 ユーザ間のメッセージ伝達に関しては、本システムのユーザ間の主要な通信手
段は、各メッセージが通過するごとにこれをチエックおよびログするメッセージ
・ハンドリング・ユニットを介した電子メッセージである。メッセージ・ハンド
リング・ユニットはまた、メッセージが実際に届いたことを送信側に確認させる
ために、各メッセージが受信されるとその受取通知(acknowlegement、アクノレ
ッジメント)を送る。

【００４３】 オンライン・ユーザ・サポート・リソースのブラウジングに関しては、メッセ
ージ・ハンドリング・ユニットを利用して別のシステム・ユーザにメッセージを
送信するため、ユーザは受取側のユーザ識別子（すなわちユーザＩＤ）を知らな
ければならない。オンライン・ユーザ・サポート・リソースによって、一方のユ
ーザは、ユーザに関する入手できるその他の情報を検索するために他方のユーザ
識別子をルックアップし、メッセージのステータスをチェックし、かつ本システ
ムを使用する際のヘルプを得ることができ、これらは全て簡単なウェブ・ブラウ
ザ・インターフェースを介して行われる。ユーザの認可された代理人はまた、ユ
ーザに関するある種の情報を更新することができる。

【００４４】 ユーザ・サポート・リソースおよびユーザ・データベースの情報の変更に関し
ては、ユーザ・サポート・リソースの情報は、新規のユーザがシステムに加入す
る登録プロセスから始まる。登録後、ユーザはユーザ・サポート・リソースを介
して入手できる特定のオンライン・フォームを利用してその情報を更新する。

【００４５】 タイトル・レジストリとの対話に関しては、ユーザは、メッセージ・ハンドリ
ング・ユニットを介してデジタル式にサイン（署名）されたメッセージを送信す
ることによって、タイトル・レジストリへとレコードを導入する。同じ手段によ
って、ユーザはこれらのレコードを更新し、かつこれらのレコードのステータス
およびこれらのレコードとそれが表わす権利との関係を変更するために更に別の
情報を入力する。

【００４６】 これらの処理プロセスはウェブ・ブラウザのような良く知られているデスクト
ップ・アプリケーションを利用するものの、インターネット・アプリケーション
で標準的であるよりも大幅に高いレベルの信頼性とセキュリティに向けに設計さ
れている。

【００４７】 １．２．システム・セキュリティ 本システムは、主として、ユーザ・アイデンティフィケーション、リソース・
アクセス制御、文書認証、メッセージ完全性チェック、およびメッセージ暗号化
によって、構成要素と情報の流れとを保全している。

【００４８】 ユーザ・アイデンティフィケーションに関しては、システムを利用する全ての
個人およびその関係会社のアイデンティティーが、利用が許可される前に調査さ
れ確認される。個々のユーザのアイデンティフィケーションの信頼性を弱める傾
向がある要因（スマートカードの紛失の繰り返し、長期にわたる使用実績がない
ことなど）は、ユーザを識別する証書を発行するか否かを判断する上で考慮され
る。

【００４９】 リソース・アクセス制御に関しては、ユーザが本システムの構成要素にアクセ
スし、これを使用する能力は、ユーザの合法的な要求に限定される。さらに、シ
ステムへのアクセスとその利用は追跡され監査される。

【００５０】 文書の認証に関しては、全てのメッセージ（メッセージに含まれる添付文書を
含む）がそれを発する人によってデジタル署名される。メッセージにデジタル署
名することによって、システム・ユーザはペーパー書類へのインクによるサイン
と機能的に同様に、メッセージでユーザ自体を識別する。デジタル署名は規則書
に規定されている法的効力を有する。

【００５１】 メッセージ完全性チェックに関しては、デジタル署名（デジタル・サイン）の
確認によって、メッセージにサインされた時点と確認が行われた時点との間にな
された、デジタル・サインされたメッセージに対してなされる何らかの変更が証
明される。本システムはメッセージ・ハンドリング・ユニットにメッセージが受
信された時にメッセージのデジタル・サインを確認する。次に、メッセージ・ハ
ンドリング・ユニットはそのメッセージが改ざんされていないことが立証された
場合だけメッセージを送信する。

【００５２】 メッセージ暗号化に関しては、メッセージの送信側が希望すれば、通常のこと
であるが、対象とされるレシピエント（受取側）以外のユーザには読み取り不可
能であるように、送信側はメッセージを暗号化する。幾つかの法体系は暗号化能
力の使用可能性と使用を規定している。これらの法体系に従うユーザは、勿論、
適用可能な暗号化の法規を遵守する必要がある。それに従うことは、法規自体の
拘束力によって、また適用可能な法規を遵守する旨の規則書の基本要求によって
要求される。本システムは、実施されるシステムが適応できる実際の限度以外に
は、暗号化技術の利用に制限を設けない。

【００５３】 これらのセキュリティ・プロセスには自動的に動作するものもあるが、ユーザ
がある種の動作を起こす必要があるものもある。ユーザが能動的なセキュリティ
手段を考慮すべき領域には非公開鍵(private key、プライベート・キー)の安全
保護、非公開鍵を紛失後の迅速な手続き、および基本的なシステム・セキュリテ
ィが含まれる。

【００５４】 非公開鍵の安全保護に関しては、第２．４項に説明するように、本システムで
送信される全てのメッセージは、その真正性を確認できるようにデジタル・サイ
ンされる。ユーザ・システムは、ユーザの非公開鍵、すなわちサインの計算で使
用される多くの数を必要とする数学的なプロセスを経てデジタル・サインを作成
する。その結果作成されたサインは事実上誤りがないように、上記の非公開鍵に
関連付けされる。その非公開鍵を有する誰でもユーザのデジタル・サインを作成
することができるので、小切手書き込み機またはその他のサイン装置が安全に保
持されなければならないと全く同様に、非公開鍵の秘密と安全保護を保つことが
極めて重要である。スマートカード、パスワード、または個人識別番号（ＰＩＮ
）および同類のセキュリティ手順を利用することで、非公開鍵の安全保護が促進
される。

【００５５】 非公開鍵を紛失した後の迅速な処理に関しては、非公開鍵のセキュリティが不
明確または危険にさらされた場合の救済手段は、その証書を即座に無効にするこ
とである。デジタル・サインは確認によってその非公開キーに対してトレースさ
れることもできるが、それは非公開鍵を、識別れたユーザと関連付ける証書であ
る。証書を無効にすることによって、ユーザは自ら関連する非公開鍵との関係を
断つことになり、その結果、その非公開鍵によるデジタル・サインは、無効にし
た後は、ユーザに帰属しない。ユーザはユーザの公開鍵証明側によって与えられ
ると同じ方法で証書を無効にすることができる。

【００５６】 ２．メッセージ・ハンドリング・ユニット 本システムでユーザがなし得ることの多くはメッセージ・ハンドリング・ユニ
ットを介して達成される。別のユーザにメッセージを送るには、電子船荷証券を
タイトル・レジストリに入力し、また、タイトル・レジストリ内の電子船荷証券
に関する権利を変更するには、ユーザはメッセージ・ハンドリング・ユニットを
通じてメッセージを送信する。

【００５７】 ２．１．メッセージの構成要素 メッセージは図２に示すような一連の構成要素からなっている。 図２に示すように、標準的なメッセージの基本構成要素は、メッセージ・ヘッ
ダと、メッセージ・パート・ヘッダと、タイプ・ヘッダと、文書パートと、メッ
セージ・エンド・インジケータとである。

【００５８】 メッセージ・ヘッダはメッセージ全体の初めに現れるテキスト行であり、メッ
セージを（「〜へ（Ｔｏ）」または「〜から（Ｆｒｏｍ）」のように）経路指定
し、その「案件（Subject、サブジェクト）」を示し、ソフトウェアに対して（
例えばその「コンテンツ・タイプ（Content-Type）」を記することによって）メ
ッセージの処理方法を示し、メッセージ全体のレベルで同様の目的を果たす。メ
ッセージ・ヘッダは規格によって規定されており、本発明に特有なものではない
。シンプル・メール・トランスポート・プロトコル（Simple Mail Transport Pr
otocol）を使用したインターネット・メールのためのメッセージ・ヘッダを規定
した基本的な規格はインターネット・エンジニアリング・タスク・フォースのＲ
ＦＣ８２２である。

【００５９】 メッセージ・パート・ヘッダに関しては、メッセージはマルチパーパス・イン
ターネット・メール・エクステンション（ＭＩＭＥ）のための仕様に従って各パ
ートに区分される。ＭＩＭＥのメッセージ・フォーマットは主としてインターネ
ット・エンジニアリング・タスク・フォースのＲＦＣ１５２１および１５２２で
規格化されている。各パートは、コンテンツ形式と、これをｅメール・チャネル
を経て送るために使用されるエンコード方式とを記したヘッダによって区切られ
る。メッセージ・パート・ヘッダはＭＩＭＥ規格によって規定され、本発明に特
有なものではない。

【００６０】 タイプ・ヘッダは各メッセージに含まれている。これは本システムでのメッセ
ージの形式と機能を示すメッセージの部分であり、データを本システムのログ、
タイトル・レジストリ、およびその他のレコードへと伝送する。タイプ・ヘッダ
は本発明に特有のものである。これは拡張メークアップ言語およびサービス・プ
ロバイダが規定する文書タイプ定義に従ってエレメントとしてタグされるデータ
を含む。ＸＭＬはデータにラベリングする方法である。これは１９９８年２月１
０日にワールド・ワイド・ウエブ・コンソーティアム（World Wide Web Consort
ium）によって採用された「拡張マークアップ言語（ＸＭＬ）１．０：Ｗ３Ｃ推
奨事項」と題された仕様に規定されている。これはオンラインでhttp://www.w3.
org/TR/REC-xmlで入手できる。

【００６１】 タイプ・ヘッダの後に、メッセージには単数または複数の文書パートを含めて
もよい。メッセージは、各々がメッセージ・パート・ヘッダによってもたらされ
る文書からなる、単数または複数の上記の追加部分を有していてもよい。メッセ
ージの文書（ドキュメント）部分は「添付（アタッチメント）」、「添付文書」
などと称されることが多い。文書部分はオプションであるが、本システムで送信
されるほとんどのメッセージでは一般的である。文書部分の形式は本発明に特有
なものではなく、ＭＩＭＥ規格によって規定されている。

【００６２】 メッセージ・エンド・インジケータはメッセージ全体の終了のマークである単
一のドットからなる行である。メッセージ・エンド・インジケータはインターネ
ットｅメール規格（主としてＲＦＣ８２２）に基いてメッセージの終了を示す標
準的な方法である。

【００６３】 メッセージ・ヘッダ、メッセージ・パート・ヘッダ、およびタイプ・ヘッダは
、主として、場面の背後のメッセージを移動および処理し、それらのコンテンツ
のコンテナの役割を果たすために使用される技術的デバイスである。メッセージ
・ヘッダは、その内部のもの（タイプ・ヘッダを含む）にサインや暗号化がなさ
れていても、サインも暗号化もされない。

【００６４】 上記のことはシステムにおけるメッセージの形式に関するオペレーション規則
１によって要約される。 オペレーション規則１： メッセージの形式 Ａ．メッセージはＩＥＴＦ ＲＦＣ ８２２、ＩＥＴＦ ＲＦＣ １５２１お
よび１５２２（ＭＩＭＥ規格）、およびＩＥＴＦ ＲＦＣ １８４７および１８
４８が要求する形式であるものとする。さらに、メッセージは、本明細書に記載
の仕様に基づく技術的に適正なコンテンツを有するものとする。

【００６５】 Ｂ．ユーザは、別の規則が不適合のメッセージのアクノレッジメントを要求し
ない限り、このオペレーション規則の要求基準に適合しないメッセージを無視す
るものとする。

【００６６】 メッセージをこのような技術形式に構成することは、メッセージ・ハンドリン
グ・ユニットまたはシステム・サービス・プロバイダによって維持されるその他
のコンポーネントのタスクではなく、ユーザ・システムのタスクである。しかし
、メッセージ・ハンドリング・ユニットはメッセージがこのような要求された形
式であることを要求する。メッセージ・ハンドリング・ユニットはさらに、認可
されたユーザ・システムがその形式にメッセージを構成する能力を実証すること
を要求する。ユーザ・システムは、入力用オン・スクリーン・フォームと、テキ
スト編集およびディスプレイ能力と、ローカル・データベースおよび文書システ
ムとのリンクと、メッセージの作成を補助するその他の機能性とを提供すること
によって、上記の実証を行う。

【００６７】 ユーザ・システムが受信されたメッセージをこのような生の形式(raw form)で
ディスプレイすることは稀である。ユーザ・システムはメッセージ・ヘッダの全
てをディスプレイしなくてもよく、トラブルシューティングの場合を除いて、送
信先（to）、受信元（from）、送信および受信の日付、および重要性を保持する
案件(subject)ヘッダだけをディスプレイする。これとは対照的に、メッセージ
内のタイプ・ヘッダと文書は、通常はユーザにより親しまれるオン・スクリーン
・ディスプレイで表示されるが、本システムを介して業務を実行する際に広範に
使用される。タイプ・ヘッダの生の形式は通常は読み取り易い方法で提示される
が、タイプ・ヘッダの形式はメッセージ・ハンドリング・ユニットを経てのメッ
セージの流れにおいて重要で決定的な役割を果たす。

【００６８】 ２．２．タイプ・ヘッダの形式と流れ メッセージ・ハンドリング・ユニットを含む３つの基本的なユーザの活動は、
メッセージの送信、受信のアクノレッジメントの発行、および取引の拒否の取扱
いである。

【００６９】 メッセージの送信に関しては、或るユーザから他のユーザに、またはタイトル
・レジストリのような本システムのリソースに、そこで機能を実行する（例えば
電子船荷証券の作成）ための命令と共にメッセージが送信される。前述したよう
に、メッセージはメッセージの経路を指定および処理する際に利用されるヘッダ
と共に、タイプ・ヘッダおよび場合によって１以上の含まれる文書からなってい
る。

【００７０】 本システムを経て送信されるメッセージの受信のアクノレッジメントに関して
は、ユーザが加入者ユーザから発せられるメッセージを受信すると、オペレーシ
ョン規則２（ＦＭｓｇメッセージのアクノレッジメント）は、本システムに対し
て入来メッセージが受信されたことを通知するために、受信したユーザが返信メ
ッセージを送信することを要求する。アクノレッジメントはアクノレッジメント
されたメッセージで提案される何らかの義務に同意するものではない。これはメ
ッセージが適正に、真正な形式で着信したことを単に示すだけのものであり、そ
れ以上の何ものをも示すものではない。レシピエント（受取側）は、メッセージ
で提案される何らかの取引の進展を断る場合でも、メッセージの受信をアクノレ
ッジメントする。

【００７１】 受信されアクノレッジメントされたメッセージの後に続くビジネス拒否に関し
ては、メッセージの受取側はその元の送信側に対して、受取側が受信して元の送
信側からアクノレッジメントがなされたメッセージに応答してアクションを起こ
す意思がない旨を通知してもよい。

【００７２】 これらの３つの基本的機能を実行するため、メッセージのタイプ・ヘッダは、
各々が異なる機能的な含意とコンテンツを有する異なる形式をとる。タイプ・ヘ
ッダのこのような異なる形式は、メッセージを作成し、送信し、受信するこれら
の基本的なメッセージ処理プロセスの説明において記載する。

【００７３】 ２．２．１．メッセージの送信 或るユーザから別のユーザまたはタイトル・レジストリへのメッセージの送信
は２段階の動き(movement)からなっている。第１に、送信側はメッセージ・ハン
ドリング・ユニットにメッセージを送信し、メッセージ・ハンドリング・ユニッ
トは次にこれを受取側に中継する。メッセージ・ハンドリング・ユニットは全て
のユーザの仲介側として全てのメッセージの流れをチェックし、追跡するので、
全てのメッセージは本システムを通過して最終宛先へと送られる。

【００７４】 メッセージを他のユーザまたはタイトル・レジストリに送信するには、ユーザ
は送信メッセージすなわちＳＭｓｇの形式のタイプ・ヘッダを有するメッセージ
を作成する。ＳＭｓｇは、システム・ユーザによってメッセージ・ハンドリング
・ユニットへと送信されたメッセージ、およびそこから最終の受取側に送信され
るべきメッセージに対するタイプ・ヘッダの形式である。

【００７５】 メッセージ・ハンドリング・ユニットがＳＭｓｇを受信すると、メッセージ・
ハンドリング・ユニットは以下のことを行う。 メッセージをチェックして、それがＳＭｓｇのメッセージ妥当性要求を満たす
か否かを判定する。

【００７６】 タイプ・ヘッダ、含まれている何らかの文書のハッシュ結果、処理時間、およ
びその他の情報を記録することによってＳＭｓｇをログする。 適用可能なレコード保持スケジュールに指定されている期間だけ、メッセージ
・ハンドリング・ユニットのメッセージ・データベース・コンポーネントにメッ
セージを記憶する。（レコード保存スケジュールは、システム・サービス・プロ
バイダとユーザとの間のそれぞれのオペレーション・サービス契約の一部を構成
する。それぞれのオペレーション・サービス契約のスケジュールがどのように記
載されているか、および契約を交わす際に各ユーザが選択したオプションに応じ
て、送信側の契約からのレコード保存スケジュールまたは最終的な受取側のレコ
ード保存スケジュールのいずれかまたは双方を適用できよう。） メッセージ・ハンドリング・ユニットがメッセージを受信し、それがメッセー
ジ妥当性要求を満たしているものと判明すると、メッセージ・ハンドリング・ユ
ニットによって受信のアクノレッジメントを返信する。返信されるこのアクノレ
ッジメントはＢＡｃｋと略される「システム・アクノレッジメント」の形式のタ
イプ・ヘッダを有するメッセージである。ＢＡｃｋはメッセージの最終的な受取
側による受信を示すものではなく、メッセージ・ハンドリング・ユニットがＳＭ
ｓｇを受信し処理したことを示すに過ぎない。メッセージ・ハンドリング・ユニ
ットがメッセージを受信したが、それを阻止するエラーに遭遇した場合は、これ
はボレロ非アクノレッジメント（Bolero Non-acknowledgement）（ＢＮａｋ）の
形式のタイプ・ヘッダを返信する。ここでのボレロとはサービス・プロバイダの
商標である。メッセージ・ハンドリング・ユニットがメッセージを受信しない場
合は、送信側へは何も返信されない。認可されたユーザ・システムは、各ＳＭｓ
ｇをそのＢＡｃｋまたはＢＮａｋとリンクさせ、ＢＮａｋが着信した後、または
ＢＡｃｋまたはＢＮａｋなしで所定期間だけメッセージが残された後で、ユーザ
に警告を発する機能を果たす。

【００７７】 送信側によって指定された受取側（１または複数）へＳＭｓｇを転送する。Ｓ
Ｍｓｇは、一旦転送されると、ＦＭｓｇと略される転送されたメッセージの形式
をとる。ＦＭｓｇ（中継されたＳＭｓｇ）の受取側はユーザでもタイトル・レジ
ストリでもよい。ＦＭｓｇは通常は、主として、そのタイプ・ヘッダ、メッセー
ジ識別子、タイミング情報、デジタル・サイン（ＦＭｓｇにおけるサービス・プ
ロバイダのもの、およびＳＭｓｇにおける元の送信側のもの）、およびタイトル
・レジストリと関連するエレメントが、先のＳＭｓｇとは異なっている。

【００７８】 転送されたメッセージ（ＦＭｓｇ）が受信されたことを示す、受取側からのア
クノレッジメントを待機する。 図３は、メッセージ・ハンドリング・ユニットを経てのこのようなメッセージ
送信プロセスの流れを示している。

【００７９】 まとめると、他のユーザまたはタイトル・レジストリへメッセージを送信する
際の基本的な情報の流れは、（１）サービス・プロバイダへメッセージ（ＳＭｓ
ｇ）を発信し、（２）サービス・プロバイダから、メッセージがサービス・プロ
バイダによって受信され処理されたことを示すアクノレッジメント（ＢＡｃｋ）
、またはメッセージは受信されたが処理も転送されなかったことを示すＢＮＡｋ
を受信し、（３）本システムが、対象の受取側へメッセージ（この時点ではＦＭ
ｓｇ）を転送するようにすることからなっている。

【００８０】 ２．２．２．受取側による受信のアクノレッジメント ユーザによるアクノレッジメントはオペレーション規則２に従って行う。 オペレーション規則２： ＦＭｓｇメッセージのアクノレッジメント Ａ．ユーザが技術的に不適正なＦＭｓｇメッセージを受信すると、受取側は、
可能ならば、そのメッセージに対して、合理的な最も早い機会にメッセージ・ハ
ンドリング・ユニットに対してＵＮＡｋメッセージを返信するものとする。

【００８１】 Ｂ．その他の全てのＦＭｓｇについては、メッセージの受取側は合理的な最も
早い機会にメッセージ・ハンドリング・ユニットに対してＵＡｃｋメッセージを
返信するものとする。

【００８２】 メッセージが受取側のユーザ・システムに着信すると、オペレーション規則２
は、受取側に対して、その受信を迅速にアクノレッジメントすることを要求する
。受取側は、ユーザ・アクノレッジメント（ＵＡｃｋ）の形式のタイプ・ヘッダ
を有するメッセージをメッセージ・ハンドリング・ユニットへ送信することによ
って、このアクノレッジメントを行う。ＵＡｃｋを受信すると、メッセージ・ハ
ンドリング・ユニットは、それを、元のＳＭｓｇの送信側が配達の通知を要求し
ている場合は、配達通知（ＤＮｏｔ）の形式のタイプ・ヘッダとして元の送信側
へ中継する。

【００８３】 図４はこのプロセスを示す。 ＵＡｃｋ−ＤＮｏｔのシーケンスは、対象となる受取側（メッセージを受信す
るユーザとして指定された受取側）によるメッセージの受信を示す。言い換える
と、このシーケンスは、システム・サービス・プロバイダによって規定される技
術的な要求に従って、ＦＭｓｇメッセージが宛先の受取側のユーザ・システムに
着信したことを示す。ＵＡｃｋを返信することによって、受取側は、受取側がメ
ッセージを読んだこと、メッセージを適正に読むのに必要な機能性を有すること
、そのコンテンツの何れかの知識または通知を有すること、またはメッセージ中
の何らかの義務への同意または受け入れること、を認めない（ルールブックを参
照）。ＵＡｃｋ−ＤＮｏｔのシーケンスは、まさにメッセージがＦＭｓｇとして
本システムから転送されたものとして、そのメッセージが技術的に妥当なメッセ
ージとして着信したという単なる事実以外のなにものをも示すものではない。

【００８４】 転送されたメッセージが技術的に妥当なＦＭｓｇメッセージとして着信せず、
確認できないデジタル・サインが付されているか、またはＦＭｓｇ用に指定され
た形式ではない場合は、受取側はユーザ非アクノレッジメント(user non-acknow
ledgment)（ＵＮＡｋ）の形式のタイプ・ヘッダをメッセージ・ハンドリング・
ユニットへ返信する。メッセージ・ハンドリング・ユニットは、失敗通知(failu
re notification)（ＦＮｏｔ)の形式のタイプ・ヘッダを含むメッセージを元の
送信側へ中継する。メッセージ・ハンドリング・ユニットは、タイムアウト期間
内にそのメッセージに対するＵＡｃｋが受信されない場合も、ＦＮｏｔを返信す
る。メッセージのオリジネータ（originator、創作者）はタイムアウト期間を指
定してもよく、またはメッセージ・ハンドリング・ユニットがデフォルトによっ
てこれを適用してもよい。次に元の送信側は失敗の原因としてＦＮｏｔに示され
た問題点に対処し、メッセージを再送するか、必要なその他のアクションを起こ
す。

【００８５】 図５は非アクノレッジメント・プロセスを示している。認可されたユーザ・シ
ステムはＦＭｓｇが受信されるごとに、受取側に何らかのアクションを起こすこ
とを要求せずに、ＵＡｃｋまたはＵＮＡｋメッセージを自動的に返信する。

【００８６】 オペレーション規則２が要求するように、受取側は、受信されたメッセージに
重大な技術的欠陥がある場合、ＵＮＡｋのみを送信する。ＵＮＡｋは、受取側が
受信したメッセージを持つことを望まないか、メッセージを読むことを拒否する
か又はメッセージによって拘束されることを拒否するか、またはメッセージを無
視することを意図するかを示すために用いられるべきものではない。簡略に述べ
ると、ＵＮＡｋは、明白な技術的理由によりメッセージの配達に失敗したことを
示すものであり、これに対して、送信側の取引拒否（ＳＢＲｆ）は、人の意思ま
たは進展不能であるという理由から、すなわち受取側がメッセージのコンテンツ
に関しての更なる進展または対処を望まないという理由から、それ以上の応答は
見込めないということを示す。

【００８７】 ２．２．３．メッセージに従って取引することの拒否 メッセージが技術的な障害なく受け取られるが、意味をなさないことがあり、
これは、恐らくは、受取側が、有意であると知られている取引状況とメッセージ
とを関連付けることができないためである。別の状況では、メッセージは歓迎さ
れないものであるか、または受取側の判断で無視されることがある。このような
環境では、受取側はメッセージの元の送信側に対して、受取側はメッセージに応
じて動作を起こす意思がなく、これを無視する旨を通知してもよい。

【００８８】 これらの意思を元の送信側に通知するには、受取側はメッセージ・ハンドリン
グ・ユニットに対して送信ビジネス拒否（ＳＢＲｆ）の形式のタイプ・ヘッダを
送信し、メッセージ・ハンドリング・ユニットはユーザ・ビジネス拒否（ＦＢＲ
ｆ）をメッセージの元の送信側へ中継する。

【００８９】 図６はこの手順を示す。 メッセージの受取側は、メッセージの受信後、２４時間以内にＳＢＲｆを送信
すればよい（それによって元の送信側に対するＦＢＲｆがトリガされる）。それ
以外の任意の便利な期間を選択してもよい。ＳＢＲｆは、受取側がメッセージに
応答して既に何らかの明確なアクションを起こした後に送信された場合は、混乱
および矛盾を生ずることになる。説明すると、受取側Ｒが送信側Ｓからメッセー
ジを受信し、順当にアクノレッジメントしたものと想定する。次にＲはＳに対し
て、「通信を受信し、早急に検討します。」というメッセージを返信する。その
後、ＲはＳからのメッセージを「検討」し、これを無視し、破棄することを決め
る。Ｓに対するＲからの以前のメッセージの後では、ＳＢＲｆ−ＦＢＲｆのシー
ケンスは混乱を生じ、曖昧になることがあろう。ＲはＳＢＲｆ−ＦＢＲｆシーケ
ンスの自由なテキスト・フィールドに説明を含めることによって、またはＳＢＲ
ｆのオプション全体を先行させ、送信側に対してＲの意思を表明する通常のＳＭ
ｓｇを単に送信することによって、そのような混乱を回避できる。

【００９０】 ２．２．４．メッセージの流れとタイプ・ヘッダの概要 メッセージ・ハンドリング・ユニット内のメッセージは、確実性が高いメッセ
ージ・サービスを提供するのに必要な異なる機能を果たす。これらの機能はメッ
セージ中のタイプ・ヘッダによって示される。タイプ・ヘッダの形式が変化する
ことはユーザに変化する有意性をもたらし、それらはメッセージ・ハンドリング
・ユニット内で多様なオペレーション、しばしば応答的タイプ・ヘッダを有する
別のメッセージ、をトリガする。

【００９１】 図７は、１つのメッセージが別のメッセージをトリガする、タイプ・ヘッダの
流れのシーケンスをまとめている。 図７Ａは図７に示したタイプ・ヘッダの形式をテーブルとして示し、それらが
どこから来て、何処に行き、何を意味するのかを示す。図７Ａの数字は図７で用
いられる数字を示す。

【００９２】 これらのメッセージの全てにはデジタル・サインがなされ、ＢＮａｋは、確認
に失敗したデジタル・サインの結果としてのものである。デジタル・サインおよ
びメッセージの真正性に関するより詳細な情報については第２．４．２項を参照
されたい。

【００９３】 実際的には、元の送信メッセージ（ＳＭｓｇ）は、動作において、一連の他の
タイプのヘッダ又は連鎖反応を存在させ設定する。幾つかのタイプ・ヘッダのタ
イプは、環境に応じて他のタイプ・ヘッダの代替であり、またはオプションであ
る。認可されたユーザ・システムは、全てが同じ元の送信メッセージ（ＳＭｓｇ
）に関連する、単一のシリーズまたは連鎖からなる様々なメッセージからの全て
のタイプ・ヘッダを共にリンクすることまたは関連付けすることが可能である。
幾つかのユーザ・システムには、関連するメッセージをリンクするこのようなプ
ロセスを「再調停(reconcilling)」と称するものがある。

【００９４】 異なる形式のタイプ・ヘッダは、メッセージ・ハンドリング・ユニットにおい
てメッセージが流れる変化する方向を示す。メッセージの流れを示すことの他に
、各形式のタイプ・ヘッダは、ユーザ識別子およびメッセージに添付された文書
に関する情報のような、ある種のコンテンツを必要とする。タイプ・ヘッダは、
メッセージをトラッキング（追跡）し、それが文書、アドレス指定および経路指
定、および真正性に対する要求を満たしていることを確証するために、メッセー
ジ・ハンドリング・ユニットのサーバが利用する主要な手段である。そのトラッ
キングと確証を提供するために、メッセージ・ハンドリング・ユニットは各メッ
セージのタイプ・ヘッダをチェックし、要求されるコンテツがエラーである場合
は先へ進まない。次の項ではこれらのコンテンツに対する要求の幾つかを吟味す
る。

【００９５】 ２．３．含まれる文書 第２．１．項で説明したように、メッセージはタイプ・ヘッダと１または複数
のオプションの文書からなり、それらの全ては、メッセージの経路の指定および
処理に使用されるメッセージ・ヘッダ内に格納される。前項では本システムで認
識される様々な形式のタイプ・ヘッダを説明した。この項では、本システム、特
にメッセージ・ハンドリング・ユニットとタイトル・レジストリがメッセージ内
に含まれる文書に対して実行することを説明する。

【００９６】 メッセージに含まれている、すなわち「添付」されている文書は、インターネ
ットＭＩＭＥ規格が要求する態様でユーザ・システムによってメッセージに組込
まれる。ＭＩＭＥ方式は、ｅメール用に使用されるデジタル通信チャネルを経て
メッセージ内の文書を伝送する。しかし、一般的な電子メール技術では標準的で
あるように、ＭＩＭＥはｅメール・システムを通じて伝送される文書のトラッキ
ングを行うものではなく、ｅメール・チャネルを通じて伝送するのに必要なほん
の最小限の情報以外は、文書に関する情報を伝えない。

【００９７】 システムは文書を走査したりそのコンテンツを検査することはないが、文書は
追跡する。システムが保存する文書に関する情報は、メッセージが含まれている
メッセージ（１または複数）に関する情報、その形式、および別の文書と同一で
あると見なされる文書が実際に同一であるか否かを判定するのに必要な情報から
なっている。その情報は文書に独自の識別子の下で記憶される。

【００９８】 或る文書が別の文書と同一があるか否かを判定するため、メッセージ・ハンド
リング・ユニットのようなシステムのコンポーネントは２つの文書の「ハッシュ
結果」を比較する。

【００９９】 ハッシュ結果は数学的な「メッセージ・ダイジェスト」、「暗号の検査合計」
、または「シール」（技術文書におけるもの、シールの法的効力と無関係）とし
ても知られている。

【０１００】 ２．３．１．文書ＩＤおよびリファレンス システムは、システムでログされる全ての文書からある文書を一意的に識別す
る文書識別子（「文書ＩＤ」とも称される）によって、文書をトラッキングする
。従って、対応するオペレーション規則は以下のように規定している。

【０１０１】 オペレーション規則３： 文書ＩＤの必要性 ユーザがシステムへ送信する各文書ごとに、そのユーザは所定の形式で文書Ｉ
Ｄを指定するものとする。

【０１０２】 文書ＩＤはユーザ識別子と、一般識別子と、バージョン・インジケータとから
構成される。 ユーザ識別子は、文書を最初にシステムへ送信したユーザのシステム・ユーザ
識別子である。（ユーザ識別子は第２．４．１項で説明される。）ベース・ユー
ザ識別子と、任意のユーザ・ディビジョン識別子の双方が文書ＩＤに含まれるが
、ユーザ識別子の拡張子は含まれない（拡張子が用いられる場合）。

【０１０３】 一般識別子は、文書ＩＤの一部を形成するユーザ識別子に示されているユーザ
によって本システムへ送信された全ての文書の中から文書を一意的に識別する一
連の英数字である。

【０１０４】 バージョン・インジケータは文書のバージョンを示す英数字テキストの一部で
ある。 上記の３つのサブ識別子が共になり文書ＩＤを構成する。これらのサブ識別子
はそれ自体が一意的である必要はないが、共になり文書の一意的な識別子を形成
する。例えば、同じ文書の２つの別個の事例が同じ文書ＩＤを共用してもよいが
、これらは同一でなければならない。

【０１０５】 文書ＩＤのこれらの基本的な構成要素の他に、文書ＩＤを作成する送信側は、
送信側が識別された文書を予備的で拘束力がなく、最終的な効力があるテキスト
ではなく草案であると見なしていることを示すために、文書ＩＤにオンまたはオ
フ・インジケータを含めることを選択することができる。

【０１０６】 一旦文書がシステム内に首尾よく記録されると、文書の送信側または受取側は
ユーザ・サポート・リソースにおいてこれをルックアップすることによって、本
システムを介して文書の動きを再調査することができる。本システムで文書を再
調査することができるユーザ代表者の場合、その代表者は、（１）ユーザの組織
の一員であることを示すユーザ識別子を有していなければならず、（２）関連す
るユーザ識別子に含まれるディビジョン（部門）識別子内で見られる文書の送信
側または受取側と同等又はそれより上位でなければならず、（３）ユーザ・デー
タベースに監視特権を有するものとしてリストされていなければならない。

【０１０７】 一旦文書が文書ＩＤの下でファイルされると、それ以降のメッセージまたは文
書はその文書ＩＤによって文書を参照できる。草案インジケータがオンである場
合は、それ以降のメッセージは、以前にファイルされた文書を、同じ文書識別子
を有する新規の文書で置換することもできる。しかし、草案インジケータがオフ
である場合（文書が最終的な文書であることを示す）は、新規のメッセージは旧
メッセージに上書きされることはない。新規のメッセージは、その文書ＩＤによ
って、以前ファイルされた文書を参照してもよく、文書のコピー添えて送信して
もよい。このような場合、メッセージ・ハンドリング・ユニットが新規のメッセ
ージを処理する際に、メッセージ・ハンドリング・ユニットは文書コピーと文書
ＩＤをチェックして、それらが以前にファイルされた文書および文書ＩＤと同一
であるか否かを判断する。同一ではない場合は、不一致文書において送信するＳ
Ｍｓｇのために、メッセージ・ハンドリング・ユニットはＢＮＡｋを返信する。
同一である場合は、メッセージ・ハンドリング・ユニットは、メッセージが他の
全ての面で妥当であるならば、ＢＡｃｋを返信する。

【０１０８】 ２．３．２．文書タイプの説明 システムは文書の特有の識別子だけではなく、その形式についての情報をも記
録する。目下のところ、文書タイプだけが形式のインジケータとしてサポートさ
れている。

【０１０９】 文書タイプは、本システムで規定されている文書の取引の役割を示す。本明細
書に関しては、文書タイプはＥＤＩＦＡＣＴに対して定義されている何れかの文
書タイプまたはメッセージ様式であり得る。

【０１１０】 ２．４．ユーザのアイデンティフィケーションとメッセージの真正性 前項ではメッセージ、特にメッセージのタイプ・ヘッダおよび文書に含まれる
コンポーネントについて説明した。一旦これらのコンポーネントがメッセージへ
と組み立てられると、メッセージは他のシステム・ユーザまたはタイトル・レジ
ストリのような他のリソースへと送信される準備ができる。

【０１１１】 本システムを介してメッセージを送信し、またはその他の有意のアクションを
起こすには、送信側はそのユーザ識別子を宣言する必要がある。各メッセージを
受信すると、本システムはユーザ識別子をチェックし、そのユーザ識別子および
関連する公開鍵証書に従ってメッセージ上のデジタル・サインを確かめる。この
確認プロセスは、あるユーザが検知されないままに他のユーザになりすますこと
を防止するためのものである。それによってさらに、本システムの全てのユーザ
に対して、規則書によって管理された加入者だけがメッセージ・ハンドリング・
ユニットを介してメッセージを送信および受信できることが保証される。このよ
うに、ユーザは有効なユーザ識別子を提供し、各メッセージまたは情報ストリー
ムにデジタル・サインしなければならない。本項ではユーザ識別子およびユーザ
がそのメッセージにデジタル・サインする方法を説明する。

【０１１２】 情報ストリームとは、ウェブ・ブランザとサーバのような２つのデジタル情報
リソースをリンクするチャネルである。情報ストリームへのサインは、ストリー
ムを構成するパケット（データの小さいデジタル・ブロック）またはパケット群
にサインすることからなる。

【０１１３】 ２．４．１．ユーザ識別子 ユーザ識別子（アイデンティファイヤ）は、システム・ユーザが本システム内
で知られるための名前のことである。それは名前であるので、ユーザ識別子は、
ｅメール・アドレスを含むアドレス、および本システムに記録され得るユーザの
その他の属性とは異なるものである。特に、ｅメール・アドレスは、厳密に述べ
ると、ユーザを識別せず、むしろ、ｅメールを受信できる機械の場所を識別する
ものである。ｅメール・アドレスは、街路の住所、電話番号、およびその他の位
置コードと同様に、会社(company)を識別する有効な属性であるが、会社自体で
はない。これらの属性はいずれも、会社のアイデンティティに実際に影響を及ぼ
すことなく変更できる。他の全てのユーザから、また正に他の全ての会社から区
別されるそのアイデンティティは、ユーザ識別子が表すものである。

【０１１４】 全てのシステム・ユーザは、会社を代表する個々の従業員またはその他の人で
はなく、会社である。従って、略称される場合が多いが、各々のユーザ識別子は
会社を示すものである。ユーザ識別子を解釈し、またはユーザに関する更なる情
報を見いだすには、ユーザ・サポート・リソースのユーザ識別子をルックアップ
する。

【０１１５】 ユーザは、ユーザ識別子に、会社の部門（ディビジョン）または部局の参照（
リファレンス）と、ユーザが希望することを記載した「拡張子（エクステンショ
ン）」を追加してもよい。

【０１１６】 図８はベース・ユーザ識別子への追加オプションを示す。 部門識別子（ディビジョン・アイデンティファイヤ）とエクステンション（図
面ではイタリック体で示す）はそれぞれオプションであり、ユーザが決定する。
これらはすべてユーザの利便を図るためのものであり、法的な意義はない（規則
書を参照）。第２．４．３．項に示すように、他のユーザは、何れの部門または
拡張子がユーザ識別子に付加(tack)されているかに関わらず、識別されたユーザ
がメッセージの責任を負うものと見なしてよい。

【０１１７】 システム・サービス・プロバイダは、ユーザが登録されるときに各ユーザにユ
ーザ識別子を割当てる。ユーザが合併のような基本的な組織改編をされない限り
、ユーザ識別子が後に変更されることは稀である。ユーザが脱会するかまたは除
名された後、またはユーザが取引停止とされたときは、システム・サービス・プ
ロバイダはユーザ識別子を使用中止にし、これを承認することはない。

【０１１８】 オペレーション規則４： 要求された場合のユーザ識別子の供給 メッセージ・ハンドリング・ユニットに送信された全てのメッセージに、ユー
ザは、システムによって指定されたエレメント内のユーザ識別子を含めるものと
する。

【０１１９】 オペレーション規則５： ユーザ識別子の悪用 ユーザは以下の場合には、メッセージ・ハンドリング・ユニットへ送信された
メッセージにユーザ識別子を含めようとしてはならないものとする。

【０１２０】 （ａ）ユーザが良好な状態で登録していない場合。 （ｂ）システム・サービス・プロバイダがそのユーザ識別子をユーザに割当て
ていない場合。本オペレーション規則に反してユーザ識別子が明らかに悪用され
ている場合は、システム・サービス・プロバイダは、送信側に対してＢＮＡｋメ
ッセージを返信してメッセージをそれ以上処理することをやめる権利を有する。

【０１２１】 ２．４．２．証書（サーティフィケート）およびデジタル・サイン ユーザ識別子はユーザ・グループに公開される。いかなるアクティブのユーザ
も、ユーザ・サポート・リソースの他のユーザの識別子をルックアップすること
ができ、ユーザは、メッセージを送信するための早見アドレス帳として、一般的
なユーザ識別子のリストを保存する場合が多い。ユーザの全てがたがいのユーザ
識別子を有しているので、ユーザ識別子は文書を認証する安全な手段ではない。
従って、ユーザは一般に、メッセージまたは文書が識別されたユーザによって真
正にサインされたことや識別されたユーザに関連することを、ユーザ識別子から
信頼性をもって推測することはできない。むしろ、デジタル・サインを有効な証
書によって適正に検証（照合）できる場合は、このような推測はユーザのデジタ
ル・サインから引き出すべきものである。

【０１２２】 ２．４．２．１．デジタル・サインの作成と照合 デジタル・サイン（デジタル署名）は複雑な数学的計算から作られるものであ
り、所与のデータ・ユニットと所与の非公開鍵の双方に対して一意的な大きい数
を作成する。サインされるデータとサインする非公開鍵の双方に一意的なこの大
きい数がデジタル・サインである。認可されたユーザ・システムにはメッセージ
にデジタル・サインを作成するための機能が含まれている。

【０１２３】 デジタル・サインが作成された後、「照合(verification、検証)」と称される
別の数学的プロセスによって、デジタル・サインは、サイン済みデータの署名者
のサインであるものと確認できる。デジタル・サインを照合するためには、コン
ピュータが機能を実行し、サインされたものと主張するデータと証書との双方を
提供する。メッセージ・ハンドリング・ユニットはそれが受信および転送する全
てのメッセージのデジタル・サインを照合し、全てのユーザは、メッセージ・ハ
ンドリング・ユニット、または、そのメッセージがサービス・プロバイダから来
たことを確信している場合は、その他のシステムのコンポーネントから受信した
と思われる全てのメッセージ上のサービス・プロバイダのデジタル・サインを照
合しなければならない。認可されたユーザ・システムはデジタル・サインを照合
する明示された能力を有しており、メッセージが受信されると自動的に照合する
場合が多い。

【０１２４】 メッセージのデジタル・サインの照合のほかに、ユーザは、メッセージ内に送
信され、メッセージ・ハンドリング・ユニットによって転送される文書にデジタ
ル・サインし、またはこれを暗号化してもよい。本システムは、このような文書
のデジタル・サインを照合したり暗号解読を行ったりすることはない。このよう
な照合または暗号解読は文書の受取側に委ねられる。

【０１２５】 証書（サーティフィケート）とは、この特定のデジタル・サインに関しては、
非公開鍵をリストすることによってではなく（何故ならば非公開鍵は秘密である
）、公開鍵をリストすることによって示される、非公開鍵のホールダー（Holder
）を識別するデジタル・レコードを意味する。公開鍵は、その非公開鍵に対して
一意的な大きい数であり、従って、公開鍵はその非公開鍵を指示または識別する
ために使用できる。このような一対の公開鍵と非公開鍵は数学的に関連している
が、公開鍵を知ることによって非公開鍵を発見することは計算上不可能である。

【０１２６】 デジタル・サインの照合の結果が肯定的である場合、それは（１）デジタル・
サインがなされたデータ・ユニットは、デジタル・サインがなされてから変更さ
れていないこと、および（２）デジタル・サインが、照合のために使用された証
書にリストされた公開鍵に対応する非公開鍵を用いて作成されたことを示す。ま
た、その証書はその非公開鍵のホールダー（デジタル・サインの署名者）を特定
のユーザとして識別し、確認者（verifier）は、証書に基づいて、デジタル・サ
インがその特定のユーザによって作成されたものと推測できる。

【０１２７】 規則書に従うと、デジタル・サインがシステム・サービス・プロバイダによっ
て交付された証書にリストされた公開鍵を使用して照合でき、かつデジタル・サ
インが作成された時に有効である場合は、このデジタル・サインはそのユーザに
絶対的に帰属するものと考えられる。このように、デジタル・サインは下記の場
合は特定のユーザであるものは見なされる。

【０１２８】 （ａ）それが照合される場合： デジタル・サインに頼るユーザは、デジタル
・サインを照合できない場合は自らのリスクでそれに頼る。 （ｂ）証書が、認可された認証者（認証側）（certifier）によって交付され
た場合： 存在しないユーザ、または証書によって示される非公開鍵を有してい
ないユーザを識別する証書は、誤まった、危険を生ずる可能性がある推測につな
がる。

【０１２９】 （ｃ）デジタル・サインが作成された時に有効である場合。 これらの要件は定義された用語「サイン済み（signed）」において反映される
。メッセージまたは文書は、上記のリストに示されたように照合できるデジタル
・サインがある場合は、「サイン済み」である。さらに、メッセージまたは文書
にサインがなされている場合、それは形式に関する適用可能ないずれの法的要求
をも満たすものである（第２．２．２．項の規則書を参照）。

【０１３０】 このようにしてメッセージを確認できるようにするため、送信側はオペレーシ
ョン規則７で要求されるように、メッセージにデジタル・サインをしなければな
らない（デジタル・サインの要求）。

【０１３１】 まとめると、デジタル・サインは、メッセージを特定の非公開鍵と関連付ける
ものである。そのデジタル・サインの照合は、それを作成するために何れの非公
開鍵が使用されたかを示し、証書は、何れのユーザがその非公開鍵を所持してい
るかを示す。適正な照合がされれば、メッセージはその署名者に帰属させること
ができる。

【０１３２】 オペレーション規則６： 送信されたメッセージへのデジタル・サイン ユーザはメッセージ・ハンドリング・ユニットを経て送信される各メッセージ
にデジタル・サインをするものとする。

【０１３３】 オペレーション規則７： デジタル・サインの要件 （ａ）ユーザは、認可された認証側（認証者）によってユーザに交付された証
書にリストされている公開鍵に対応する非公開鍵を用いてデジタル・サインを作
成するものとする。

【０１３４】 （ｂ）システム・サービス・プロバイダは、送信側へＢＡＮｋメッセージを返
信し、本オペレーション規則の要件を満たさないメッセージのそれ以上の処理を
停止する権利を有するものとする。

【０１３５】 オペレーション規則８： 受信したメッセージの照合 ユーザは、メッセージにサインがされていない場合は、そのメッセージの真正
性に疑義があるものとして取り扱うものとする。ユーザは、サインされていない
メッセージを無視してもよい。

【０１３６】 オペレーション規則９： 文書の真正性 サイン済みメッセージにて送信された文書は、別個のユニットとしてサインさ
れているか否かに関わらず、前記メッセージにて受信されたのでサイン済みであ
るものと見なされる。

【０１３７】 ２．４．２．２．メッセージ・ハンドリング・ユニットにおけるデジタル・サ
インの実施 前述したように、本システムの主要な利点の１つは、そのメッセージ・ハンド
リング・ユニットがメッセージをトラッキングし、メッセージのアクノレッジメ
ントを通じて配達の保証を提供することである。メッセージのトラッキングおよ
び信頼性のある配達を提供するために、本システムはユーザ間の公平な操作仲介
側の役割を果たす。一方のユーザから他方のユーザへのメッセージの送信プロセ
スは上述の第２．２項に記載されている多段階の手順である。本項ではデジタル
・サインがその手順にいかに適合するかについて説明する。

【０１３８】 その手順の各ステップで、送信側はメッセージにデジタル・サインをする。本
システムがメッセージ（アクノレッジメントを含む）を一方のユーザから他方の
ユーザへと中継送信する場合、本システムは元の送信側から中継されたメッセー
ジにデジタル・サインをする。その転送される上記メッセージへのデジタル・サ
インは、元のメッセージの元の送信側のデジタル・サインを照合できることの証
明になる。本図はこのシーケンシャルな署名およびメッセージ伝達のプロセスを
示す。

【０１３９】 図９に示すように、メッセージ・ハンドリング・ユニットにおけるメッセージ
の流れ、デジタル署名、および照合は以下のようなステップの手順で進む。 （１）メッセージはＳＭｓｇの形式で送信される。発信側ユーザはメッセージ
にデジタル・サインし、これが受取側に転送されるようにメッセージ・ハンドリ
ング・ユニットへ送信する。

【０１４０】 （２）メッセージ・ハンドリング・ユニットは、ＢＡｃｋと称する肯定の形式
のアクノレッジメントを発するか、または否定のアクノレッジメントすなわちＢ
Ｎａｋと称するアクノレッジメントを発する。メッセージ・ハンドリング・ユニ
ットは、ＳＭｓｇにおける送信側のデジタル・サインを照合し、その真正性と形
式をチェックし、メッセージ・ハンドリング・ユニットが元の送信側のデジタル
・サインを適正に照合し且つコンテンツが適正な形式であると判明した場合は、
元の送信側へＢＡｃｋを返信する。メッセージ・ハンドリング・ユニットがデジ
タル・サインを適正に照合できないか、または形式におけるエラーを発見した場
合、メッセージ・ハンドリング・ユニットはＢＮａｃｋを返信する。ＢＡｃｋま
たはＢＮａｋメッセージはシステム・サービス・プロバイダによってサインされ
る。

【０１４１】 （３）メッセージは転送メッセージすなわちＦＭｓｇで転送される。元の送信
側からのＳＭｓｇに照合済みのデジタル・サインがあり、且つ技術的に適正な形
式である場合は、メッセージ・ハンドリング・ユニットは元の送信側へＢＡｃｋ
を返信し、その最終的な受取側へＦＭｓｇとしてＳＭｓｇメッセージを送信する
。ＦＭｓｇはシステム・サービス・プロバイダによってデジタル・サインがなさ
れる。そのデジタル・サインは、ＦＭｓｇがサービス・プロバイダからのもので
あることを示し、さらにまた、メッセージ・ハンドリング・ユニットが、オペレ
ーション・サービス契約プロバイダとして、元のＳＭｓｇ上の送信側のデジタル
・サインを適正に照合したことを証明する。要求に応じて、システム・サービス
・プロバイダは、オペレーション・サービス契約に従ってその照合を証明する。
元のユーザのサインおよび元のＳＭｓｇは、要求に応じて、サービス・プロバイ
ダが保存しているログおよびレコードから入手できる。ＦＭｓｇは、それを存在
させる原因となったＳＭｓｇとは異なるタイプ・ヘッダ形式を有している。ＦＭ
ｓｇおよびそのＳＭｓｇの実質的なコンテンツは同一のままに留まっているもの
の、ＦＭｓｇは、システム・サービス・プロバイダ実行部によるロギングおよび
トラッキングを反映する。その結果、ＦＭｓｇの形式はＳＭｓｇと厳密に同一な
ものではないので、元のＳＭｓｇのデジタル・サインは、結果的に生ずるＦＭｓ
ｇと対照して照合することはできない。

【０１４２】 （４）ユーザ・アクノレッジメント（ＵＡｃｋ）またはユーザ非アクノレッジ
メント（ＵＮＡｋ）が発行される。ＦＭｓｇを受信すると、受取側はＦＭｓｇ上
のサービス・プロバイダのデジタル・サインを確認する。メッセージが適正に受
信され確認されると、受取側のユーザ・システムはメッセージ・ハンドリング・
ユニットへＵＡｃｋを送信することにより、応答する。照合に失敗するか、また
は技術的な障害が明らかになった場合は、受取側のユーザ・システムはＵＮＡｋ
を返信する。ＵＡｃｋまたはＵＮＡｋは、それがメッセージ・ハンドリング・ユ
ニットへと送信される前に、ＦＭｓｇの受取側によってデジタル・サインされる
。

【０１４３】 （５）配達通知（ＤＮｏｔ）または失敗通知（ＦＮｏｔ）が発行される。メッ
セージ・ハンドリング・ユニットがＵＡｃｋを受信すると、それは元のＳＭｓｇ
の送信側へＤＮｏｔを中継する。メッセージ・ハンドリング・ユニットがＵＮＡ
ｋを受信すると、それは元の送信側へＦＮｏｔを中継する。ＤＮｏｔまたはＦＮ
ｏｔには、場合によっては、システム・サービス・プロバイダのデジタル・サイ
ンがなされ、このデジタル・サインはＵＡｃｋまたはＵＮＡｋ上の受取側のデジ
タル・サインの適正な照合を証明する。

【０１４４】 メッセージ・ハンドリング・ユニットは、ＵＮＡｋと同様の方法で、最終的な
受取側からの送信済みビジネス拒否（ＳＢＲｆ）を処理する。 図１０は図示したデジタル・サイン・ステップを伴うメッセージ・ハンドリン
グ・ユニットの流れを示したフローチャートである。

【０１４５】 ２．４．３．代理側およびユーザの責任 本システムでは、デジタル・サインされたメッセージおよびその中の文書は、
法的に、デジタル・サインを照合するために用いられる証書にリストされたユー
ザによってサインされたものと見なされる（規則書第２．２．１（１）；オペレ
ーション規則６を参照）。

【０１４６】 ユーザのユーザ識別子および該ユーザに認可された非公開鍵を使用する全ての
人は、議論の余地なく、その行為がユーザを拘束するために必要な権利を有する
ものと見なされる（規則書を参照）。

【０１４７】 非公開鍵は、ユーザのユーザ識別子が証書のサブジェクト・フィールドのサブ
フィールドにある場合は、該ユーザに対して認証されたものと見なされる。証書
の交付者と共同したユーザのオプションで、サブジェクト・フィールド内に他の
フィールドがあってもよい。これらの他のフィールドは、ユーザの個々の代表者
およびそれらの鍵を管理し、ユーザの組織内での個々の活動を追跡および監査す
るために利用することができる。

【０１４８】 ２．５．メッセージおよび文書の暗号化 メッセージ・ハンドリング・ユニットを介してメッセージを送信するユーザは
、希望すれば、これらのメッセージを暗号化してもよい。暗号化は規則書では要
求されていないが、ユーザはメッセージを暗号化することを選択してもよい。

【０１４９】 本システムで実施される場合、ユーザ・データベースはユーザまたはユーザの
代表者がメッセージを暗号化する権利を有しているか否かを記録する。権利を有
している場合は、ユーザまたはユーザの代表者はシステム・サービス・プロバイ
ダを加入者としてリストしている証書中の公開鍵を使用してメッセージを暗号化
してもよい。そのメッセージを受信すると、メッセージ・ハンドリング・ユニッ
トは非公開鍵を使用して暗号を解読する。メッセージ・ハンドリング・ユニット
が入来メッセージに基づいてメッセージ（ＦＭｓｇのようなもの）を送信すると
、メッセージ・ハンドリング・ユニットは受取側の公開鍵を使用してこれを暗号
化する。その後、受取側は非公開鍵を使用して暗号を解読することができる。

【０１５０】 オペレーション規則１０： メッセージの暗号化 法律が許容する限り、ユーザがメッセージを暗号化する場合、ユーザは、 （ａ）認可された認証者によって交付され、 （ｂ）その公開鍵を暗号化のために使用してもよいことを示す鍵使用（KeyUsa
ge）フィールドを含み、 （ｃ）承認されたリポジトリで公表される 証書にリストされた公開鍵を使用して暗号化するものとする。

【０１５１】 ３．公開鍵の証明（サーティフィケーション） 公開鍵の証書は、メッセージの真正性を確認し、またオプションとして、輸送
中の機密を保持するために、メッセージ・ハンドリング・ユニットで使用される
。真正性照合（認証）サービスはデジタル・サインによってなされ、デジタル・
サインされたデータをその署名者と関連付ける証書に依存する。機密保持サービ
スを行う際に、機密性を設定する人が、その人の非公開鍵を使用してその機密性
を破るその人の公開鍵によって機密データを暗号化することを確実にするために
、証書が使用される。

【０１５２】 ３．１．基本的な役割（ロール）と構造 図１１に示すように、ある人の有し得るその他の役割がタイトル・レジストリ
内にあるか否かに関わりなく、証書に関して、例えば下記のような役割がある。

【０１５３】 交付者（発行者）とは証書を発行する会社であり、言い換えると、証書を生成
してそれにデジタル・サインし、それらを証書にリストされたサブスクライバ（
加入者）へ送付する会社のことである。

【０１５４】 加入者（もしくは署名者）とは、証書にリストされた公開鍵に対応する非公開
鍵のホールダーとして証書にリストされた人のことである。加入者は、その証書
によって照合可能なデジタル・サインを作成する人でもある。この者は、証書に
リストされた人を言う場合には「加入者」と称され、またデジタル・サインを作
成者する場合には「署名者」と称される。

【０１５５】 信頼側(Relying Party)とは、デジタル・サインの署名者が、デジタル・サイ
ンの作成後に、信頼側へのメッセージと共に上記デジタル・サインを送信する相
手の人のことであり、これがデジタル・サインを照合する。次に信頼側は通常は
、デジタル・サインされたメッセージの真正性を確定するために、デジタル・サ
インと証書を信頼する。

【０１５６】 リポジトリとはディレクトリまたはデータベースのことである。証書を照合す
る際、信頼側はその現時点での有効性に関する最新情報を得る必要がある。この
情報は通常は証書のオンライン・ディレクトリまたはデータベース、およびそれ
に関する情報から得られる。このディレクトリまたはデータベースはリポジトリ
と称する。これは１または複数の交付者またはその他の情報源から得られた情報
を利用して証書を信頼するプロセスをサポートする。

【０１５７】 証書に関連するこれらの役割は以下のようにメッセージ・ハンドリング・ユニ
ットにおける役割へとマッピングされる。 本システムにおける証書の唯一の認可された交付者はサービス・プロバイダ、
すなわち本システムのオペレータである。もちろん、その他の交付者も認可され
ることができる。サービス・プロバイダは各ユーザとの契約に従って交付者の役
割を果たし、その契約はこの関係の詳細を規定する。

【０１５８】 サービス・プロバイダと全てのユーザとは加入者／署名者である。メッセージ
・ハンドリング・ユニットを介して送信されるメッセージにデジタル・サインを
する者は全て、証書の加入者であり、それによってその証書を照合できる。

【０１５９】 サービス・プロバイダおよび全てのユーザは信頼側である。メッセージ・ハン
ドリング・ユニットおよびユーザはデジタル・サインを照合し、これを信頼する
。メッセージ・ハンドリング・ユニットの設計は、そのオペレータ、システム・
サービス・プロバイダを、ユーザのデジタル・サインを直接信頼し、次に、その
デジタル・サイン入りのメッセージを別のユーザへ転送する役割に置き、この別
のユーザはサービス・プロバイダの上記デジタル・サインを信頼する。メッセー
ジ・ハンドリング・ユニットがファイルの証書を参照してもメッセージのデジタ
ル・サインを確認できない場合は、メッセージ・ハンドリング・ユニットは送信
側にＢＮａｋを返信し、メッセージをそれ以上処理しない。メッセージ・ハンド
リング・ユニットはまた、それが送信する全てのメッセージにデジタル・サイン
をする。そのデジタル・サインは全てのユーザに配付された証書によって照合す
ることができる。この二段階のプロセスは第２．４．２．２項に詳細に記載され
ている。

【０１６０】 サービス・プロバイダはリポジトリである。サービス・プロバイダは全てのユ
ーザ証書をユーザ・データベースに保存する。メッセージ・ハンドリング・ユニ
ットはデジタル・サインを照合すると、必要な証書をユーザ・データベースから
得る。ユーザがメッセージ上のサービス・プロバイダのデジタル署名を照合する
と、これはリポジトリをチェックすることによって、関連する証書に関する最新
情報を得る。

【０１６１】 しかし、この基本構造は、図表の上部で起きることを過度に簡略化する。証書
を交付する際、交付者は他人から得た情報を信頼し、また、ユーザが本システム
を利用するため及びユーザ・グループのメンバになる契約をする加入プロセスを
信頼する。

【０１６２】 ３．２．証書の真正性 証書は、公開鍵をもって命名された者を識別するデジタル・レコードであり、
その利用を管理および制限するために必要なその他の情報を含んでいる。信頼側
はメッセージの真正性を確定するために証書を信頼するので、交付者は証書中の
情報に重大な責任を負う。

【０１６３】 証書の真正性は証書のデジタル・サインの照合（検証）によって確定される。
証書を交付する際、認証者はその証書にデジタル署名する。その証書をデジタル
署名の照合に使用するとき、認証者は、その証書が真正のものであるか否かを判
断するために、その証書のデジタル・サインを照合しなければならない。証書の
デジタル・サインを照合するには、認証者は、必要な公開鍵および加入者アイデ
ンティフィケーションを得るために他の証書を参照しなければならない。他の証
書のデジタル・サインも同様に、その真正性を確定するために照合されなければ
ならない。このように、照合には、認可されなくとも信頼できる公開鍵で終了す
る作成ラインに沿った証書のデジタル・サインの検証の連鎖反応を含んでいる。

【０１６４】 図１２は、場合によって「証書連鎖」と称されるこのような連鎖反応を示す。
証書連鎖中の「リンク」の数、言い換えると、デジタル・サインを検証するため
に認証者が検証しなければならない証書の数は、証書の交付者および連鎖中のそ
の先行するものによって決定される。この数は、図示した３つの証書とは異なっ
ていてもよい。

【０１６５】 ３．３．証書の内容と意味（証書のプロファイル） 証書の内容と意味は主としてＩＴＵ Ｘ．５０９によって規格化され、本シス
テムではこれらの規格に適合するように認証を行う。

【０１６６】 公開鍵証書の基本的な規格は、国際テレコミニュテーション・ユニオン（ＩＴ
Ｕ、以前のＣＣＩＴＴ）の推奨Ｘ．５０９号、および「Ｘ．５０９号証書および
ＣＲＬプロファイル」と題されたインターネット・エンジニアリング・タスク・
フォースのＰＫＩＸのワーキング・グループの一連の草案規格のうちの最初のも
のである。本明細書およびその他で「ＰＫＩＸ-１」と呼ばれるこの草案は、最
終的に採用はされていないものの、大きな影響を与えてきた。

【０１６７】 しかし、証書の規格はかなり制限がなく、特定の実施態様で規定されるように
多くの細部を残している。本項は本システムが形式および意味のこのような細部
をいかにして実施するかを記載する。

【０１６８】 ３．４．ユーザ認証者(certifier)の実施 加入者と認証者（認証側）との間の顧客−プロバイダの関係は、本システムで
は「証書口座」(certification account、サーティフィケーション・アカウント
)と呼ばれる。各々の証書口座ごとに、認証者は、（ａ）加入者との契約を締結
し、（ｂ）証書で用いられる事実の正確さを確証し、かつ（ｃ）証書口座履歴を
保存する。

【０１６９】 ３．４．１．証書口座の開設 ユーザがサービス・プロバイダとのサービス契約に従って本システムに加入（
登録）した後、認証者は証書口座を開設する。この口座を開設するために正確に
必要なことは、上記契約によって左右される。

【０１７０】 ３．４．１．２．証書口座の閉鎖 認証者または加入者は、契約に従って証書口座を閉じてもよい。口座を閉じる
と一般に契約が終了し、また、その逆も同様である。

【０１７１】 メッセージ・ハンドリング・ユニットを介してメッセージを送信するには有効
な証書が必要であるので、証書口座を閉じることは、実際的にはユーザがシステ
ムを利用する能力に影響を及ぼし得るが、本システムのユーザとしての加入者の
登録を終了させるものではない。

【０１７２】 ３．４．２．証書のライフ・サイクル 図１３は、証書がどのようにして、交付されると開始され、加入者によって受
け入れられると有効になり、満期になるか又は解約されるときに終結するかを示
したフローチャートである。この項でフローチャートに示されている事象を詳細
に説明する。

【０１７３】 口座が開設されると、デジタル形式で提供されるある種の情報と共に、ペーパ
ー（紙）およびインクでサインされた要請書に基づいて、当初の証書が交付され
る。口座は新設されるので、加入者はおそらく証書の要請書にデジタル・サイン
する手段を持たず、従って、その当初の、すなわち「ブートストラップ」の証書
はペーパーで要求されなければならない。通常は、この当初の証書は初期口座維
持証書になる。

【０１７４】 認証者は、加入者が許容するか、または加入者と認証者との契約が公表を前提
としている場合は、有効である証書をリポジトリに公表する。 加入者の非公開鍵の安全保持が危うくなったり、または疑わしい場合、または
加入者が証書に関する義務にもはや拘束されたくない場合は、加入者は認証者に
対して証書を解約することを要求（リクエスト）するものとする。解約によって
証書は無効になるので、加入者も認証者ももはや証書に拘束されない。

【０１７５】 解約によって、無効にされた証書は完全に信頼できなくなったとしても、利用
不能にはならないので、信頼側は証書が解約されているか否かを確認するために
ｃｒｌＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓフィールドにリストされたリポジ
トリをチェックすることが重要である。メッセージ・ハンドリング・ユニットは
、デジタル・サインを照合する時にこのチェックを行う。しかし、ユーザが、メ
ッセージ・ハンドリング・ユニットから転送されたメッセージ上のサービス・プ
ロバイダによるデジタル・サインを含む、デジタル・サインを受信すると、ユー
ザはそのデジタル・サインを照合し、その照合のために用いられた証書の解約に
ついてチェック（検査）しなければならない。加入者のユーザ・システムは通常
は、加入者の介在なく自動的に解約をチェックするが、それにも関わらず加入者
にはチェックがなされたか否かを確認する責任がある。

【０１７６】 オペレーション規則１１： 解約の検査 デジタル・サインの照合が要求されると、加入者は証書中のｃｒｌＤｉｓｔｒ
ｉｂｕｔｉｏｎＰｏｉｎｔｓフィールドに（または、証書にｃｒｌＤｉｓｔｒｉ
ｂｕｔｉｏｎＰｏｉｎｔｓがない場合はｉｓｓｕｅｒフィールドに）リストされ
たリポジトリをチェックして、その照合に必要な証書の解約通知が送付されてい
るか否かを判断するものとする。

【０１７７】 加入者が証書にリストされた公開鍵を用いて情報を暗号化する場合は、加入者
はさらに、証書が解約されたか否かの検査を、そのような検査がオペレーション
規則によって現在要求されていない場合でも、行うべきである。

【０１７８】 証書の解約は見込みの効果しか有していない。解約されるまでは、有効な証書
は満期になるまでは効力を保持する。従って、証書が解約（無効化）される前に
作成されたデジタル・サインは適切に照合でき、加入者の非公開鍵が盗まれて証
書を無効化すべき場合でも、他のユーザはそのデジタル・サインを信頼する場合
があり、照合のために用いられた証書に加入者がリストしたデジタル・サインに
対する責任を負うことがある。

【０１７９】 オペレーション規則１２： 無効化とデジタル・サインの時期 証書は、解約通知にリストされた時点で無効化（解約）される。デジタル・サ
インがいつ作成されたのかを判断するために、意志決定者は、デジタル・サイン
がなされたメッセージまたは文書に付された時間を含む、関連する全ての事実お
よび環境を考慮する。

【０１８０】 認証者は、解約通知書では、解約の時期が、解約通知が適宜のリポジトリに公
表される実際の時点よりも以前であることを決して表明しない。認証者と加入者
との契約は、リクエスト（要求）を受理した後、認証者が要求された解約を公表
を通じていかに迅速に実施しなければならないかを規定するものである。

【０１８１】 ここでリポジトリへの公表について記載する。リポジトリは、解約、証書、お
よび証書を信頼するプロセスで有用なその他の情報を含むオンライン・ディレク
トリもしくはデータベースである。リポジトリは、サービス・プロバイダによっ
て交付される全ての証書ごとに解約通知が送付される場所（ｃｒｌＤｉｓｔｒｉ
ｂｕｔｉｏｎＰｏｉｎｔ）としてリストされる。

【０１８２】 メッセージ・ハンドリング・ユニットは、メッセージ・ハンドリング・ユニッ
トを通じて送信されたメッセージ上のユーザのデジタル・サインを照合する際に
、証書の解約通知に関してリポジトリをチェックする。

【０１８３】 ４．タイトル・レジストリ タイトル・レジストリは電子船荷証券に関する情報の中央電子データベースで
ある。以下では、タイトル・レジストリが電子船荷証券を処理する方法を記載す
る。伝統的な紙の船荷証券の基本知識があることを前提にする。

【０１８４】 タイトル・レジストリは、電子船荷証券（ｅＢＬ）に含まれる権利および義務
を記録および伝送するデータベース・アプリケションである。タイトル・レジス
トリは、ｅＢＬ文書を記憶したり、読み出したりせず、タイトル・レジストリ命
令に含まれるｅＢＬに関する情報を記憶する。このように、船荷証券自体は現在
使用されている船荷証券の単なる電子バージョンである。

【０１８５】 タイトル・レジストリ命令はｅＢＬと共になり、ＢＢＬ（図３１参照）と呼ば
れる。ＢＢＬと規則書は伝統的な紙の船荷証券と同じ機能を提供する。 各ＢＢＬごとに、タイトル・レジストリはレコードの集合を作成し、それは、
（１）関与する側（関与する当事者）（ユーザＩＤ）、（２）要求／遂行される
機能、（３）ｅＢＬのタイプ、および（４）ｅＢＬ識別子を含む。

【０１８６】 タイトル・レジストリ・レコードの作成または変更は認可された当事者によっ
て行われる。これらの命令は通常のシステム・メッセージとして送られれる。メ
ッセージ・ハンドリング・ユニットがタイトル・レジストリ命令を含むメッセー
ジを受信すると、これはそのメッセージをタイトル・レジストリへ転送する。タ
イトル・レジストリは情報を確認し、レコードを作成または更新し、その結果を
メッセージ・ハンドリング・ユニットに返信する。メッセージ・ハンドリング・
ユニットは、その結果を送信側のメッセージへ加え、新しいメッセージを受取側
に送る。順序はずれの命令の受信を回避するため、タイトル・レジストリはシス
テム・メッセージの１つの命令だけを許容する。ペーパー（紙）の船荷証券と、
タイトル・レジストリに記憶されているｅＢＬとでは１つの重要な区別をする必
要がある。紙の船荷証券には標準的には３部の「オリジナル（原本）」がある。
複数部のオリジナルというコンセプトは本システムでは必要ない。なぜなら、メ
ッセージ・ハンドリング・ユニットは、輸送業者またはＮＶＯＣ（船舶を運用し
ない輸送業者）のｅＢＬ（デジタル・サインを使用）のオリジナル・コンテンツ
を保証し、また、タイトル・レジストリは一か所で全ての権利および義務を記録
するからである。ｅＢＬは情報用に複数の当事者へとコピーできるが、行為を行
う能力は、タイトル・レジストリのＢＢＬのステータスによって定められる。

【０１８７】 タイトル・レジストリは、情報の記録と記録へのアクセスの制御の他に、４つ
の付加的な機能を果たす。すなわち（１）自動通知、（２）必要な時にｅＢＬが
同封されることの保証、（３）ＢＢＬの修正の管理、および（４）規則書に記載
されている規則との適合である。

【０１８８】 エンドースメント（裏書）連鎖のメンテナンス。 タイトル・レジストリでの処理が完了すると、結果は送信側と受取側（１また
は複数）へと交付される。

【０１８９】 ４．１．１．電子船荷証券の性質 簡単な言い方では、船荷証券とは輸送業者によってサインされた書類であり、
輸送における商品の受領書、その輸送の契約書、およびホールダーに輸送業者か
らの商品の受け渡し権利を与える書類である。機能的には、船荷証券は輸送業者
から荷送人（荷主）へ、また最終的には商品の買手へと移動し、また、その途上
で銀行のような第三者の手を通過することもある。彼らが証券を所有すると、こ
れらの人々はそれに関連する権利および義務を得られる。

【０１９０】 電子船荷証券は、紙の媒体に電子レコードが取って代わってはいるものの、船
荷証券の伝統的な取引上の意味と機能とを保持している。その目的のため、電子
船荷証券は、取引情報と組合わせた文書の電子レコードからなっている。

【０１９１】 文書（ドキュメント）部分は船荷証券を表す。輸送業者によってデジタル・サ
インされたドキュメントは、文書ＩＤと、そのドキュメントが他のドキュメント
と同一であるか否かを判定するために利用できるハッシュ結果を含む、第２．３
項に記載の文書のその他のプロパティとを備えている。船荷証券の文書は電子船
荷証券を作成するメッセージの一部としてデジタル署名される。デジタル・サイ
ンされたメッセージに含まれる全ての文書と同様に、デジタル・サインは、特に
文書だけにではなく、メッセージ全体に適用される。船荷証券の文書は、メッセ
ージ・ハンドリング・ユニットを介してサービス・プロバイダによって維持され
ているシステムの中心部へと送信され、そこで文書ＩＤによって記録される。こ
の文書を「電子船荷証券テキスト」すなわちｅＢＬテキストと称する。

【０１９２】 取引情報は、関連の船荷証券文書に関連している。各電子船荷証券ごとに、タ
イトル・レジストリは「タイトル・レジストリ・レコード」として知られている
表の形式のデータベース・レコードを保存する。タイトル・レジストリ・レコー
ドは、電子船荷証券に関連してある役割を占めるユーザのユーザ識別子、並びに
ある種のその他のデータをリストする。規則書はこれらの役割の詳細を理解して
、電子船荷証券に関連するある種の権利および義務を作成する。タイトル・レジ
ストリレコード内のデータを変更する権利を与えられたユーザは、メッセージ・
ハンドリング・ユニットを介して送信されたメッセージのタイプ・ヘッダにタイ
トル・レジストリ命令を送信することによって、データの変更を行う。

【０１９３】 このように、電子船荷証券は、（１）ｅＢＬテキスト、すなわち従来の紙の船
荷証券と同様のものと理解できる文書であり、これは（２）タイトル・レジスト
リ・レコードと呼ばれるデータベース・レコードと組み合わされるものであり、
タイトル・レジストリ・レコードは、規則書に従ってシステム・ユーザが権利お
よび義務を得る文書に関連する取引を記録するためにシステム・サービス・プロ
バイダによって保存されている。

【０１９４】 ４．１．２ タイトル・レジストリ側 以下はタイトル・レジストリ命令において命名された側（当事者）である。紙
書類の世界で現在使用されている用語は可能な限りそのまま使用する。しかし、
特に、本システムおよびｅＢＬの特有の特徴を考慮に入れるため、新たな用語を
使用しなければならず、他の用語の意味が変更された。いずれにせよ、一度に１
つの当事者に１つのユーザＩＤのみが命名される。

【０１９５】 オリジネータとはＢＢＬを作成する当事者（輸送業者もしくはＮＶＯＣ）であ
る。このフィールドは必須である。 引渡側(Surrender party)とはＢＢＬを引き渡される当事者である（輸送業者
の代理人）。オリジネータが引渡側でもある場合は、このフィールドは使用され
ない。

【０１９６】 荷主(shipper、荷送人)とは、商品を輸送する契約をオリジネータと締結する
当事者である。このフィールドは必須である。 ホールダー（holder）とは、ｅＢＬが紙文書であるとした場合に、ｅＢＬを物
理的に所有する者と似た者である。ホールダーは、ＢＢＬが紙に切り換えられた
場合、紙の船荷証券を受領する権利を有する当事者である。ＢＢＬに指図側(To
Order Party)が命名されていないまたは荷受側(Consignee、受託者)が記名（指
定）されていない（白地裏書）場合、ホールダーは持参人（Bearer）ホールダー
と言われる。ホールダーまたは抵当権者ホールダー（プレッジー・ホールダー）
のいずれかが必須である。

【０１９７】 プレッジー・ホールダーはＢＢＬに質権を有する当事者である。プレッジー・
ホールダーは、ＢＢＬによってカバーされる貿易取引のために危険のある融資を
行っている銀行である（標準的には信用状を介して行う）。質権（抵当）によっ
て、銀行は債務不履行の場合にＢＢＫに関する権利（責任に関する）を引き受け
ることができる。ＢＢＬに指図側が記名されていないか又は荷受側が記名されて
いない場合（白地裏書）、プレッジー・ホールダーはプレッジー持参人ホールダ
ーと呼ばれる。ホールダーまたはプレッジー・ホールダーのいずれかが必須であ
る。

【０１９８】 指図側とは、譲渡可能（流通可能）なＢＢＬの被裏書人である者（側）のこと
である。タイトル・レジストリは白地裏書（指図側の記名がない）の譲渡可能な
ＢＢＬを保持することもできる。このフィールドはオプションである。

【０１９９】 荷受側とは、通常は商品の買手であり、譲渡不可（流通不可）のＢＢＬに記名
されている。このフィールドはオプションである。 その上、何れのユーザＩＤ（登録されたもの）もタイトル・レジストリ・レコ
ードの当事者であることができる。タイトル・レジストリは、ユーザＩＤが同じ
ルート名を共用している限り、ある側（当事者）からの命令に従って作用する。
例えば、ユーザ「Ｓｈｏｅ．ＧＢ」（ルート名＝「Ｓｈｏｅ」）がＢＢＬのホー
ルダーであり、ユーザ「Ｓｈｏｅ．ＪＰ」（ルート名＝「Ｓｈｏｅ」）はホール
ダーとしてＢＢＬに作用できる。

【０２００】 ４．２．電子船荷証券の役割 電子船荷証券に関するユーザの権利および義務は役割へと区分され、これらの
役割は、船荷証券の伝統的な機能と、役割のレコードをタイトル・レジストリ・
レコード内のデータ・フィールドとして保存する、タイトル・レジストリの動作
によって上記の機能が複製される方法との双方を、反映する。タイトル・レジス
トリ・レコード内のこれらのフィールドにおいて、タイトル・レジストリは電子
船荷証券のステータスに関する情報、およびこれに関連するシステム・ユーザの
権利および義務を記憶する。

【０２０１】 図１４はタイトル・レジストリ・レコードの論理構造を簡略して示す。この図
面のフィールドはこの項で述べる。 役割フィールドのコンテンツは、全てのユーザ部門識別子（ユーザ識別子の一
部がユーザの部局またはその他のサブユニットを示す）を含むが、ユーザ識別子
の拡張子を含まないユーザ識別子でなければならない。全ユーザ識別子がリスト
されているが、ユーザの代理としてデジタル・サインできる人は誰でも、ユーザ
自身のシステムによって制限されない限りは、ユーザ用のタイトル・レジストリ
を変更するタイトル・レジストリ命令を送信することができる。ユーザの部門識
別子はタイトル・レジストリ・レコードにリストされているが、タイトル・レジ
ストリがタイトル・レジストリ命令を実行する際は無視される。

【０２０２】 必要な権利を有するユーザが自らまたは他のユーザを或る役割に指定すると、
ユーザはタイトル・レジストリ内のその役割を果たす。ユーザを役割に指定する
プロセスは第４．４項に説明されている。第４．２項は役割自体を説明する。

【０２０３】 ４．２．１．オリジネータ（輸送業者） オリジネータは、契約する輸送業者、すなわち荷主との合意に基づき電子船荷
証券を作成するユーザである。オリジネータの役割は、以下に説明するようにタ
イトル・レジストリ内の様々なプロパティを有している。

【０２０４】 実世界で事実上は、特定のユーザのみが実際に輸送業者として活動できるが、
機能的な能力に関しては、何れのユーザもオリジネータ（輸送業者）用のタイト
ル・レジストリ・レコードのフィールドに入力できる。

【０２０５】 電子船荷証券のオリジネータとして単一のユーザのみがリストされることがで
きる（即ち、そのユーザ識別子がオリジネータ役割フィールド内にある）。 全ての電子船荷証券にはオリジネータ（輸送業者）がいる。

【０２０６】 オリジネータ（輸送業者）は、第４．４．２項に記載されているように電子船
荷証券を作成する際に自らをオリジネータとして指定する。 電子船荷証券の作成が終了すると、何れのユーザもその証券に対する新規のオ
リジネータを指定することができず、また、そのオリジネータとしてレコードさ
れたユーザ識別子を変更できない。

【０２０７】 オリジネータには、（１）第４．４．２項に記載されているようなその他の役
割と共に、電子船荷証券を作成し、作成時にその荷主、初期ホールダー、および
その初期指図側またはその荷受側を指定し、（２）電子船荷証券の修正リクエス
トを承認または拒否し、かつ（３）他のユーザによって与えられた紙への切換え
指令を実行する、という権利を有している。

【０２０８】 ４．２．２ 引渡側 引渡側は、引き渡される電子船荷証券を受領すべく、オリジネータによって指
定された者である。タイトル・レジストリは「引渡」という用語を、荷積みされ
た商品の引き渡しが行われる際に、電子船荷証券をそのオリジネータ（または引
渡側）に最終的に渡すという意味で用いている。引渡側の役割は、以下に説明す
るようにタイトル・レジストリ内の多くのプロパティを有している。

【０２０９】 何れのユーザも引渡側として指定されることができる（すなわち、引渡側役割
フィールドにそのユーザ識別子を記載できる）。 電子船荷証券の引渡側としては一つのユーザ識別子だけが示されることができ
る。

【０２１０】 引渡側の指定は、オリジネータ（輸送業者）の裁量によるオプションである。
引渡側が指定されない場合は、オリジネータ（輸送業者）が引き渡される電子船
荷証券を受領する。

【０２１１】 電子船荷証券のオリジネータだけが引渡側を指定することができる。 引渡側は、一旦指定されると、永続的に入力され、第４．４．５項に記載のよ
うにオリジネータによる電子船荷証券の修正によって変更することはできるが、
通常のタイトル・レジストリ機能によっては変更できない。

【０２１２】 引渡側は、引渡側としての役割において、いずれのタイトル・レジストリ機能
を実施する権利も有していない。 ４．２．３． 荷主 荷主（荷送人）とは、当該の商品を発送するためにオリジネータ／輸送業者と
契約を締結する者のことである。多くの場合、荷主は商品の売手または輸出業者
である。荷主役割フィールドは以下に説明するようにタイトル・レジストリ内に
多くのプロパティを有している。

【０２１３】 何れのユーザも荷主として指定されることができる（すなわち、荷主役割フィ
ールドにユーザ識別子を記載できる）。 電子船荷証券の荷主としては一つのユーザだけが指定されることができる。

【０２１４】 全ての電子船荷証券は、その作成時に荷主が指定される。 電子船荷証券を作成するオリジネータは、その荷主との合意に基づいて、荷主
を指定する。

【０２１５】 荷主は、一旦指定されると、永続的に入力され、第４．４．５項に記載のよう
にオリジネータによる電子船荷証券の修正によって変更することはできるが、通
常のタイトル・レジストリ機能によっては変更できない。

【０２１６】 荷主は、単に荷主としての役割おいては、如何なるタイトル・レジストリ処理
を実行する権利も有していない。荷主の権利は、荷主であること以外の役割から
派生するものである。第４．３項に詳細に記載するように、荷主は、他の役割と
の組合わせで、例えば下記の役割を実施することができる。

【０２１７】 （１）荷主が同時に電子船荷証券のホールダーでもある場合は、ホールダーま
たはプレッジーを指定すること。 （２）荷主が同時に証券の指図側ホールダー（Holder-To Order）または持参
人ホールダーでもある場合には、荷受側（受託者）または後継の指図側を指定し
、またはそのホールダーを変更することによって証券を譲渡できるようにするた
めに証券を白地裏書きにすること。

【０２１８】 （３）荷主が同時に証券の指図側ホールダー、またはホールダーおよび荷受側
の双方でもある（稀なケースであると予測される）場合は、証券を引き渡すこと
。

【０２１９】 （４）荷主が同時に電子船荷証券のホールダーでもある場合は、電子船荷証券
の修正をリクエストするか、または紙への切換え指令を与えること。 電子船荷証券のホールダーであることを止めた荷主は、その証券に関連するい
かなる機能を実行することもできない。

【０２２０】 ４．２．４． 荷受側 荷受側（受託者）は買手または輸入業者、すなわち譲渡不可の電子船荷証券に
従って商品を受領する者である。譲渡可能な電子船荷証券に荷受側が指定される
と、その証券は譲渡不可となる。荷受側役割フィールドには以下に説明するよう
にタイトル・レジストリ内の様々なプロパティがある。

【０２２１】 何れのユーザも荷受側として指定されることができる（すなわち、荷受側役割
フィールドにそのユーザ識別子を記載できる）。 電子船荷証券の荷受側としては一つのユーザ識別子だけが指定されることがで
きる。

【０２２２】 本システムは荷受側が指定されることを要求しない。 電子船荷証券を作成する際、オリジネータは、その証券に対する指図側を指定
していない場合は、証券の荷受側を指定することができる。証券に対して指図側
が指定された後は、その現行の指図側ホールダー、または持参人ホールダーが荷
受側を指定できる。

【０２２３】 荷受側は、一旦指定されると、永続的に入力され、第４．４．５項に記載のよ
うにオリジネータによる電子船荷証券の修正によって変更することはできるが、
通常のタイトル・レジストリ機能を利用することによっては変更できない。

【０２２４】 同時に電子船荷証券のホールダーでもある荷受側は、下記の権利を有する。 （１）電子船荷証券の修正をリクエストすること。 （２）電子船荷証券をオリジネーター−輸送業者または指定された引渡側に引
き渡すこと。

【０２２５】 （３）電子船荷証券の紙への切換え指令を与えること。 荷受側が電子船荷証券のホールダーを兼ねていない場合は、荷受側はいかなる
タイトル・レジストリ処理も実施することができない。

【０２２６】 ４．２．５． 指図側（To Order Party） 指図側とは、譲渡可能な電子船荷証券の被裏書人である。タイトル・レジスト
リ内の指図側のための役割フィールドには以下に説明するような様々なプロパテ
ィがある。

【０２２７】 何れのユーザも指図側として指定されることができる（すなわち、指図側役割
フィールドにそのユーザ識別子が記載される）。 電子船荷証券の指図側としては一つのユーザ識別子だけが一時に指定されるこ
とができる。

【０２２８】 本システムは荷受側が指定されることを要求しない。 電子船荷証券の作成に際して、オリジネータはその最初の指図側を指定しても
よい（荷主命令として）。

【０２２９】 持参人ホールダーはまた、証券の白地裏書きを取り除いて指図側役割フィール
ドにユーザ識別子を入力する命令によって、指図側を指定してもよい。一旦指定
されると、指図側は、第４．４．３．３項に記載のとように、裏書きに類似した
手続きによって後継の者を指定してもよい。

【０２３０】 指図側が一旦指定されると、これは第４．４．３．３項に記載した手続きによ
って変更できる。 電子船荷証券の現行の指図側であり、同時にホールダーでもあるユーザ（すな
わち指図側ホールダー)は以下の権利を有する。

【０２３１】 （１）証券の後継の指図側を指定すること。 （２）荷受側を指定し、それによって電子船荷証券を譲渡不可の証券に転換す
ること。

【０２３２】 （３）証券を白地裏書としてから新規のホールダーを指定することによって、
新規の持参人ホールダーによる証券の譲渡を可能にすること。 （４）プレッジー（質権者、抵当権者）を指定することによって証券に抵当権
を設定すること。

【０２３３】 （５）証券をオリジネータ−輸送業者、または指定された引渡側に引き渡すこ
と。 （６）電子船荷証券の紙への切換え指令を与えること。

【０２３４】 指図側が同時に当該の電子船荷証券のホールダーでもある場合以外は、指図側
はタイトル・レジストリのいかなる処理も行うことができない。ホールダーでも
あるこのような指図側を「指図側ホールダー」と称する。

【０２３５】 ４．２．６．持参人ホールダー 持参人ホールダー（Bearer Holder）とは、船荷証券を物理的に所有する者、
すなわち証券の物理的所有権を変更することによって譲渡可能である者と同類で
ある。持参人ホールダーは、電子船荷証券を白地裏書きにして、次に第４．４．
３．１項に記載のようにホールダーを指定することによって作成される。このよ
うに、持参人ホールダーは、単に、白地裏書きの電子船荷証券のホールダーのこ
とである。

【０２３６】 持参人ホールダーの役割は以下に説明するようにタイトル・レジストリ内に様
々なプロパティを有している。 何れのユーザも持参人ホールダーとして指定されることができる（すなわち、
白地裏書きの電子船荷証券のホールダー役割フィールドにそのユーザ識別子を記
載できる）。

【０２３７】 一時に一つのユーザだけが電子船荷証券のホールダー（従って、持参人ホール
ダー）であることができる。 持参人ホールダーは、電子船荷証券が白地裏書きとなっている場合だけ存在す
る。白地裏書きもオプションである。

【０２３８】 電子船荷証券の作成の際、オリジネータ（輸送業者）または現時点の指図側ホ
ールダーは、証券を白地裏書きとすることができる。 電子船荷証券の後継のホールダーは第４．４．３．１項に記載のように指定さ
れる。前述のように、電子船荷証券は白地裏書きとされている間は、ホールダー
の指定は、その持参人ホールダーの指定と同等である。

【０２３９】 現時点の持参人ホールダーは、他のユーザを電子船荷証券のホールダーにする
ことによって、後継の者を指定できる。持参人ホールダーはまた、白地裏書きを
取り除き、指図側または荷受側を指定することによって、役割を解除することが
できる。

【０２４０】 電子船荷証券の現時点の持参人ホールダーは下記の権利を有する。 （１）新規の持参人ホールダーを指定すること（白地裏書きの電子船荷証券の
新規のホールダーを指定することによる）。しかし、持参人ホールダーは、証券
が既に白地裏書きとされたものであるので、これを白地裏書きとすることはでき
ない。

【０２４１】 （２）指図側を指定し、それにより、後継の指図側を指定することによって電
子船荷証券を譲渡可能な証券に転換すること。 （３）荷受側を指定し、それにより、電子船荷証券を譲渡不可の証券に転換す
ること。

【０２４２】 （４）質権者を指定することにより証券に抵当権を設定すること。 （５）証券の修正をリクエストすること。 （６）電子船荷証券を紙に切り換える指令を与えること。

【０２４３】 ４．２．７． 質権者（抵当権者） 抵当権者は、出荷された商品に融資すること、またはその支払いを保証するこ
とに基づいて、電子船荷証券に利害関係を有する金融機関である。抵当権者役割
フィールドにはタイトル・レジストリ内の下記のプロパティがある。

【０２４４】 何れのシステム・ユーザ識別子も抵当権者として指定されることができる（す
なわち、抵当権者役割フィールドに記載できる）。 一時に一つのユーザ識別子だけが電子船荷証券の抵当権者として指定されるこ
とができる。

【０２４５】 抵当権者の指定は必須ではない。 指図側ホールダー、または持参人ホールダーは抵当権者を指定することができ
る。一つの抵当権者は、他の後継の抵当権者を指定してもよい。抵当権者が指定
されると、抵当権者は自動的に、抵当にされた電子船荷証券のホールダーにも指
定される。抵当権者は、抵当権者である限り、ホールダーである。同時にホール
ダーでもある抵当権者をプレッジー・ホールダーと称する。

【０２４６】 抵当権者は後継の者を指定でき、また、抵当権者役割フィールドからそのユー
ザ識別子を削除することによってその抵当権を放棄してもよい。 同時にホールダーでもある抵当権者（すなわちプレッジー・ホールダー）は下
記の権利を有する。

【０２４７】 （１）抵当権者役割フィールドからそのユーザ識別子を削除することによって
抵当権を放棄すること。 （２）電子船荷証券が白地裏書きとされていない場合は、自らを指図側に指定
することによって、その抵当権を強制すること。白地裏書きとされている場合は
、プレッジー・ホールダーは、抵当権者役割フィールドから単にそのユーザ識別
子を削除することにより、もはや抵当権が設定されていない証券の持参人ホール
ダーになる。

【０２４８】 （３）電子船荷証券を紙に切り換える指令を与えること。 （４）後継の抵当権者を指定すること。しかし、プレッジー・ホールダーは、
抵当権者を兼ねていない新規のホールダーを指定することはできない。

【０２４９】 前述のように、ホールダーを兼ねていない抵当権者は理論上でしか存在しない
。タイトル・レジストリは新規に指定された抵当権者にホールダーを兼ねさせ、
抵当権者が、ホールダーを兼ねる他の抵当権者を指定することを許可しない。

【０２５０】 ４．２．８． ホールダー ホールダーは、電子船荷証券が紙に切り替わる場合に、船荷証券文書を物理的
に所有する権利を有する者である。ホールダー役割フィールドは、タイトル・レ
ジストリ内に以下に説明するような様々なプロパティを有している。

【０２５１】 何れのシステム・ユーザ識別子もホールダーとして指定されることができる（
すなわち、ユーザー識別子をホールダー役割フィールドに記載できる）。 一時に一つのユーザだけが電子船荷証券のホールダーになることができる。

【０２５２】 全ての電子船荷証券が、作成から引渡しまでの全ての時に、ホールダーを有し
ていることは必須である。ホールダーは、ホールダー役割フィールドからそのユ
ーザ識別子を削除することができない。

【０２５３】 電子船荷証券の現時点のホールダーであるシステム・ユーザは、ホールダーが
抵当権者を兼ねていない限り、他のシステム・ユーザをホールダーとして指定す
ることができる。

【０２５４】 電子船荷証券のホールダーは、証券が有効である限り（すなわち、証券の作成
時から、それが引き渡されるかまたは紙に切り換えられるまでの期間）変更でき
る。

【０２５５】 ホールダーは、（１）プレッジー・ホールダー、または後継のホールダー（プ
レッジー（抵当権者）を兼ねていない場合）を指定し、（２）電子船荷証券を紙
に切り換える指令を与え、かつ（３）電子船荷証券の修正を要求する、という権
利を有する。

【０２５６】 ４．３． 電子船荷証券の状態と様式 何世紀にもわたって確立されてきた伝統によって、船荷証券には幾つかの分類
法があり、これには例えば、無故障(clean、クリーン)または条項付き(claused)
、あるいは記名式(straight)または「流通可能」などの船荷証券がある。これら
の区別は基本的に、本システムで実施されているような電子形式の船荷証券に存
続している。本システムへと送信される船荷証券の文書は、オリジネータおよび
その相手側がｅＢＬのテキストをいかに立案するかに応じて、例えば条項付き、
または無故障の船荷証券であることができる。

【０２５７】 しかし、船荷証券間のこのような伝統的な区別に対して、タイトル・レジスト
リの機能性は、電子船荷証券が運用上、使用可能(active、アクティブ)であるか
否に基づいて新規の類型法を追加する。この機能性はさらに、譲渡性のコンセプ
ト、およびこのコンセプトに基づく区別に、運用上の幾つかのニュアンスを追加
する。以下では、運用上の活動および譲渡性に基づくこれらの区別を吟味する。

【０２５８】 ４．３．１． 運用状態 電子船荷証券は作成と終結のライフサイクルを経る。タイトル・レジストリが
電子船荷証券に対して実施できる処理は、電子船荷証券の状態に応じて異なる。
簡略に述べると、電子船荷証券には３つの運用状態がある。これは活動状態にな
るように作成され、修正が懸案中である間に一時停止状態に移行し、さらに、取
引きサポート証書としての電子船荷証券の機能性が尽きることによる終結状態を
有している。

【０２５９】 活動状態は、オリジネータが電子船荷証券を適正に作成した時点で始まる。活
動状態は、電子船荷証券が未解決の修正リクエスト（要求）を示す一時停止状態
になると中断される。活動状態は、電子船荷証券が契約終結されると終了する。
活動状態では、電子船荷証券は第４．４．３項に記載のように譲渡され、または
抵当権設定され、修正され、紙へと切換えられ、または引き渡されることが可能
である。

【０２６０】 電子船荷証券の修正を要求する権限を有する当事者がその要求を行うと、一時
停止状態に入る。一時停止状態は、オリジネータが修正要求を拒否するか、また
は要求を承認して修正を完了すると終了し、活動状態に復帰する。電子船荷証券
が一時停止状態にある間は、修正要求に対する承認または拒否以外のその他の処
理はできない。

【０２６１】 必要な権限を有する当事者が電子船荷証券を引き渡すか、または紙に切り換え
ると、終結状態に入る。終結状態に入るとそれを取り消しできない。その上、終
結状態に入った電子船荷証券ではどのような処理もできない。

【０２６２】 下記の第４．４項は、電子船荷証券をこれらの運用状態間で変更させる処理を
より詳細に記載している。 ４．３．２． 譲渡可能状態 処理動作の活動状態、一時停止状態、または終結状態を区別する基準は、電子
船荷証券のライフサイクルの各段階、および各段階で許容されるべき処理に基づ
くものである。ここで記載する類型法を区別する基準は、電子船荷証券の譲渡性
である。譲渡は、他のユーザを特定の役割に指定することからなる処理であるの
で、譲渡性は、機能性ではなくおそらくは概念的にのみ動作状態とは異なるもの
である。

【０２６３】 システムは譲渡性を３つの状態、すなわち譲渡不可、譲渡可、および抵当権設
定に区別する。 オリジネータ、現行の指図側ホールダー、または持参人ホールダーが電子船荷
証券の荷受側を指定すると、譲渡不可状態に入る。譲渡不可状態に入ると、譲渡
性の状態に関する限り、取り消し不能かつ永続的なものであり、電子船荷証券が
引き渡しによって終結状態に入るか又は紙に切り換えられた時のみ、その状態は
終了する。譲渡性の状態の変更は、電子船荷証券が譲渡不可状態にあっては不可
能である。

【０２６４】 オリジネータが指図側を指定するか、または新規の電子船荷証券に白地裏書き
すると、譲渡可能状態に入る。譲渡性は、証券に抵当権が設定されている間は中
断する。荷受側を指定することによって証券が譲渡不可になるか、または証券が
処理終結状態に入ると、譲渡可能状態は終了する。譲渡可能な証券の現時点の指
図側または持参人ホールダーは後継の指図側または持参人ホールダーを指定する
か、荷受側を指定するか（証券に抵当権を設定する）、または荷受側を指定（証
券を譲渡不可にする）することができる。

【０２６５】 ホールダーが譲渡可能な電子船荷証券の抵当権者を指定すると、抵当権設定状
態に入る。抵当権者が抵当を実施するか又は放棄すると、抵当権設定状態は終了
する。抵当権設定状態では、抵当権の実施または放棄が可能である。また、証券
は修正することや、紙に切り換えることもできる。譲渡（例えば、後継のホール
ダー、指図側、または荷受側の指定）はできない。

【０２６６】 ４．４． 電子船荷証券での処理 第４．３．１項での処理状態活動の状態の説明で示したように、電子船荷証券
は、標準的には開始から終了までに、幾つかの取引きまたは事象を経る。この進
展で、電子船荷証券用のタイトル・レジストリ・レコードのデータは変更される
。一方、規則書に従って、このようなデータの変更で、紙の船荷証券がその取引
きの過程で権利を引き渡したり譲渡するのと全く同様に、電子船荷証券に関する
システム・ユーザの権利が変更される。このような権利の変更を行うには、必須
の権限を有する役割を占めるユーザが、他のユーザを役割に指定する。指定の他
に、適切な権限を有する役割にあるユーザは、タイトル・レジストリ・レコード
に影響を及ぼすその他の処理を実施することができる。この項ではこれらの処理
を説明する。

【０２６７】 以下はタイトル・レジストリによってサポートされる命令のリストである。当
事者が利用できる機能は図３２に要約してある。 （１）作成 − 新規のＢＢＬ用にタイトル・レジストリにレコードを作成で
きる。

【０２６８】 （２）ホールダー指定 − 既存のＢＢＬレコードにおいてホールダーシップ
を転記できる。 （３）プレッジー・ホールダーの指定 − プレッジー・ホールダーを指定す
るか、または既存のＢＢＬレコードにおいて抵当権を転記する。

【０２６９】 （４）指図側の指定 − 既存のＢＢＬレコードにおいて指図側を指定する。 （５）荷受側の指定 − 既存のＢＢＬレコードにおいて荷受側を指定する。 （６）白地裏書 − 既存のＢＢＬレコードにおいて指図側を削除する。

【０２７０】 （７）質入強制（Enforce Pledge） − 既存のＢＢＬレコードにおいて、プ
レッジー・ホールダーを、譲渡可能なＢＢＬのプレッジー・ホールダーをホール
ダーおよび指図側（記名されている場合）にする。

【０２７１】 （８）修正要求 − オリジネータに対して、既存のＢＢＬレコード（１また
は複数）に関連するＢＢＬ（１または複数）を修正するように要求する。 （９）修正許可 − タイトル・レジストリにおいてＢＢＬレコード（１また
は複数）を、更新または作成することによる修正を承認する。

【０２７２】 （１０）修正拒否 − タイトル・レジストリにおいてＢＢＬレコード（１ま
たは複数）を、修正要求前の状態に戻すことによる修正を拒否する。 （１１）紙へ切り替え − オリジネータに対して、ＢＢＬ原本から紙のＢＬ
原本を作成するように要求する。

【０２７３】 （１２）引渡し − ＢＢＬをオリジネータへ戻す（輸送の契約の義務を満た
すように）。 ４．４．１． 基本的なタイトル・レジストリのオペレーション タイトル・レジストリ・レコードを含む各オペレーション（処理）は、この項
の後の項に特に詳細に記載されいてる。しかし、この項は、全てのタイトル・レ
ジストリのオペレーションがメッセージ・ハンドリング・ユニットの基本的なメ
ッセージング・フレームワークを利用する共通の方法を有していることを、冒頭
に記載する。タイトル・レジストリに影響を及ぼすそれぞれのオペレーションは
、図１５に示すように、また第２．２項で説明されたメッセージ・ハンドリング
・ユニットのＳＭｓｇ−ＦＭｓｇ−ＤＮｏｔのシーケンスによって達成される。

【０２７４】 図１５では、参照番号１はユーザから中央システムのメッセージ・ハンドリン
グ・ユニットへ送信されたＳＭｓｇメッセージを示し、参照番号２はメッセージ
・ハンドリング・ユニットから中央システムのタイトル・レジストリへの入力を
示し、参照番号３はデータベース更新の成功に関するタイトル・レジストリから
のリターン・コードを示し、参照番号４は当事者ユーザへのＦＭｓｇの形式の通
知を示し（必要な場合）、参照番号５はＳＭｓｇの送信側へ送信される完了に関
するＤＮｏｔ通知を示す。

【０２７５】 特に特定すれば、タイトル・レジストリのデータを変更するオペレーションを
実施するには、 （１）オペレーションを開始するユーザは、ＳＭｓｇ形式のタイプ・ヘッダを
有するメッセージをメッセージ・ハンドリング・ユニットに送信する。このＳＭ
ｓｇメッセージはそのタイプ・ヘッダに、図１６に示すようにＩｎｓｔｒｕｃｔ
ｉｏｎ（命令）のラベルを付したエレメントを含んでいる。加えて、送信側ユー
ザはメッセージ内の文書としてｅＢＬテキストを含めなければならない場合が多
い。抵当権を放棄または執行、修正を要求または拒否、紙への切換え、または電
子船荷証券の引渡しの際には、ｅＢＬテキストを含める必要はない。その他の全
ての取引きについては、送信側はＳＭｓｇメッセージにｅＢＬテキストを含めな
ければならない。必要がない場合にｅＢＬテキストを含めることが誤りである場
合はない。ＳＭｓｇメッセージはＦＭｓｇメッセージのレシピエント（受取側）
を指示する必要はない。なぜなら、メッセージ・ハンドリング・ユニットおよび
／またはタイトル・レジストリは、以下の項目で記載するように、送信側が何れ
のレシピエントをＳＭｓｇメッセージ内において示すかに関わりなく、何れのユ
ーザに通知がなされ、ＦＭｓｇメッセージを送信すべきかを自動的に判定するか
らである。通常は、メッセージ・ハンドリング・ユニットがＩｎｓｔｒｕｃｔｉ
ｏｎエレメントを伴うＳＭｓｇを受信すると、ＢＡｃｋ（または、所定の基準で
規定されるようにＳＭｓｇメッセージが技術的に無効である場合には、ＢＮａｋ
）を返信する。

【０２７６】 （２）ＳＭｓｇメッセージが技術的に有効である場合は、メッセージ・ハンド
リング・ユニットはそのＩｎｓｔｒｕｃｔｉｏｎエレメントに基づいてタイトル
・レジストリに命令を送り、タイトル・レジストリは、それぞれの特定のタイプ
の命令に関して後述するようにそのＩｎｓｔｒｕｃｔｉｏｎ（命令）を処理する
。命令の処理後に、タイトル・レジストリはメッセージ・ハンドリング・ユニッ
トに対して、処理プロセスが成功したか失敗したかを示すコードを返信する。

【０２７７】 （３）タイトル・レジストリがＳＭｓｇ Ｉｎｓｔｒｕｃｔｉｏｎからの入力
を処理した後、当事者ユーザ（ＳＭｓｇの送信側以外）に対して、各々がＦＭｓ
ｇ形式のタイプ・ヘッダを有する送信メッセージの形式でアクション（行動）を
報告する。何れのユーザがこのようなＦＭｓｇメッセージを受信するかについて
は、タイトル・レジストリの各々のオペレーションに関連して以下に説明する。

【０２７８】 （４）メッセージ・ハンドリング・ユニットが当事者ユーザへＦＭｓｇメッセ
ージを送信し、それらのユーザが各々にＵＡｃｋメッセージを返信した後、メッ
セージ・ハンドリング・ユニットは、元のＳＭｓｇメッセージの送信側に対して
、タイトル・レジストリが命令を遂行して関連するＦＭｓｇ通知を当事者ユーザ
へ送信したことを示す配達通知ＤＮｏｔメッセージを返信する。１または複数の
当事者ユーザがＵＡｃｋを返信することでＦＭｓｇ通知をアクノレッジメントす
るのに失敗した場合は、メッセージ・ハンドリング・ユニットは、ＳＭｓｇメッ
セージの送信側へＦＮｏｔを返信する。

【０２７９】 ＳＭｓｇメッセージの全体的な構造は、そのＳＭｓｇタイプ・ヘッダが図１６
での簡略な例に示すようにＩｎｓｔｒｕｃｔｉｏｎと呼ばれるエレメントを含ん
でいること以外は、他のメッセージと同じである。Ｉｎｓｔｒｕｃｔｉｏｎエレ
メントは、本項でより詳細に説明するように、タイトル・レジストリを更新する
ために必要な情報を含んでいる。

【０２８０】 タイトル・レジストリとＳＭｓｇメッセージとが関連するオペレーションと、
それを実行させるＩｎｓｔｒｕｃｔｉｏｎエレメントは、（ａ）作成、（ｂ）譲
渡、（ｂ）抵当、（ｄ）修正、（ｅ）引き渡し、および（ｆ）紙への切換えのカ
テゴリーに分類できる。

【０２８１】 電子船荷証券の作成はオリジネータ（輸送業者）によって行われる。 譲渡は、規則書に従って、指図側、ホールダー、荷受側などのような役割にユ
ーザを指定することによって、ユーザが電子船荷証券における権利および義務を
変更する際に発生する。

【０２８２】 抵当は、金融機関が自らを抵当権者として指定することから生ずる。抵当によ
って、電子船荷証券は、出荷された商品の販売への融資の際に金融機関が広げた
信用貸しの見返り担保と類似したものとなる。抵当権者として指定されると、金
融機関はその抵当を執行または放棄することができる。

【０２８３】 電子船荷証券の修正は、あるユーザによる要求で、電子船荷証券のオリジネー
タによって承認されることができる。 引き渡しは、電子船荷証券がその過程をたどった後に発生する。電子船荷証券
はオリジネータ（輸送業者）または引渡側（もし存在すれば、輸送業者の代理人
）に引き渡される。オリジネータまたは引渡側は、その後、出荷された商品の配
達手順に入る。

【０２８４】 紙への切換えは、適宜の役割にあるユーザの要求で、必要であれば、電子船荷
証券を紙の形式に変換するために実施できる。 本項の残りの部分ではこれらのカテゴリーの各オペレーションを詳細に検討す
る。

【０２８５】 ４．４．２．電子船荷証券の作成 電子船荷証券の作成によって、ｅＢＬテキストに対する参照をもってタイトル
・レジストリにおいて証券に対する新規のレコードが開始される。レコードには
証券に対する可能な様々な役割の空欄が含まれる。

【０２８６】 オペレーション規則１３： 電子船荷証券の作成 電子船荷証券を作成する際、オリジネータは、 （ａ）タイトル・レジストリ命令を、 （１）ｅＢＬテキスト用の文書ＩＤを供給すること、 （２）荷主を指定すること、 （３）電子船荷証券が譲渡可か譲渡不可であるかを述べること、 （ｉ）譲渡不可である場合は、荷受側を指定し、 （ｉｉ）譲渡可である場合は、指図側を指定するか、または証券が
白地裏書きであることを示すこと、 （４）引渡側（存在する場合）を指定すること、 （５）電子船荷証券のホールダーを指定すること によって完成させ、 （ｂ）文書形式のｅＢＬテキストを添付し、 （ｃ）メッセージ（上記の副規則（ａ）に基づいて作成されたタイトル・レジ
ストリ命令およびｅＢＬテキストを含む）にサインし、メッセージ・ハンドリン
グ・ユニットを介してタイトル・レジストリへ送信するものとする。

【０２８７】 本項の残りの部分ではこのオペレーション規則を注釈する。 オリジネータ（輸送業者）は電子船荷証券を作成する。本システムは、オリジ
ネータであり電子船荷証券を作成してもよいユーザと、作成できないユーザとを
を区別しない。

【０２８８】 タイトル・レジストリは、オリジネータが電子船荷証券を作成してもよい時期
を制限しない。 図１７は電子船荷証券の作成プロセスを示す。作成は以下のステップで行われ
る。

【０２８９】 （１）ユーザ・システムを利用して、オリジネータはメッセージ・ハンドリン
グ・ユニットへのメッセージを作成する。メッセージはＳＭｓｇ形式のタイプ・
ヘッダを有している。

【０２９０】 （２）タイトル・レジストリは、次に、必要な情報が供給される。オリジネー
タのユーザ・システムは、メッセージのＳＭｓｇタイプ・ヘッダ内のＩｎｓｔｒ
ｕｃｔｉｏｎエレメントにサブエレメントＣｒｅａｔｅＢＢＬ（ＢＢＬ作成）を
挿入し、これはタイトル・レジストリに対して新規の電子船荷証券を作成するこ
とを指令する。オリジネータは、ＣｒｅａｔｅＢＢＬエレメント内に、以下のよ
うな多くのパラメータを指定する。

【０２９１】 （ａ）オリジネータは、付属するｅＢＬテキストの文書ＩＤを供給する。 （ｂ）オリジネータは、新規の電子船荷証券を「譲渡可」（すなわち第４．３
．２項に記載のように譲渡可である）であるか、または「譲渡不可」（第４．３
．２項に記載のように譲渡不可である）であるかを示す。タイトル・レジストリ
は、譲渡性のこのような表示（インジケータ）を、電子船荷証券に対して指定さ
れた役割と対照してチェックし、役割の指定が証券の「譲渡可」または「譲渡不
可」のリストと合致するか否かを判定する。

【０２９２】 （ｃ）オリジネータはまた、何れのユーザがメッセージを送信し、その電子船
荷証券を作成するのかを示すために、自身のユーザ識別名（identifier、識別子
）を含んでいる。

【０２９３】 （ｄ）オリジネータはまた、オリジネータは代理人が証券の引き渡し時に代理
として行動をとることを認可する意思があるか否かに応じて、引渡側を指定して
もよい。

【０２９４】 （ｅ）オリジネータは新規の電子船荷証券の荷主のユーザ識別名を指定する。 （ｆ）オリジネータはまた、新規の証券の当初ホールダーを指定する。 （ｇ）オリジネータは、荷受側または指図側のいずれかを指定してもよく、ま
た、オリジネータは新規の証券に白地裏書きすることによって、そのホールダー
を持参人ホールダーにしてもよい。指図側が指定されるか、または証券に白地裏
書きがなされた場合は、命令は証券が「譲渡可」であることも示さなければなら
ない。荷受側が指定された場合は、命令は証券を「譲渡不可」とすることも示さ
なければならない。

【０２９５】 （３）オリジネータは、船荷証券のテキストとして、すなわちｅＢＬテキスト
として機能すべき文書をメッセージ内に含める（または「添付」する）。この文
書は、文書ＩＤを有していなければならず、また、上記の第２．３項に示した、
一意性を含む他の要件を満たすものでなければならない。タイトル・レジストリ
はこの文書を適切な文書保持スケジュールの指定通りに記憶する。一般に、紙で
の単一の船荷証券の複数の副本を交付する実践との類推により、同じ文書の複数
の実例を添付することは不要である。電子船荷証券を見てこれを変更する必要が
あるユーザは全てそのようにすることができるので、ユーザは、複数のコピーに
伴う混乱と議論に先んずることができる。

【０２９６】 （４）次にオリジネータは、ｅＢＬテキストおよび当初の役割指定を含むメッ
セージにデジタル的にサインし、そのメッセージをメッセージ・ハンドリング・
ユニットへ送信する。

【０２９７】 （５）何れのＳＭｓｇメッセージに関しても、メッセージ・ハンドリング・ユ
ニットは、メッセージに関して、メッセージ上のオリジネータによるデジタル・
サインの照合を通じての真正性のチェックを含めての、メッセージの妥当性の要
件に合致するか否かのチェックを行う。タイトル・レジストリおよび／またはメ
ッセージ・ハンドリング・ユニットはさらに、メッセージの形式もチェックする
。デジタル・サインを照合できない場合、またはメッセージ内に他の何らかの欠
陥が検知された場合は、メッセージ・ハンドリング・ユニットはオリジネータに
ＢＮａｋを返信する。

【０２９８】 （６）メッセージが技術的に妥当であり、サインされていることが確認される
と、これはデコードされ、メッセージに含まれるｅＢＬテキストが記憶される。 （７）メッセージがサインされ、技術的に妥当であることをタイトル・レジス
トリとメッセージ・ハンドリング・ユニットとが確認すると、新規の電子船荷証
券のレコードがタイトル・レジストリ内で作成され、オリジネータによって指定
された当初の役割がそのレコードに入力される。

【０２９９】 （８）タイトル・レジストリは、メッセージ・ハンドリング・ユニットを介し
てＦＭｓｇタイプ・ヘッダを有するメッセージを荷主と新規の電子船荷証券のホ
ールダーとに送信し、また、引渡側が指定されている場合は引渡側へ送信する。
このメッセージは、新規の電子船荷証券の作成、および新規の電子船荷証券の関
連するユーザの指定に付随する権利および義務を通知する役割を果たす。

【０３００】 （９）次にタイトル・レジストリは、メッセージ・ハンドリング・ユニットを
介してＢＡｃｋタイプ・ヘッダを有するメッセージを新規の電子船荷証券を作成
したオリジネータへ返信することによって、電子船荷証券の作成が成功したこと
を確認する。そのタイプ・ヘッダは、タイトル・レジストリからの、これが実行
したアクションの報告を含んでいる。

【０３０１】 電子船荷証券が一旦作成されると、これは新規のレコードがタイトル・レジス
トリ内に作成されることから始まって、第４．３．１項に記載のように使用可能
(active、アクティブ)になる。

【０３０２】 電子船荷証券の作成時にタイトル・レジストリに入力された、ｅＢＬテキスト
および指定を含む情報は全てタイトル・レジストリ内に残され、認可されたユー
ザは、適用可能な保持スケジュールで指定された期間中、これを利用できる。新
規の電子船荷証券の入力もメッセージの流れの日付順のログに記入され、そのロ
グは適用可能な保持スケジュールに指定された通りに保持される。

【０３０３】 ４．４．３． アクティブな電子船荷証券の譲渡 電子船荷証券の譲渡は、権利および義務を一方のユーザから他のユーザへと移
す。ユーザは役割フィールド内に他のユーザを指定することで譲渡を行う。本シ
ステムは紙の船荷証券での従来の実践に基づいて４種類の譲渡を認識する。すな
わち、一人のホールダーによる後継の者への譲渡、荷受側への譲渡、指図側への
譲渡、および白地裏書きによる持参人ホールダーへの譲渡である。

【０３０４】 一人のホールダーにより後継の者に譲渡する場合、ホールダーの権利の譲渡は
、それがあたかも有形のものであるかのように、船荷証券の物理的な所有権の譲
渡と類似している。この譲渡は、現時点のホールダーが後継の者を指定すること
を含む。

【０３０５】 荷受側への譲渡の場合、この譲渡は紙の船荷証券を「記名式」もしくは「譲渡
不可」にする場合と同様である。荷受側のある電子船荷証券は、指図側へは譲渡
不可であり、または白地裏書きが不可能である。荷受側は、ホールダーでもある
場合は、電子船荷証券を引き渡し、商品を配達することができる。

【０３０６】 指図側への譲渡の場合、これが新規の電子船荷証券を作成するオリジネータに
よって行われる場合、指図側を指定することは、指定人の指図に対して譲渡可の
紙の船荷証券を交付し、これをホールダー（恐らくは荷主）に渡すことと同様で
ある。指図側がホールダーを兼ねていないかぎり、即ち指図側ホールダーではな
い限り、その権限は極めて限られる。既存の指図側ホールダーまたは持参人ホー
ルダーが指図側ホールダーを指定した場合、その効力は指定された被裏書人に対
して船荷証券を裏書きすることと類似している。

【０３０７】 白地裏書きによって持参人ホールダーに譲渡する場合、白地裏書きは、電子船
荷証券が白地裏書きのものであることを示し、既存の指図側を削除する。電子船
荷証券は、単にホールダーを変更することで譲渡可の証券に留まる。このように
、これは持参人により譲渡可の紙の証券と類似している。

【０３０８】 次に、アクティブな電子船荷証券の上記の譲渡を詳細に検討する。安全保護の
目的のための利害関係(interest)の譲渡である、電子船荷証券の抵当は、第４．
４．４項で検討する。

【０３０９】 ４．４．３．１．ホールダーの指定 第４．２．８項で説明したように、ホールダーは、電子船荷証券があたかも有
形の文書であるかのように、電子船荷証券を物理的に所持する者と類似している
。従って、ホールダーは、電子船荷証券が紙に切り換えられた場合に、紙の船荷
証券を受領する権限を有する者である。さらに、第４．４．３．４項に記載する
ように証券が白地裏書きされた場合は、そのホールダーは第４．２．６項に記載
の持参人ホールダーである。このように、白地裏書きされていない証券の新規の
ホールダーの指定は、紙への切換えが行われた場合に、それ以降に誰が紙の証券
を受領するかを示すものである。しかし、証券が白地裏書きされている場合は、
ホールダーを指定することは持参人ホールダーの指定と同義である。

【０３１０】 当初ホールダーは、電子船荷証券の作成時に指定される。その後、証券には常
にホールダーがいる。なぜなら、タイトル・レジストリはホールダー役割フィー
ルド内のユーザー識別子を代替できるのみであるからである。タイトル・レジス
トリのコンテンツを空にしない。

【０３１１】 ホールダーを指定する命令は、指図側の指定、荷受側の指定、または電子船荷
証券の白地裏書きする命令の何れかと組合わせてもよい。これは常に抵当権者の
指定と自動的に組合わされるので、抵当権者として指定されたユーザは常にホー
ルダーとしても指定される。抵当権者をホールダーとして指定することは自動的
に行われ、タイトル・レジストリ命令に含める必要はない。

【０３１２】 オペレーション規則１４： ホールダーの指定 電子船荷証券の新規のホールダーを指定するには、その電子船荷証券の現ホー
ルダーは、 （ａ）その電子船荷証券の新規のホールダーを指定するタイトル・レジストリ
命令を完成し、 （ｂ）文書形式でその電子船荷証券のｅＢＬテキストを添付し、 （ｃ）メッセージ（その命令およびｅＢＬテキストを含む）にサインし、これ
をメッセージ・ハンドリング・ユニットを介してタイトル・レジストリへ送信す
る、 ものとする。

【０３１３】 本項の残りの部分は上記オペレーション規則に対する注釈を記載する。 ユーザが電子船荷証券の現ホールダーであるか、または新規の電子船荷証券を
作成するオリジネータである場合に限り、ユーザはホールダーを指定することが
できる。

【０３１４】 ホールダーは、電子船荷証券が第４．３．１項に記載のようにアクティブであ
る場合に限り、新規のホールダーを指定できる。さらに、電子船荷証券に抵当権
が設定された場合は、ホールダーは、指定者が抵当権者でもあり、ホールダーを
指定したユーザが同時に抵当権者として指定される場合に限り、新規のホールダ
ーを指定できる。オリジネータは、電子船荷証券の作成時に限りホールダーを指
定できる。

【０３１５】 図１８が示すように、新規のホールダーの指定には以下のプロセスが含まれる
。 （１）ユーザ・システムを利用して、適宜のユーザがメッセージ・ハンドリン
グ・ユニットへのメッセージを作成する。

【０３１６】 （２）次に、メッセージ・タイプ・ヘッダのＩｎｓｔｒｕｃｔｉｏｎエレメン
ト内の適宜のタグ内に、新規のホールダーのユーザ識別子をリストすることによ
って、作成メッセージに新規ホールダーをユーザが指定することにより、ユーザ
識別子がタグされる。その際に、該当する証券の文書ＩＤのようなその他のタグ
されるデータも必要である。

【０３１７】 （３）次にユーザは、新規のホールダーの指定を含むメッセージにデジタル・
サインし、メッセージをメッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側のデジタル・サインを照合することによってメッセージの真正性をチェ
ックする。メッセージ・ハンドリング・ユニットおよび／またはタイトル・レジ
ストリはさらにメッセージの形式もチェックする。メッセージ・ハンドリング・
ユニットおよびタイトル・レジストリがデジタル・サインを適正に確認できない
か、またはメッセージの形式が適正であることを確認できない場合、メッセージ
・ハンドリング・ユニットはＢＮａｋを返信する。

【０３１８】 （５）送信側のデジタル・サインが確認され、メッセージが妥当であることが
判明すると、タイトル・レジストリは、ホールダー役割フィールドのコンテンツ
をメッセージ・タイプ・ヘッダにリストされた新規のホールダーのユーザ識別子
へと変更することによって、更新される。以前のホールダーのユーザ識別子はそ
の証券のタイトル・レジストリ・レコードから削除される。

【０３１９】 （６）次にタイトル・レジストリは、メッセージ・ハンドリング・ユニットを
介して送信側ユーザへ、ＢＡｃｋタイプ・ヘッダを有するＤＮｏｔメッセージを
返信することによって、新規のホールダーの指定に成功したことを確認する。そ
のタイプ・ヘッダは、タイトル・レジストリからの、それが実行したアクション
の報告を含んでいる。

【０３２０】 タイトル・レジストリは新規に指定されたホールダーにその指定を通知する。 新規のホールダーの指定は、一般に、電子船荷証券の状態に影響を及ぼさない
。しかし、証券作成の一部として指定が行われた場合は、作成プロセスの完了に
よって証券はアクティブ状態に留まる。

【０３２１】 ホールダーの指定を含むタイトル・レジストリ・レコードは、タイトル・レジ
ストリ内に残り、適用可能な保持スケジュールで指定された期間、認可されたユ
ーザが利用できる。指定を行うタイトル・レジストリ命令もメッセージの流れの
日付順のログに記録され、そのログは適用可能な保持スケジュールで指定された
期間だけ保存される。

【０３２２】 ４．４．３．２．荷受側の指定 第４．２．４項に説明するように、電子船荷証券の荷受側は、従来の譲渡不可
の船荷証券の荷受側と類似である。荷受側の指定によって電子船荷証券はその時
点から譲渡不可になる。荷受側の指定は、通常は、電子船荷証券の継続期間中に
一度だけ行われるので、荷受側役割フィールドが一旦記入されると、その内容は
変更されないままに留まる。

【０３２３】 オペレーション規則１５： 荷受側の指定 Ａ．オリジネータは電子船荷証券を作成する際に荷受側を指定できる（オペレ
ーション規則１３を参照）。

【０３２４】 Ｂ．荷受側を指定するには、電子船荷証券のプレッジー・ホールダー、持参人
ホールダー、または指図側ホールダーは、 （ａ）その電子船荷証券の荷受側を指定するタイトル・レジストリ命令を完成
させ、 （ｂ）タイトル・レジストリ命令を含むメッセージにサインし、これをメッセ
ージ・ハンドリング・ユニットを介してタイトル・レジストリへ送信する、 ものとする。

【０３２５】 オペレーション規則１６： 荷受側ホールダーの指定 荷受側ホールダーを指定するには、電子船荷証券のホールダーはオペレーショ
ン規則１４および１５で要求されている手順を実行するものとする。同じユーザ
を荷受側とホールダーの双方に指定するタイトル・レジストリ命令は、同じメッ
セージ内に送信してもよい。

【０３２６】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 オリジネータは、電子船荷証券の作成時に荷受側を指定してもよいが、本シス
テムがオリジネータに対して証券の作成に成功した旨を通知するアクノレッジメ
ントを返信した後では荷受側を指定できない。電子船荷証券の現時点の指図側ホ
ールダーまたは持参人ホールダーも荷受側を指定できる。

【０３２７】 前述のように、オリジネータは電子船荷証券をその荷請け人を指定するように
作成しなければならない。証券が使用可能（アクティブ）であり譲渡可である場
合に限り、現時点の指図側ホールダー、または持参人ホールダーは荷受側を指定
できる。

【０３２８】 図１９が示すように、荷受側を指定するには以下のステップが実行される。 （１）適宜のユーザはメッセージ・ハンドリング・ユニットへのメッセージを
作成する。

【０３２９】 （２）メッセージ・タイプ・ヘッダのＩｎｓｔｒｕｃｔｉｏｎエレメント内の
適宜のタグ内に新規の荷受側のユーザ識別子をリストすることによって、ユーザ
はそのメッセージ内に荷受側を指定する。該当する証券の文書ＩＤおよび証券が
「譲渡不可」である旨の指示のような、その他のタグされた情報も必要である。

【０３３０】 （３）次にユーザは荷受側の指定を含むメッセージにデジタル・サインし、こ
のメッセージをメッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
送信側のデジタル・サインを照合することによってメッセージの真正性をチェッ
クする。メッセージ・ハンドリング・ユニットおよび／またはタイトル・レジス
トリはまた、メッセージの形式もチェックする。メッセージ・ハンドリング・ユ
ニットおよび／またはタイトル・レジストリがデジタル・サインを適正に確認で
きないか、またはメッセージの形式が適正でないことを発見した場合、ＢＮａｋ
を返信する。

【０３３１】 （５）送信側のデジタル・サインが確認され、メッセージが妥当であることが
判明すると、タイトル・レジストリは、荷受側役割フィールドのコンテンツを空
欄から、メッセージ・タイプ・ヘッダにリストされた新規の荷受側のユーザ識別
子へと変更する。

【０３３２】 （６）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して送信側ユーザへＢＡｃｋタイプ・ヘッダを有するＤＮｏｔメッセージを
返信することによって、荷受側の指定に成功したことを確認する。そのタイプ・
ヘッダは、タイトル・レジストリからの、それが実行したアクションの報告を含
んでいる。

【０３３３】 タイトル・レジストリは新規の荷受側にその指定を通知する。荷受側が現ホー
ルダーを兼ねている場合は（恐らくは、荷受側の指定を行うメッセージと同じメ
ッセージを介して）、通知には以下のテキスト通知が含まれる。「あなたは規則
書に従って本電子船荷証券のホールダーに指定されました。本電子船荷証券のホ
ールダーとしてのあなたの権限によって、あなたを指図側、荷受側、持参人、ま
たは抵当権者として指定することに加えて、当方（サービス・プロバイダ）は本
電子船荷証券のオリジネータ（輸送業者）に代わって、商品が現在あなたの指図
下にあることを認めます」。

【０３３４】 さらに、新規の荷受側がホールダーをも兼ねている場合は、指定されたユーザ
が証券に関して他の何らかのアクションを起こす前にＳＢＲｆメッセージが送信
されることを条件として、タイトル・レジストリ・レコードが新規の指定で更新
された時点から始まる２４時間のタイムアウト期限内に、ＳＢＲｆ形式のヘッダ
を有するメッセージをタイトル・レジストリへ返信することによって、荷受側は
指定を覆してもよい。あるいは、荷受側はＵＡｃｋを返信するか、タイムアウト
期限を満了させるか、またはＳＢＲｆの返信以外の証券に関するアクションを起
こすことによって、指定を受け入れてもよい。

【０３３５】 荷受側の指定によって、電子船荷証券は、タイトル・レジストリの更新時点か
ら譲渡不可になる。 荷受側の指定を含むタイトル・レジストリ・レコードはタイトル・レジストリ
内に留まり、適用可能な保持スケジュールで指定された期間だけ、認可されたユ
ーザが利用できる。指定を行うタイトル・レジストリ命令もメッセージの流れの
日付順のログにレコードされ、このログは適用可能な保持スケジュールで指定さ
れた期間だけ保存される。

【０３３６】 ４．４．３．３．指図側の指定 第４．２．５項に説明するように、電子船荷証券の指図側は、従来の船荷証券
の被裏書人と類似である。被裏書人と同様に、指図側が証券を所持もしている場
合、指図側はこの証券をさらに譲渡することができる。電子船荷証券の場合、指
図するための裏書きに類似するプロセスは、後継の指図側およびホールダー（す
なわち指図側ホールダー)を指定することからなる。

【０３３７】 オペレーション規則１７： 指図側の指定 Ａ．オリジネータは電子船荷証券を作成する際に指図側を指定できる（オペレ
ーション規則１３を参照）。

【０３３８】 Ｂ．指図側を指定するには、電子船荷証券のプレッジー・ホールダー、持参人
ホールダー、または指図側ホールダーは、 （ａ）その電子船荷証券に対する指図側を指定するタイトル・レジストリ命令
を完成させ、かつ、 （ｂ）そのタイトル・レジストリ命令を含むメッセージにサインし、これをメ
ッセージ・ハンドリング・ユニットを介してタイトル・レジストリに送信する、
ものとする。

【０３３９】 オペレーション規則１８： 指図側ホールダーの指定 指図側ホールダーを指定するには、電子船荷証券のプレッジー・ホールダー、
持参人ホールダー、または既存の指図側ホールダーは、オペレーション規則１４
および１７で要求されている手順を実行するものとする。同じユーザを指図側と
ホールダーの双方として指定するタイトル・レジストリ命令は、同じメッセージ
内に送信してもよい。

【０３４０】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 オリジネータは、電子船荷証券の作成時に指図側を指定してもよいが、本タイ
トル・レジストリがオリジネータに対して証券の作成に成功した旨を通知するア
クノレッジメントをメッセージ・ハンドリング・ユニットを介して返信した後で
は、指図側を指定できない。電子船荷証券の現持参人ホールダーも荷受側を指定
できる。一つの指図側はまた、指定する指図側がホールダーでもある場合（すな
わち指図側ホールダー）は、後継の指図側を指定できる。

【０３４１】 前述のように、オリジネータは電子船荷証券をその指図側を指定するように作
成しなければならない。電子船荷証券がアクティブであり譲渡可である場合に限
り、現時点の持参人ホールダーまたは指図側ホールダーは指図側を指定できる。

【０３４２】 図２０は、以下のステップを有する、指図側を指定するプロセスを示す。 （１）適宜のユーザはメッセージ・ハンドリング・ユニットへのメッセージを
作成する。

【０３４３】 （２）メッセージ・タイプ・ヘッダのＩｎｓｔｒｕｃｔｉｏｎエレメント内の
適宜のタグ内に新規の指図側のユーザ識別子をリストすることによって、ユーザ
はそのメッセージにおいて、指図側を指定する。その際に、該当する証券の文書
ＩＤおよび電子船荷証券が「譲渡可」である旨の表示のような、その他のタグさ
れる情報も必要である。

【０３４４】 （３）次に、ユーザは、指図側の指定を含むメッセージにデジタル・サインし
、このメッセージをメッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側のデジタル・サインを照合することによって、メッセージの真正性をチ
ェックする。メッセージ・ハンドリング・ユニットおよび／またはタイトル・レ
ジストリはさらにメッセージの形式もチェックする。メッセージ・ハンドリング
・ユニットまたはタイトル・レジストリがデジタル・サインを適正に確認できな
いか、またはメッセージの形式が適正ではないことを見つけた場合、ＢＮａｋが
返信される。

【０３４５】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが、
送信側のデジタル・サインを適用に確認し、且つメッセージが妥当であると判明
すると、タイトル・レジストリは、指図側役割フィールドのコンテンツを、メッ
セージ・タイプ・ヘッダにリストされた新規の指図側のユーザ識別子へと変更す
る。以前の指図側のユーザ識別子は、その証書に対するタイトル・レジストリ・
レコードから除かれる。

【０３４６】 （６）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して送信側へ、ＢＡｃｋタイプ・ヘッダを有するＤＮｏｔメッセージを返信
することによって、新規の指図側の指定に成功したことを確認する。そのタイプ
・ヘッダは、タイトル・レジストリからの、それが実行したアクションの報告を
含んでいる。

【０３４７】 タイトル・レジストリは、新規の指図側にその指定を通知する。新規に指定さ
れた指図側が現ホールダーを兼ねている場合（恐らくは、指図側の指定を行うメ
ッセージと同じメッセージを介して）、通知には以下のテキスト通知が含まれる
。「あなたは規則書に従って本電子船荷証券のホールダーに指定されました。本
電子船荷証券のホールダーとしてのあなたの権限によって、あなたを指図側、荷
受側、持参人、または抵当権者として指定することに加えて、当方（システム・
サービス・プロバイダ）は本電子船荷証券のオリジネータ（輸送業者）に代わっ
て、商品が現在あなたの指図下にあることを認めます」。さらに、新規の指図側
がホールダーをも兼ねている場合、指図側は、指定されたユーザが証券に関して
他の何らかのアクションを起こす前にＳＢＲｆメッセージが送信されることを条
件として、タイトル・レジストリ・レコードが新規の指定で更新された時点から
始まる２４時間のタイムアウト期限内に、ＳＢＲｆ形式のタイプ・ヘッダを有す
るメッセージをタイトル・レジストリへ返信することによって、指定を覆しても
よい。あるいは、指図側はＵＡｃｋを返信するか、タイムアウト期限を満了させ
るか、またはＳＢＲｆの返信以外の証券に関するアクションを起こすことによっ
て、指定を受け入れてもよい。

【０３４８】 現在誰も指定されていないときに指図側を指定することは、証券を、後継の指
図側を指定することによって、タイトル・レジストリの更新時点から譲渡可にす
る。１つの指図側が後継の指図側を指定する場合、証券は譲渡可に留り、譲渡は
、タイトル・レジストリの更新時点からその後継人に限り可能である。

【０３４９】 指図側の指定を含むタイトル・レジストリ・レコードはタイトル・レジストリ
内に留まり、適用可能な保持スケジュールで指定された期間だけ、認可されたユ
ーザが利用できる。指定を行うタイトル・レジストリ命令もまたメッセージの流
れの日付順のログに記録され、このログは適用可能な保持スケジュールで指定さ
れた期間だけ保存される。

【０３５０】 ４．４．３．４．持参人ホールダーの白地裏書きおよび指定 電子船荷証券が持参人ホールダーによって既に譲渡可ではない場合、そのため
に持参人ホールダーを作ることは、証券を白地裏書きとすることを含む。白地裏
書きは、電子船荷証券をタイトル・レジストリ内で白地裏書きされたものとして
フラグを立てることを含み、これは、その時点でホールダーを持参人ホールダー
にする効力を有している。新規の持参人ホールダーは、その後、第４．４．３．
１項に記載するようにホールダーを単に変更することによって、証券を譲渡して
もよい。言い換えると、持参人ホールダーとは白地裏書きされた電子船荷証券の
ホールダーのことである。

【０３５１】 新規のホールダーの指定については第４．４．３．１項で既に触れた。本項で
は電子船荷証券の白地裏書きに焦点をあてて記載する。 オペレーション規則１９： 電子船荷証券の白地裏書き Ａ．オリジネータは電子船荷証券を作成する際にこれに白地裏書きできる（オ
ペレーション規則１３を参照）。

【０３５２】 Ｂ．電子船荷証券に白地裏書きするには、電子船荷証券の指図側ホールダーは
、 （ａ）その電子船荷証券に白地裏書きするタイトル・レジストリ命令を完成さ
せ（注： 指図側の指定は、この命令の処理によりタイトル・レジストリによっ
て自動的に除かれる）、 （ｂ）そのタイトル・レジストリ命令を含むメッセージにサインし、これをメ
ッセージ・ハンドリング・ユニットを介してタイトル・レジストリに送信する ものとする。

【０３５３】 オペレーション規則２０： 白地裏書きによって持参人ホールダーになる Ａ．電子船荷証券のホールダーは、白地裏書きを行う命令がタイトル・レジス
トリ・レコードに入力されると、その証券の持参人ホールダーになる。

【０３５４】 Ｂ．指図側ホールダーは、白地裏書きを行う命令と同じメッセージ内の命令に
よって、新規のホールダーを指定できる。新規に指定されたホールダーは、新規
の白地裏書きされた電子船荷証券の持参人ホールダーになる。

【０３５５】 オペレーション規則２１： 持参人ホールダーによる譲渡 持参人ホールダー（白地裏書きされた電子船荷証券のホールダー）は、新規の
ホールダーの指定に関するオペレーション規則１４で要求される手順によって、
新規の持参人ホールダーを指定できる。

【０３５６】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 電子船荷証券を作成するオリジネータ、または現時点の指図側ホールダーだけ
が、電子船荷証券に白地裏書きできる。

【０３５７】 電子船荷証券は、それがアクティブであり、譲渡可であり、抵当権が設定され
ていな場合に限り、白地裏書きできる。 本項で前述したように、白地裏書き証券のある持参人ホールダーが他の者を指
定するには、持参人ホールダーは単に、第４．４．３．１項に記載のように新規
のホールダーを指定する。

【０３５８】 持参人ホールダーが既に存在していない場合に持参人ホールダーを作るには、
証券の現時点の指図側ホールダーがこれに白地裏書きする。 図２１は電子船荷証券に白地裏書きするプロセスを示し、以下にそのオペレー
ションを記載する。

【０３５９】 （１）適宜のユーザはメッセージ・ハンドリング・ユニットへ発信するメッセ
ージを作成する。 （２）そのメッセージに、ユーザは、メッセージ・タイプ・ヘッダのＩｎｓｔ
ｒｕｃｔｉｏｎエレメントのＢｌａｎｋＥｎｄｏｒｓｅ（ブランク・エンドース
）タグの形式の白地裏書インジケータを含める。該当する証券の文書ＩＤ、およ
び電子船荷証券が「譲渡可」である旨の指示のような、その他のタグされる情報
も必要である。

【０３６０】 （３）次にユーザはＢｌａｎｋＥｎｄｏｒｓｅタグを含むメッセージにデジタ
ル・サインし、このメッセージをメッセージ・ハンドリング・ユニットに送信す
る。

【０３６１】 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側のデジタル・サインを照合することによって、メッセージの真正性をチ
ェックする。メッセージ・ハンドリング・ユニットおよび／またはタイトル・レ
ジストリはさらにメッセージの形式もチェックする。メッセージ・ハンドリング
・ユニットまたはタイトル・レジストリがデジタル・サインを適正に確認できな
いか、またはメッセージの形式が適正ではないことを発見した場合は、ＢＮａｋ
が返信される。

【０３６２】 （５）送信側のデジタル・サインが適正に確認され、メッセージが妥当である
ことが判明すると、タイトル・レジストリは、電子船荷証券を白地裏書きされた
ものとしてマークし、指図側役割フィールドのコンテンツを空欄に変更する。

【０３６３】 （６）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して、送信側へＢＡｃｋタイプ・ヘッダを有するＤＮｏｔメッセージを返信
することによって、白地裏書きに成功したことを確認する。そのタイプ・ヘッダ
は、タイトル・レジストリからの、それが実行したアクションの報告を含んでい
る。

【０３６４】 新規の持参人ホールダーにはＦＭｓｇメッセージ内の下記のテキストによって
通知がなされる。「あなたは規則書に従って本電子船荷証券のホールダーに指定
されました。本電子船荷証券のホールダーとしてのあなたの権限によって、あな
たを指図側、荷受側、持参人、または抵当権者として指定することに加えて、当
方（システム・サービス・プロバイダ）は本電子船荷証券のオリジネータ（輸送
業者）に代わって、商品が現在あなたの指図下にあることを認めます」。

【０３６５】 新規の持参人ホールダーは、指定されたユーザが証券に関して他の何らかのア
クションを起こす前にＳＢＲｆメッセージが送信されることを条件として、タイ
トル・レジストリ・レコードが新規の指定で更新された時点から始まる２４時間
のタイムアウト期限内に、ＳＢＲｆ形式のヘッダを有するメッセージをタイトル
・レジストリに返信することによって、指定を覆してもよい。あるいは、持参人
ホールダーは、ＵＡｃｋを返信するか、タイムアウト期限を満了させるか、また
はＳＢＲｆの返信以外の証券に関するアクションを起こすことによって、指定を
受け入れてもよい。

【０３６６】 電子船荷証券の白地裏書きによって、証券は持参人ホールダーにより譲渡可に
なる。 白地裏書きを含むタイトル・レジストリ・レコードはタイトル・レジストリ内
に留まり、適用可能な保持スケジュールで指定された期間だけ、認可ユーザが利
用できる。指定を行うタイトル・レジストリ命令も、メッセージの流れの日付順
のログに記録され、このログは、適用可能な保持スケジュールで指定された期間
だけ保存される。

【０３６７】 ４．４．４．抵当権（質権）の取引き 抵当権の取引きは船荷証券に関与する金融機関の活動を反映するものである。
３つの主要な抵当権の取引き、すなわち抵当権者の指定、抵当権の放棄、および
抵当権の執行である。

【０３６８】 抵当権者の指定に関しては、現時点の指図側ホールダーまたは持参人ホールダ
ーが抵当権者を指定すると、それはユーザ識別子を電子船荷証券の抵当権者役割
フィールドに入力する。それによって証券は抵当権設定状態に転換し、ひいては
、第４．３．２項に記載したように、証券に抵当権が設定されている間、指図側
または持参人ホールダーの通常の権限が一時中断される。電子船荷証券に当初抵
当権者を指定することは、従来の船荷証券を荷為替信用状のための一種の安全保
護として銀行へ渡すことと類似である。抵当権者が一旦指定されると、それは後
継の者を指定することもできる。

【０３６９】 抵当権の放棄に関しては、証券を抵当権設定状態から通常の譲渡可能な状態に
戻すために、抵当権者は抵当権者役割フィールドからそのユーザＩＤを削除する
。このような削除は抵当権の放棄を意味する。

【０３７０】 抵当権の執行に関しては、抵当権者が抵当権によって示されるその安全保護の
権利を行使しなければならない場合に、抵当権者は、指図側が既に指定されてい
る場合は、自らを現時点の指図側ホールダーとして指定し、また、電子船荷証券
が既に白地裏書きされている場合は持参人ホールダーとして指定する。抵当権者
によるこの二重指定を「抵当権の行使」と称する。

【０３７１】 以下では、これらの取引きをより詳細に説明する。 ４．４．４．１．プレッジー・ホールダーの指定 抵当権者の指定には常にホールダーの指定が含まれる。当該の電子船荷証券の
抵当権者役割フィールドへユーザ識別子を入力することによって新規の抵当権者
が指定されると、タイトル・レジストリはまた、ユーザ識別子をホールダー役割
フィールドに入力する。本項はこのような二段階のプロセスをより詳細に説明す
る。

【０３７２】 オペレーション規則２２： プレッジー・ホールダーの指定 ホールダーが電子船荷証券のプレッジー・ホールダーを指定するには（または
、プレッジー・ホールダーが自らをプレッジー・ホールダーとして復位するには
）、その証券のホールダーは、 （ａ）その電子船荷証券のプレッジー・ホールダーを指定するタイトル・レジ
ストリ命令を完成させ、かつ、 （ｂ）文書形式の電子船荷証券のｅＢＬテキストを添付し、 （ｃ）その命令およびｅＢＬテキストを含むメッセージにサインし、これをメ
ッセージ・ハンドリング・ユニットを介してタイトル・レジストリに送信する。

【０３７３】 本項の残りの部分ではこのオペレーション規則を注釈する。 現ホールダー（持参人ホールダー、指図側ホールダー、またはプレッジー・ホ
ールダーを含む）は抵当権者を指定することができる。電子船荷証券に抵当権が
設定されている場合、そのホールダーは必然的にその抵当権者であり、プレッジ
ー・ホールダーは証券を譲渡してもよい。

【０３７４】 抵当権者は、証券がアクティブであり譲渡可である場合は、電子船荷証券用に
対して指定されることができる。 図２２が示すように、抵当権者（質権者）の指定には以下のステップが含まれ
る。

【０３７５】 （１）適宜のユーザがメッセージ・ハンドリング・ユニットへのメッセージを
作成する。 （２）メッセージ・タイプ・ヘッダのＩｎｓｔｒｕｃｔｉｏｎエレメントの適
宜のタグ内に新規の抵当権者のユーザ識別子をリストすることによって、ユーザ
はそのメッセージ内に抵当権者を指定する。その際に、該当する証券の文書ＩＤ
のような、その他のタグされる情報も必要である。

【０３７６】 （３）次に、ユーザは抵当権者の指定を含むメッセージにデジタル・サインし
、このメッセージをメッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側のデジタル・サインを照合することによって、メッセージの真正性をチ
ェックする。メッセージ・ハンドリング・ユニットおよびタイトル・レジストリ
はさらにメッセージの形式もチェックする。メッセージ・ハンドリング・ユニッ
トまたはタイトル・レジストリがデジタル・サインを適正に確認できないか、ま
たはメッセージの形式が不適正であると判断した場合は、ＢＮａｋが返信される
。

【０３７７】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを適正に照合し、メッセージが妥当であることが判明す
ると、タイトル・レジストリは、抵当権者役割フィールドのコンテンツを、メッ
セージ・タイプ・ヘッダ内にリストされた新規の抵当権者のユーザ識別子へと変
更する。以前の抵当権者のユーザ識別子は、その証券のタイトル・レジストリ・
レコードから除かれる。さらに、タイトル・レジストリは、また、新規の抵当権
者のユーザ識別子を、ホールダー役割フィールドに、そこにあったユーザ識別子
に代えて入力する。

【０３７８】 （６）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して、送信側へＢＡｃｋタイプ・ヘッダを有するＤＮｏｔメッセージを返信
することによって、新規の抵当権者の指定に成功したことを確認する。そのタイ
プ・ヘッダは、タイトル・レジストリからの、それが実行したアクションの報告
を含んでいる。

【０３７９】 タイトル・レジストリはこうして新規のプレッジー・ホールダーにその指定を
通知する。 抵当権者の指定によって、電子船荷証券は、タイトル・レジストリの更新時点
から、第４．３．２項に記載のように抵当権が設定された証券になる。

【０３８０】 新規の抵当権者の指定を含むタイトル・レジストリ・レコードはタイトル・レ
ジストリ内に留まり、適用可能な保持スケジュールに規定の期間だけ、認可され
たユーザが利用できる。指定を行うタイトル・レジストリ命令も、メッセージの
流れの日付順のログに記録され、このログは適用可能な保持スケジュールで指定
された期間だけ保存される。

【０３８１】 ４．４．４．２． 抵当権の放棄 抵当権の放棄は、現時点の抵当権者のユーザ識別子を抵当権者役割フィールド
から削除し、それによって証券を抵当権設定状態から譲渡可の状態に復帰させる
効力を有する。本項は放棄のプロセスを詳細に説明する。

【０３８２】 オペレーション規則２３： 抵当権の放棄 電子船荷証券の抵当権を放棄するには（オペレーション規則２４に規定されて
いるように後継のプレッジー・ホールダーを記名することによる以外に）、プレ
ッジー・ホールダーは、 （ａ）タイトル・レジストリ命令であって、 （１）抵当権者としてのその指定を取り除くこと、 （２）オペレーション規則１４で要求されているように、新規のホールダ
ーを指定する タイトル・レジストリ命令を完成させ、 （ｂ）文書形式のその電子船荷証券のｅＢＬテキストを添付し、 （ｃ）そのタイトル・レジストリ命令およびｅＢＬテキストを含むメッセージ
にサインし、これをメッセージ・ハンドリング・ユニットを介してタイトル・レ
ジストリに送信する ものとする。

【０３８３】 図２３は抵当権を放棄するプロセスを示したフローチャートである。本項の残
りの部分ではこのオペレーション規則に注釈を加える。 現プレッジー・ホールダーのみが電子船荷証券の抵当権を放棄できる。オリジ
ネータは、証券の作成時に（またはその他の状況で）、持参人ホールダーを指定
することができない。むしろ、証券を譲渡可にするならば、オリジネータは指図
側（多くの場合は荷主）を指定し、この指図側はその後にその証券を白地裏書で
きる。

【０３８４】 明らかであるが、抵当権者が抵当権を放棄するには、電子船荷証券は抵当権設
定状態になければならない。 抵当権の放棄は、抵当権者が指定されていないように、その抵当権者役割フィ
ールドを空欄にすることで行われる。これは以下のステップによって実施される
。

【０３８５】 （１）現時点の抵当権者がメッセージ・ハンドリング・ユニットへのメッセー
ジを作成する。 （２）このメッセージ内で、現抵当権者は、メッセージ・タイプ・ヘッダのＩ
ｎｓｔｒｕｃｔｉｏｎエレメント内にＲｅｌｉｎｑｕｉｓｈＰｌｅｄｇｅ（抵当
権放棄）サブエレメントを含める。該当する証券の文書ＩＤのような、その他の
タグされる情報も必要である。

【０３８６】 （３）次に、現抵当権者は空白の抵当権者の指定を含むメッセージにデジタル
・サインし、このメッセージをメッセージ・ハンドリング・ユニットに送信する
。

【０３８７】 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側のデジタル・サインを照合することによって、メッセージの真正性をチ
ェックする。メッセージ・ハンドリング・ユニットおよびタイトル・レジストリ
はさらにメッセージの形式もチェックする。メッセージ・ハンドリング・ユニッ
トおよびタイトル・レジストリがデジタル・サインを適正に確認できないか、ま
たはメッセージの形式が不適正であると判断した場合は、ＢＮａｋが返信される
。

【０３８８】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを適正に照合し、且つメッセージが妥当であることが判
明すると、タイトル・レジストリは、抵当権者役割フィールドのコンテンツを空
欄へと変更する。

【０３８９】 （６）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して、送信側へＢＡｃｋタイプ・ヘッダを有するＤＮｏｔメッセージを返信
することによって、抵当権の放棄に成功したことを確認する。そのタイプ・ヘッ
ダは、タイトル・レジストリからの、それが実行したアクションの報告を含んで
いる。

【０３９０】 抵当権の放棄についての通知は行われない。 抵当権の放棄は、証券の抵当権設定状態を中断し、タイトル・レジストリが更
新された時点から証券を譲渡可の状態に復帰させる。

【０３９１】 抵当権の放棄を反映するタイトル・レジストリ・レコードはタイトル・レジス
トリ内に留まり、適用可能な保持スケジュールに規定の期間だけ、認可されたユ
ーザが利用できる。放棄を行うタイトル・レジストリ命令もまた、メッセージの
流れの日付順のログに記録され、そのログは、適用可能な保持スケジュールで指
定された期間だけ保存される。

【０３９２】 ４．４．４．３． 抵当権の執行 抵当権を執行することによって、電子船荷証券の現プレッジー・ホールダーは
、証券の現指図側がもし存在する場合はそれに取って代わり、その指図側ホール
ダーになる。電子船荷証券に白地裏書きがなされている場合（および、従って、
指図側がいない場合）、そのプレッジー・ホールダーはその抵当権者としての指
定を単に解除し、持参人ホールダーに留まる。本項では抵当権の執行プロセスを
詳細に記載する。

【０３９３】 オペレーション規則２４： 指図側が指定されているときの抵当権の執行 目下指図側が指定されている時に電子船荷証券に抵当権を執行するには、プレ
ッジー・ホールダーは、 （ａ）自らを指図側として指定し、その抵当権者としての指定を解除するタイ
トル・レジストリ命令を遂行し、 （ｂ）そのタイトル・レジストリ命令を含むメッセージにサインし、これをメ
ッセージ・ハンドリング・ユニットを介してタイトル・レジストリに送信する。

【０３９４】 オペレーション規則２５： 白地裏書きのときの抵当権の執行 目下白地裏書きされている時に電子船荷証券の抵当権を執行するには、プレッ
ジー・ホールダーは、 （ａ）プレッジー・ホールダーとしての指定を解除するタイトル・レジストリ
命令を完成させ、 （ｂ）そのタイトル・レジストリ命令を含むメッセージにサインし、これをメ
ッセージ・ハンドリング・ユニットを介してタイトル・レジストリに送信する。

【０３９５】 本項の残りの部分ではこのオペレーション規則を注釈する。 電子船荷証券の現抵当権者だけが抵当権を行使することができる。 一般に、抵当権を執行する抵当権者の権利を生じる、何らかの事象が発生しな
ければならない。しかし、タイトル・レジストリは、抵当権者が実際にこのよう
な権利を有しているか否かを照会することはない。

【０３９６】 図２４は抵当権を執行するプロセスを示す。指図側が指定されている場合の抵
当権の執行は、新規の指図側を指定する場合のプロセスと実質的に同一である。
電子船荷証券に白地裏書きがなされている場合、抵当権の執行は、抵当権を放棄
する場合と実質的に同一であり、以前の抵当権者が持参人ホールダーに留まる。

【０３９７】 タイトル・レジストリは、抵当権の執行により影響を受けるユーザーに通知は
行わないが、執行するプレッジー・ホールダーが独自に通知してもよい。 抵当権が執行されると、タイトル・レジストリが更新された時点から、電子船
荷証券は新規の指図側ホールダーまたは持参人ホールダーとしての以前の抵当権
者によって、譲渡可になる。

【０３９８】 抵当権の執行を反映するタイトル・レジストリ・レコードはタイトル・レジス
トリ内に留まり、適用可能な保持スケジュールに規定の期間だけ、認可されたユ
ーザが利用できる。抵当権の執行を行うタイトル・レジストリ命令も、メッセー
ジの流れの日付順のログに記録され、そのログは適用可能な保持スケジュールで
指定された期間だけ保存される。

【０３９９】 ４．４．５． 電子船荷証券の修正 本システムに一旦ファイルされると、ｅＢＬテキストとして機能する文書を含
む文書は、変更されずに当初受信された状態のまま留まる。その文書への事後の
照会によってこれは変更されず、文書が当初受信された際に本システムに入力さ
れた文書の属性と適合しなければならない。これらの属性には、文書の数学的ダ
イジェストがあり、これは、本システムが、同じであると称する文書の全ての事
後の参照または事例を比較して、それらが本システムのファイル上の文書と正確
に同一であることを確認するために使用する。

【０４００】 本システムは既存の文書を未変更のまま留めるが、特定の電子船荷証券のため
のタイトル・レジストリは、他の、恐らくは修正プロセスによって最近にファイ
ルされたｅＢＬテキストと関連付けることもできる。「修正」という用語を用い
ているが、電子船荷証券の修正によっても、既存の文書は未変更のままに留まり
、タイトル・レジストリ内の文書参照が、運用可能なｅＢＬテキストとして異な
る文書を指示するようにするだけである。各タイトル・レジストリ・レコードは
対応するｅＢＬテキストのための文書ＩＤを含むフィールドを含んでいる。この
フィールドはｅＢＬテキストを参照する役割を果たし、また、このフィールドの
コンテンツを変更して新規の文書ＩＤをリストするステップを、電子船荷証券の
修正と称するが、以前の文書は未変更のままに留まって将来参照するために未変
更の形式で利用できる。

【０４０１】 この「修正」プロセスは２つの基本的ステップで実行される。第１に、ユーザ
がオリジネータに証券を修正するよう要求し、次に、オリジネータはその要求を
認可又は拒否する。要求が認可された場合、新規の文書ＩＤがタイトル・レジス
トリ内の以前の文書ＩＤと入れ替えられ、次にタイトル・レジストリ内の取引デ
ータが入れ替えられたｅＢＬに適用され、それにより、システム・ユーザの修正
前の権利および義務は、新規の文書に関しても回復される。

【０４０２】 オリジネータはｅＢＬテキストを作成し、これにサインするので、新規の文書
を、タイトル・レジストリ内で既に参照された文書と入れ替えるには、オリジネ
ータの許可が必要である。オリジネータ以外の、利害関係を持つ他のユーザは修
正を要求することができ、それらが要求する場合、タイトル・レジストリは電子
船荷証券の効力を一時停止するので、全てのタイトル・レジストリ命令は、オリ
ジネータが修正要求を認可または拒否するまで拒否される。タイトル・レジスト
リは、修正するか否か、またどのように修正するかを決定する際のオリジネータ
と他のユーザとの対話を処理することはない。タイトル・レジストリは単に、要
求が代替のｅＢＬテキストと共に拒否又は認可されるまで、そのタイトル・レジ
ストリ・レコードをが関与する活動を一時停止するだけである。

【０４０３】 このように、修正に関するタイトル・レジストリ命令は三つの部分をもつ。す
なわち修正の要求、修正の認可、および修正の拒否である。 修正要求のタイトル・レジストリ命令は、タイトル・レジストリに影響するオ
ペレーションを一時中断し、それを検討するためにオリジネータに転送される。
要求するユーザは、通常は、要求の理由を説明する文書と、おそらくは改定の提
案を含める。オリジネータが要求の認可または拒否を決定するまで、後続の討議
はタイトル・レジストリを含めない。

【０４０４】 オリジネータからの修正認可のタイトル・レジストリ命令は、タイトル・レジ
ストリ・レコードに以前に参照されたｅＢＬと新規のｅＢＬを入れ替える。そこ
で電子船荷証券は（一時中断状態ではなく）使用可能（アクティブ）状態に回復
する。

【０４０５】 修正拒否のタイトル・レジストリ命令は、タイトル・レジストリ・レコードを
変更せずに、単に電子船荷証券を利用可能状態に復帰させる。 本項の残りの部分では修正プロセスをより詳細に検討する。

【０４０６】 ４．４．５．１．修正要求 修正プロセスはホールダーが修正を要求した時点から開始される。この要求は
主としてオリジネータに向けられるが、以下に詳細に説明するように、修正要求
の懸案中に、電子船荷証券に関するそれ以上の取引きを一時中断するために、タ
イトル・レジストリに記録される。

【０４０７】 オペレーション規則２６： 修正の要求 ｅＢＬテキストの修正を要求または提案するには、そのホールダーは、 （ａ）修正要求の形式のタイトル・レジストリ命令を作成し、 （ｂ）その命令を含むメッセージにサインし、これをメッセージ・ハンドリン
グ・ユニットを介してタイトル・レジストリに送信するものとする。

【０４０８】 オペレーション規則２７： 要求の認可または拒否 メッセージ・ハンドリング・ユニットによって送られた修正要求を受信した電
子船荷証券のオリジネータは、 （ａ）修正要求を認可するか、または （ｂ）修正要求を拒否する。

【０４０９】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 何れのホールダーも電子船荷証券の修正を要求することができる。 修正要求がなされる時点で、証券は利用可能でなければならず、抵当権が設定
されていてはならない。

【０４１０】 図２５は電子船荷証券の修正要求のプロセスを示したフローチャートである。
このプロセスは以下のステップによって実施される。 （１）適宜のユーザが、ユーザ・システムを利用して、メッセージ・ハンドリ
ング・ユニットへのメッセージを作成する。

【０４１１】 （２）ユーザは、メッセージ・タイプ・ヘッダのＩｎｓｔｒｕｃｔｉｏｎエレ
メントに修正要求を含める。タグされたデータには、影響を受ける電子船荷証券
の文書ＩＤも含まれる。

【０４１２】 （３）次に、ユーザはそのメッセージにデジタル・サインし、これを本システ
ムへ送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
送信側のデジタル・サインを照合することによってメッセージの真正性をチェッ
クし、さらにメッセージの形式もチェックする。メッセージ・ハンドリング・ユ
ニットがデジタル・サインを適正に確認できないか、またはメッセージの形式が
不適正であると判断した場合は、ＢＮａｋを返信する。

【０４１３】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを照合し、且つメッセージが妥当（有効）であることが
判明すると、タイトル・レジストリは、電子船荷証券に、懸案中の修正を有する
ものとしてフラグを立て、その状態を一時停止状態へと変更する。タイトル・レ
ジストリはさらに、何れの要求が上記一時停止状態と要求された修正に関する後
続のオペレーションとを誘発したかを追跡する要求識別子を入力する。

【０４１４】 （６）修正要求がオリジネータへ転送される。それを行うために、タイトル・
レジストリは、メッセージ・ハンドリング・ユニットを介して、電子船荷証券の
オリジネータに対し、メッセージ送信側からの修正要求が受信された旨の報告を
送信する。

【０４１５】 （７）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して、送信側へＢＡｃｋの形式のタイプ・ヘッダを有するＤＮｏｔメッセー
ジを返信することによって、修正要求の処理結果を確認する。そのタイプ・ヘッ
ダは、タイトル・レジストリからの、これが実行したアクションの報告を含んで
いる。

【０４１６】 修正の要求により、タイトル・レジストリの更新の時点から、電子船荷証券は
一時停止状態になる。修正要求の認可または拒否による以外には、この状態の終
了のためのタイムリミットは定められていない。

【０４１７】 修正要求を反映するタイトル・レジストリ・レコードはタイトル・レジストリ
内に留まり、適用可能な保持スケジュールに規定の期間だけ、認可されたユーザ
が利用できる。修正要求を行うタイトル・レジストリ命令も、メッセージの流れ
の日付順のログに記録され、そのログは適用可能な保持スケジュールで指定され
た期間だけ保存される。

【０４１８】 ４．４．５．２． 修正要求の拒否 修正要求が最終的に送られるオリジネータは、ここに記載するように要求を拒
否することができる。

【０４１９】 オペレーション規則２８： 修正要求の拒否 電子船荷証券のｅＢＬテキストの修正要求を拒否するには、そのオリジネータ
は、 （ａ）要求を拒否する所定の形式のタイトル・レジストリ命令を完成させ、 （ｂ）かかる命令を含むメッセージにサインし、これをメッセージ・ハンドリ
ング・ユニットを介してタイトル・レジストリに送信するものとする。

【０４２０】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 電子船荷証券のオリジネータだけが他のユーザによる証券の修正要求を拒否す
ることができる。

【０４２１】 オリジネータが要求された修正を拒否するには、証券は一時停止状態でなけれ
ばならない。 タイトル・レジストリは、オリジネータが修正を拒否する法的権利を有してい
るか否か、または任意のユーザが修正を行うためにオリジネータと合意した何ら
かの条件を満たしたか否かを照会するものではない。

【０４２２】 図２６は以下のように進展する修正拒否プロセスを示す。 （１）オリジネータがユーザ・システムを利用してメッセージ・ハンドリング
・ユニットへのメッセージを作成する。

【０４２３】 （２）オリジネータは、サービス・プロバイダによって指定されたフォームに
修正要求の拒否を示すタグを含めることによって、修正要求を拒否する意思を表
明する。タグされたデータには、影響を受ける証券の文書ＩＤおよび拒否される
修正要求の要求識別子も含まれる。

【０４２４】 （３）次に、オリジネータは上記メッセージにデジタル・サインし、これをメ
ッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側（オリジネータ）のデジタル・サインを照合することによってメッセー
ジの真正性をチェックし、また、メッセージの形式もチェックする。メッセージ
・ハンドリング・ユニットがデジタル・サインを適正に確認できないか、または
メッセージの形式が不適正であると判断した場合は、ＢＮａｋを返信する。

【０４２５】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを適正に照合し、且つメッセージが妥当であることが判
明した場合、タイトル・レジストリは、電子船荷証券のフラグをリセットして、
修正がもはや処理されていないことを示す。

【０４２６】 （６）次に、修正要求がオリジネータへ送られる。次に、タイトル・レジスト
リは、電子船荷証券のオリジネータへ、メッセージ・ハンドリング・ユニットを
介して、メッセージ送信側からの修正要求が受信された旨の報告を送信する。

【０４２７】 （７）次に、タイトル・レジストリは、オリジネータへ、ＢＡｃｋの形式のタ
イプ・ヘッダを含むＤＮｏｔメッセージを返信することによって、修正拒否の処
理結果を確認する。そのタイプ・ヘッダは、タイトル・レジストリからの、これ
が実行したアクションの報告を含んでいる。

【０４２８】 修正要求の拒否により、タイトル・レジストリの更新の時点から、電子船荷証
券の一時停止状態は終了し、使用可能状態へと復帰する。 ホールダーの指定を含むタイトル・レジストリ・レコードはタイトル・レジス
トリ内に留まり、適用可能な保持スケジュールで規定された期間だけ、認可され
たユーザが利用できる。修正を拒否するタイトル・レジストリ命令も、メッセー
ジの流れの日付順のログに記録され、このログは適用可能な保持スケジュールで
規定された期間だけ保存される。

【０４２９】 ４．４．５．３． 修正要求の認可 修正要求が送られるオリジネータは、ここに示すように要求を認可または拒否
できる。

【０４３０】 オペレーション規則２９： 修正要求の認可（許可） 電子船荷証券のｅＢＬテキストの修正要求を認可するには、そのオリジネータ
は、 （ａ）要求を認可するためにサービス・プロバイダによって指定されたフォー
ムにタイトル・レジストリ命令を完成させ、 （ｂ）その命令を含むメッセージにサインし、これをメッセージ・ハンドリン
グ・ユニットを介してタイトル・レジストリに送信する。

【０４３１】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 電子船荷証券のオリジネータだけが他のユーザによる証券の修正要求を認可す
ることができる。

【０４３２】 オリジネータは自身が修正を開始することはできない。要求は、修正される証
券のホールダーまたは荷受側（受託者）を兼ねている荷主（荷送人）によってな
されなければならず、証券は一時停止状態にならなければならない。タイトル・
レジストリは、オリジネータが修正を認可する権利を有しているか否か、または
任意のユーザが修正を行うためにオリジネータと合意した何らかの条件を満たし
たか否かを照会するものではない。

【０４３３】 図２７は修正要求の認可プロセスを示す。以下のステップが含まれる。 （１）オリジネータがユーザ・システムを利用してメッセージ・ハンドリング
・ユニットへのメッセージを作成する。

【０４３４】 （２）オリジネータは、サービス・プロバイダによって指定されたフォームで
修正要求の認可を表示するタグを含めることによって、修正要求を認可する意思
を表明する。タグされるデータには、認可された修正要求の要求識別子および添
付される新規の電子船荷証券の文書ＩＤも含まれる。修正が、複数の電子船荷証
券を一つに統合する修正である場合、複数の文書ＩＤが認可命令に現れ得る。修
正が、１つの電子船荷証券を複数の別個の電子船荷証券に分割する修正である場
合、複数の命令を有することになり、その全ては、同じ修正要求識別子を有する
が、その各々は、メッセージに含まれる別個のｅＢＬテキストを言及する別個の
文書ＩＤを含む。

【０４３５】 （３）次に、オリジネータは上記メッセージにデジタル・サインし、これをメ
ッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
、送信側（オリジネータ）のデジタル・サインを照合することによってメッセー
ジの真正性をチェックする。メッセージ・ハンドリング・ユニットおよびタイト
ル・レジストリはさらにメッセージの形式もチェックする。デジタル・サインを
適正に確認できないか、またはメッセージの形式が不適正であると判断した場合
、メッセージ・ハンドリング・ユニットはＢＮａｋメッセージを返信する。

【０４３６】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを適正に照合し、且つメッセージが妥当であることが判
明した場合、タイトル・レジストリは、電子船荷証券のフラグを、修正がもはや
処理中でないことを示すように、リセットする。

【０４３７】 （６）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して、オリジネータへＢＡｃｋの形式のタイプ・ヘッダを含むＤＮｏｔメッ
セージを返信することによって、修正拒否の処理を確認する。そのタイプ・ヘッ
ダは、タイトル・レジストリからの、これが実行したアクションの報告を含んで
いる。

【０４３８】 修正要求の認可により、タイトル・レジストリの更新の時点から、電子船荷証
券の一時停止状態は終了し、修正された電子船荷証券（１または複数）を、新規
のｅＢＬテキストと共に、使用可能状態に復帰させる。

【０４３９】 修正前のタイトル・レジストリ・レコードはタイトル・レジストリ内に留まり
、適用可能な保持スケジュールに規定される期間だけ、認可されたユーザが利用
できる。修正を認可するタイトル・レジストリ命令も、メッセージの流れの日付
順のログに記録され、このログは適用可能な保持スケジュールで指定された期間
だけ保存される。

【０４４０】 ４．４．６． 電子船荷証券の引き渡し 電子船荷証券の引き渡しは、荷積みされた商品と引換えに輸送業者に対する荷
受側または被裏書人（一般に買手または輸入業者）による紙の船荷証券の提出と
類似している。それは何れの役割フィールドも変更しないが、以下により詳細に
説明するように、単に証券が終了したことを示す。

【０４４１】 以下の当事者だけが電子船荷証券を引き渡すことができる。（１）ホールダー
も兼ねている場合の荷受側、および（２）現時点の指図側ホールダー。 証券は、引き渡されるには、使用可能でなければならず、また、抵当権が設定
されていてはならない。

【０４４２】 図２８は電子船荷証券の引き渡しプロセスを示し、以下のステップにより行わ
れる。 （１）荷受側または現時の指図側ホールダーが、ユーザ・システムを利用して
、メッセージ・ハンドリング・ユニットへのメッセージを作成する。

【０４４３】 （２）荷受側または指図側ホールダーは、サービス・プロバイダによって指定
されたフォームに命令を含める。情報には、引き渡される証券の文書ＩＤも含ま
れる。

【０４４４】 （３）次に、荷受側または指図側ホールダーはメッセージにデジタル・サイン
し、これをメッセージ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
送信側のデジタル・サインを照合することによってメッセージの真正性をチェッ
クする。メッセージ・ハンドリング・ユニットおよび／またはタイトル・レジス
トリはさらにメッセージの形式もチェックする。メッセージ・ハンドリング・ユ
ニットまたはタイトル・レジストリ・システムがデジタル・サインを適正に確認
できないか、またはメッセージの形式が不適正であると判断した場合、メッセー
ジ・ハンドリング・ユニットはＢＮａｋを返信する。

【０４４５】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを適正に照合し、且つメッセージが妥当であることが判
明した場合、タイトル・レジストリは電子船荷証券を引き渡されたものとしてフ
ラグを立てる。

【０４４６】 （６）次に、タイトル・レジストリは、オリジネータにＢＡｃｋの形式のタイ
プ・ヘッダを返信することによって、引き渡しを確認する。そのタイプ・ヘッダ
は、タイトル・レジストリからの、それが実行したアクションの報告を含んでい
る。

【０４４７】 タイトル・レジストリは、メッセージ・ハンドリング・ユニットを介して、オ
リジネータおよび引渡側（存在する場合）へＦＭｓｇメッセージを送信して、彼
らに、電子船荷証券が引き渡されたことを通知し、且つ誰が現時の荷受側または
指図側ホールダーであるかを伝える。

【０４４８】 引渡しは、タイトル・レジストリの更新時点から、電子船荷証券を終了にする
。 終了した電子船荷証券のタイトル・レジストリ・レコード（全ての以前の取引
きを含む）はタイトル・レジストリ内に留まり、適用可能な保持スケジュールに
規定された期間だけ、認可されたユーザが利用できる。引き渡しを行うタイトル
・レジストリ命令も、メッセージの流れの日付順のログに記録され、このログは
適用可能な保持スケジュールで指定された期間だけ保存される。

【０４４９】 ４．４．７． 紙への切換え指令 電子船荷証券を紙形式から電子形式に変換するには、ユーザは証券のオリジネ
ータに対して、船荷証券の文書をプリントアウトし、プリントしたものにサイン
し、それを、規則書セクション３．７に記載のように、次の適正な当事者に渡す
ように指示する。技術的なプロセスとしては、後述するように、これは最終的に
オリジネータに宛てられ、且つ途中で、電子船荷証券が終了したものであること
を示すフラグが立てられるようにタイトル・レジストリを通過するメッセージで
ある。

【０４５０】 オペレーション規則３０： 抵当権が設定されていない証券の紙への切換え指
令 抵当権が設定されていない電子船荷証券のオリジネータに対して、規則書セク
ション３．７（２）が規定するように証券を紙に切り換えるように指令するには
、その荷主ホールダー、指図側ホールダー、持参人ホールダー、または荷受側ホ
ールダーは、 （ａ）サービス・プロバイダによって指定された形式に、オリジネータに対し
て紙に切り換えるように指示するタイトル・レジストリ命令を作成し、 （ｂ）その命令を含むメッセージにサインし、これをメッセージ・ハンドリン
グ・ユニットを介してタイトル・レジストリに送信する、 ものとする。

【０４５１】 オペレーション規則３１： 抵当権が設定されている証券の紙への切換え指令 抵当権が設定されている電子船荷証券のオリジネータに対して、規則書セクシ
ョン３．７（２）が規定するように証券を紙に切り換えるように指令するには、
そのプレッジー・ホールダーは、 （ａ）サービス・プロバイダによって指定された形式に、要求を認可するタイ
トル・レジストリ命令を作成し、 （ｂ）その命令を含むメッセージにサインし、これをメッセージ・ハンドリン
グ・ユニットを介してタイトル・レジストリに送信する、 ものとする。

【０４５２】 本項の残りの部分ではこのオペレーション規則に注釈を加える。 電子船荷証券の現行の持参人ホールダー、指図側ホールダー、または荷受側ホ
ールダーは、それに抵当権が設定されていない場合には、紙に切り換えることが
できる。抵当権が設定されている場合は、そのプレッジー・ホールダーだけが証
券を紙に切り換えることができる。例外的な状況では、システムのサービス・プ
ロバイダも紙への切換え指令を発することができるが、それは重要なユーザが活
動停止している場合だけである。その後サービス・プロバイダが介入しない場合
は、電子船荷証券はタイトル・レジストリ内に永続的に「スタック（保留）」さ
れる。重要なユーザとは、（１）ホールダーを兼ねる場合の荷主、（２）ホール
ダーを兼ねる場合の荷受側、（３）証券に抵当権が設定されていない場合の現時
の指図側ホールダー、（４）証券に抵当権が設定されていない場合の現時の持参
人式ホールダー、（５）現時の持参人ホールダーである。システム・サービス・
プロバイダがユーザの活動を停止する場合、サービス・プロバイダは、タイトル
・レジストリをチェックして、そのユーザが上記の役割の１つを占めているか否
かを判断し、占めている場合は紙への切換え指令を開始する。

【０４５３】 電子船荷証券は、紙への切換え指令が発される時点で既に終了していてはなら
ない。 図２９が示すように、紙への切換え命令は以下のように実施される。

【０４５４】 （１）適宜のユーザがユーザ・システムを利用してメッセージ・ハンドリング
・ユニットへのメッセージを作成する。 （２）紙への切換えを指示する命令を含める。荷受側または指図側ホールダー
はサービス・プロバイダが規定するフォームに命令を含める。情報には、紙に切
り換えられる証券の文書ＩＤが含まれる。

【０４５５】 （３）次に、ユーザは上記メッセージにデジタル・サインし、これをメッセー
ジ・ハンドリング・ユニットに送信する。 （４）何れのメッセージに関しても、メッセージ・ハンドリング・ユニットは
送信側のデジタル・サインを照合することによってメッセージの真正性をチェッ
クする。メッセージ・ハンドリング・ユニットおよび／またはタイトル・レジス
トリはさらにメッセージの形式もチェックする。メッセージ・ハンドリング・ユ
ニットおよびタイトル・レジストリがデジタル・サインを適正に確認できないか
、または形式が不適正であると判断した場合は、メッセージ・ハンドリング・ユ
ニットからＢＮａｋが返信される。

【０４５６】 （５）メッセージ・ハンドリング・ユニットおよびタイトル・レジストリが送
信側のデジタル・サインを適正に照合し、且つメッセージが妥当であることが判
明した場合、タイトル・レジストリは電子船荷証券に、紙に切り換えられるもの
としてフラグを立てる。

【０４５７】 （６）メッセージ・ハンドリング・ユニットを介して電子船荷証券のオリジネ
ータに対して、メッセージの送信側から紙への切換え指令が受信された旨の報告
を、タイトル・レジストリが送信することによって、オリジネータに、紙への切
換え指令が送られる。タイトル・レジストリはオリジネータに対して、オリジネ
ータがこの指令を実行したか否かを照会するものではない。指令の実行を強いる
指令側ユーザの権利については、規則書を参照されたい。

【０４５８】 （７）次に、タイトル・レジストリは、メッセージ・ハンドリング・ユニット
を介して、送信側にＢＡｃｋの形式のタイプ・ヘッダを返信することによって、
紙への切換え指令の処理を確認する。そのタイプ・ヘッダは、タイトル・レジス
トリからの、それが実行したアクションの報告を含んでいる。

【０４５９】 紙への切換えよって、タイトル・レジストリの更新時点から、電子船荷証券は
終了させられる。 終了した電子船荷証券（全ての以前の取引きを含む）のタイトル・レジストリ
・レコードはタイトル・レジストリ内に留まり、適用可能な保持スケジュールに
規定された期間だけ、認可されたユーザが利用できる。紙への切り替えを行うタ
イトル・レジストリ命令もメッセージの流れの日付順のログに記録され、このロ
グは適用可能な保持スケジュールで指定された期間だけ保存される。

【０４６０】 ４．５． 裏書き連鎖（エンドースメント・チェーン） タイトル・レジストリは各ＢＢＬの裏書き連鎖を保存する。裏書き連鎖は輸送
契約の当事者を反映する。サービス・プロバイダは、契約状態とＢＢＬの譲渡を
それぞれ反映する裏書き連鎖の作成と配達を管理する。

【０４６１】 ４．５．１． 裏書き連鎖の作成 タイトル・レジストリは、輸送契約の新規の当事者が指定されるごとに、裏書
き連鎖内にレコードを作成する。これは、当事者が多数の命令のうちの１つの命
令の結果として、ホールダー及び指図側の双方または荷受側になると実行される
。これらの命令には、ホールダーの指定、ホールダーの指定および指図側または
荷受側の指定、持参人ホールダーが自身を指図側または荷受側に指定するときの
指図側または荷受側の指定、ＢＢＬにおいて指定された指図側がいる場合の抵当
権を執行、および或る場合における修正の認可、がある。修正の認可によって、
裏書き連鎖にレコードが作成されるが、それが作成されるのは、新規のバージョ
ン番号をもつｅＢＬがあり、（ｉ）指図側も兼ねているホールダーが荷受側にな
り、（ｉｉ）荷受側も兼ねているホールダーが指図側になるときである。修正の
認可によってさらに、新規のｅＢＬ識別子を有するｅＢＬがある場合には、裏書
き連鎖にレコードが作成される。この場合、ホールダーが指図側または荷受側を
兼ねているとき、修正された各ｅＢＬごとにレコードが作成される。

【０４６２】 妥当（有効）な取引き拒否が発生すると、タイトル・レジストリは、取引き拒
否を表明した当事者を裏書き連鎖から削除する。 図３０は裏書き連鎖の構文の例を示している。裏書き連鎖がいつ作成されるか
に関する定義的規則については図３１から図３７を参照して説明する。

【０４６３】 ４．５．２． 裏書き連鎖の配達 タイトル・レジストリは、多くの機能、すなわち、ホールダーの指定、プレッ
ジー・ホールダーの指定、抵当権の執行、修正要求、修正認可、紙への切換え、
およびＢＢＬの引渡し、が完了したときに裏書き連鎖情報を配達する。

【０４６４】 レコードが空である場合、タイトル・レジストリは裏書き連鎖を配達しない。
裏書き連鎖がいつ配達されるかに関する定義的な規則については図３１から図３
７を参照して記載する。

【０４６５】 ４．６． タイトル・レジストリ情報のルックアップ ユーザに対して限定されたワールド・ワイド・ウェブ・サイトは、電子船荷証
券に利害があるユーザにだけに、その現在の状態（ステータス）およびそれに関
するその他の情報をルックアップできるようにされている。一般に、電子船荷証
券に関する情報は、情報を提供するユーザとサービス・プロバイダとの契約によ
り機密である。しかし、その契約に基づいて、特定の情報は特定の時期に特定の
者に開示してもよい。ウェブ・サイトは、適正に識別されたユーザ代表者だけが
タイトル・レジストリ情報にアクセスすることを保証するため、証書（サーティ
フィケート）とトランスポート・レイヤー・セキュリティ（以前のセキュア・ソ
ケット・レイヤ）を使用する。さらに、ユーザ代表者は、ユーザ・データベース
に従って情報監視特権を有している場合だけ、アクセスすることができる。

【０４６６】 インタラクティブなウェブ・サイト以外にも、ユーザはサービス・プロバイダ
のヘルプ・デスクへの電話による照会によっても情報を得ることができる。ウェ
ブ・サイトに適用可能なアクセス制限は、ヘルプ・デスクで情報を提供するスタ
ッフにも適用される。

【０４６７】 所与のユーザが得られる情報は、情報の種類および要求側ユーザの役割によっ
て異なる。メッセージに関して、ユーザは、送信または受信したメッセージのコ
ピーを入手できる（但し、ほとんどのユーザ・システムはコピーを保存するので
、コピーを入手するために中央メッセージ・ハンドリング・ユニットに頼る必要
性はまれであろう）。タイトル・レジストリ内の情報（現行またはアーカイブの
何れか）については、ユーザは、何れのユーザが通知される権限を有する（また
は有していた）かの情報、または何れのユーザに以前に提供されたかの情報を入
手できる。この場合も、ユーザ・システムは、通常、本システムから送信された
通知および本システムに送信された情報のコピーを保存しているので、本システ
ムからの情報を検索する必要はまれである。

【０４６８】 荷受側、指図側ホールダー、または持参人ホールダーの指定時に送信される通
知には、前項に記載した権利の譲渡に関する助言、ならびに、次項に記載するよ
うな、新規に指定されたユーザに案内する裏書き連鎖の報告が含まれる。

【０４６９】 ４．６．１． 裏書き連鎖の報告 タイトル・レジストリは指図側裏書き連鎖、すなわち指図側による電子船荷証
券の譲渡の手順に関する情報を、後述するように、特定の電子船荷証券で特定の
役割を有するユーザに報告する。

【０４７０】 譲渡情報を入手できるようにするために、本システムは、システム・ユーザの
個人的利害と、ユーザの権利および義務に影響する情報を知る必要性との総体的
バランスをとるように設計されている。技術的なオペレーションが総体的バラン
スを実施し、これはほとんどのユーザには受け入れられるが、おそらくは全ての
ユーザに受け入れられるものではない。本システムは、規則書を補足し、情報の
入手可能性にさらに制約を加えるユーザ間の約束を妨げるものではない。即ち、
譲渡情報を得るための技術的な能力は、これを得る権利とは関わりがない。従っ
て、本システムにユーザが譲渡情報を得るオプションがあったとしても、プライ
バシーを守るためのユーザ間の約束は、上記オプションを行使するユーザの法的
権利を制限し得る。

【０４７１】 このような総体的バランスの一部として、指図側の譲渡および抵当権に関する
情報だけを入手できる。抵当権に関して入手できる情報には、一つの抵当権者か
ら他の抵当権者への譲渡に関する情報が含まれる。ホールダー、および持参人ホ
ールダーを含むその他の役割（ロール）による譲渡に関する情報は、電子船荷証
券が何れの時期に白地裏書きされたか（そうなった場合）、および（そうされた
場合に）それが何れの時期に再び指図側に譲渡されるかを裏書き連鎖が示すこと
を除いて、入手できない。もちろん、持参人ホールダーの譲渡に関する機密性は
、このような情報が本システムに保存されている限りは、システムのサービス・
プロバイダの管理上の調査の対象にはなる。

【０４７２】 さらに、荷受側の指定によって、電子船荷証券は譲渡不可になるので、それに
よって裏書き連鎖は終了する。したがって、荷受側の指定後の譲渡に関する情報
は入手できず、実際、存在しない。また、情報は、証券が使用可能である期間だ
け入手できる。本システムの外で行われるどのような譲渡（例えば、電子船荷証
券が紙に切り換えられた後や、当初の指図側の指定前）も、タイトル・レジスト
リは掌握していない。情報の範囲は、証券の修正（それがなされる場合）の前と
後の双方の譲渡を含んでいる。

【０４７３】 入手可能な譲渡情報を得る能力を有するユーザ、およびユーザが情報を得る能
力へのさらなる制約は、以下のとおりである。 指図側が入手できる裏書き情報は以下のとおりである。要求側の指図側に先行
するそれぞれの指図側譲渡または抵当権に関して、指図側は、譲受人または抵当
権者のユーザ識別子、および譲渡または抵当権の日付および時間の情報を得るこ
とができる。

【０４７４】 現時の持参人ホールダーが入手できる裏書き情報は以下のとおりである。要求
側の持参人ホールダーに先行するそれぞれの指図側譲渡または抵当権に関して、
現時の持参人ホールダーは、譲受人または抵当権者のユーザ識別子、および譲渡
または抵当権の日付および時間の情報を得ることができる。

【０４７５】 以前に譲渡可能であった証券の荷受側が入手できる裏書き情報は以下のとおり
である。それぞれの譲渡または抵当権に関して、荷受側は、譲受人または抵当権
者のユーザ識別子、および譲渡または抵当権の日付および時間の情報を得ること
が出来る。

【０４７６】 終了した証券のオリジネータが入手できる裏書き情報は以下の通りである。そ
れぞれの譲渡または抵当権に関して、引き渡された又は紙に切換えられた証券の
オリジネータは、譲受人または抵当権者のユーザ識別子、および譲渡または抵当
権の日付および時間の情報を得ることができる。

【０４７７】 終了した証券の引渡側が入手できる裏書き情報は以下のとおりである。それぞ
れの譲渡または抵当権に関して、引き渡された又は紙に切換えられた証券の引渡
側は、譲受人または抵当権者のユーザ識別子、および譲渡または抵当権の日付お
よび時間の情報を得ることができる。

【０４７８】 その上、譲渡情報は、電子船荷証券がその履歴のある時点で譲渡可能になった
場合だけ、また譲渡がなされる時点で証券のステータスに誤りがない場合だけ、
入手可能である。

【０４７９】 裏書き連鎖は、荷受側、指図側ホールダー、または持参人ホールダーが指定さ
れるときはいつでも、指定されたユーザに送信される。 ４．６．２． 編入される文書 本システムを介して送信され、利用される文書の多くは、他の文書を照会（参
照）する。多くの文書は参照によって他の文書を編入し、この編入によって文書
はより簡潔になる。規則書は、ある状況で参照によって編入された文書に関連す
るある種の法体系で生ずる論点を取り扱っている。ユーザ・システムは、ワール
ド・ワイド・ウェブで一般的なハイパーリンク機構を通じて、参照された文書の
ルックアップのプロセスを自動化してもよい。外部エンティティをサポートする
ユーザ・システムおよびＸＭＬ文書において、エンティティの参照もまた、文書
の編入プロセスを自動化することができる。

【０４８０】 しかし、編入された文書が入手可能ではなく、また明確に参照されない場合は
、困難が生ずる。このような困難を防止するため、本システムは、ユーザがオン
ライン・ユーザ・サポート資源に共通に照会される文書をオンラインで送付でき
るようになっている。それにより、システム・ユーザがハイパーテキスト・トラ
ンスポート・プロトコル（ＨＴＴＰ）、ワールド・ワイド・ウェブで一般的に使
用される通信プロトコル、を通じてこの文書を入手可能となる。文書が送付（ポ
スト）されると、システム・サービス・プロバイダはそれに、送付側ユーザとの
合意によってこれにユニフォーム・リソース・ロケータ（ＵＲＬ）を割当て、そ
れに基づいて文書を入手できるようにする。ＵＲＬはユーザ・サポート資源にお
いてオンラインの全文書ごとに一意性を有している。現システムでは、サービス
・プロバイダはユーザ・サポート資源へのｅメール要求に従って文書を送付する
。

【０４８１】 送付側ユーザとシステム・サービス・プロバイダが合意しない限り、送付され
た文書は、セキュア・ソケット・レーヤー（ＳＳＬ、トランスポート・レイヤ・
セキュリティ（ＴＬＳ）とも言われる）および特定の等級の公開鍵サーティフィ
ケートを利用してこれにアクセスすることの制限が合意されていなければ、ＨＴ
ＴＰを通じて全てのシステム・ユーザによって入手および閲覧可能である。

【０４８２】 オペレーション規則３２： ユーザ・サポート資源でのユーザ文書の公表 ユーザは、システムのサービス・プロバイダとのさらに別の合意により、参照
のための文書をユーザ・サポート資源に送付（ポスト）してもよい。

【０４８３】 ４．７． タイトル・レジストリ機能 ここでタイトル・レジストリ機能のさらに別の面を記載する。 ４．７．１． 同時機能 ほとんどの場合、タイトル・レジストリは一度に一つの命令だけを受け入れる
。例外は、（抵当権者）ホールダー指定の命令の場合であり、追加の命令を同時
に発することができる。

【０４８４】 ホールダー指定命令は、指図側指定、荷受側指定、または指定裏書きの命令の
いずれかと同時に受け入れられ得る。 抵当権者ホールダー指定の命令は、指図側指定または白地裏書きの命令と同時
に受け入れられ得る。

【０４８５】 上記の同時機能は同じメッセージ内に発行することができる。その他の同時機
能は利用不可能である。同時機能は、送信側が各々の機能を別個に実行する権利
を有している場合だけ、利用できる。

【０４８６】 ４．７．２． 複数のｅＢＬ ほとんどの場合、タイトル・レジストリは一度に一つのｅＢＬだけを受け入れ
る。例外は、修正要求または修正認可の命令の場合である。修正要求の場合、送
信側は輸送業者に対して、分割または統合によりＢＢＬを修正するよう要求でき
る。分割の場合、送信側は単一のＢＢＬから複数のＢＢＬを作成することを要求
する。統合（組み合わせ）の場合、送信側は複数のＢＢＬから単一のＢＢＬを作
成することを要求する。

【０４８７】 分割の修正要求の場合、要求側のユーザは単一のｅＢＬをタイトル・レジスト
リに送信し、オリジネータは修正認可で応答して複数のｅＢＬを発行する。統合
の修正要求の場合、要求側のユーザは複数のｅＢＬをタイトル・レジストリに送
信し、オリジネータは修正認可で応答して単一のｅＢＬを発行する。

【０４８８】 その他の何れのような場合も、タイトル・レジストリに一度に複数のｅＢＬを
発行することはできない。 ４．７．３． ＢＢＬのタイプ タイトル・レジストリは、譲渡可（受け渡しできる）および譲渡不可(受け渡
しできない)のＢＢＬを提供する。役割が、ＢＢＬの譲渡可能性を決定する。譲
渡可のＢＢＬは、指定された指図側または白地裏書きされたＢＢＬによって表さ
れる。譲渡不可のＢＢＬは、指定された荷受側のＢＢＬによって表される。指図
側および荷受側の役割は単一のＢＢＬでは共存できない。

【０４８９】 タイトル・レジストリはまた、タイトル・レジストリのサブ・エンベロープに
、必須の譲渡可／譲渡不可フィールドを備えている。ＢＢＬが譲渡不可であるこ
とが示されたときに指図側が指定されるか又はＢＢＬが白地裏書きとされると、
タイトル・レジストリはメッセージを拒否する。ＢＢＬが譲渡可であることが示
されたときに荷受側が指定されると、タイトル・レジストリはメッセージを拒否
する。

【０４９０】 ４．７．４． ｅＢＬ識別子（文書ＩＤ） タイトル・レジストリは、メッセージ・ハンドリング・ユニットで使用される
同じ文書（ドキュメント）ＩＤ協定および構文を遵守する。これは、ＲＩＤ、一
般ＩＤおよびバージョンからなっている。

【０４９１】 ＲＩＤとは、オリジネータの登録されたユーザＩＤである６４文字以下の英数
字ストリングである。 一般ＩＤとは、オリジネータにより指定され、このユーザに対して一意的でな
ければならない６４文字以下の英数字ストリングである。

【０４９２】 バージョンとは、修正された文書を識別するためにオプションで追加される１
６文字以下の英数字ストリングである。バージョン番号を別とした同じである２
つのｅＢＬ識別子は、同じｅＢＬの２つのバージョンに対応する。最も新しいバ
ージョンは、ホールダーが発行した要求の結果としてオリジネータによって発行
された修正に対応する。

【０４９３】 これらの属性の組合わせによって、各ｅＢＬ識別子がシステム内で一意的であ
ることが確保される。 タイトル・レジストリは文書の草案を受け入れず、従って、タイトル・レジス
トリ命令では草案の属性は許可されない。

【０４９４】 ４．７．５． 自動通知 タイトル・レジストリ・レコードが作成または変更されるとき、タイトル・レ
ジストリは送信側に応答して、影響を受ける側（当事者）（受信者（１または複
数））に自動的に通知する。このことは、タイトル・レジストリに命令を送信す
る場合に受信側を指定する必要がない、ということを意味している。送信側が追
加の当事者を伝えたければ、そうしてもよい。送信側が、タイトル・レジストリ
が通知する当事者を指定する場合、メッセージ・ハンドリング・ユニットは、単
一のメッセージだけが受信側に送信されることを確実にするため、タイトル・レ
ジストリからの結果をフィルタリングする。

【０４９５】 通知が作成される場合を図３３にまとめている。 ４．７．６． 同封されたｅＢＬのチェック タイトル・レジストリ命令を含むメッセージにｅＢＬを同封（添付）すること
は必ずしも必要ではない。なぜなら、結果の通知が存在せず、または、当事者が
既にｅＢＬを所有しているからである。一貫性（コンシンタンシ）を維持するた
めに、タイトル・レジストリは必要な時にｅＢＬが確実に添付されるようにチェ
ック（検査）する。必要なときにｅＢＬが添付されていない場合は、タイトル・
レジストリは否定的な結果を出し、送信側はＢＮＡＫを受信する。

【０４９６】 ｅＢＬを添付するための条件は図３３にまとめている。 ４．７．７． 修正の管理 タイトル・レジストリは、修正の要求（リクエスト）、認可（許可）、拒否の
命令を通じての修正の機能を備えている。修正要求命令は意図的に包括的であり
、全ての修正要求のための設備を提供する。要求は現ホールダーによって発せら
れ、オリジネータによってのみ実行可能である。

【０４９７】 タイトル・レジストリが妥当（有効）な修正要求を受け取ると、タイトル・レ
ジストリは、オリジネータによって修正認可または修正拒否の命令が出されるま
で、ＢＢＬへの全てのアクションを一時停止状態にする。異なる種類の修正要求
（例えば分割、統合、切換え）に対処するために、タイトル・レジストリは、妥
当な修正要求命令が受理されると、オリジネータへ要求ＩＤを発行する。それに
よって、オリジネータは、取引環境で要求されるように、自由に修正を認可また
は拒否できる。

【０４９８】 オリジネータがＢＢＬを統合するための修正要求を認可したい場合は、オリジ
ネータは、ホールダーによって送信されたＢＢＬの数に関わりなく、タイトル・
レジストリによって供給された要求ＩＤおよび新規のＢＢＬを用いて応答する。
タイトル・レジストリは、以前の全てのＢＢＬを新規のＢＢＬと置換するために
、要求ＩＤを利用する。同様に、オリジネータがＢＢＬを分割するための修正要
求を認可したい場合は、オリジネータは、タイトル・レジストリによって供給さ
れた要求ＩＤおよび新規のＢＢＬを用いて応答する。タイトル・レジストリは、
以前のＢＢＬを新規のＢＢＬと置換するために、要求ＩＤを利用する。

【０４９９】 修正されたＢＢＬは新規のｅＢＬ識別子を備えていなければならない。新規の
ＢＢＬを１つの古いＢＢＬと入れ替える場合（１：１）、輸送業者は、新規のｅ
ＢＬ識別子を使用するか又は異なるバージョン番号を有する同じｅＢＬ識別子を
使用するかを選択できる。新規のＢＢＬを複数の古いＢＢＬと置換する場合（ｎ
：１）、または複数の新規のＢＢＬを１つの古いＢＢＬと入れ替える場合（１：
ｎ）、輸送業者は新規のｅＢＬ識別子を使用しなければならない。

【０５００】 ４．７．８． 規則書の遵守 ＢＢＬに対するユーザの権利および義務は規則書（ルール・ブック）に規定さ
れている。規則書は、法定的所有に関連する法的権利および義務および輸送契約
を規定する。

【０５０１】 簡略に述べると、ＢＢＬのオリジネータ（輸送業者）は、物理的に所有してい
る貨物を、独立した当事者（法律用語では独立受託者）として保持する。オリジ
ネータは、規則書を介して、オリジネータに命令を与える発権利は規則書の条項
に従って譲渡してもよいということに合意する。ＢＢＬの予め規定された状態の
１つが生ずると、タイトル・レジストリは、オリジネータに代わって、その特定
の状態にあるユーザに通知を送る。この通知は譲渡(attornment、アトーンメン
ト)通知であり、法定的所有権を授与する。法定的所有権は当初は荷主にあり、
以下の状況下で他の当事者に譲渡される。（１）持参人ホールダーが指定された
場合、（２）指定されたホールダーが指図側または荷受側を兼ねている場合、お
よび（３）プレッジー・ホールダーが指定されるとき。

【０５０２】 輸送契約は当初はオリジネータと荷主との間で交わされる。ユーザは、ホール
ダーと、指図側または荷受側とを兼ねている場合に、輸送契約の当事者になる。
このような状態は以下の場合に発生することができる。

【０５０３】 （１）（プレッジー）持参人ホールダが他のユーザをホールダー、および指図
側または荷受側に指定した場合。 （２）異なる指定された指図側を有するＢＢＬの（プレッジー）ホールダーが
その指図側をホールダーに指定した場合。

【０５０４】 （３）異なる指定された荷受側を有するＢＢＬのホールダーがその荷受側をホ
ールダーに指定した場合。 （４）ＢＢＬのホールダーおよび指図側が他のユーザをホールダー、および指
図側または荷受側に指定した場合。

【０５０５】 （５）持参人ホールダーが自らを指図側または荷受側に指定した場合。 （６）指定された指図側を有するＢＢＬのプレッジー・ホールダーが抵当権を
執行する場合。

【０５０６】 ４．７．８．１． 譲渡通知 アトーンメント通知は、法定的所有を授与するものとして上記の状態の１つに
ユーザが指定されると、オリジネータに代わってタイトル・レジストリによって
作成される。これは以下の例外を除いて上記の３つの場合に行われる。これらの
例外とは（１）持参人ホールダーが自らを指図側または荷受側に指定した場合、
（２）抵当権を執行した後、および（３）バージョン番号を使用した場合の修正
認可の後、である。

【０５０７】 例外がある理由は、命令を発したユーザが、命令の発令前および命令の実行後
の双方に法定的所有権を有するからである。 アトーンメント通知のテキストは次のとおりである。「あなたは規則書に従っ
て電子船荷証券のホールダーとして指定されました。指図側、荷受側、持参人、
または抵当権者としての指定に加え、電子船荷証券のホールダーとしてのあなた
の能力によって、本電子船荷証券のオリジネータ（輸送業者）に代わって行動す
る当サービス・プロバイダは、商品があなたの指図下で保持されることを認めま
す」。

【０５０８】 アトーンメント通知がいつ配達されるかに関する定義的な規則は図３１から３
７に示されている。 ４．７．８．２． 取引き拒否 ユーザが輸送契約の当事者として指定されると、ユーザは「取引拒否」を発動
することによって、契約者としての指定を拒否する機会を有する。妥当な取引拒
否権を発動することによって、オリジネータ（輸送業者）に対して契約関係を授
与する状態に指定されたユーザは、契約者（契約側）としての指定を拒否する。
その結果、輸送契約の当事者は、指定拒否の直前の当事者のままに留まる。取引
拒否権は、ユーザが輸送契約者になった場合に、（１）持参人ホールダーが自身
を指図側または荷受側に指定した場合、（２）ユーザが抵当権を執行した場合、
および（３）ユーザによる修正要求に応じて修正が認可された場合には、発動す
ることができない。このような場合に取引き拒否権を発動できない理由は、ユー
ザが輸送契約の当事者に指定されることの承諾を明確に与えているからである。
取引拒否メッセージは２４時間以内に送信されなければならず、また、当事者は
取引拒否権を発動する前に他の何れのタイトル・レジストリ命令も発令すること
ができない。ある当事者が２４時間後に、または同じＢＢＬに関連する別の命令
の発令後に、取引拒否を送信しようと試みると、タイトル・レジストリはメッセ
ージを拒否し、否定的アクノレッジメント（ＢＮＡＬ）を発する。

【０５０９】 タイトル・レジストリが有効な取引拒否を受理すると、それによってＢＢＬは
以前の状態（すなわちユーザが指定される前の状態）に戻され、以前の当事者に
拒否が通知される。タイトル・レジストリはまた、取引拒否権を発動した当事者
を裏書き連鎖から削除する（以下を参照）。

【０５１０】 取引き拒否権をいつ発動できるかに関する定義的な規則は図３１から３７に記
載されている。 ４．８． タイトル・レジストリの結果 タイトル・レジストリは、処理が完了すると送信側および受信側（１または複
数）に結果を送付する。この結果は上記のように受信側（１または複数）に対し
て自動的に作成される。結果が否定的である場合は、送信側への結果は、エラー
・コードおよび説明である。結果が肯定的である場合は、送信側への結果は、通
知されたユーザＩＤのリスト、および完全な受信側の結果情報である。エラー・
コードのリストは図４１に記載されている。

【０５１１】 送信側の結果が肯定的である場合、受信者の結果には以下の情報が含まれる。 （１）タイトル・レジストリ・レコードを変更させた命令。 （２）ｅＢＬ識別子、すなわちｅＢＬの文書ＩＤ。

【０５１２】 （３）ＢＢＬの現在の状態、すなわち使用可能（アクティブ）、一時停止、ま
たは終了状態を通知するステータス情報。使用可能である場合、ＢＮＬレコード
が存在し、認可された当事者によってアクションが起こされることが可能である
。一時停止状態の場合、ＢＢＬレコードは存在するが、修正が懸案中であるので
、オリジネータが修正認可命令または修正拒否命令を返信するまでは、アクショ
ンを起こすことはできない。終了状態にある場合、ＢＢＬレコードはタイトル・
レジストリのログにしか存在せず、もはや使用可能ではない。終了状態に入るの
は、紙への切換え又は引き渡し命令の結果である。

【０５１３】 （４）ＢＢＬの現時の当事者。 （５）それぞれの裏書きの日付および時間と共に、輸送契約の当事者の形式で
の裏書連鎖情報（すなわち、現在、および過去のホールダー／指図側、およびホ
ールダー／荷受側）。

【０５１４】 （６）命令の結果として、白地裏書きされたＢＢＬのホールダー、指図側また
は荷受側を兼ねるホールダー、またはプレッジー・ホールダーが存在する場合に
提供されるフリー・テキストであるアトーンメント通知。

【０５１５】 （７）要求ＩＤ、すなわち修正要求命令が発動された場合にタイトル・レジス
トリによって作成される識別子。 送信側の結果は、要求に応じて、ＢＮＡＫまたはＢＡｃｋのいずれかでメッセ
ージ・ハンドリング・ユニットによって送信される。受信側の結果はＦＭｓｇで
メッセージ・ハンドリング・ユニットによって送信される。

【０５１６】 ４．９． 期間および条件 サービス・プロバイダは、安全でインタラクティブな設備で、輸送業者が船荷
証券の期間と条件を記憶する設備を提供する。全ての登録されたユーザはこの情
報にアクセスすることができ、それぞれの船荷証券の期間と条件を送信する必要
をなくす。

【０５１７】 期間と条件を記憶するプロセスは以下のとおりである。 （１）輸送業者はデジタル・サインされたメッセージ（ＳＭｓｇ）をヘルプ・
デスクに送信する。ＳＭｓｇは、添付された期間と条件、および期間の効力が生
ずる日付を含んでいる。

【０５１８】 （２）ヘルプ・デスクの管理者は、期間と条件をシステムのインタラクティブ
な設備にロードする。 （３）ヘルプ・デスクの管理者は、期間と条件が提示されたことを確認するた
めのデジタル・サインされたメッセージ（ＳＭＳＧ）を輸送業者に送信する。

【０５１９】 （４）輸送業者は発効の日の前にインタラクティブなサイトで期間および条件
を検討する。 （５）輸送業者は、発効の日の前に提示された期間と条件の受入れを確認する
ためのデジタル・サインされたメッセージ（ＳＭＳＧ）をヘルプ・デスクに送信
する。

【０５２０】 （６）確認メッセージがヘルプ・デスクによって受信されない場合、発効の日
は、確認メッセージが受信されるまで延長される。 ４．１０． タイトル・レジストリ命令 図３３には各命令に対する以下の情報が図表で示されている。

【０５２１】 １．発令元 − 命令を発する権限を有する当事者。その他の全ての当事者は
タイトル・レジストリによって拒否される。 ２．必須情報 − 機能を実行するためにタイトル・レジストリに要求される
情報。必須情報が不完全であると、タイトル・レジストリはメッセージを拒否す
る。

【０５２２】 ３．オプション情報 − 認可された当事者が命令と共に送信できる追加の情
報。 ４．ｅＢＬを添付（同封）する必要性 − タイトル・レジストリはｅＢＬ文
書を利用しないので、受信者がｅＢＬを必要とする場合にそれを添付するのみで
よい。

【０５２３】 ５．取引拒否 − 当事者がホールダーと指図側または荷受側との双方になる
と、取引拒否権を発動できる。 ６．通知先 − タイトル・レジストリは、影響を受ける当事者に自動的に通
知する。送信側が、影響を受ける当事者を受信側として指定すると、メッセージ
・ハンドリング・ユニットはタイトル・レジストリ通知をフィルタリングする。

【０５２４】 ７．アトーンメント通知 − タイトル・レジストリは、命令の結果として、
白地裏書きされたＢＢＬのホールダーが存在するか、ホールダーが指図側または
荷受側をも兼ねるか、またはプレッジー・ホールダーが存在するかの場合に、ア
トーンメントの通知を作成する。

【０５２５】 ８．裏書連鎖レコード − タイトル・レジストリは、命令の結果として、ホ
ールダーが指図側または荷受側を兼ねる場合に、裏書き連鎖にエントリを作成す
る。

【０５２６】 ９．返送される裏書連鎖 − タイトル・レジストリは、作成後に当事者間で
ＢＢＬが譲渡されるときに、裏書き連鎖を発行する。 ここで、それぞれのタイトル・レジストリ命令をさらに説明する。

【０５２７】 ４．１０．１． 作成 Ｃｒｅａｔｅ（作成）命令の目的は、新規のＢＢＬに対してタイトル・レジス
トリにレコードを作成できるようにすることである。

【０５２８】 持参人ホールダーをもってＢＢＬが作成された場合のみ、アトーンメント通知
がなされる。 終了状態（ホールダーが指図側または荷受側を兼ねる）においてＢＢＬを作成
すること、またはプレッジャー・ホールダーをもってＢＢＬを作成することはで
きない。

【０５２９】 ４．１０．２． ホールダー指定 ホールダー指定（Name Holder）命令の目的は、既存のＢＢＬレコードにおけ
るホールダーシップ（所有権）を譲渡することである。

【０５３０】 命令の結果として、指図側または荷受側を兼ねる新規の持参人ホールダーまた
は新規のホールダーが存在する場合、アトーンメント通知が作成される。命令の
結果として、指図側または荷受側を兼ねる新規のホールダーが存在する場合には
、裏書き連鎖レコードが作成される。

【０５３１】 ４．１０．３． プレッジー・ホールダーの指定 プレッジー・ホールダー（Pledgee Holder）命令の目的は、プレッジー・ホー
ルダーの指定、または既存のＢＢＬレコードにおけるプレッジ・ホールダーシッ
プの譲渡である。

【０５３２】 ４．１０．４． 指図側の指定 指図側指定（Name To Order）命令の目的は、既存のＢＢＬレコードにおける
指図側（To Order party）の指定である。

【０５３３】 命令の結果として、ホールダーが指図側を兼ねる場合に、裏書き連鎖レコード
が作成される。裏書き連鎖は、持参人ホールダーが自らを指図側に指定した場合
に返送され、その後に送信側結果においてのみ返送される。

【０５３４】 ４．１０．５． 荷受側の指定 荷受側指定（Name Consignee）命令の目的は、既存のＢＢＬレコードにおける
荷受側の指定である。荷受側が指定されると、ＢＢＬは譲渡不可になる。

【０５３５】 命令の結果として、ホールダーが荷受側を兼ねる場合に、裏書き連鎖レコード
が作成される。裏書き連鎖は、持参人ホールダーまたは指図側を兼ねるホールダ
ーが自らを荷受側に指定した場合に返送され、その後に送信側結果においてのみ
返送される。

【０５３６】 ４．１０．６． 白地裏書き 白地裏書（Blank Endorse）命令の目的は、指定された指図側を有する譲渡可
のＢＢＬに白地裏書きすることである。

【０５３７】 ４．１０．７． 抵当権の執行 抵当権執行（Enforce Pledge）命令の目的は、既存のＢＢＬレコードにおいて
、プレッジー・ホールダーを譲渡可能ＢＢＬのホールダーおよび指図側（指定さ
れた場合）にすることである。

【０５３８】 裏書き連鎖レコードは、命令の結果として、ホールダーが指図側を兼ねている
場合に、作成される。裏書き連鎖は送信側結果においてのみ返送される。 ４．１０．８． 修正要求 修正要求（Request Amendment）命令の目的は、オリジネータに対して、既存
のＢＢＬレコードに関連するＢＢＬを修正するように要求することである。

【０５３９】 修正されるべき各ｅＢＬに対して裏書き連鎖が返送される。 ＢＢＬを「分割」（１部の原本から２部以上のＢＢＬを作成）、またはＢＢＬ
を「統合」（２部以上の原本から１部のＢＢＬを作成）するように修正要求する
ことができ、これは、この命令に関して複数のＢＢＬをタイトル・レジストリに
送信できることを意味する。

【０５４０】 ４．１０．９． 修正の認可 修正認可（Grant Amendment）命令の目的は、タイトル・レジストリにおける
ＢＢＬレコード（１または複数）の更新または作成による修正を認可することで
ある。

【０５４１】 アトーンメント通知に関しては、新規のバージョン番号を有するｅＢＬに対し
て、ホールダーではなかった指図側または荷受側を修正により削除する場合は、
アトーンメント通知が送信される。新規のｅＢＬ識別子を有するｅＢＬについて
は、ホールダーが指図側または荷受側ではない場合を除いて、修正されたｅＢＬ
ごとにアトーンメント通知が送信される。

【０５４２】 裏書き連鎖レコードに関しては、新規のバージョン番号を有するｅＢＬに対し
て、裏書き連鎖レコードは作成されない。新規のｅＢＬ識別子を有するｅＢＬに
対して、ホールダーが指図側または荷受側を兼ねている場合は、修正されたｅＢ
Ｌごとに裏書き連鎖レコードが作成される。

【０５４３】 裏書き連鎖の返送に関しては、これは、新規のバージョン番号を有するｅＢＬ
に対して行われる。新規のｅＢＬ識別子を有するｅＢＬに関しては、ホールダー
が指図側または荷受側を兼ねている場合は、修正されたｅＢＬごとに裏書き連鎖
が返送される。

【０５４４】 ＢＢＬを「分割」（１部の原本から２部以上のＢＢＬを作成）し、また、ＢＢ
Ｌを「統合」（２部以上の原本から１部のＢＢＬを作成）するように修正を認可
することができ、これは、この命令に対して複数のＢＢＬをタイトル・レジスト
リに送信できることを意味する。

【０５４５】 要求が終了状態から作成されない限り、修正認可命令によって、ＢＢＬを終了
状態（ホールダーが指図側または荷受側を兼ねている）へと修正することはでき
ない。

【０５４６】 オリジネータおよびホールダーまたはプレッジー・ホールダーは、修正要求か
ら変更できない。オリジネータおよびホールダーまたはプレッジー・ホールダー
のフィールドに修正認可が与えられた場合は、タイトル・レジストリはエラー（
ＢＮＡＫ）を作成する。

【０５４７】 ４．１０．１０． 修正の拒否 修正拒否（Deny Amendment）命令の目的は、タイトル・レジストリにおけるＢ
ＢＬレコード（１または複数）を修正要求前の状態に戻すことによる修正の拒否
である。

【０５４８】 ４．１０．１１． 紙への切換え 紙への切換え（Switch to Paper）命令の目的は、オリジネータに対して、原
本のＢＢＬから原本の紙の船荷証券を作成するように要求することである。

【０５４９】 紙への切換え命令の後は、ＢＢＬレコードはタイトル・レジストリでもはや使
用可能ではない。 ４．１０．１２． 引渡し 引渡し（Surrender）命令の目的は、ＢＢＬをオリジネータに返すことである
（輸送契約の義務を果たすため）。

【０５５０】 引渡し命令の後、ＢＢＬレコードはタイトル・レジストリでもはや使用可能で
はない。 ４．１１． タイトル・レジストリ命令ＰＤＵ タイトル・レジストリ命令は、メッセージ・ハンドリング・ユニットへ送信さ
れたＳＭＳＧに含まれる。ＴＲ ＤＴＤはメッセージ・ハンドリング・ユニット
ＤＴＤと同じ基本エレメントを使用する。

【０５５１】 ＲＩＤおよびＧｅｎｅｒａｌＩＤ（一般ＩＤ）のような一般エレメントの定義
は、メッセージ・ハンドリング・ユニットの場合と全く同様であり、データ・タ
イプへの同じ制約を含んでいる。DocumentID（文書ＩＤ）およびFreeText（フリ
ーテキスト）のようなエレメントも、メッセージ・ハンドリング・ユニットに対
して指定された基準と一致するが、最初にこれらがテキストに現れる情報として
以下に複写する。

【０５５２】 ４．１１．１． ＳＭＳＧ ＳＭＳＧは、付加価値アプリケーションおよび／または受信側へ転送するため
にメッセージ・ハンドリング・ユニットにメッセージを送信するために使用され
る。タイトル・レジストリ命令がＳＭＳＧに含まれる。形式は以下のとおりであ
る。 <!ELEMENT SMSG ( SntEnvelopeID, Sender, Receiver *, DeliveryAttr ?, Urgent ?, Reference *, ApplicationAttr ?, Document *, FreeText ? ) > タイトル・レジストリについては、ApplicationAttr（アプリケーション属
性）は下記のとおりである。 <!ELEMENT ApplicationAttr TRA > <!ELEMENT TRA ANY > ４．１１．２． 「指定（Name）」命令 「指定」命令は、契約者を指定する全ての機能（「BlankEndorse（白地裏書き
）」機能を含む）に対しての総称的な指定命令である。これによって、２人の当
事者が、同じメッセージの一部として実施される２つの同時的な指定機能で指定
されることが可能になる。形式は以下のとおりである。 <!ELEMENT Instruction ( CreateBBL | Name | EnforcePledge | RequestAmendment | GrantAmendment | DenyAmenendment | SwitchToPaper | Surrender ) > ４．１１．３． ＣｒｅａｔｅＢＢＬ（ＢＢＬ作成） CreateBBL（ＢＢＬ作成）命令の形式は以下のとおりである。 <!ELEMENT CreateBBL ( Document ID, BBLType, Originator, SurrenderParty?, Shipper, Holder, ( BlankEndorse | ToOrder | Consignee ) ) > <!ELEMENT DocumentID (RID, GeneralID, Version?) > <!ELEMENT BBLType EMPTY > <!ATTLIST BBLType Type ( Transferable | NonTransferable | ILLEGAL) "ILLEGAL"> <!ELEMENT Originator ( RID ) > <!ELEMENT SurrenderParty ( RID ) > <!ELEMENT Shipper ( RID ) > <!ELEMENT Holder ( RID ) > <!ELEMENT BlankEndorse EMPTY > <!ELEMENT ToOrder ( RID ) > <!ELEMENT Consignee ( RID ) > ＢＢＬの一貫性を確実にするために必須フィールド「BBLType（ＢＢＬタイプ
）」が用いられる。ＢＢＬタイプが「Transferable（譲渡可）」である場合、Ｂ
ＢＬをBlankEndorse（白地裏書き）とすするか、または指図側を指定できる。Ｂ
ＢＬタイプが「NonTransferable（譲渡不可）」である場合、荷受側が指定され
なければならない。

【０５５３】 ４．１１．４． Ｎａｍｅ（指定） 指定機能の形式は以下のとおりである。 <!ELEMENT Name ( Document ID, BBLType?, ( Holder, ( ToOrder | Consignee | BlankEndorse )? ) | ( PledgeeHolder, ( ToOrder | BlankEndorse )?) | ( ToOrder | Consignee | BlankEndorse ) <!ELEMENT PledgeeHolder ( RID ) > 指定機能は、ＢＢＬにおける全ての役割を指定するために使用される総称的な
機能である。指定副機能（sub-function）は、総称的な指定機能のパラメータと
して指定される。

【０５５４】 ＢＢＬは、ToOrder（指図側）、Consignee（荷受側）またはBlankEndorse（白
地裏書き）のうちの一つ且つ唯一のものを有していなければならない。 新規のホールダー及びもう一つの役割を１つのメッセージで指定することがで
きる。これは同時機能と呼ばれる。

【０５５５】 指図側、白地裏書き、または荷受側が指定される場合、BBLType（ＢＢＬタイ
プ）は必須である。 荷受側が指定され際に、ＢＢＬタイプは「譲渡不可」でなければならない。指
図側が指定されるか、またはＢＢＬが白地裏書きとされる場合、ＢＢＬタイプは
「譲渡可」でなければならない。

【０５５６】 白地裏書き、又は指図側が指定されているＢＢＬに対しては、PledgeeHolder
（プレッジー・ホールダー）を指定することだけが可能である。 ４．１１．５． ＥｎｆｏｒｃｅＰｌｅｄｇｅ（抵当権の執行） 抵当権執行命令の形式は以下のとおりである。 <!ELEMENT EnforcePledge ( DocumentID ) > プレッジー・ホールダーは抵当権を執行することができる。これは、プレッジ
ー・ホールダーがホールダーおよび指図側としての役割に入ることを示唆する。
後者は、抵当権の執行前に指図側が指定された場合だけである。

【０５５７】 ４．１１．６． ＲｅｑｕｅｓｔＡｍｅｎｄｍｅｎｔ（修正要求） 修正要求命令の形式は以下のとおりである。 <!ELEMENT RequestAmendment ( DocumentID+, FreeText ) > <!ELEMENT FreeText ( #PCDATA ) > <!ATTLIST FreeText xml:space (default | preserve) “preserve”> 送信側はオリジネータに対してＢＢＬを修正するように要求する。修正は、同
じ文書の新バージョンでよく、または、１または複数の新規の文書を作成しても
よい。後者の場合は、古い文書はタイトル・レジストリでもはや使用可能ではな
い。

【０５５８】 送信側は以下の３種類の修正のうちの１つを要求することができる。（１）１
つの文書を新規の文書（もしくは新バージョン）に置換する。（２）幾つかの文
書を１部の新文書に置換する（統合、マージ）、この場合、修正要求における全
ての文書のオリジネータは同一でなければならない。（３）１つの文書を幾つか
の新規文書に置換する（分割）。

【０５５９】 修正に関する情報を非構成（フリー）のテキストとしてオリジネータへ送信す
ることができる。要求のアイデンティフィケーションは、通知の一部（Ｒｅｑｕ
ｅｓｔＩＤ）としてオリジネータへ送られる。

【０５６０】 ４．１１．７． ＧｒａｎｔＡｍｅｎｄｍｅｎｔ（修正の認可） 修正認可命令の形式は以下のとおりである。 <!ELEMENT GrantAmendment ( RequestID, GrantDocument+ ) > <!ELEMENT RequestID ( NumericID ) > <!ELEMENT GrantDocument ( Document ID, BBLType, SurrenderParty?, Shipper, ( BlankEndorse | ToOrder | Consignee ) ) > 修正認可は、オリジネータが修正要求を受理し、１または複数の新規の文書（
または旧文書の新バージョン）を認可した場合に、オリジネータによって出され
る。ホールダーが１つの文書を２つ以上の新規の文書に置換すること（分割）を
要求した場合、文書認可命令において２つ以上の文書を指定することのみが許容
される。

【０５６１】 修正要求は最初のパラメータ（要求ＩＤ）において識別される。 認可された各文書ごとに、役割およびその他の属性が記述子（GrantDocument(
文書認可））に指定される。

【０５６２】 オリジネータの役割およびホールダーまたはプレッジー・ホールダーの役割は
、修正要求／認可プロトコルによって暗黙に定義される。要求の送信側は、新規
のホールダー（および旧ホールダー）であり、修正認可の送信側は、全ての旧文
書および新文書のオリジネータである。

【０５６３】 ４．１１．８． ＤｅｎｙＡｍｅｎｄｍｅｎｔ（修正の拒否） 修正拒否命令の形式は以下のとおりである。 <!ELEMENT DenyAmendment ( RequestID ) > オリジネータは修正要求を拒否する。修正要求命令で照会（参照）される文書
はもはや一時停止状態にはない。

【０５６４】 ４．１１．９． ＳｗｉｔｃｈＴｏＰａｐｅｒ（紙への切換え） 紙への切換え命令の形式は以下のとおりである。 <!ELEMENT SwitchToPaper ( DocumentID ) > この機能の実行後、オリジネータは紙バージョンのＢＢＬを作成する責任を負
う。ＢＢＬはタイトル・レジストリにおいてもはや使用可能ではない（状態は「
終了」になる）。

【０５６５】 ４．１１．１０． Ｓｕｒｒｅｎｄｅｒ（引渡し） 引渡し命令の形式は以下のとおりである。 <!ELEMENT Surrender ( DocumentID ) > ＢＢＬはオリジネータに返送され、そこでオリジネータは輸送契約の下にその
要求を完了しなければならない。ＢＢＬはタイトル・レジストリにおいてもはや
使用可能ではない（状態は「終了」になる）。

【０５６６】 ４．１２． タイトル・レジストリ結果ＰＤＵ タイトル・レジストリは、標準的な結果ＰＤＵでタイトル・レジストリ命令の
実行に関する情報をメッセージ・ハンドリング・ユニットへ送る。結果中の２つ
のエレメント（送信側フィードバック（SenderFeedback）および受信側フィード
バック（ReceiverFeedback））について、タイトル・レジストリは送信側および
通知されるべき当事者へ、特定の情報を送る。

【０５６７】 送信側フィードバックは、メッセージ・ハンドリング・ユニットによって送信
側へ送られるＢＡＣＫに含まれる。受信者フィードバックは、メッセージ・ハン
ドリング・ユニットによって送信側へ送られるＦＭＳＧに含まれる。ＢＡＣＫお
よびＦＭＳＧの詳細については［１］を参照されたい。タイトル・レジストリに
関連するＢＡＣＫおよびＦＭＳＧにおける特定のエレメントを情報資料としてこ
こに複写する。

【０５６８】 タイトル・レジストリはまた、妥当なＳＢＲｆ（取引き拒否）を受理すると標
準的な結果を出す。この結果はメッセージ・ハンドリング・ユニットによって当
初の送信側に送られたＦＢＲｆ内に含まれる。タイトル・レジストリに関連する
ＳＢＲＦおよびＦＢＲＦ内の特定のエレメントを情報資料としてここに複写する
。

【０５６９】 タイトル・レジストリはまた、有効なＳＢＲｆ（取引拒否）を受け取ると、標
準的な結果を発行する。その結果は、メッセージ・ハンドリング・ユニットによ
り元の送信側へ送られるＦＢＲｆに含まれる。タイトル・レジストリに関連する
ＳＢＲＦおよびＦＢＲＦの特定のエレメントを、情報としてここに複写する。

【０５７０】 ４．１２．１． ＳｅｎｄｅｒＦｅｅｄｂａｃｋ（送信側フィードバック） タイトル・レジストリは、命令の送信側へ、肯定または否定のフィードバック
を送る。否定的フィードバックはエラー状態の結果である。肯定的フィードバッ
クは、妥当性が確認されたタイトル・レジストリ命令の結果である。フィードバ
ックは、メッセージ・ハンドリング・ユニットによって送信側へ返送されるＢＮ
ＡＫまたはＢＡＣＫに送られる。

【０５７１】 ４．１２．１．１． 否定的フィードバック 否定的フィードバックの形式は以下のとおりである。 <!ELEMENT Reason ( ReasonSource, ReasonCode, ReasonDescription? ) > <!ELEMENT ReasonSource ( #PCDATA ) > <!ELEMENT ReasonCode ( #PCDATA ) > <!ELEMENT ReasonDescription ( #PCDATA ) > <!ATTLIST ReasonDescription xml:space ( default | preserve ) “preserve”> 理由ソース（ReasonSource）は、関連する値が付加されたアプリケーションを
示すために用いられる。タイトル・レジストリの場合、理由ソースは常に「ＴＲ
Ａ」である。理由コード（ReasonCode）は、クライアント・コンピュータが利用
することを目的としたエラーの数値である。理由記述（ReasonDescription）は
、エラーを記述するテキストである。エラー・コードのリストは図４１に含まれ
ている。

【０５７２】 否定的フィードバックは、メッセージ・ハンドリング・ユニットによってＢＡ
ＮＫにおいて送信側へ送られる。ＢＮＡＫの形式は以下のとおりである。 <!ELEMENT BNAK ( SntEnvelopeID, Sender, Reason, Time, ApplicationResult ?, OriginalSignature ) > タイトル・レジストリに対して、ApplicationResult（アプリケーション結果
）は以下のとおりである。 <!ELEMENT ApplicationResult TRA > <!ELEMENT TRA ANY > ４．１２．１．２． 肯定的フィードバック 否定的フィードバックの形式は以下のとおりである。 <!ELEMENT SenderFeedback ( NotifiedParties?, RequestID?, Instruction, BB
LInfo* ) > <!ELEMENT NotifiedParties ( RID )* > <!ELEMENT RequestID ( NumericID ) > <!ELEMENT BBLInfo ( Document ID, FreeText?, BBLState, Originator, SurrenderParty?, Shipper, (Holder | PledgeeHolder), ( ToOrder | Consignee )? EndorsementChain? ) > <!ELEMENT EndorsementChain ( EndorsementEntry )+ > <!ELEMENT EndorsementEntry ( Time, ( ToOrder | Consignee )) > NotifiedParty（通知された当事者）とはユーザＩＤであって、それに対して
タイトル・レジストリが命令に基づいて返答を自動的に作成する、ユーザＩＤで
ある。RequestID（要求ＩＤ）はRequestAmendment（修正要求）の数値識別子で
ある。この識別子は、要求を識別するために、後続の修正拒否または修正認可に
際して使用されなければならない。フィールドは修正要求命令によって作成され
るReceiverFeedback（受信側フィードバック）にのみ存在する。Instruction（
命令）は、ＳＭＳＧからのタイトル・レジストリ命令のコピーである。情報によ
って、返答のコンテキストを理解できるようになる。BBLInfo（ＢＢＬ情報）は
、関連する当事者およびEndorsementChain（裏書き連鎖）を含む、ＢＢＬの現時
点のレコードを提供する。フリー・テキスト（FreeText）はアトーンメント情報
に対してのみ使用される。これは、命令の結果として当事者が法定的所有権を有
する場合に、作成される。BBLState（ＢＢＬ状態）はＢＢＬの状態（「使用可能
」、「終了」、「一時停止」）を含む。裏書き連鎖（EndorsementChain）はＢＢ
Ｌの全ての契約者（荷主を含む）のエントリと、裏書きの時間とを含む。

【０５７３】 肯定的フィードバックはメッセージ・ハンドリング・ユニットによってＢＡＣ
Ｋにおいて送信側へ送られる。 ＢＡＣＫの形式は以下のとおりである。 <!ELEMENT BACK SntEnvelopeID, Sender, Reason, Time, ApplicationResult ?, OriginalSignature ) > タイトル・レジストリに対して、アプリケーション結果（ApplicationResult
）は以下のとおりである。 <!ELEMENT ApplicationResult TRA > <!ELEMENT TRA ANY > ４．１２．２ ＲｅｃｅｉｖｅｒＦｅｅｄｂａｃｋ（受信側フィードバック） タイトル・レジストリは以下の形式でメッセージ・ハンドリング・ユニットに
ReceiverFeedback（受信側フィードバック）を送る。 <!ELEMENT ReceiverFeedback Request ID?, Instruction, BBLInfo* ) > 含まれる情報は肯定的な送信者フィードバック（SenderFeedback）と同じであ
る。

【０５７４】 ４．１２．２．１． ＦＭＳＧにおける受信側フィードバック ＦＭＳＧはＳＭＳＧの妥当性検査（メッセージ・ハンドリング・ユニットおよ
びＴＲ内）がなされると、指定又は通知される受信者（１または複数）へ送信さ
れる。タイトル・レジストリの受信者フィードバック（ReceiverFeedback）はＦ
ＭＳＧに含まれる。形式は以下のとおりである。 <!ELEMENT FMSG ( FwdEnvelopeID SntEnvelopeID, Sender, Receiver, Urgent ?, OtherReceiver ?, Time, ExpiryDate, Reference *, ApplicationInfo ?, Document *, FreeText ? ) > タイトル・レジストリに対して、ApplicationInfo（アプリケーション情報）
は以下のとおりである。 <!ELEMENT ApplicationInfo TRA > <!ELEMENT TRA ANY > ４．１２．３． 取引拒否 タイトル・レジストリは、メッセージ・ハンドリング・ユニットによって使用
される取引拒否ＰＤＵを用いる。ユーザは、タイトル・レジストリ命令を拒否す
るためにＳＢＲＦを送信し、メッセージ・ハンドリング・ユニットは、タイトル
・レジストリによる処理の後にＦＢＲＦを関連のユーザへ転送する。

【０５７５】 ４．１２．３．１． ＳＢＲＦ ＳＢＲＦは、契約状態を戻すためにタイトル・レジストリ命令と共にＦＭＳＧ
の受信側によって使用される。タイトル・レジストリは、ホールダーと指図側ま
たは荷受側を兼ねる当事者からのＳＢＲＦのみを受理し、そして、（１）ＳＢＲ
Ｆが関連するＢＡＣＫの２４時間以内に発せられたとき、また、（２）識別され
たＢＢＬに関連してその他の妥当な命令が送信されなかたときに限り受理する。

【０５７６】 ＳＢＲＦの形式は以下のとおりである。 <!ELEMENT SBRF ( SntEnvelopeID, Sender, DeliveryAttr ?, Urgent ?, SMSGEnvelopeId, BusinessReason ) > <!ELEMENT BusinessReason (#PCDATA) > <!ATTRLIST BusinessReason xml:space (default|preserve)‘preserve’> メッセージ・ハンドリング・ユニットおよびタイトル・レジストリによるＳＢ
ＲＦの妥当性検査の後、メッセージ・ハンドリング・ユニットは送信側へＢＡＣ
Ｋを発し、受信側（１または複数）へＦＢＲＦを発する。

【０５７７】 ４．１２．３．１． ＦＢＲＦ ＦＢＲＦは、ＳＢＲＦおよびタイトル・レジストリからの妥当な応答を受信す
ると、メッセージ・ハンドリング・ユニットによって作成される。ＦＢＲＦは、
メッセージ・ハンドリング・ユニットによって、拒否されたＳＭＳＧの送信側へ
送られる。ＦＢＲＦの形式は以下のとおりである。 <!ELEMENT FBRF ( FwdEnvelopeID, SntEnvelopeID, Sender, Receiver, Urgent ?, OtherReceiver ?, Time, ExpiryDate, SMSGEnvelopeId, BusinessReason, ApplicationInfo ? ) > ＦＢＲＦを受信し、そのサインを照合した後、受信側はＵＡｃｋを返信するこ
とを要求される。ＦＢＲＦはＳＢＲＦによって拒否されることはできなきい。Ｆ
ＢＲＦのサインが無効であり、ＵＮＡｋが返信された場合、タイトル・レジスト
リは、ＳＢＲＦに従って実施された復旧（戻し）を無効にしない。

【０５７８】 ４．１３． タイトル・レジストリ機能と当事者（party、側） 図３２の表はタイトル・レジストリで利用できる機能の要約と、何れの当事者
が各機能を実行できるかを示している。記述を完全なものにするために、一度に
ＢＢＬに存在できる当事者の可能な全ての組合わせ（「状態」と呼ばれ，図表の
上部をカバーする）と、各状態で利用できる機能（図表の下部をカバーする）と
を定義した。用いられている略語はＯ＝オリジネータ、ＳＰ＝引渡側、Ｓ＝荷主
（荷送人）、Ｈ＝ホールダー、ＰＨ＝プレッジー（質権者）、ＴＯ＝指図側、Ｃ
＝荷受側（受託者）、である。

【０５７９】 図３２の表の上付き文字について説明する。 １： 引渡側の役割はオプションである。 ２： ホールダーは自らを質権者（プレッジー）ホールダーに指定できない。

【０５８０】 ３： プレッジー・ホールダーは、抵当権を保持している場合は自らを指図側
に指定できない。 ４： プレッジー・ホールダーは、同時命令によってホールダーをも指定する
場合、荷受側を指定することのみできる。

【０５８１】 ５： 要求が終了状態にないか、またはプレッジー・ホールダーからのもので
ない限りは、要求を終了状態（Ｈ＝ＴＯまたはＨ＝Ｃ）に、またはプレッジー・
ホールダーを伴って認可することはできない。

【０５８２】 ４．１４．タイトル・レジストリ機能および条件 図３３はタイトル・レジストリにおいて可能な機能と、適用される条件とを要
約している。特定の役割で可能な機能を判定するには図３２を参照されたい。

【０５８３】 図３３で用いられる略語は以下のとおりである。 ＩＤ − 文書ＩＤ（ｅＢＬ識別子） Ｔ − ＢＢＬタイプ（譲渡可または譲渡不可） Ｏ − オリジネータ ＳＰ − 引渡側 Ｓ − 荷主（荷送人） Ｈ − ホールダー ＰＨ − プレッジー・ホールダー ＴＯ − 指図側 Ｃ − 荷受側（受託者） Ｂ − 白地裏書き ＲＡＩＤ − 修正要求ＩＤ。

【０５８４】 図３３の表の上付き文字について説明する。 １．交付（発行）側およびオプションの当事者は図３２および添付のテキスト
に規定された規則を遵守しなければならない。

【０５８５】 ２．オプションの当事者が含まれている場合。 ３．これは同時的なホールダー指定および指図側指定または荷受側指定命令を
含む。命令の結果としてホールダーが変更されない場合は、取引き拒否を発する
ことはできない。

【０５８６】 ４．オリジネータおよびホールダーまたはプレッジー・ホールダーは元のＢＢ
Ｌ（１または複数）から変更することはできない。 ５．送信側結果においてのみ返信される。

【０５８７】 ６．修正される各ｅＢＬごとに１つ。 ４．１５． 状態管理 タイトル・レジストリは、以下の４つの機能エレメントに関して各ＢＢＬの状
態を能動的に管理する。（１）アトーンメント通知の配達、（２）取引拒否の許
容、（３）裏書き連鎖レコードの作成、および（４）裏書き連鎖レコードの配達
。

【０５８８】 図３１から図３７は上記の各エレメントに関する完全かつ定義的な規則を記載
している。これらの表は、上記のテキストとの何れの明確な矛盾よりも先立つも
のである。

【０５８９】 図３１から図３７は、１つの状態から他の状態への動き、および各動きの結果
としての、４つのエレメントに関するタイトル・レジストリのアクションを記述
している。その例外は、チャート作成（Create chart）であるが、その理由は、
以前の状態がないからである。

【０５９０】 図３１から図３７で用いられる略語は以下のとおりである。 ＢＨ − 持参人ホールダー ＰＨ − プレッジー持参人ホールダー ＴＯ − 指図側 Ｃ − 荷受側 Ａ − アトーンメント通知の配達 Ｂ − 取引拒否の許容 Ｒ − 裏書連鎖レコードの作成 Ｄ − 裏書連鎖の配達（裏書レコードが存在する場合だけ適用可能） ヌル（Ｎｕｌｌ） − タイトル・レジストリはこの状態変化の結果として、
アトーンメント通知、取引拒否、および裏書レコード作成及び配達に対して何の
アクションも起こさない。

【０５９１】 空白のボックス又はセルは、１つの状態から別の状態への移行が不可能である
ことを示す。特に注記されていない限り、表は受信側情報だけをカバーし、送信
側情報を反映するものではない。

【０５９２】 ４．１５．１． Ｃｒｅａｔｅ（作成） 図３４に示すように、ＢＢＬが作成されると、関連するエレメントだけがアト
ーンメント通知であり、従って、ＢＢＬが持参人ホールダーをもって作成された
場合だけである。

【０５９３】 ４．１５．２． ホールダーおよびプレッジー・ホールダーの指定 ホールダーおよびプレッジー・ホールダーの指定に関する図３５は、ホールダ
ー指定命令およびプレッジー・ホールダー指定命令を含んでいる。図３５はまた
、命令の結果として生ずる２つの場合、すなわち、ホールダーまたはプレッジー
・ホールダーが変化しない場合（「０」で示す）、およびホールダーまたはプレ
ッジー・ホールダーが新規の当事者である場合（「１」で示す）をも区別する。

【０５９４】 ４．１５．３． 指図側、荷受側、および白地裏書きの指定 図３６、すなわち指図側、荷受側、および白地裏書きの指定のチャートは、指
図側指定命令、荷受側指定命令、および白地裏書き指定命令を含んでいる。図３
６は、別の部分に記載されている同時命令を含んでいない。図３６の上付き文字
１は、裏書き連鎖が送信側結果のみと共に配達されることを示している。

【０５９５】 ４．１５．４． 同時命令 図３７は、許容された同時命令の取扱いを示した表である。 第１群の許容された同時命令は、ホールダー指定命令と、（ｉ）指図側指定命
令、（ｉｉ）荷受側指定命令、または（ｉｉｉ）白地裏書き命令のいずれかとの
組合わせである。許容される別の組合わせは、指図側指定命令と同時のプレッジ
ー・ホールダー指定命令である。

【０５９６】 図３７はまた、命令の結果として生ずる以下の２つの場合を区別するものであ
る。第１に、ホールダーまたはプレッジー・ホールダーが変化しない場合（「０
」で示す）、および、第２に、ホールダーまたはプレッジー・ホールダーが新規
の当事者である場合（「１」で示す）。

【０５９７】 ４．１５．５． 抵当権の執行 図３８は抵当権の執行命令の取扱いを示している。抵当権執行命令が発せられ
る際の唯一の関連エレメントは、指定された指図側がいるＢＢＬに抵当権が執行
されるときに作成され配達される裏書き連鎖レコードである。図３８の上付き文
字１は、裏書き連鎖が送信側結果のみと共に配達されることを示している。

【０５９８】 ４．１５．６． 新規のｅＢＬバージョンを伴う修正認可 図３９は、新規のｅＢＬバージョンがある場合の修正認可命令の取扱いを示し
ている。オリジネータは、これが一つのＢＢＬを別のＢＢＬと入れ替える場合に
、新規のｅＢＬバージョンを伴う修正認可を発行するのみが可能である。この場
合、裏書き連鎖は以前のＢＢＬから繰り越される。この場合、影響されるエレメ
ントのみが、持参人ホールダーに認可される修正に関するものであり、この場合
、指図側または荷受側が削除されるとアトーンメント通知が送信される。

【０５９９】 ４．１５．７． 新規のｅＢＬ識別子を伴う修正認可 図４０は、新規のｅＢＬ識別子がある場合の修正認可命令の取扱いを示してい
る。オリジネータは、一つのＢＢＬを置換するため、ＢＢＬを統合するため、ま
たはＢＢＬを分割するために、新規のｅＢＬ識別子を使用する。このような場合
、持参人ホールダー、プレッジー・ホールダーがいるあらゆる場合、またはホー
ルダーが指図側または荷受側を兼ねる場合に、アトーンメント通知が作成される
。後者の場合、裏書き連鎖レコードが作成され配達される。図４０の上付き文字
１は、複数のｅＢＬが修正認可をもって返送されると、複数のアトーンメント通
知が配達され、複数の裏書き連鎖レコードが作成され配達されるということを示
している。

【０６００】 ４．１６． エラー・メッセージ タイトル・レジストリ命令の実行結果は、肯定的または否定的なものであり得
る。結果が肯定的である場合は、命令は首尾良く実行されたことになる。結果が
否定的である場合は、命令は実行されておらず、結果メッセージが送信側に返信
される。この場合は何れのシステム・ユーザにもメッセージは送られない。各々
の否定的エラーについては、理由ソース、理由コード、および理由記述（理由説
明）とともに更に説明する。

【０６０１】 図４１は、入来メッセージにおける妥当性検査エラーまたはその他のエラーの
結果として送信側が受信し得るエラーをリストし、説明している。タイトル・レ
ジストリまたはメッセージ・ハンドリング・ユニットの内部システム・エラーは
リストには含まれていない。あらゆる場合、ReasonSource（理由ソース）はＴＲ
Ａである。

【０６０２】 ５． 規則書（ルールブック） 前述したように、各々のユーザは、システムのユーザになる条件として、規則
書と呼ばれる規則の本に規定されている１組の規則の条項に拘束されることに合
意する。規則書およびそれに対するユーザの契約上の合意は、システムを支持し
、例えば、データベース・レコードのコンテンツの法的重要性およびメッセージ
の法的効力を規定することで、システムが財産取引きのサポート・システムとし
て機能できるようにする。念のために規則書をここに複写する。

【０６０３】 １． 定義と解釈 １．１． 定義 受け入れ、受諾： サーティフィケートに関して、明示的に、または例えばか
かるサーティフィケートを照会して照合可能なデジタル・サインを作成すること
によって暗示的に、サーティフィケートの是認を証明することである。

【０６０４】 添付物、添付文書： 文書（ドキュメント）の項を参照。 ＢＢＬテキスト： （ａ）メッセージ・ハンドリング・ユニットに送信され、
タイトル・レジストリに電子船荷証券の文書要素としてレコードされ、（ｂ）海
上輸送の輸送業者によって商品の受領をアクノレッジする、文書である。

【０６０５】 持参人ホールダー： 白地裏書きされた電子船荷証券の指定ホールダーである
か、その指定ホールダーになるユーザである。 受益ユーザ： 荷為替信用状（Documentary Credit）で指定された当事者であ
って、その当事者に対してまたはその当事者の指図に対して、支払いがなされる
か、またはその為替手形が受理され支払われるべきである当事者であるユーザ。

【０６０６】 白地裏書き： 運用手順に記載されているプロセスによって、電子船荷証券を
単に新規のホールダーの指定によって譲渡できるようにすること。 中央システム、またはシステム： 取引きプロセスおよび方法であり、メッセ
ージおよび文書を通信し、かつ商業取引きを促進するためにサービス・プロバイ
ダＸＹＺ社によって提供されるデジタル情報システムであり、双方を管理する規
則。

【０６０７】 輸送業者： 何らかの輸送手段によって商品を輸送するための契約を別のユー
ザと行うユーザであり、輸送業者が、使用される輸送手段のオーナーであるか操
作者であるかは関係ない。

【０６０８】 サーティフィケート： 最低でも、（ａ）交付人の名義をリストし、（ｂ）公
開鍵をリストし、（ｃ）リストされた公開鍵に対応する非公開鍵を保持するユー
ザを名義でリストするか、又はその他の方法で示し、（ｄ）交付人によってデジ
タル・サインされ、かつ（ｅ）関連する文書形式でそれに帰属する本定義と意味
が一致する、情報ユニットである。

【０６０９】 サーティフィケーション・アカウント: ＸＹＺ社とユーザとの関係性であり
、ＸＹＺ社がユーザへのサーティフィケートの交付人として行動し、ユーザはこ
れらのサーティフィケートの加入者として行動する。

【０６１０】 サーティファイヤ（証人）： ユーザにサーティフィケートを交付する者（Ｘ
ＹＺ社によって認定）である。特定のサーティフィケートを交付するサーティフ
ァイヤもその「交付人（Issuer）」と呼ばれる。

【０６１１】 公認された船荷証券(Chartered Bill of Landing)： 船舶での輸送について
商品の受け取りの輸送業者による承認のことであり、これに関して、同じ航海に
対して（航海用船）または上記輸送が行われる期間に対して（期間用船契約）の
何れかの、船舶の使用に関して現在効力を有する裸用船または裸用船契約以外の
、用船契約が存在する。

【０６１２】 荷受側ホールダー： 電子船荷証券の荷受側とホールダーとに同時に指定され
るユーザ。 通信リンク： ユーザによって確立される、中央システムとのデジタル・ネッ
トワーク接続のことである。

【０６１３】 荷受側： 輸送業者によって商品の配達がなされなければならず、かつ電子船
荷証券を譲渡不可にする意思を示す当事者として特定されるように、荷受側とし
て指定されるユーザ。

【０６１４】 指定： 電子船荷証券に関してタイトル・レジストリ内の役割にユーザを記名
、または指名すること。「指定」とは、指定する行為、または指定された状態を
意味する。

【０６１５】 デジタル・サイン（デジタル署名）： デジタル情報のユニットと非公開鍵と
から計算される数学的結果であり、情報ユニットおよびこれに対応する公開鍵を
有する者が、照合することによって、（１）その数学的結果が前記非公開鍵を使
用して作成されたのか否か、および（２）前記数学的結果が計算されてから情報
ユニットが変更されたか否かを、正確に判定できるようにする。

【０６１６】 文書： メッセージの細分化された部分として送信される、契約書、証券、ま
たは多くの場合はテキスト形式のその他の実在的な情報ユニットである。同義語
は添付物、添付文書。

【０６１７】 文書識別子、もしくは「文書ＩＤ」： システムへと送信され、システムによ
ってトラックされる文書の一意的な識別子である。 サーティフィケートの文書形式： 交付人によって認定されたサーティフィケ
ートのテキスト解釈。

【０６１８】 電子船荷証券（ｅＢＬ）： 関連のタイトル・レジストリ・レコードを伴うＢ
ＢＬテキストである。 登録、登録済み： 運用手続きサービス契約に基づいてシステムのユーザにな
ること。

【０６１９】 ヘッド・チャーター： 船舶のオーナーまたはディスポネント(disponent)オ
ーナーとしての輸送業者と、用船契約者としての別のユーザとの間の、裸用船ま
たは裸用船契約以外の用船契約のことであり、特定の航海または一連の航海、ま
たは特定期間にわたり貨物を輸送する目的で輸送業者の船舶を使用するためのも
のである。

【０６２０】 ヘッド・チャータラー： 輸送業者とのヘッド・チャーターを契約するユーザ
である。 指図側ホールダー： 電子船荷証券のホールダーと指図側との双方になるか、
または双方に同時に指定されるユーザである。

【０６２１】 ホールダー： 同時に指図側でも持参人ホールダーでもないホールダーである
か、またはそのようなホールダーに指定されるユーザ。 サーティフィケート（証書）の交付： 証書に自らが交付人であると記載し、
その証書にデジタル・サインすること。証書を交付する業務に携わる人も「サー
ティファイヤ」と呼ばれる。

【０６２２】 交付人： 証書に関連して、証書を交付したサーティファイヤのことである。 メッセージ： メッセージ・ハンドリング・ユニットを介して送信され、また
前述のフォーマットである、あらゆる通信、文書、通知、またはその他の情報で
ある。

【０６２３】 メッセージ・ハンドリング・ユニット： 前述のように、サービス・プロバイ
ダによって中央システムの一部として維持されるメッセージング・システムであ
る。

【０６２４】 解約通知： 証書に関連して、証書の交付人、または交付人によって認定され
た物による、証書が解約された旨のステートメントのことである。 運用手続き(operating procedure)： このタイトルの文書である。（運用手
続きは、実質的に本特許明細書の詳細な説明で説明したとおりである。） オペレーション規則： ユーザが遵守する義務がある必須条項を含む運用手続
きの部分である。

【０６２５】 運用手続きサービス契約： 各ユーザとＸＹＺ者との間の、随時に修正される
標準的な形式の契約である。 プレッジー・ホールダー： 抵当設定者とホールダーとを同時に兼ねる、また
はそのように指定されるユーザである。

【０６２６】 非公開鍵： デジタル・サインを作成するために使用される一対の鍵のうちの
鍵である。 公開鍵： デジタル・サインを照合するために使用される一対の鍵のうちの鍵
である。

【０６２７】 信頼側（Relying Party）： デジタル・サインを照合し、また、証書の表示
内容を信頼する者、またはその双方の者。 解約： 証書に関して、適宜の照会に応答して証書の交付人がその証書（各々
または纏めて）が解約された旨を通知している、証書のクラスに、証書を含める
こと。

【０６２８】 規則、ルール・ブック、またはルールブック： 随時修正され、ユーザとユー
ザによるシステムの利用との関係を支配する規則書である。 船舶貨物運送状： ＢＢＬテキストまたは船舶の荷渡し指図以外の文書であり
、船舶による商品の輸送契約を含み、または証明し、かつかかる契約に従って輸
送業者により商品が配達されるユーザーを特定するような商品の領収書である。

【０６２９】 サービス： システムを介してＸＹＺ社によって提供され、運用手続サービス
契約に指定されているサービスのことである。 荷主（荷送人）： 輸送業者が船舶による品物の輸送契約を締結する、元の契
約側であるユーザ。

【０６３０】 船舶の荷渡（配達）指図： ＢＢＬテキスト、または船舶貨物運送状以外の文
書であり、特定の商品、およびこれらの特定商品を含む商品の船舶による輸送契
約に基づいて、または輸送契約の目的のために、これらの商品を特定のユーザに
配達する保証を含む。

【０６３１】 サイン済み： 適正にデジタル・サインされたこと、すなわち、ＸＹＺ社によ
り交付された証書にリストされた公開鍵を使用して照合でき、かつデジタル・サ
インの作成時に有効な証書であった、デジタル・サインがなされていること。

【０６３２】 加入者（サブスクライバ）： 証書にリストされている公開鍵に対応する非公
開鍵を保持するものとして前記証書に特定されている者である。加入者は技術的
な基準では「サブジェクト(subject)」と呼ばれることが多い。

【０６３３】 引渡し（Surrender）： 船舶輸送の終了時に商品が荷渡しされるように、オ
ペレーション規則に従って、輸送業者または輸送業者によって指定された他のユ
ーザに電子船荷証券を提出すること。

【０６３４】 引渡側： 引渡側であるか又はまたはそのように指定されるユーザであり、そ
のユーザに対して、船舶輸送の終了時に商品が荷渡しされるように電子船荷証券
が提出されなければならない。

【０６３５】 タイトル・レジストリ： 貿易取引き、特に船積みおよび電子船荷証券に関連
する貿易取引きで使用される情報のシステムの中央電子レポジトリのことである
。タイトル・レジストリはＸＹＺ社によって実行されるアプリケーションであり
、以下の手段を提供する。（ａ）電子船荷証券のホールダーシップおよび譲渡に
関する機能を実行する。（ｂ）現時の電子船荷証券の状態のレコードを維持する
。（ｃ）前記の電子船荷証券に関する監査証跡を維持する。

【０６３６】 タイトル・レジストリ命令、命令： タイトル・レジストリが、特定の電子船
荷証券についてのタイトル・レジストリ・レコードに或る種の特定の情報を入力
するか、またはこれを変更するように指示するタイプ・ヘッダの部分である。

【０６３７】 タイトル・レジストリ・レコード： 電子船荷証券の作成後にタイトル・レジ
ストリに保存され、ＢＢＬテキストとリンクされる、電子船荷証券を含む取引き
に関連する構造化された情報である。

【０６３８】 輸送文書： 輸送業者によって発行される、船舶貨物運送状または船舶荷渡指
図のいずれかである文書。 指図側（To Order Party）： 電子船荷証券のホールダーを兼ねない、指図側
として指定されるユーザ。

【０６３９】 タイプ・ヘッダ、もしくはヘッダ： システム内でのメッセージのタイプおよ
び機能を示し、データをシステムのログ、ユーザ・データベース、タイトル・レ
ジストリ、およびその他のレコードへ運び、場合によっては、システムの１また
は複数の活動を促進する、メッセージの一部。

【０６４０】 一意的、一意的に： ユーザまたは文書識別子、またはデータベース・フィー
ルドのその他のコンテンツで使用される場合、ＩＴＵ Ｘ．５００ディレクトリ
属性の値、または類似のデータ・アイテムは、そのコンテンツまたは数値が指定
の範囲内にある唯一のものであり、等価または同一のコンテンツまたは数値がそ
の範囲内にはないことを意味する。

【０６４１】 ユーザ： システムのユーザとして登録している者。 ユーザ証書（サーティフィケート）： ユーザによってデジタル・サインされ
たメッセージのデジタル・サインを照合（検証）するために使用される公開鍵を
リストした証書。

【０６４２】 ユーザ・データベース： システム内に保持されているユーザに関するレコー
ド。 ユーザ・ディビジョン・アイデンティファイア： 部門、部局、課、または特
定されたユーザの組織のその他の部分を示す、ユーザ識別子のオプション部分。

【０６４３】 ユーザ識別子： システム内でユーザを一意的に識別する名称。 ユーザ識別子拡張子： ユーザの代表者によってユーザ識別子に添付される、
そのユーザの便宜のための、他のユーザには有意ではない表記。

【０６４４】 ユーザ・マニュアル： 一般に全てのユーザにＸＹＺ社により適時交付される
ユーザ・マニュアル。 ユーザ・サポート資源： ワールド・ワイド・ウェブ・インターフェースを介
してＸＹＺ社により提供されるオンラインの情報および機能。

【０６４５】 ユーザ・システム： ユーザが中央システムと接続し、これを利用する手段で
ある。これには、メッセージを構成、送信、受信し、文書を読み出し、処理する
ための通信リンク、ソフトウェア、およびハードウェア、並びにコンピュータ・
セキュリティ設備、およびその他の構成部品が含まれ、これらは全てユーザ・シ
ステムの仕様書によに要求されたものである。

【０６４６】 ユーザ・システムの仕様書： ユーザ・システム（通信リンクを含む）のため
の技術的な要求基準。 有効（妥当）な証書： 文書形式で指定された条件に従って有効である証書の
ことである。このような条件が指定されていないか又はその証書を信頼するユー
ザが入手できない場合、その証書は、交付人によってサインされており且つ券面
上期限切れになっておらず且つ運用手続きに記載されているように解約されてい
ない場合には、有効である。

【０６４７】 確認、照合： 所与のデジタル・サインされたメッセージおよび公開鍵に関し
て、（ａ）メッセージ上のデジタル・サインが公開鍵に対応する非公開鍵によっ
て作成され、（ｂ）デジタル・サインが作成されてからメッセージが変更されて
いないことを、正確に判定することである。

【０６４８】 ＸＡＬサービス契約： ＸＹＺ会社と各ユーザとの間の、随時修正される契約
のことである。 ＸＹＺ会社、または「ＸＡＬ」： システムのユーザを代表し、かつＸＡＬサ
ービス契約によって割当てられる様々な規則および規律を実行するように作られ
た法人体である。

【０６４９】 ＸＹＺ社、またはＸＹＺ： 当面は、システムのオーナー、運用者、またはサ
ービス・プロバイダ、またはその資格の後継者である。 ２．総則 ２．１． 範囲及び適用 ２．１．１． 当事者（party、側） ユーザ間の合意としての効力。この規則は、自らのため、及び随時に他の全て
の適格なユーザのために行動し、また必要な場合はＸＹＺ社のために行動する、
ユーザ間、および各ユーザとＸＹＺ有限会社（ＸＡＬ）との間の合意を形成する
規則である。

【０６５０】 ユーザ間の義務。ＸＡＬおよびＸＹＺ社は、本規則またはその他により一方の
ユーザがいずれかの他のユーザに対して負うべき何らかの義務または責務の遂行
に対する何れの責任も、を負うものでも受け入れるものもない。

【０６５１】 サービス契約の効力。いずれかのユーザに対するＸＡＬまたはＸＹＺ社の側の
責任は、ＸＡＬの場合はＸＡＬサービス契約、およびＸＹＺ社の場合は運用サー
ビス契約の条項の下で且つこれに基づく以外には、発生しない。

【０６５２】 ２．１．２． 遵守 各ユーザは、システムのユーザになる条件として、規則の条項に拘束されるこ
とに合意する。

【０６５３】 ２．１．３． 資格（適格性） 必要条件。全てのユーザは、随時修正される運用サービス契約に記載されてい
る基準に従って適格でなければならず、ユーザである期間を通して適格性を維持
しなければならない。

【０６５４】 登録機関の必要条件。各ユーザは、関連の登録機関の必要条件を完全に満たす
ことを確言し、かつユーザから登録機関に供給される全ての情報が真実であり、
全ての資料の細目において完全なものであることを保証するものとする。

【０６５５】 情報の変更。各ユーザは、以前に提供された何らかの情報が不正確または誤り
となった場合は、登録機関に即刻通知するものとする。 ２．２． メッセージ ２．２．１． オペレーション 真正性。各ユーザは、ユーザによって又はユーザの代わりに中央システムを介
して送信された全てのメッセージが、（ａ）ユーザによりサインされ、（ｂ）送
信側を特定し、かつ（ｃ）レシピエント（受信側）を特定するものであることに
合意するものとする。

【０６５６】 オペレーション規則。各ユーザはオペレーション規則に従い、これを遵守する
ものとする。 送信の推定。ユーザは、ユーザがオペレーション規則に従ってメッセージにサ
インしてこれを送信すると直ちに、メッセージを送信したものと推定される。

【０６５７】 受信の推定。ユーザは、中央システムがオペレーション規則に従ってかかるユ
ーザにメッセージを適正に転送すると直ちに、メッセージを受信したものと推定
される。

【０６５８】 装置およびアプリケーション。各ユーザは、ユーザ・システムを運用し、これ
を適切に運用できる状態を保持するための全ての合理的な配慮を施すものとする
。

【０６５９】 配達ミス。或るユーザに対して明確にアドレス指定されたメッセージが他のユ
ーザに謝って配達された場合、かかるユーザは、（ａ）誤りが判明すると直ちに
中央システムを介して送信側へメッセージを返送し、（ｂ）メッセージのいかな
るコピーを保管または保持することも差し控え、（ｃ）メッセージに含まれる情
報を機密扱いにし、いかなる目的にもそれを使用せず、また開示しないものとす
る。

【０６６０】 ２．２．２． 妥当性と執行可能性 記述の必要条件。適用可能な何れの法律、契約、慣習、または、何れの取引き
、文書または通信も記載、サイン又は捺印されて作成又は証明されるという慣行
における必要条件は、サインされたメッセージによって満たされるべきものとす
る。

【０６６１】 サインの必要条件。ユーザによってサインされるメッセージの内容は、メッセ
ージが手書きのサインされた形式で存在する場合と同様の範囲まで、かかるユー
ザを拘束し、それと法的に同じ効力を有するものとする。

【０６６２】 妥当性（有効性）に異議を申し立てない保証。メッセージが紙の代わりに電子
メッセージの形式で作成され、かつ／またはサインまたは捺印されたという理由
に基づき、いかなるユーザも、サインされたメッセージによって行われる如何な
る取引き、声明、または通信の妥当性にも異議を申し立ててはならない。

【０６６３】 ２．２．３． 証拠としてのメッセージ 適格性。各ユーザは、サインされたメッセージ、またはサインされたメッセー
ジからの抜粋部分が、記録された事実の証拠として、いずれの法廷または裁判所
の前でも証拠として認められることに合意するものとする。

【０６６４】 一次的証拠。いずれかのメッセージの書面による記録が要求された場合、ＸＹ
Ｚ社が運用サービス契約の第２．６．１（３）項の条項に基づき認証した、ユー
ザ作成のコピーが、メッセージの内容の一次的証拠としてかかるユーザおよびそ
の他の任意のユーザにより受け入れられるものとする。

【０６６５】 認証されたコピーの優先性。各ユーザは、任意のユーザのレコードと、ＸＹＺ
社によって認証されたコピーとの間に矛盾があった場合、認証されたコピーが優
先することに合意するものとする。

【０６６６】 ２．２．４． メッセージに対する責任 非公開鍵のセキュリティ。各ユーザは、自らの非公開鍵のセキュリティの保持
に失敗したとしても、それに関わりなく、非公開鍵によってサインされた全ての
メッセージに責任を負う。

【０６６７】 サイト・セキュリティ。各ユーザは、中央システムへの又は中央システムから
のデータ通信が無認可のアクセス、変更、遅延、損失または破壊から確実に保護
されるように、必要な全てのセキュリティ手続きおよび手段を講ずる責任を有す
る。

【０６６８】 メッセージの内容。サイン入りのメッセージを受信するユーザは、かかるメッ
セージおよびそれに含まれるいかなる文書も、メッセージおよび文書が紙に手書
きでサインされた場合と同様に、その条件が既定するように拘束力があるものと
見なしてよい。

【０６６９】 ２．２．５． 通知 各ユーザは、その非公開鍵が紛失するか又は危険にさらされたり、または非公
開鍵が誤用されたか又は無認可のユーザに不正使用されたと信ずるに足る合理的
理由がある場合は、ＸＹＺ社に即座に通知し、関連するオペレーション規則に従
う義務があるものとする。

【０６７０】 ２．３． 非合法性 強制の必要条件。各ユーザは、データを電子的に送信できる許容された形式に
関して、およびこのようなデータの内容に関しての、いかなる強制的に適用され
る法的要件に従う義務があるものとする。

【０６７１】 非合法の貿易およびマネー・ロンダリング。ユーザは、いかなる非合法貿易、
密輸商品の貿易、貨幣の何れもの違法な譲渡、または当局に報告しなければなら
ない商品または貨幣の貿易または譲渡を行うため又はこれを促進するためにメッ
セージを伝送するために、中央システムを使用してはならない。

【０６７２】 規則の遵守。各ユーザは、中央システムを介して参加するいかなる取引きに関
しても適用されるあらゆる法律を遵守し、かつ、それに限定されるものではない
が、商品の輸出または輸入、為替管理規則、危険商品または物質の移動、取扱い
または貯蔵、汚染物、データ保護、または暗号に関する法規を含む適用可能な全
ての法規を遵守する責任を負う。

【０６７３】 ２．４． 辞任または解約の結果 中央システムから出た後のメッセージ。ユーザが、運用サービス契約またはＸ
ＡＬサービス契約の条項に基づいて中央システムから辞任するか又はこれにアク
セスするユーザの権利を解約した場合、終了日の以前に中央システムから送信さ
れたユーザの既存の全てのメッセージが収集され、読み出されることと、ユーザ
が中央システムから離脱した旨を、メッセージを受信することが予期される他の
全てのユーザに対して通告することと、他のユーザに対して、将来の通信を受信
できるために必要な情報を提供する全ての合理的な手段を講じることとを保証す
ることは、専らユーザの責任となる。

【０６７４】 辞任するユーザによる紙への切換え。辞任した時点で電子船荷証券のホールダ
ー、指図側ホールダー、持参人ホールダー、またはプレッジー・ホールダーであ
るユーザは、その辞任通知を出すと同時に、本規則書の規則第３．７項に従って
紙への切換え手続きを開始しなければならない。

【０６７５】 解約したユーザによる紙への切換え。ユーザが、運用サービス契約またはＸＡ
Ｌサービス契約の条項に基づいてアクセス権を解約した時点で、ユーザが電子船
荷証券のホールダー、指図側ホールダー、持参人ホールダー、またはプレッジー
・ホールダーである場合は、ユーザは、これに限定されるものではないが、本規
則書の第３．７項の規則に基づく紙への切換え手続きを開始する命令を含む、Ｘ
ＹＺ社またはＸＡＬが発することができる命令に従うものとする。しかし、ＸＹ
Ｚ社にもＸＡＬにも、このような命令を発するいかなる義務もない。

【０６７６】 ３． タイトル・レジストリ ３．１． 電子船荷証券の作成 ＢＢＬテキストの内容およびアイデンティフィケーション。各輸送業者は、用
船契約された船荷証券としての運用を意図したメッセージ以外の、かかる輸送御
者によって電子船荷証券として送信されたいずれのメッセージも、ＢＢＬテキス
トにおいて、前記輸送業者により船舶輸送される商品の輸送業者による受取のア
クノレッジメントを含み、かつ輸送契約の条件またはこれを立証する、というこ
とに合意する。メッセージはタイトル・レジストリへ伝送されるものとする。

【０６７７】 用船契約された船荷証券。輸送業者は用船契約された船荷証券として運用する
ことを意図した電子船荷証券を作成してもよく、この用船契約された船荷証券は
、首席用船契約者(head charterer)が荷主およびホールダーとして指定されてい
る場合には、輸送業者と首席用船契約者との輸送の契約の条件を含まず、また証
拠とはならないが、ＢＢＬテキストは、前記輸送業者により船舶輸送される商品
の受取りの輸送業者による受取りのアクノレッジメントを含むものとする。

【０６７８】 受領した商品に関するステートメント。ＢＢＬテキスト内の商品に関する導標
、数、量、重量、または外見上の状態について輸送業者が作成する何れのステー
トメントも、このステートメントが紙の船荷証券に含まれている場合と同じ範囲
および同じ環境で、輸送業者を拘束する。

【０６７９】 元の当事者（original party）。輸送業者が電子船荷証券を作成する際、輸送
業者は、（ａ）荷主を指定し、（ｂ）船荷証券のホールダーを指定し、（ｃ）（
ｉ）指図側を指定するか、（ｉｉ）荷受側を指定するか、または（ｉｉｉ）電子
船荷証券に白地裏書きすることによってホールダーを持参人ホールダーとして指
定しなければならない。船荷証券のホールダーの指定に関するいかなる命令もな
い場合は、輸送業者が荷主を持参人ホールダーとして指定する。

【０６８０】 ３．２． 参照による組入れ(incoroporation by reference) 標準的契約条件。標準となる貿易契約条件を組入れるために、ＢＢＬテキスト
に契約条件を完全に記載しなくとも、輸送業者はオペレーション規則に指定の手
順に従うものとする。

【０６８１】 組入れの効力。このような組入れが、かかる契約条件が輸送契約の当事者を拘
束するものとするのに有効であるということに、各ユーザは合意するものとする
。

【０６８２】 用船契約者条件の組入れ。 各ユーザは、いずれの用船契約者の規定条項を組入れたＢＢＬテキストに含まれ
る表現も、それが輸送業者によって交付された紙の船荷証券に記載された条件の
一部として表記されたの場合と同様の効力を有することに合意するものとする。

【０６８３】 国際協定。輸送業者が作成した電子船荷証券に関する輸送契約は、同じ条件の
紙の船荷証券がその契約に関連して発行された場合に強制的に適用されているで
あろういかなる国際協定にも、またかかる国際協定を発効させるいかなる国内法
にも従うものとする。このような国際協定または国内法は、電子船荷証券に組入
れられるものとみなされる。このように組入れられたいずれかの国際協定または
国内法と、ＢＢＬテキストに含まれる輸送契約のその他の規定との間に矛盾が生
じた場合は、国際協定の規定が優先する。

【０６８４】 ３．３． 電子船荷証券の下での権利と義務 譲渡性（transrerability）。電子船荷証券は、譲渡可または譲渡不可であり
得る。

【０６８５】 譲渡可にする。輸送業者が譲渡可能な電子船荷証券を作成したい場合は、指図
側を指定するか、証券を白地裏書きにするものとする。 指図側指定の効力。輸送業者が指図側を指定した場合、（ａ）電子船荷証券の
指図側ホールダーであるか、または指図側ホールダーになるこのような指図側は
、新規の指図側、プレッジー・ホールダー、持参人ホールダー、または荷受側を
指定することができることと、（ｂ）その後の何れの指図側ホールダー、プレッ
ジー・ホールダー、または持参人ホールダーも同様の指定をすることができるこ
ととに、合意したものとみなされる。

【０６８６】 白地裏書きの効力。輸送業者が、電子船荷証券に白地裏書きするタイトル・レ
ジストリ命令を発すると、（ａ）ホールダーは持参人ホールダーであり、新規の
持参人ホールダー、指図側、プレッジー・ホールダー、または荷受側を指定でき
ることと、（ｂ）その後の何れの指図側ホールダー、プレッジー・ホールダー、
または持参人ホールダーも同様の指定ができることとに、合意したものとみなさ
れる。

【０６８７】 荷主ではない指図側ホールダー、または持参人ホールダー。荷主ではない持参
人ホールダーまたは指図側ホールダーを指定する電子船荷証券を作成することに
よって、輸送業者は、電子船荷証券に記載されている商品を前記持参人ホールダ
ーまたは指図側ホールダーの指図のもとに保持することをアクノレッジする。

【０６８８】 譲渡不可にする。輸送業者が荷受側を指定する場合、電子船荷証券は譲渡不可
になるものとする。 輸送契約を遵守する輸送業者の責任。輸送業者は、かかる輸送業者がタイトル
・レジストリ命令で行う指定が正確に、（ａ）荷主の表現する又は意味した命令
、および（ｂ）ＢＢＬテキストに含まれるか又はこれによって立証される輸送契
約の契約条件および効果、または（ｃ）首席用船契約者が荷主に指定される用船
契約船荷証券の場合においての、輸送契約の条件であるかのようにＢＢＬに述べ
らた条件、を反映することを保証するものとする。

【０６８９】 ３．４． 所有権の譲渡 ３．４．１． 所有権の譲渡の手順 指定による。譲渡可の電子船荷証券の作成後の、商品の法定的所有権の譲渡は
、（ａ）新規の指図側ホールダー、（ｂ）新規のプレッジー・ホールダー、（ｃ
）新規の持参人ホールダー、または（ｄ）荷受側ホールダーの指定によって行う
ものとする。

【０６９０】 指定者がホールダーを兼ねる場合の指定の効力。輸送業者は、かかる指図側ホ
ールダー、プレッジー・ホールダー、持参人ホールダー、または荷受側ホールダ
ーを指定すると、その時点から、輸送業者が場合に応じて、新規の指図側ホール
ダー、プレッジー・ホールダー、持参人ホールダー、または荷受側ホールダーの
指図のもとに電子船荷証券に記載されている商品を保持することをアクノレッジ
するものとする。 指図側がホールダーになる。新規の指図側が指定されると、指図側がホールダー
に指定され、ひいては指図側ホールダーになる時点までは、商品の法定的所有権
の譲渡は行われない。

【０６９１】 荷受側がホールダーになる。新規の荷受側が指定されると、荷受側がホールダ
ーにも指定される時点までは、商品の法定的所有権の譲渡は行われない。 譲受人による拒否。指定された指図側ホールダーまたは荷受側ホールダーが規
則第３．５．２項に基づいて輸送契約の更改の受け入れを拒否した場合、商品の
法定的所有権は、自動的に、直前までの指図側ホールダー、持参人ホールダー、
プレッジー・ホールダーに、または、これらが存在しない場合は、荷主に自動的
に戻される（また、輸送業者は、場合に応じて、指図側ホールダー、持参人ホー
ルダー、プレッジー・ホールダー、または荷主の指図のもとに商品の保持を継続
することをアクノレッジするものとする）。

【０６９２】 抵当権者による拒否。指定されたプレッジー・ホールダーがその抵当権を放棄
してホールダーシップ（所有者権）を直前のホールダーに戻すことにより譲渡を
拒否した場合は、商品の法定的所有権は自動的に直前の指図側ホールダー、持参
人ホールダー、プレッジー・ホールダーに、または、これらが存在しない場合は
、荷主に自動的に戻される（また、輸送業者は、場合に応じて、その指図側ホー
ルダー、持参人ホールダー、プレッジー・ホールダー、または荷主の指図のもと
に商品の保持を継続することをアクノレッジするものとする）。

【０６９３】 ３．４．２． 輸送業者の代理人として行動するＸＹＺ社 各輸送業者は、この結果、規則第３．４．１項に基づいて指定された又は直前
までの指図側ホールダー、プレッジー・ホールダー、持参人ホールダー、荷受側
ホールダー、または荷主の指図のもとに商品を保持することをアクノレッジする
目的で、ＸＹＺ社をその代理人として変更不可に指定する。

【０６９４】 ＸＹＺ社は、関連するタイトル・レジストリ命令を受信した直後に、輸送業者
の代わりに送信されるメッセージに、中央システムを介して、前記アクノレッジ
メントを送信することを保証する。

【０６９５】 ３．５． 輸送契約の更改 ３．５．１． 発生と効力 ＢＢＬの作成後の、首席用船契約者を兼ねていない新規の指図側ホールダーま
たは新規の荷受側ホールダーの指定は、輸送業者、荷主、存在する場合は直前の
指図側ホールダー、および新規の指図側ホールダーまたは荷受側ホールダーは全
て、このように同意することを意味する。

【０６９６】 輸送契約に対する新規当事者。新規の指図側ホールダーまたは荷受側ホールダ
ーがそのように指定されることを受け入れるか、または、規則第３．５．２項に
基づく譲渡の拒否が許容される２４時間の期間が満了するかの、いずれか先の方
の時に、輸送契約が、輸送業者と新規の指図側ホールダーまたは荷受側ホールダ
との間で、ＢＢＬテキストに含まれるか又はこれにより実証される輸送契約の条
件において、または、荷主が首席用船契約者である場合は、元の輸送契約を含む
か又はこれを実証するかのようにＢＢＬテキストに記載または組み込まれた条件
において、発生する。

【０６９７】 権利と義務の相続。新規の指図側ホールダーまたは荷受側ホールダーは、電子
船荷証券に含まれるか又はこれによって実証される、またはそのように含まれる
又は実証されると考えられる輸送契約の全ての権利を与えられ、かつ全ての義務
を受け入れるものとする。

【０６９８】 消滅する以前の被指定人の権利と義務。首席用船契約者でない限り、輸送業者
との輸送契約に基づく、直前の指図側ホールダーの権利、またはそれが存在しな
い場合は荷主の権利、および、荷主のではなく直前の指図側ホールダーの義務、
は直ちに停止して消滅する。

【０６９９】 ３．５．２． 新規ホールダーが指定を拒否する権利 通知による拒否。新規の指図側ホールダーまたは荷受側ホールダーは、その通
知を受けてから２４時間以内に、新規の指図側ホールダーまたは荷受側ホールダ
ーとしての指定を拒否してもよく、その場合、以前の指図側ホールダーと輸送業
者との輸送契約に基づく全ての権利および義務は、あたかも契約を更改する企図
がなされなかったかのように、以前の指図側ホールダーに、又は、それが存在し
ない場合には荷主に、帰属したままとなる。

【０７００】 受諾。指定された指図側ホールダーまたは荷受側ホールダーが、２４時間の期
間内かつ指定の拒否の前に、更改を受諾することを表すか、または商品の荷渡し
を行うことや商品の紛失または損傷に関して輸送業者に対する訴訟を開始するこ
となどによって、商品に関する何らかの権利を行使することを試みる場合は、規
則第３．５項の目的のために指定が行われた時点でその指定を受諾したものとみ
なされる。本規則第３．９項の「通知による拒否」のパラグラフに従って行われ
る事後的な何れの拒否通知も無効とする。

【０７０１】 ３．５．３． プレッジー・ホールダー 抵当権の行使。プレッジー・ホールダーがその抵当権を行使したい場合は、自
らを指図側ホールダーとして指定するものとし、その結果、輸送契約は、指図側
ホールダーとしてのかかるプレッジー・ホールダーに商品の法定的所有権が譲渡
されたかのように、規則第３．５項の規定に基づいて更改される。

【０７０２】 更改なし。プレッジー・ホールダーの指定によって輸送契約が更改されるもの
ではなく、プレッジー・ホールダーが抵当権を行使しない限り、また、行使する
まではされない。

【０７０３】 ３．５．４． 持参人ホールダー 更改なし、持参人ホールダーの指定による輸送契約の更改はないものとする。 権利の行使。商品の荷渡しを要求すること、または商品の荷渡しがなされない
ことに対して輸送業者に対する訴訟を開始することを望む持参人ホールダーは、
先ず、自らを指図側ホールダーとして指定し、その後、商品の法定的所有権が指
図側ホールダーとしての前記持参人ホールダーへ譲渡されたかのように、規則第
３．５項の規定に従って輸送契約の当事者になるものとする。

【０７０４】 ３．６． 商品の荷渡し 荷渡しの権限を有する者。電子船荷証券が関連して作成された輸送契約の下で
、商品の荷渡しは、輸送業者によって、電子船荷証券を滞りなく引き渡す指図側
ホールダーまたは荷受側ホールダーに対してのみ行われるものとする。

【０７０５】 電子船荷証券の引き渡し。電子船荷証券は、オペレーション規則に従って、引
渡側として特定されたユーザ、またはそれが存在しない場合は輸送業者に、引き
渡されるものとする。

【０７０６】 電子船荷証券の終了。電子船荷証券が引き渡されたことをタイトル・レジスト
リ・レコードが一旦記録すると、電子船荷証券は、電子船荷証券としての効力を
失い、タイトル・レジストリを介してさらにこれを取り扱うことはできなくなる
。

【０７０７】 ３．７． 紙への切換え 紙に切り換える権限を有する者。電子船荷証券の関連する商品が輸送業者によ
って荷渡しされる前の任意の時点で、現在のホールダー、指図側ホールダー、プ
レッジー・ホールダー、または持参人ホールダーは、オペレーション規則に基づ
いて、輸送業者が紙の船荷証券を発行するように要求する権限を有するものとす
る。

【０７０８】 紙の船荷証券の形式。輸送業者は、上記の要求を受けると直ちに、（ａ）元の
ＢＢＬテキストに含まれる全てのデータ、（ｂ）それが電子船荷証券として始ま
ったという意味のステートメント、および（ｃ）紙形式で発行された日付、を記
載した紙の船荷証券を発行するものとする。

【０７０９】 不一致。上記のようにして発行された紙の船荷証券と、船荷証券の電子レコー
ドとが一致しない場合は、電子レコードが優先するものとする。 紙船荷証券の配達。輸送業者は、紙の船荷証券を、現在それを保持する権限の
ある者、すなわち（ａ）現在のプレッジー・ホールダー、またはこれが存在しな
い場合は（ｂ）現在の指図側ホールダーまたは持参人ホールダー、またはこれが
存在しない場合には現ホールダーの命令に従って、配達するものとする。

【０７１０】 裏書き連鎖（エンドースメント・チェーン）。このような紙の証券には、電子
船荷証券の作成日から、オペレーション規則に基づいて紙への切換え要求が中央
システムによって送信された日まで、輸送業者と輸送契約を締結した当事者であ
るユーザ連鎖のＸＹＺ社によって証明されたレコードが添付されるものとする。

【０７１１】 電子船荷証券の停止。紙の船荷証券を発行する命令が輸送業者に出された時点
から、電子船荷証券に関連するタイトル・レジストリ命令はなくなるものとする
。電子船荷証券は、輸送業者による紙の船荷証券の発行の時点から効力を停止す
るものとする。

【０７１２】 ３．８． 電子船荷証券に対する当事者の権限 権限の表。以下に定義する電子船荷証券の当事者は、以下の表のとおりに電子
船荷証券に関する機能を行使する権限を有するものとする。

【０７１３】

【表１】

【０７１４】 輸送業者の権利のタイミング。輸送業者は、電子船荷証券の作成時にのみ、お
よび本規則書の第３．１項の規定に基づいてのみ、修正の認可と拒否以外の、表
に示した機能を実行してもよい。

【０７１５】 指図側を指定する荷主ホールダー。白地裏書きされた電子船荷証券のホールダ
ーを兼ねる荷主は、指図側を指定することができる。 ホールダーではない荷主、荷受側、または指図側。荷主、荷受側、または指図
側がホールダーを兼ねていない限り、タイトル・レジストリ命令を発する権限は
ない。

【０７１６】 単一のホールダー。何れの一時にも電子船荷証券の１人より多くのホールダー
（持参人ホールダー、指図側ホールダー、プレッジー・ホールダー、荷受側ホー
ルダー、またはホールダーのいずれにせよ）は存在しないものとする。

【０７１７】 抵当権者のホールダーへの自動的指定。抵当権者の指定により、以前のホール
ダーは解除され、抵当権者が自動的にホールダーとして指定される。指定された
何れの指図側も、抵当権が放棄されるか執行されるまで、指定された状態に留ま
るものとする。

【０７１８】 持参人ホールダーではない抵当権者。電子船荷証券に白地裏書きされている場
合、抵当権者の指定により、その者は持参人ホールダーではなくプレッジー・ホ
ールダーにされるものとする。

【０７１９】 証券に抵当権が設定されている間、抵当権者はホールダーに留まる。新規のホ
ールダーまたは指図側を指定するプレッジー・ホールダーの権限は、（ａ）その
抵当権を放棄するときに行使可能であり、その時にプレッジー・ホールダーは、
新規のホールダーを指定し、また、指図側または荷受側または白地裏書きを指定
し得るものであり、また、（ｂ）抵当権を執行するときに行使可能であり、その
時に、プレッジー・ホールダーは自らを指図側ホールダーとして指定する。

【０７２０】 基礎をなす契約の義務。本規則の何れも、取引きを管理する基礎契約の下で発
生する又はこれに関連する責任または責務を履行しない者を指定することを、何
れのユーザにも許容するものではないと解釈されるものではない。

【０７２１】 修正を要求する荷主の権利。本規則の何れも、電子船荷証券のホールダーであ
る荷主が、電子船荷証券の修正を主張する権利を制限するものではない。 電子船荷証券の下での輸送業者に対する命令。電子船荷証券が現在効力を有す
るか、または関連する荷積み文書が電子形式で存在する場合、輸送業者は、かか
る輸送業者に対する全ての命令が中央システムを介したメッセージによってのみ
発されることを要求できる。

【０７２２】 ３．９． 所有権および販売契約 所有権の譲渡。取引きの当事者の意図または適用可能ないずれかの法律の効力
の結果として、それらの規則に規定された商品の法定的所有権の譲渡および／ま
たは輸送契約の更改が、商品の所有権またはその他の財産的権益（商品の法定的
所有権に加えて）を譲渡する効力を有している場合は、本規則の何れの条項も、
所有権またはその他の財産的権益のそのような譲渡が行われることを妨げるもの
ではない。

【０７２３】 規則は所有権に影響しない。本規則の何れの条項も、電子船荷証券またはその
他の輸送文書に含まれるか又はこれによって実証される輸送契約の対象である商
品の所有権に影響を及ぼすものと解釈すべきではない。

【０７２４】 文書の電子提出の効力。各ユーザは、荷積み文書を、商品のバイヤー（買手）
に対して、またはバイヤーによりノミネートされた別の当事者に対して提出され
ることが、ユーザ間の販売契約により要求されている場合において、中央システ
ムによる文書の提出は、提出されるその文書が販売契約で要求される全てのデー
タを含むことを前提とした電子メッセージまたは画像の形式であるという理由か
ら、拒否されるものではない、ということに合意する。

【０７２５】 電子的交換により終結する販売。ユーザ間の販売契約が、メッセージまたは一
連のメッセージを用いて（全部または一部に用いて）終結した場合、各ユーザは
、かかるメッセージ（１または複数）が、ユーザ間で終結した契約を構成および
／または実証する、ということに合意するものとする。

【０７２６】 販売契約のための紙への切換え。元の販売契約を要求する権限を有するいずれ
かのユーザからの要求に応じて、契約するユーザは、契約に効力を生じさせるた
めに適用可能な法が要求する何れの全ての正式手続きにも従って、メッセージ（
１または複数）を書面でプリントしてサインする。

【０７２７】 販売契約日。「販売契約のための紙への切換え」のパラグラフに記載した手順
によって紙に切り換えられた販売契約は、かかる販売契約が、関連するメッセー
ジ（１または複数）の日付に書面で作成されサインされた場合と同様の効力を有
するものとする。

【０７２８】 ３．１０． 荷為替信用状 文書の電子的提示の効力。電子伝送される文書が同等の紙文書であるかのよう
に、これらの規則は適用され、中央システムを介しての電子伝送による何れの文
書の提示も受理されるものとし、紙文書の場合において、ユーザは、応募人ユー
ザの命令において荷為替信用状を交付、通告または確認し、その下で、受益ユー
ザは、荷為替信用状を運用するために、規定された文書を提示することが要求さ
れ、その条件は、（ａ）荷為替信用状が、中央システムの下での提示が受け入れ
可能であることを明示すること、（ｂ）かかる伝送に含まれるデータが文書に存
在しており、その文書の記述が、信用状の条件により提示を要求されている文書
と一致すること、および、（ｃ）荷為替信用状が、特定の文書が特定の者によっ
て交付され、認証され、またはサインされることを要求する場合に、そのデータ
伝送が、その者、または自身のために行動して責任を負うように権限を与えられ
たユーザによって、サインされていることである。

【０７２９】 「元のもの（オリジナル、原本）」である電子文書。本規則が適用される荷為
替信用状の条件の下での、「元の」文書を提示する、という要求は、文書を交付
または作成したと思われる者のサイン、または自身のために行動し且つ責任を果
たす権限を与えられたユーザのサインがある文書を提示することによって満たさ
れるものとする。

【０７３０】 コピー。本規則が適用される荷為替信用状の条件が、受益ユーザから他のユー
ザ、すなわち「レシピエント（受信側）」ユーザに対して文書の多数のコピーを
提示することを要求する場合、（ａ）かかる要求は、そのレシピエント・ユーザ
へ、単一の伝送で等価の文書を送信することによって満たされるものとし、（ｂ
）電子船荷証券は常に何れの時も１より多くのホールダー（指図側ホールダー、
持参人ホールダー、プレッジー・ホールダー、荷受側ホールダー、またはホール
ダーのいずれにせよ）を有さないという前提の下で、紙環境での取引きを完了す
るのに必要であったのと同様に、レシピエント・ユーザは、多数の先への送信を
行い、場合によっては、その文書の多数のコピーを作成する権利、即ち、権限が
与えられるものとする。

【０７３１】 電子船荷証券のホールダーとしての銀行。発行または確認する銀行として活動
するユーザが、荷為替信用状の機能を行う目的で電子船荷証券のプレッジー・ホ
ールダーまたは持参人ホールダーとして指定された場合、ユーザは、意図される
荷為替信用状の取引の当事者として、商品の所有権のみを獲得し、また商品に対
する責任のみを負うものとする。

【０７３２】 ６． 要約 本発明の特定の実施形態を記載してきたが、本発明の趣旨と範囲内で多くの変
更／追加および／または代替実施例が可能であることが理解されよう。

【図面の簡単な説明】

【図１】 図１はユーザ、メッセージ・ハンドリング・ユニットおよびタイトル・レジス
トリを含むシステムの構成要素間の情報の流れを示すブロック図である。 図１Ａはタイトル・レジストリの内部構造をより詳細に示す図である。

【図２】 図２はメッセージの構造を示す図である。

【図３】 図３は送信側ユーザから中央システムのメッセージ・ハンドリング・ユニット
を介して受信側ユーザへのメッセージの送信を示す図である。

【図４】 図４は送信側ユーザから発する送られたメッセージの、受信側ユーザによる受
信のアクノレッジメントを示す図である。

【図５】 図５は送信側ユーザから発する送られたメッセージの、受信側ユーザによる受
信の非アクノレッジメント示す図である。

【図６】 図６は、ＳＢＲｆ−ＦＢＲｆのシーケンスを経ての、ユーザがメッセージを無
視する意図のユーザ意思表示を示す図である。

【図７】 図７は全てのタイプ・ヘッダの流れを示す図である。 図７Ａはメッセージの流れとタイプ・ヘッダをまとめた表である。

【図８】 図８はユーザ識別子、ユーザ部門識別子、および拡張子の識別子部分を示す識
別子構造を示す図である。

【図９】 図９はメッセージ・ハンドリング・ユニットを利用した、サイン済みメッセー
ジの流れを示すブロック図である。

【図１０】 図１０はサインの照合とアクノレッジメントを伴う、ユーザからユーザへのメ
ッセージの送信を示す流れ図である。

【図１１】 図１１は証券サービスのための基本的な組織構造を示す図である。

【図１２】 図１２は証券の連鎖の例を示す図である。

【図１３】 図１３は加入者の証券のライフサイクルを開始から終了まで示す流れ図である
。

【図１４】 図１４はユーザに対してのフィールドに関して示されるタイトル・レジストリ
・レコードの簡略化された図である。

【図１５】 図１５はタイトル・レジストリのオペレーションのためのメッセージの流れを
示すブロック図である。

【図１６】 図１６はタイトル・レジストリに対する命令エレメントを示すメッセージの構
成要素を示す図である。

【図１７】 図１７は電子船荷証券の作成プロセスを示す流れ図である。

【図１８】 図１８は新規のホールダーを指定するプロセスを示す流れ図である。

【図１９】 図１９は荷受側を指定するプロセスを示す流れ図である。

【図２０】 図２０は指図側を指定するプロセスを示す流れ図である。

【図２１】 図２１は電子船荷証券に白地裏書きするプロセスを示す流れ図である。

【図２２】 図２２は抵当権者を指定するプロセスを示す流れ図である。

【図２３】 図２３は電子船荷証券における抵当権を放棄するプロセスを示す流れ図である
。

【図２４】 図２４は、指図側が指定された場合の、抵当権の執行のプロセスを示す流れ図
である。

【図２５】 図２５は電子船荷証券の修正を要求するプロセスを示す流れ図である。

【図２６】 図２６は電子船荷証券の修正を拒否するプロセスを示す流れ図である。

【図２７】 図２７は電子船荷証券の修正を許可するプロセスを示す流れ図である。

【図２８】 図２８は電子船荷証券の引き渡しプロセスを示す流れ図である。

【図２９】 図２９は紙への切換え指令を処理するプロセスを示す流れ図である。

【図３０】 図３０は裏書連鎖の例を示す図である。

【図３１】 図３１は、メッセージおよび文書情報を含むシステム文書、およびタイトル・
レジストリ命令および添付の電子船荷証券（ｅＢＬ）のフォーマットを示す図で
ある。

【図３２】 図３２はタイトル・レジストリの機能、および何れの当事者が何れの機能を実
行できるかをまとめた表である。

【図３３】 図３３はタイトル・レジストリの機能と、それに適用される条件とをまとめた
表である。

【図３４】 図３４は、作成命令に対しての、アトーンメント通知の配達、取引拒否の認可
、裏書連鎖レコードの作成、および裏書連鎖レコードの配達の機能エレメントを
示す表である。

【図３５】 図３５は、ホールダー指名、プレッジー・ホールダー指名の命令に対しての、
アトーンメント通知の配達、取引拒否の認可、裏書連鎖レコードの作成、および
裏書連鎖レコードの配達の機能エレメントを示す表である。

【図３６】 図３６は、指図側指名、荷受側指名および白地裏書きの命令に対しての、アト
ーンメント通知の配達、取引拒否の認可、裏書連鎖レコードの作成、および裏書
連鎖レコードの配達の機能エレメントを示す表である。

【図３７】 図３７は、認可された同時的命令に対しての、アトーンメント通知の配達、取
引拒否の認可、裏書連鎖レコードの作成、および裏書連鎖レコードの配達の機能
エレメントを示す表である。

【図３８】 図３８は、抵当権執行命令に対しての、アトーンメント通知の配達、取引拒否
の認可、裏書連鎖レコードの作成、および裏書連鎖レコードの配達の機能エレメ
ントを示す表である。

【図３９】 図３９は、（新規のｅＢＬバージョンを伴う）修正認可命令のための、譲渡通
知の配達、取引き拒否の認可、裏書き連鎖レコードの作成、および裏書き連鎖レ
コードの配達の機能エレメントを示す表である。

【図４０】 図４０は修正認可命令（新規のｅＢＬ識別子を伴う）に対しての、アトーンメ
ント通知の配達、取引拒否の認可、裏書連鎖レコードの作成、および裏書連鎖レ
コードの配達の機能エレメントを示す表である。

【図４１】 図４１は、入来する情報における妥当性検査エラーまたはその他のエラーの結
果として送信側が受信し得るエラーを記述した図表である。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１３年３月２１日（２００１．３．２１）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】請求項１

【補正方法】変更

【補正の内容】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】請求項３３

【補正方法】変更

【補正の内容】

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ＺＥＣ Ｇ０６Ｆ 17/60 ＺＥＣ Ｂ６５Ｇ 61/00 ５００ Ｂ６５Ｇ 61/00 ５００ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｕ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ， ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，Ｌ Ｋ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ， ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，Ｔ Ｍ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ ，ＺＡ，ＺＷ (71)出願人 14ｔｈ Ｆｌｏｏｒ， Ｃｅｎｔｒｅｐｏ ｉｎｔ， 103 Ｎｅｗ Ｏｘｆｏｒｄ Ｓｔｒｅｅｔ， Ｌｏｎｄｏｎ ＷＣ１Ａ １ＤＵ， Ｕｎｉｔｅｄ Ｋｉｎｇｄｏ ｍ (72)発明者 マーロン，ポール・マイケル イギリス国ロンドン エスダブリュー15・ ２キューエス，プットニー，スキュバー ト・ロード 74 (72)発明者 クラーク，ルロイド・アシュレー イギリス国ロンドン ダブリュー８・５キ ュージー，ケルソ・プレイス 31

Claims (40)

【特許請求の範囲】
1. 【請求項１】 各々がユーザ識別子を持つ、規定されたユーザ・グループの
   個々のユーザの間で、財産の取引をサポートするための電子取引サポートシステ
   ムであって、 （ａ）レコードのデータベースを備えるレジストリであって、各レコードは、
   １つの取引をサポートし、かつユーザを指名できる複数のフィールドを含み、各
   レコードは、前記取引の基礎となる前記財産に関連する指名された前記ユーザの
   権利および義務を反映し、各レコードは、少なくとも１つのフィールドを含み、
   そのフィールドにおいて、ユーザの一つが指名されて、そのレコードに関しての
   そのユーザの所有権と、その所有権を別のユーザに渡すための独占的な権利とが
   表明され、前記少なくとも１つのフィールドはホールダー・フィールドを含む、
   レジストリと、 （ｂ）前記ユーザから送信されたメッセージを受信するように構成されたメッ
   セージ・ハンドリング・ユニットであって、前記メッセージは、送信側ユーザの
   ユーザ識別子とレジストリ命令とを含み、ユーザ・メッセージに含まれるレジス
   トリ命令に応答してデータベース・レコードの作成、メンテナンス、および無効
   化が実行される、メッセージ・ハンドリング・ユニットと、 （ｃ）レジストリ命令および関連するユーザ識別子を受信するように前記メッ
   セージ・ハンドリング・ユニットに接続されたレジストリ・メンテナンス・ユニ
   ットであって、該レジストリ・メンテナンス・ユニットは、閉じたグループの命
   令タイプに従うレジストリ命令に応答するものであり、各レジストリ命令は、前
   記レジストリ命令と、対象の命令タイプに特有の規則集合との一致を確認するた
   めに実施されるテストを条件として、前記レジストリ・メンテナンス・ユニット
   によって実行され、前記規則集合は、共通の契約協定によって前記システムの全
   ユーザが遵守する義務を負う規則書を反映し、かつ前記取引の基礎となる前記財
   産に関連する前記ユーザの権利および義務を厳密に規定する、レジストリ・メン
   テナンス・ユニットと、 を備える電子取引サポート・システム。
2. 【請求項２】 請求項１に記載のシステムであって、少なくとも１つの命令
   タイプの前記規則集合は、前記送信側ユーザの前記ユーザ識別子が、前記レコー
   ドの前記少なくとも１つのフィールドおよびもう１つの別のフィールドに指名さ
   れたユーザに対応することを明記し、それによって、前記取引の基礎となる前記
   財産に関連する前記権利および義務の幾つかが、前記レコードの２つのフィール
   ドにおいて指名されることにより規定される一致した役割を有する単一のユーザ
   から導出される、システム。
3. 【請求項３】 請求項１または２に記載のシステムであって、前記少なくと
   も１つのフィールドは、ホールダー・フィールドとプレッジー・ホールダー・フ
   ィールドとから構成され、それぞれのレジストリ命令タイプに関する前記規則集
   合は、ユーザがホールダー・フィールドとプレッジー・ホールダー・フィールド
   のうちの１つ且つ唯一のフィールドに指名されるものであることを総体的に確か
   なものとする、システム。
4. 【請求項４】 請求項１ないし３の何れかに記載のシステムであって、前記
   各々のレコードはさらに、 そこにおいてユーザの一人が指名されてもよいが、ユーザが指名されていなく
   てもよい、指図側フィールドと、 そこにおいてユーザの一人が指名されてもよいが、ユーザが指名されていなく
   てもよい、荷受側フィールドと を含み、 それぞれの前記レジストリ命令タイプの全てに対しての前記規則集合は、一般
   に、前記指図側フィールドと前記荷受側フィールドとのうちの１つより多くに同
   時に、１つの指名されたユーザがあることを禁止する、システム。
5. 【請求項５】 請求項１ないし４の何れかに記載のシステムであって、各レ
   コードはさらに、 使用中の各レコードにおける前記ユーザの一つが指名されるオリジネータ・フ
   ィールドと、 使用中の各レコードにおけるユーザの１つが指名される荷主フィールドと を含み、 前記命令タイプには、新規のレコードを作成するための命令タイプがあり、前
   記レコード作成命令タイプのための前記規則集合は、ユーザがオリジネータ・フ
   ィールド、荷主フィールドおよびホールダー・フィールドの各々に指名されるこ
   と、および前記オリジネータ・フィールドに指名されたユーザが前記送信側ユー
   ザの前記ユーザ識別子に対応することを規定する、 システム。
6. 【請求項６】 請求項３に付加されたときの請求項５に記載のシステムであ
   って、前記レコード作成命令タイプに対する前記規則集合は、新規のレコードの
   前記プレッジー・ホールダー・フィールドには指名されたユーザがないというこ
   とを規定する、システム。
7. 【請求項７】 請求項５または６に記載のシステムであって、それぞれの前
   記レジストリ命令タイプの全てに対する前記規則集合は、共通に、前記オリジネ
   ータ・フィールドにおいて指名されたユーザの変更を許可しないという規則を有
   している、システム。
8. 【請求項８】 請求項４に付加されたときの請求項５、６、または７の何れ
   かに記載のシステムであって、前記レコード作成命令タイプに対する前記規則集
   合は、レコード作成命令が、（ｉ）前記荷受側フィールドにおいて指名するため
   のユーザ識別子と、（ｉｉ）前記指図側フィールドにおいて指名するためのユー
   ザ識別子と、（ｉｉｉ）前記荷受側フィールドと前記指図側フィールドとの双方
   に何れのユーザも指名されないことの指示とのうちの、１つ且つ一つのみのもの
   を含むことを規定する、システム。
9. 【請求項９】 請求項４に付加されたときの請求項５、６、７、または８の
   何れかに記載のシステムであって、前記レコード作成命令タイプに対する前記規
   則集合は、前記ホールダー・フィールドにおいて指名されるように指定されたユ
   ーザが前記荷受側フィールドまたは前記指図側フィールドのいずれかに指名され
   るように指定されたユーザに対応しないということを規定する、システム。
10. 【請求項１０】 請求項５ないし９の何れかに記載のシステムであって、前
    記レジストリ・メンテナンス・ユニットはさらに、レコード作成命令が前記レジ
    ストリ・メンテナンス・ユニットによって実行されるときに、前記メッセージ・
    ハンドリング・ユニットが、作成された前記レコードの前記ホールダー・フィー
    ルドにおいて指名されたユーザに対して、該レコードに対する前記ユーザの所有
    権を表明するメッセージを送信するようにさせ、且つ前記荷主フィールドにおい
    て指名されたユーザに対して更なるメッセージを送信するようにさせるように構
    成される、システム。
11. 【請求項１１】 請求項１ないし１０の何れかに記載のシステムであって、
    前記命令タイプには、前記ホールダー・フィールドにおいて指名されたユーザを
    変更して、それにより前記レコードの所有権を変更するための少なくとも１つの
    命令タイプがあり、前記ホールダー指名命令タイプに対する前記規則集合は、前
    記送信側ユーザの前記ユーザ識別子が前記少なくとも１つのフィールドにおいて
    現在指名されているユーザに対応するということを規定する、システム。
12. 【請求項１２】 請求項３に付加されたときの請求項１１に記載のシステム
    であって、前記ホールダー指名命令タイプに対する前記規則集合は、前記送信側
    ユーザの前記ユーザ識別子が前記ホールダー・フィールドと前記プレッジー・ホ
    ールダー・フィールドの一つに現在指名されているユーザに対応するということ
    を規定する、システム。
13. 【請求項１３】 請求項１２に記載のシステムであって、前記命令タイプの
    中には、前記プレッジー・ホールダー・フィールドにおいて指名されたユーザを
    変更して、それにより前記レコードの所有権を変更するための少なくとも１つの
    命令タイプがあり、前記プレッジー・ホールダー指名命令タイプに対する前記規
    則集合は、前記送信側ユーザの前記ユーザ識別子が前記ホールダー・フィールド
    と前記プレッジー・ホールダー・フィールドの一つに現在指名されているユーザ
    に対応するということを規定する、システム。
14. 【請求項１４】 請求項４に付加されたときの請求項１３に記載のシステム
    であって、前記プレッジー・ホールダー指名命令タイプに対する前記規則集合は
    さらに、 （ａ）前記荷受側フィールドには指名されたユーザが存在してはならず、 （ｂ）前記送信側ユーザの前記ユーザ識別子は、前記命令において前記プレッ
    ジー・ホールダーになることを指定されたユーザに対応してはならず、 （ｃ）前記命令の実行の結果として、前記プレッジー・ホールダー・フィール
    ドにおいて指名されたユーザと前記指図側フィールドにおいて指名されたユーザ
    とが一致してはならない、 ということを規定する、 システム。
15. 【請求項１５】 請求項１３または１４に記載のシステムであって、前記レ
    ジストリ・メンテナンス・ユニットは、ホールダー指名の命令またはプレッジー
    ・ホールダー指名の命令のそれぞれの実行の後に、前記ホールダー・フィールド
    または前記プレッジー・ホールダー・フィールドにおいて指名された前記ユーザ
    に対して、前記メッセージ・ハンドリング・ユニットから、前記レコードの所有
    権が前記ユーザへ譲渡された旨を通知するメッセージを送信するように構成され
    る、システム。
16. 【請求項１６】 請求項１ないし１５の何れかに記載のシステムであって、
    各々の前記レコードは、関連する履歴ファイルを更に含み、前記レジストリ・メ
    ンテナンス・ユニットは、少なくとも幾つかのタイプのレジストリ命令を実行し
    て、レジストリ命令の要求に関連するデータを対象となるレコードの前記履歴フ
    ァイルに書き込み、前記レコードで要求されている実行の監査追跡を維持するよ
    うに構成されており、前記システムのユーザが履歴ファイルにアクセスすること
    を可能とするレジストリ命令タイプは存在しない、システム。
17. 【請求項１７】 請求項３に付加されたときの又は請求項４、または請求項
    ３および４に付加されたときの請求項５ないし１６の何れかに記載のシステムで
    あって、それぞれの前記レジストリ命令タイプの全てに対する前記規則集団は共
    通に更に、 （ａ）前記プレッジー・ホールダー・フィールドと前記荷受側フィールドの１
    つよりも多くに同時に、指名されたユーザがあることを禁止し、 （ｂ）前記プレッジー・ホールダー・フィールドにおいて指名されたユーザが
    前記指図側フィールドにおいて指名されたユーザに対応する状態をレコードが採
    用することを妨げる、 システム。
18. 【請求項１８】 請求項１７に記載のシステムであって、各々の前記レコー
    ドは、該レコードに対しての契約側となっているユーザの時間順のリストが記憶
    されている関連する裏書連鎖ファイルを更に含み、前記裏書連鎖ファイルは前記
    レジストリ・メンテナンス・ユニットによって維持され、前記契約側は、（ａ）
    レコードの前記ホールダー・フィールドおよび前記荷受側フィールドと、（ｂ）
    レコードの前記ホールダー・フィールドおよび前期指図側フィールドとに同時に
    指名されたユーザを含むものと規定されている、システム。
19. 【請求項１９】 請求項１８に記載のシステムであって、新規の契約側を作
    成するために前記レコードが状態を変更するごとに、前記レジストリ・メンテナ
    ンス・ユニットは、前記メッセージ・ハンドリング・ユニットが前記新規の契約
    側である前記ユーザへ前記裏書連鎖のコピーを送付するようにさせるように構成
    されている、システム。
20. 【請求項２０】 請求項１ないし１９の何れかに記載のシステムであって、
    前記レジストリ命令は、前記レコードの所有権の変更を表明する、前記少なくと
    も１つのフィールドに指名されているユーザを変更する結果となる直前のレジス
    トリ命令を無効にするための取引拒否命令タイプを含んでおり、前記レジストリ
    ・メンテナンス・ユニットは、前記レコードをその直前の状態に戻すように変更
    することによって、取引拒否命令を実行するように構成されており、前記取引拒
    否命令タイプに対しての前記規則集合は、 （ａ）前記送信側ユーザの前記ユーザ識別子が前記少なくとも１つのフィール
    ドにおいて指名されたユーザに対応すること、および （ｂ）前記取引拒否命令が、前記直前のレジストリ命令から所定期間内に受け
    取られること を規定する、 システム。
21. 【請求項２１】 請求項４に付加されたときの請求項２０に記載のシステム
    であって、前記取引拒否命令タイプの前記規則集合はさらに、 （ｃ）前記送信側ユーザの前記ユーザ識別子が、前記ホールダー・フィールド
    において指名されたユーザに対応すること、および （ｄ）前記送信側ユーザの前記ユーザ識別子が、前記指図側フィールドおよび
    前記荷受側フィールドの一つにおいて指名されたユーザに対応すること を規定する、 システム。
22. 【請求項２２】 請求項２０または２１に記載のシステムであって、前記レ
    ジストリ・メンテナンス・ユニットは、該レジストリ・メンテナンス・ユニット
    による取引拒否命令の実行に続いて、該取引拒否命令の実行後に前記メッセージ
    ・ハンドリング・ユニットから前記少なくとも１つのフィールドにおいて指名さ
    れたユーザへ、メッセージが送信されるように構成して、前記レコードの前記所
    有権を受け入れるための前記直前の命令によって前記ホールダー・フィールドに
    おいて指名されたユーザの拒否に続いて、前記レコードの前記所有権が前記ユー
    ザに復帰した旨を通知するように構成される、システム。
23. 【請求項２３】 請求項１８に付加されたときの請求項２２に記載のシステ
    ムであって、前記レジストリ・メンテナンス・ユニットは、取引拒否命令を実行
    して、前記直前のレジストリ命令により生じた前記裏書連鎖ファイルにおける何
    れの変更も取り消すように構成されている、システム。
24. 【請求項２４】 請求項２０ないし２３の何れかに記載のシステムであって
    、取引拒否命令を実行するための前記所定期間は約２４時間の固定期間である、
    システム。
25. 【請求項２５】 請求項３および４、またはこれに付加されたときの請求項
    ５ないし２４の何れかに記載のシステムであって、前記レジストリ命令は、前記
    指図側フィールドにおけるユーザを指名するための命令タイプを含み、前記指図
    側指名命令タイプに対する前記規則集合は、 （ａ）前記荷受側フィールドに、指名されたユーザが存在しないこと、 （ｂ）前記送信側ユーザの前記ユーザ識別子が、前記ホールダー・フィールド
    または前記プレッジー・ホールダー・フィールドにおいて指名されたユーザに対
    応すること、および、 （ｃ）前記命令の実行の結果として、前記プレッジー・ホールダー・フィール
    ドにおいて指名されているユーザと前記指図側フィールドにおいて指名されてい
    るユーザとが一致してはならない、 ということを規定する、 システム。
26. 【請求項２６】 請求項３および４、またはこれに付加されたときの請求項
    ５ないし２５の何れかに記載のシステムであって、前記レジストリ命令は、前記
    レコードが譲渡禁止である旨を表明するために前記荷受側フィールドにおいてユ
    ーザを指名するための命令タイプを含んでおり、前記荷受側指名命令タイプに対
    する前記規則集合は、 （ａ）前記荷受側フィールドに、指名されたユーザが存在してはならないこと
    、 （ｂ）前記送信側ユーザの前記ユーザ識別子が、前記ホールダー・フィールド
    または前記プレッジー・ホールダー・フィールドにおいて指名された前記ユーザ
    に対応すること、および、 （ｃ）前記指図側フィールドには、指名されたユーザがないか、または前記ホ
    ールダー・フィールドにおて指名されたユーザがあること、 を規定する、 システム。
27. 【請求項２７】 請求項４、またはこれに付加されたときの請求項５ないし
    ２６の何れかに記載のシステムであって、前記レジストリ命令は、前記レコード
    の前記指図側フィールドにおいて指名されたユーザを削除することによって前記
    レコードを白地裏書とするための命令タイプを含み、前記白地裏書命令タイプの
    前記規則集合は、 （ａ）前記送信側ユーザの前記ユーザ識別子が、前記ホールダー・フィールド
    において指名されたユーザに対応すること、 （ｂ）前記送信側ユーザの前記ユーザ識別子が、前記指図側フィールドにおい
    て指名されたユーザに対応すること を規定する、 システム。
28. 【請求項２８】 請求項３および４、またはこれに付加されたときの請求項
    ５ないし２７の何れかに記載のシステムであって、前記レジストリ命令は、（ｉ
    ）前記プレッジー・ホールダー・フィールドにおいて指定されたユーザを、前記
    指図側フィールドにおいて指定されたユーザとして指名し、（ｉｉ）前記プレッ
    ジー・ホールダー・フィールドにおいて指定されたユーザを削除して該ユーザを
    代わりに前記ホールダー・フィールドにおいて指名することによって、レコード
    の抵当を強制するための命令タイプを含み、前記抵当強制命令タイプに対する前
    記命令集合は、前記送信側ユーザの前記ユーザ識別子が前記プレッジー・ホール
    ダー・フィールドにおいて指名されたユーザと対応するということを規定する、
    システム。
29. 【請求項２９】 請求項５ないし１０の何れか、またはこれに付加されたと
    きの請求項１１ないし２８の何れかに記載のシステムであって、前記レジストリ
    命令は、前記システムによる取引の電子的サポートから、前記システムの外側の
    取引の従来の紙を用いたサポートへと切り換えるための命令タイプを含み、 紙への切換え命令に対しての前記規則集合は、前記送信側ユーザの前記ユーザ
    識別子が前記少なくとも１つのフィールドにおいて指名されたユーザに対応する
    ことを規定し、 前記レジストリ・メンテナンス・ユニットは、紙への切換え命令を実行するこ
    とで、対象となるレコードを無効化し、前記メッセージ・ハンドリング・ユニッ
    トから前記オリジネータ・フィールドにおいて指名されたユーザへメッセージを
    送信させ、前記メッセージの一部として含まれる無効化された前記レコードのコ
    ンテンツに基づいて紙の書類を作成することを要求するように、構成される、 システム。
30. 【請求項３０】 請求項４、またはこれに付加されたときの請求項５ないし
    ２９の何れかに記載のシステムであって、各々の前記レコードは、ユーザの一つ
    が指名されてもよく、また、指名されたユーザがなくてもよい引渡側フィールド
    を更に含み、前記レジストリ命令は、前記取引の基礎となる前記財産の処分を表
    明するための、前記レコードを引き渡すための命令タイプを含み、前記レジスト
    リ・メンテナンス・ユニットは、前記レコードを無効化することによってレコー
    ド引渡命令を実行するように構成され、前記レコード引渡命令タイプに対しての
    前記規則集合は、前記送信側ユーザの前記ユーザ識別子が、（ａ）前記ホールダ
    ー・フィールドにおいて指名されたユーザ、および（ｂ）前記指図側フィールド
    および前記荷受側フィールドの１つにおいて指名されているユーザに対応すると
    いうことを規定する、システム。
31. 【請求項３１】 請求項３０に記載のシステムであって、前記レジストリ・
    メンテナンス・ユニットはさらに、引渡しのレジストリ命令タイプを含むメッセ
    ージが実施されるとき、前記レジストリ・メンテナンス・ユニットは、前記メッ
    セージ・ハンドリング・ユニットに、前記オリジネータ・フィールドにおいて指
    名されたユーザおよび前記引渡側フィールドにおいて指名された何れものユーザ
    へ、前記レコードが無効化されたことを示すメッセージを送信させるようにする
    よう構成されている、システム。
32. 【請求項３２】 請求項２９に付加されたときの請求項３０または３１に記
    載のシステムであって、前記レジストリ・メンテナンス・ユニットは、紙への切
    換え命令を実行して、前記メッセージ・ハンドリング・ユニットから前記オリジ
    ネータ・フィールドにおいて指名されたユーザおよび前記引渡側フィールドにお
    いて指名された何れものユーザへメッセージが送信されるようにするよう構成さ
    れている、システム。
33. 【請求項３３】 請求項５ないし１０の何れか、またはこれに付加されたと
    きの請求項１１ないし３３の何れかに記載のシステムであって、前記レジストリ
    命令は、レコードの修正の要求、修正の承認、および修正を拒否のための命令タ
    イプを更に含み、 前記修正要求命令タイプに対しての前記規則集合は、前記送信側ユーザの前記
    ユーザ識別子が前記少なくとも１つのフィールドにおいて指名されたユーザに対
    応することを規定し、 前記レジストリ・メンテナンス・ユニットは、前記修正要求命令を実行して、
    前記修正要求命令に修正識別子を割り当てて該修正識別子を記録し、前記メッセ
    ージ・ハンドリング・ユニットに、前記レコードの前記オリジネータ・フィール
    ドにおいて指名されたユーザへメッセージを送信させるようにするよう構成され
    、前記メッセージは、前記修正要求命令およびそれに割当てられた前記修正識別
    子とを含み、 前記修正承認命令タイプおよび修正拒否命令タイプに対しての前記規則集合は
    、それぞれ、前記送信側ユーザの前記ユーザ識別子が、前記オリジネータ・フィ
    ールドにおいて指名されたユーザに対応すること、および前記命令を含む前記メ
    ッセージが、対象となるレコードに対して記憶された前記修正識別子に対応する
    修正識別子を含むことを規定する、 システム。
34. 【請求項３４】 請求項３３に記載のシステムであって、各々の前記レコー
    ドは、修正要求命令が懸案中であるか否かを示す修正懸案フィールドを更に含み
    、前記レジストリ・メンテナンス・ユニットは、修正要求命令に応答して前記修
    正懸案フィールドを設定し、また、修正承認命令または修正拒否命令に応答して
    前記修正懸案フィールドの設定を設定解除するように構成され、前記レジストリ
    ・メンテナンス・ユニットは、前記修正懸案フィールドが設定されている間は前
    記レコードの変更を阻止するように構成されている、システム。
35. 【請求項３５】 請求項３３または３４に記載のシステムであって、前記レ
    ジストリ・メンテナンス・ユニットは、修正拒否命令を実行して、前記修正要求
    命令を発した前記ユーザへメッセージを送り、前記オリジネータ・フィールドに
    おいて指名されたユーザが前記修正要求命令に応答して修正拒否命令を発した旨
    を示すように構成されている、システム。
36. 【請求項３６】 請求項３３、３４または３５の何れかに記載のシステムで
    あって、修正承認命令は、該修正承認命令のコンテンツに応じて、前記レジスト
    リ・メンテナンス・ユニットによって実行され、それにより、 （ａ）複数の既存のレコードが、それらの無効化および一つの新規のレコード
    の作成によって、マージされること、 （ｂ）一つの既存のレコードが、該一つの既存のレコードの無効化および複数
    の新規のレコードの作成によって、複数のレコードへと分割されること、 （ｃ）一つの既存のレコードが維持されること、および、 （ｄ）一つの既存のレコードが無効化され、別の一つのレコードが作成される
    こと、 のうちの１つの結果になる、 システム。
37. 【請求項３７】 各々がユーザ識別子を備えたユーザの規定グループの、個
    々のユーザ間の財産の取引をサポートするためのタイトル・レジストリ・データ
    ベースが記憶された記録媒体であって、前記タイトル・レジストリ・データベー
    スは、各々が１つの取引をサポートする複数のレコードを備え、各レコードはユ
    ーザを指名できる複数のフィールドを含み、各レコードは、取引の基礎となる財
    産に関連して指名されたユーザの権利および義務を反映し、各レコードは少なく
    とも１つのフィールドを含み、該フィールドには、前記ユーザの１つが指名され
    て、前記レコードに対する前記ユーザの所有権と、該所有権を別のユーザに譲渡
    するための独占的な権利とを表明する、記録媒体。
38. 【請求項３８】 各々がユーザ識別子を有する複数の登録されたユーザ間の
    取引をサポートするためのサーバであって、各々が船荷証券を表し且つレコード
    識別子を含む複数のレコードを備えたデータベースを備え、前記データベース・
    レコードは、前記ホールダー・フィールドにおいて別の登録されたユーザを指名
    するためおよび／または該データベース・レコードの少なくとも１つの更に別の
    フィールドにおいて何れかの登録されたユーザを指名するたの前記登録されたユ
    ーザの中の単独的権利を含む、前記データベース・レコードの所有権を有するホ
    ールダーの前記ユーザ識別子を指定するためのフィールドを含む構造を有してい
    る、サーバ。
39. 【請求項３９】 請求項３８に記載のサーバであって、レコードの前記ホー
    ルダー・フィールドに入力されたユーザである一つの登録ユーザが、前記レコー
    ドのデータベース・フィールドにおいて別の登録ユーザを指名するとき、該サー
    バは、その新規に指名された登録されたユーザへその旨を通知することを開始す
    るように構成されている、サーバ。
40. 【請求項４０】 請求項３９に記載のサーバであって、前記新規に指名され
    たされた登録されたユーザが、前記取引の当事者であることを表明するフィール
    ドに入力されると、前記サーバは、前記登録されたユーザが承知している時間に
    対して、および／または前記サーバが、前記新規に指名された登録されたユーザ
    から対象となるレコードに関する別のコマンドを受ける時点まで、前記新規に指
    定された登録されたユーザの指名に関する取引拒否命令に応答する、サーバ。