本プロトコルは ODS-RAM の DCS「Heuristic Contracting」に対応する Complementary Protocol であり、「サードパーティの電子契約アプリケーションを通じて利用条件・契約条件の定義・合意形成を支援するインターフェース（契約そのものは含まない）」を担う。

「ヒューリスティックコントラクティング（Heuristic Contracting）」プロトコル仕様書は、2026年度に公開予定である。

Overview（概要）

クリアリング・ペイメントは、サードパーティの電子決済アプリケーションを通じてデータ取引の実績を記録・照合して精算・課金／決済するインターフェース（清算・課金／決済そのものの機能は含まない）を提供する。本プロトコルはComplementary Protocolsの1つとして、Open Dataspacesを実現するための補完的な機能である。

本レイヤは以下の領域を対象とする：

• 精算（Clearing） データ交換における、提供者と利用者間の取引を記録し、利用量と料金モデルに基づく精算処理を行う。なお、記録した取引は、ロギング機能を利用して収集したデータ交換の取引実績と比較することにより、精算対象を確認する。

• 課金／決済（Payment） 決済処理に必要な情報を提供する。なお、実際に決済を処理する機能については対象外である。

Abstract Normative Specification（抽象仕様）

Concepts and Roles（概念および役割）

本プロトコルに必要な概念は以下である。

• Open Dataspacesを介した処理における精算（Clearing）

• Open Dataspacesを介した処理における課金／決済（Payment）

• shall: 精算機能は、複数の証跡情報を突合して精算対象の取引実績を決定しなければならない。証跡情報は少なくとも (a) Dataspace Fundamental Services(DFS)の証跡、(b) 提供者申告、(c) 利用者申告を含まなければならない。

  • Rationale: データスペースの構成（連邦型・分散型）により、単一情報のみでは精算対象の正当性が担保できないため。

• should: 証跡情報の (a) DFSの証跡、(b) 提供者申告、(c) 利用者申告、全て一致する場合に精算対象とすることを原則とする。

• should: 決済の方式は、提供者が提示する決済方式から利用者が選択し、事前に取り決めることを原則とする。

  • Rationale: 一般的な商習慣に従うため。

• should: 決済処理に必要な情報は、精算処理の結果を基にすることを原則とする。

• Transaction（L2）を介して、本機能が利用されることを前提とする。

• Identity & Trust（L3）のトークンを用いて、本機能が利用されることを前提とする。

• データ交換における、提供者と利用者間の各取引は、X-TrackingIDにて一意に特定できることを前提とする。

Clearing and Paymentを利用する際の、メッセージ交換シーケンスを以下に示す。

本プロトコルで使用されるエラー処理について記す。

• CRYPTREC暗号リスト

実際の通信方式（HTTPS、ファイル転送、WebSocket等）に当てはめたときの定義を記述する。 以下に記述する内容は全てNon-normative（例示）である。

Concrete Specification（実装例）

Prerequisites（前提条件）

• 本プロトコルは HTTPS（TLS 1.2以上）を使用し、REST形式のHTTPリクエスト/レスポンスにより通信を行う。

• エンドポイント：指定されたURIに対してHTTPメソッド（GET, POST, PUT, DELETE）を使用

• データ形式：リクエストおよびレスポンスの本文はJSON形式

• 認証・認可：OAuth 2.0ベースのトークン認証を利用

• セキュリティ要件：TLS 1.2以上必須、暗号化通信を保証

本プロトコルで使用される各フィールドの定義を記す。

各フィールドについて、以下の情報を記す。

• フィールド名：binding内で使用される名称

• 型：データ型（例：整数、文字列）

• 必須性：フィールドの利用条件

Request・Responseのフィールドは、以下の通り。

Request・Responseのフィールドは本プロトコルの各機能で異なるため、の記載を参照してください。

Sent by・Resulting state(s)・Request・Response・Example・Error一覧・API固有のフィールド定義などの具体実装はの記載を参照してください。

• Loggingからのログ出力タイミングに合わせて、購入確定処理を実行する。

• 利用者からのデータ交換ステータスが交換完了、提供者からのデータ交換ステータスが交換完了、データ交換ログのステータスが成功、となったTransactionを請求予定額、支払い予定額の対象とする。

• データ提供者が、指定したデータ利用者との取引情報について、期間・精算決済状態で絞り込み、取得する。