Microsoft Word - WD ARTS XML Digital Receipt Charter V docx

(1)

ARTS XML

デジタルレシート

仕様書

v 2.1

2016-02-23

本書のステータス

本書は、技術委員会による最終稿とレビューに先立ち、デジタルレシートワークチームがコメントと改訂を行うための初回レビューに向けた ARTS XML の仕様書案である。

Copyright © 全米小売業協会 2010 年。無断転用禁止。本書の複製や使用は、ARTS メンバーが ARTS 標準の採用に沿った目的で行う場合にのみ許容される。但し、変更や一貫性のない利用については、事前に全米小売業協会の書面による承認を必要とする。そのため、本書の他者への提供は禁止され、本書へのコメントや、説明、実施の支援となるその派生物（この「派生物」に、記載された標準を根本的に修正又は変更しない、機能的な追加事項は含まれない）は、許可を得ない限り、全体又は一部においても標準を引用又は参照をしてはならない。また、著作権表示や、NRF、ARTS などの委員会への参照を削除するなど、いかなる形でも本書を修正してはならない。例外となるのは、NRF の承認する手順を踏んで ARTS 標準を策定する目的で必要な場合や、英語以外の言語への翻訳に必要な場合である。

(2)

目次 1 序章 ... 5 2 改版履歴 ... 5 3 チーム名 ... 5 4 チームの使命 ... 5 5 メンバー名簿 ... 6 6 ビジネス上の利点 ... 8 6.1 デジタルレシートとは？ ... 8 6.2 デジタルレシートのユーザー ... 8 6.3 デジタルレシートの利点 ... 9 6.4 POSLogと比べた場合のデジタルレシートの利点 ... 9 7 小売モデルインターフェイス/構築モデル ... 12 7.1 ビジネスプロセスモデル ... 12 8 ミッションの対象範囲 ... 15 8.1 Ver.1でのプロジェクト範囲 ... 15 8.2 Ver.2でのプロジェクト範囲 ... 15 Ver.2.0での範囲外 ... 16 8.2.1 8.3 Ver.2.1でのプロジェクト範囲 ... 17 9 PCI の影響 ... 17 10 ビジネス上の価値 ... 18

(3)

10.1 発行者にとってのデジタルレシート ...18 10.2 受領者にとってのデジタルレシート ...19 10.3 サードパーティーにとってのデジタルレシート ...20 11 ユースケース調査 ... 21 11.1 ユースケース：消費者による閲覧 ...21 サードパーティーによるレシートの閲覧 ...21 11.1.1 非接触通信で送信されるデジタルレシート ...24 11.1.2 11.2 ユースケース：マーケティングとマーチャンダイジング ...27 11.3 ユースケース：購入証明 ...35 11.4 ユースケース：クレジットカード係争解決 ...42 11.5 ユースケース：ファイナンスアプリケーションへの自動入力 ...44 11.6 デジタルクーポン/クーポン利用の追跡 ...47 11.7 保証 ...52 11.8 返品/交換ポリシー ...57 11.9 ターゲットマーケティング ...59 11.10 期限切れになるポイント ...63 11.11 プロモーションが追加されたデジタルレシートの発行 ...67 11.12 クーポンが追加されたデジタルレシートの発行 ...70 11.13 人数/会計組数,サービス料,場所情報が付加された,デジタルレシートの発行 74 11.14 オペレーター情報が付加された、デジタルレシートの発行 ...79 12 参照 ... 83

(4)

13 未解決の課題 ... 83 14 予定成果物 ... 83 15 用語集 ... 83 図の目次図1：デジタルレシートのインターフェイス ... 12 図2：デジタルレシート売上の BPMN ... 13 図3：デジタルレシートの BPMN ... 13 図4：デジタルレシート返品の BPMN ... 14 図5：顧客による閲覧 ... 21 図6：非接触通信で送信されるデジタルレシート ... 24 図7：マーケティングとマーチャンダイジング ... 27 図8: 購入証明 ... 35 図9: クレジットカード係争解決 ... 42 図10：ファイナンスアプリケーションへの自動入力 ... 44 図11：デジタルクーポン/クーポン償還の追跡 ... 47 図12：保証 ... 52 図13: 返品と交換 ... 57 図14:ターゲットマーケティング ... 59 図15:期限切れになるポイント ... 63 図16:プロモーションが追加されたデジタルレシートの発行 ... 67 図17:クーポンが追加されたデジタルレシートの発行 ... 70 図18:人数/会計組数,サービス料,場所情報が付加されたデジタルレシートの発行 ... 74

(5)

1 序章

本書は ARTS XML デジタルレシートワークチームの仕様書であり、概要書として位置づけられ、ARTS XML 策定プロセスに沿って作成された。

2 改版履歴

イベント変更日付 Ver.1.0 公開 2003-06-13 Ver.2.0 公開 2009-12-28 Ver 2.1 作成中 2016-02-23 承認された本書の展開方法と ARTS XML スキーマの全体像については、 www.nrf-arts.org に掲載されている ARTS XML Technical Report “Best Practices -- Schema Extensibility”を参照。適合性試験に合格するには、この方法を順守しなければならない。

3 チーム名

ARTS XML ワークチームの名称変更に際し、「電子レシート分科会」が提案されている。

4 チームの使命

本チームの使命は、販売時点の取引処理に完全なペーパーレス化が求められる現在の小売環境において、最新テクノロジーへのニーズに応えることのできるデジタルレシート XML スキーマの改訂版を作成することにある。この種の新テクノロジーは、モバイルペイメントやデジタルクーポン、顧客ロイヤリティのアプリケーションとして表すこともできる。この度のデジタルレシート XML スキーマの新バージョンの目的のするところは、上述の環境において現状の ARTS XML スキーマを考慮しつつ、様々なユースケースへの対応を提供することにある。

(6)

5 メンバー名簿

議長：

Birame Sock Third Solutions

貢献者：

Tim Wilson Lowes

Dennis Blankenship Verizon Wireless Dennis Paisley NCR

Jim Galloway Afterbot Lynn Myers Lowe’s Martin Wolfe IBM Mohammed Khan Vivotech Richard Halter ARTS Richard Mader ARTS

Hendrik Scheider Wincor-Nixdorf Jonathan Evald Buus Cellpoint Mobile Carole Barlow Lowe’s

Krystal Kolodziejak Sasktel Labs Mike Julson Escalate Retail Phuc（David）N. Tran Verizon Business

議長(日本)：

Masanori Sambe TOSHIBA TEC CORPORATION

貢献者(日本)：

Jin Hashiba Dai Nippon Printing Co., Ltd

Yasuo Sakami Foresight Co.,Ltd.

Akira Matsuyoshi Insight Corporation

Koji Sasaki LOG NOTE Co.,Ltd.

Soichi Fujii Microsoft Japan Co., Ltd.

Akio Tajima NCR Japan, Ltd.

Takuro Miyuki NEC Platforms, Ltd.

Kazutoshi Ota OK Systems

Tadashi Furuhata Seiko Epson Corporation

(7)

Yusuke Udagawa SHARP CORPORATION

Takao Tamura Sorimachi Giken Co.,Ltd

Kenichi Nagai STAR MICRONICS CO., LTD.

Ayako Shimazaki The Distribution System Research Institute

Toyohiro Yasumoto VINX CORP.

フードサービス仕様の貢献者(日本)：

Yoshio Ohba Seiko Instruments Inc.

Yuu Kusama Open Foodservice Systems Consortium (OFSC) Hidehiko Fujioka DYNAC CO. , LTD.

Umetsu Noriyuki Fujitsu Isotec Limited

Shinya Oikawa Public university corporation Miyagi university Kazuhiro Kobayashi Teraoka Seiko Co., Ltd.

Masanori Murai ASKA-T3 Co,ltd.

shigeru Okada Open Foodservice Systems Consortium(OFSC) Jun Watanabe NEC Platforms Limited

Tsuneo Yashima Justplanning Inc．

Kiyoshi Kurokura CITIZEN SYSTEMS JAPAN CO. LTD. Koichi Shibata Seiko Solutions Inc.

事務局(日本)：

Soichi Fujii Microsoft Japan Co, Ltd.

(8)

6 ビジネス上の利点

6.1 デジタルレシートとは？

デジタルレシートとは、顧客に提供される紙のレシートの記載情報のイメージであるが、小売取引の完全なログではない。これと同じドキュメントが、小売業者などにより、消費者と小売業者の間での取引発生の確認と検証に用いられることもある。消費者もまた、デジタルレシートに含まれる情報を経済状況や税金の管理に用いることができる。さらに同一の情報をマーケティング担当者が、過去の購買行動に基づいた顧客の特定に利用することもできる。デジタルレシートは次のように様々に定義できる。 • 複数のプロトコル（e メール、TCP/IP、WAP、赤外線ポート、Bluetooth など保管や抽出、分析を容易にするもの）を介した従来からの紙のレシートの電子版 • 紙のレシート以上の完全な取引データを内包する、パーソナライズされた、双方向的なコンピュータードキュメント • サードパーティーによるアプリケーション統合を容易にする、拡張可能な XML メッセージ • デジタルレシートは消費者の承認があって初めて発行される安全な取引である

6.2 デジタルレシートのユーザー

小売業界全体におけるデジタルレシートの一般的なユーザーとして、次の集団を挙げることができる • 発行者：流通業者、金融機関、製造業者などの、顧客にデジタルレシートを提供する事業者 – その他の決済形式（モバイル事業者） – オンラインやオフラインの事業者 • 受領者：デジタルレシートの発行と受領を承認する購入者 – 小売の顧客（消費者、企業/団体） – 小売業者 • サードパーティー：デジタルレシートの利用・処理を行う代理店や企業 – 経費管理 – 税金 – 経費精算 – クレジットカード利用控え等 – クーポン及び保証

(9)

6.3 デジタルレシートの利点

デジタルレシートには、小売業界全体における様々な関係者に複数の利点がある。こうした関係者には、小売業者内部の事業部や、消費者、マーケティング担当者、サードパーティーのアプリケーション業者（顧客の購買データを受領できるという利点がある）も含まれる。事業者にとっての利点 • 経費：紙のレシート利用に取って代わる、より低コストな選択肢としてどの業界にも当てはまる • クーポンの精算 • 返品や返金にまつわる不正の抑制 • 環境対策消費者にとっての利点 • 複数のインターフェイス経由で容易に情報にアクセス可能 • 税金、返金等に関する購買の証拠 • 経費管理と予算作成 • 購入製品に関する任意の情報の受領 • 保証 • リコール • クーポンマーケティング担当者にとっての利点 • ターゲットマーケティング • クーポンの交換と決済 • クーポン不正の抑制サードパーティーによる予算作成/経費管理アプリケーションにとっての利点 • 返品やクレジットカード係争、クーポンの認証などを含む、取引処理の管理の改善

6.4 POSLog

と比べた場合のデジタルレシートの利点

小売企業では ARTS データモデルと ARTS XML スキーマはともにデータ処理システムの要素として捉えられている。そのため、情報の主な利用法は、企業内での他のアプリケーションによる情報処理となる。POSLog の場合には、発行-購読型のユースケースのセットとして文書化され、分析されるが、販売時点管理（POS）システムやその同等物では、以下のアプリケーションを購読者と想定して取引を発行する。

(10)

• 売上監査 • 出退勤 • 物品移動（在庫） • 労働計画 • 店内会計 • プロモーションの追跡 • 顧客の来店頻度、ロイヤルティ、関係づくり • 承認 • セキュリティ監査 • データウェアハウジング • 返品確認（事後解約、修理など） • 予測購読者ごとに個別の XML インターフェイスを提供する可能性も考慮はされたが、全アプリケーションの要件を満たす共通の XML インターフェイスを 1 つ提供することとなった。この方が、POS 取引ログファイルを通じてアプリケーションを統合する、従来からの慣習に合致するためである。監査やセキュリティ、労働生産性、並びにアクティビティ分析の各アプリケーションには詳細な内容が強く求められる点も考慮された。これらすべてが、包括的な単一の XML スキーマの必要性を訴えていた。デジタルレシートスキーマは、本質的に異なる文脈と利用法を念頭に開発された。そのために結果も、小売取引における物品と支払の記録という基本的に同一の対象であるにも関わらず、大きく異なっている。デジタルレシートの構成は、実際の紙のレシートを評価基準として用いた POSLog の派生物である。実際にデジタルレシートの構成と内容は、従来からの紙のレシートの構成と密に沿うように図られている。 POSLog の内容は、アプリケーションによる処理を主目的としている。その項目の多くは紙のレシートに無いものであったため、デジタルレシートスキーマからはほぼ削除された。それにより、デジタルレシートの構成はより簡素になっている。もちろんアプリケーション処理を完全に見捨てたわけではない。それならデジタルレシートも、XML でなく HTML にすることもできただろう。デジタルレシートでサポートが予定されるのは、具体的には以下のアプリケーションなどである。

(11)

• 消費者へのプロモーション伝達 • 購買済品目に基づくマーケティングとマーチャンダイジング • 返品、クーポン、メーカー登録用の購入証明 • 支払に関する係争解決 • Zaim やレシーピや MoneyForward などの家計簿アプリケーション • 会計王、勘定奉行などの小企業向け財務アプリケーションこれらのアプリケーションで必要なのは、購買品目や決済方法のような、取引の最終結果についての必須情報のみである。誤入力され、取消線で修正されたような品目名は紙のレシートでも急速に姿を消しつつあり、XML デジタルレシートでも含めないこととなった。ソースの特定に必要な事業者及び店舗などのメタデータは、デジタルレシートスキーマに明示的に追加された。小売企業のデータ処理環境の文脈を超えたところでレシートのイメージを再現するために必要となる、テキスト要素だったためである。さらにデジタルレシートでは、非従来型の販路も対象として想定したため、カタログ取引やインターネット取引用の構成も追加されている。実際のところ、デジタルレシートの利点の一つに販路統合の可能性も挙げられる。全販路に単一で共通のデジタルレシートを提供でき、一つの販路に由来するレシートは、その他すべてへのリンクとプロモーションを内包しうるのである。最後に、デジタルレシートは消費者とのコミュニケーションメディアとなることも想定されている。そのためにスキーマには、消費者が目にした際にサービスやプロモーションと統合させるリンク（URL）が含まれている。これには消費財メーカーが費用を負担する品目レベルのリンクなどもあり、収益追求の機会となり得る。デジタルレシートは、レシートに対する具体的なニーズに応じて POSLog を元にした派生物である。そのような理由から、このスキーマはサイズが小さく動きも良いため、必要なメモリーは少なく、処理要件も抑えられる。また、サイズが小さいことから再現要件も抑えられており、それが本標準の大きな利点となっている。

(12)

7 小売モデルインターフェイス

/構築モデル

図1：デジタルレシートのインターフェイス • ターゲットマーケティング — 顧客と他のサードパーティーシステム（携帯電話会社）間 — 購買物に基づくマーケティングとマーチャンダイジング • データマイニング • エンドユーザーの財務 —家計簿アプリケーション • 売上記録 —小企業向け財務アプリケーション • ユーザービューアー • 返品 — 返品、クーポン、メーカー登録用の購入証明 • 支払をめぐる係争の解決 • ビジュアルマーチャンダイジング — 消費者プロモーションの伝達 • ユーザー通知

7.1 ビジネスプロセスモデル

以下のビジネスプロセスモデルは、デジタルレシートが、小売業者のネットワーク内外における売上及び返品のプロセスのどこに位置づけられるか、文脈を提供するべく作成された。

(13)

図2：デジタルレシート売上の BPMN

(14)

(15)

8 ミッションの対象範囲

8.1 Ver.1

でのプロジェクト範囲

デジタルレシートスキーマの構成では、ドキュメントベースのSGML のレガシーである、XMLの階層的かつ連続的な性質を活かし、紙のレシート文書を可能な限り直接的に、かつシンプルに模した上で、以下の重要な事業目標に対応する。 • 消費者による閲覧とプロモーションの伝達に向け、HTML へのシンプルな XSLT レンダリングに対応する • HTML イメージとリンクを埋め込んだ、単一の共通レシートを通じて流通経路の統合とプロモーションを支援する・近接する電子支払レシートに基礎を提供する • 購買品目に基づくマーケティングとマーチャンダイジングを促進する • 返品、クーポン、メーカー登録のための購入証明を提供する • 支払係争の解決を支援する

• Open Financial Exchange（OFX）のメッセージインフラストラクチャーを利用し、Zaim やレシーピや MoneyForward などのパーソナルファイナンスアプリケーションへの自動入力を支援する • 会計王、勘定奉行などの小企業向け財務アプリケーションへの自動入力を支援するこれらのアプリケーションは、購買品目や決済方法といった取引の最終結果についての最低限の情報しか求めない。誤入力され、取消線で修正された品目などは含まれない。デジタルレシートでは、ジャーナルの監査機能の対応は意図されていない。安全なインフラストラクチャー、認証や否認のサポートは、本規格の範囲ではないが、購入証明及び支払係争解決のアプリケーションに対する完全なサポートが求められる。

8.2 Ver.2

でのプロジェクト範囲

• iPhone アプリケーションのようなクライアントアプリケーションによる識別を容易にするために、デジタルレシートメッセージの命名規則を確立する。 • スキーマのアップデート – （購買プロセスの中での償還の文脈の中で用いられる）クーポンとロイヤルティ – 支払 – PCI - DSS / セキュリティ – 顧客の識別

(16)

– 返品/交換ポリシーの明確化 – データ検証 – サードパーティーアプリケーション（個人支出管理ソフトウェア） – 品目のサブ情報（ボトルリターン登録、重量など） – SOA サービス – デジタルレシートスキーマと SOA ワークとのかかわりのレビュー – 顧客インターフェイス– 顧客に自身の購買物を知らせる上で最低限のデータセット – 表示規格（XSLT） • モバイルペイメントのサポート – 詳細の特定– 携帯機器メーカーやモバイルペイメント団体に意見を求める • 他のスキーマとの相互運用性 – POSLog/Data モデルとのリンク – 可能な限りの広報互換性、ただしスキーマは以下との整合を取るものとする – ARTS XML – SOA のベストプラクティス – データディクショナリー – 共通データ • その他 – POSLog からデジタルレシートへのマッピング – 保存する値 – （顧客注文取引に対する）小売取引 – バグ修正 Ver.2.0 での範囲外 8.2.1 • インボイス発行 • 予約販売/クロスチャネル取引 -> 顧客注文取引（支払と引渡後に該当)（航空チケット購入シナリオ） • デジタルクーポン（顧客へのクーポン提供の文脈で使用する場合[レシート下部への印刷])（ARTS でのデジタルクーポンの生成を探る必要がある）

(17)

8.3 Ver.2.1

でのプロジェクト範囲

日本要件及びフードサービス要件を検討抽出し、追加した。・11.10 期限切れになるポイント・11.11 プロモーションが追加されたデジタルレシートの発行・11.12 クーポンが追加されたデジタルレシートの発行・11.13 人数/会計組数,サービス料,場所情報が付加された,デジタルレシートの発行・11.14 オペレーター情報が付加された、デジタルレシートの発行

9 PCI の影響

ユーザーにはPCI の公開するガイドラインに従うことが推奨される。

(18)

10 ビジネス上の価値

10.1 発行者にとってのデジタルレシート

デジタルレシートにより、発行者は顧客に新たなサービスを提供することができる。消費者による閲覧とプロモーションのユースケースで発行者は、顧客の購買履歴を閲覧し、e メールで顧客とのコミュニケーションをとることができる。メールの大量送信は、顧客の購買履歴と個人情報に基づく、的を絞ったe メールリストに変容する。クーポンや保証、登録の用紙は別途に送付されることが多く、付随する手数料は添付として送信可能である。マーケティングとマーチャンダイジングのユースケースでは、顧客の購買行動を分析し、受け入れの可能性の高いオファーやプロモーションを作成するための詳細なデータを提供する。発行者はデジタルレシートの利用を通じ、広告費へのリターンの少ない汎用的なプロモーションを、ハイリターンの顧客サービスに変化させることができる。非接触電子マネーのユースケースでは、商業分野への新たなテクノロジーデバイスの導入を可能にする。PDA や携帯電話を支払いや、レシート及び関連フォームの受領に利用できる。クレジットやデビットの支払いもこれらの機器から様々なデバイスに伝送できる。これにより取引時間は減少し、人件費の抑制につながる。購入証明のユースケースでは、発行者が不正を抑制することができる。発行者は、デジタル署名などの、受領者を特定する確認情報の捕捉用に提供される多数のテクニックのいずれかを用いて購入証明をコントロールする。デジタルレシートは返品システムの中に容易に組み込んで実際の購入を追跡できるため、返品プロセスの中で別途に入力を行う必要がなくなる。クレジットカード係争解決のユースケースで、発行者は、サードパーティーのクレジット会社に対し、係争となっている請求をカード会員が実際に購入したとの購入証明の、承認された実装物を以って証明することができる。購入者がその取引に異議を唱える場合には、その製品やサービスに対するチャージバックが発行者に寄せられる。購入の証明をする負担は発行者にかかる。デジタルレシートは、ドキュメントや、紙ベース又はマイクロフィルムベースのイメージの大掛かりな検索、並びに関連処理を不要にし、ここでも人件費を抑制する。取引レシートを

(19)

デジタルで保存し、伝達することにより、事業者は速やかに取引銀行に連絡し、係争を解決することができる。

10.2 受領者にとってのデジタルレシート

発行者に恩恵をもたらすデジタルレシートのユースケースは、そのまま受領者にも当てはまる。消費者による閲覧とプロモーションのユースケースでは、購買やクーポン、保証、登録に付随するフォームを受領者が受け取り、記入するための便利な手段を手にすることができる。将来的に受領者は、保証の要求や登録を通常の e メール処理で簡単に見つけ、処理できるようになる。伝達は双方向コミュニケーションとして企画されている。購入や返品、予約販売といった店頭やオンラインの小売取引について、受領者は発行者宛にe メールを簡単に送信する手段を獲得することになる。消費者にとっては真の価値がある。マーケティングとマーチャンダイジングで受領者は、特別オファーやプロモーションを送る権利を発行者に認めることにより、自身にとって価値のあるサービスや製品のリマインダーを受け取ることができる。デジタルレシートのプロセスを通じて発行者との信頼関係を構築した顧客は、興味のある特別プロモーションやディスカウントを見逃すことがないと安心することができる。非接触電子マネーで受領者は、小切手を書いたり、紛失しかねないクレジットカードを財布に入れて持ち歩いたりすることなく、製品やサービスの支払いを便利に行えるようになる。PDA や携帯電話があれば、どのアカウントからでもクレジットやデビットの支払いを送信できる。そしてレシートを電子的に返送してもらうことにより、受領者は自身の財務レコードの更新に使える購入記録を手にするのである。購入証明は、デジタルレシートプロセスの一環として提供される場合には、受領者が簡便かつ速やかに返品や保証の確認ができるようになる。返品の際の購入証明となる紙のレシートを、財布やファイル、引き出しをかき回して探す必要がない。クレジットカード係争は、単純に当月の請求書を受け取った受領者が、購入したことを忘れているために起こることが多い。係争書類を送る前に自身のデジタルレシートを少し閲覧すれば、誤った申立を防ぎ、適切な申立を確認することができる。

(20)

ファイナンスアプリケーションへの自動入力は、家庭用の予算作成ソフトウェアや会計ソフトウェアに関わっている。デジタルレシートは、特に人気のある家庭用や小企業向けのソフトウェアパッケージとの統合を目指して設計された。デジタルレシートがあれば、小売や銀行由来の受領情報を手動で入力する必要性がない。デジタルレシートのユーザーなら、シンプルなe メールパッケージでも、税金に対処する時間がずっと楽になるはずである。

10.3 サードパーティーにとってのデジタルレシート

消費者による閲覧とプロモーションで、発行者は、デジタルレシート情報を製品のメーカーやサービスプロバイダーと共有し、消費者の需要に合わせて生産サイクルや人員配置レベルを調整することができる。デジタルレシートは、サプライチェーンの関係者全員に、自身のビジネスや原材料、製造、発送、小売業者や消費者をより良く管理するための情報を提供できる。マーケティングとマーチャンダイジングでは、デジタルレシート情報を共有する参加サプライヤーが、自社製品を直接消費者に販促できるようになる。自社のウェブサイトでのより良い製品情報の提供や、消費者への直接配達で時間とコストを削減できる。購入証明により、メーカーは、保証サービスの承認と虚偽申立の抑制が容易になる。クレジットカード係争解決では、顧客が購入を忘れただけの係争を削減することにより、処理コストを抑制できる。デジタルレシートの提供する電子情報があれば、銀行やクレジットカード会社は容易に係争が解決できるようになる。ファイナンスアプリケーションへの自動入力により、家庭用や小企業向けの会計ソフトウェアパッケージの利用が増加する。自動入力の利便性は、受領者による経費管理や支払、税金対応でのソフトウェア利用を促進する。

(21)

11 ユースケース調査

11.1 ユースケース：消費者による閲覧

サードパーティーによるレシートの閲覧 11.1.1 図5：顧客による閲覧 デジタルレシート文書は HTML や WML などといった機器依存で閲覧可能なフォーマットへのレンダリングをサポートするために必要な情報を提供し、その成果物のファイルは顧客（受領者）に送信される。このファイルにはデジタルレシート由来の静的情報が含まれ、事業者（発行者）への再訪を促すための宣伝文句及び/又はハイパーリンクが含まれることもある。送信メカニズムは、発行者のサイトで変換されるシンプルな e メールから、必要に応じてサーバーで翻訳されるデジタルレシートのストレージまで様々である。シナリオ：消費者が商品を購入する概要

(22)

消費者は、商品を購入し、レシートを電子メールアドレスか電話番号宛て送信させます。 シナリオ記述 スージーは、Her Storeで現金で青いシャツを5ドルで購入し、レシートを [email protected]に送信してもらう。その後スージーはレシートを印刷する。 データ レシートのイメージタイプコード ― HTML, PDF, JPG バイナリーデータ and/or 明細行 1..* 顧客ID（電子メール） ARTS XML に適合した XML の例 –消費者が商品を購入する: <?xml version="1.0" encoding="UTF-8"?>

<DigitalReceipt xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace/ DigitalReceiptV2.0.0.xsd"

xmlns="http://www.nrf-arts.org/IXRetail/namespace/" MajorVersion="6" MinorVersion="0"

FixVersion="0">

<UnitID Name="Her Store">100</UnitID> </BusinessUnit> <Logo LogoFormat="PDF"> <FileName>www.myreceipts.com/20101225</FileName> </Logo> <SequenceNumber>50</SequenceNumber> <POSLogDateTime>2006-05-04T18:13:51.0Z</POSLogDateTime> <ReceiptDateTime>2006-05-04T18:13:51.0Z</ReceiptDateTime> <ReceiptNumber>50</ReceiptNumber> <ReceiptImage>

<ReceiptLine>Blue Shirt $5.00</ReceiptLine> <ReceiptLine>Total $5.00</ReceiptLine> <ReceiptLine>Tender $5.00</ReceiptLine> </ReceiptImage>

</Sale>

(23)

<Total TotalType="TransactionGrossAmount">75.00</Total> <Customer> <CustomerID>0101</CustomerID> <EMail> <EMailAddress>[email protected]</EMailAddress> </EMail> </Customer> </RetailTransaction> </Transaction> </DigitalReceipt> ARTS XML に適合した XML の例 –消費者が商品を購入するロゴを表示: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

<UnitID Name="Her Store">100</UnitID> </BusinessUnit> <Logo LogoFormat="PDF"> <FileName>www.myreceipts.com/20101225</FileName> </Logo> <SequenceNumber>50</SequenceNumber> <POSLogDateTime>2006-05-04T18:13:51.0Z</POSLogDateTime> <ReceiptDateTime>2006-05-04T18:13:51.0Z</ReceiptDateTime> <ReceiptNumber>50</ReceiptNumber> <ReceiptImage>

<ReceiptLine>Blue Shirt $5.00</ReceiptLine> <ReceiptLine>Total $5.00</ReceiptLine> <ReceiptLine>Tender $5.00</ReceiptLine> </ReceiptImage>

(24)

<Customer> <CustomerID>0101</CustomerID> <EMail> <EMailAddress>[email protected]</EMailAddress> </EMail> </Customer> </RetailTransaction> </Transaction> </DigitalReceipt> 非接触通信で送信されるデジタルレシート 11.1.2 図 6:非接触通信で送信されるデジタルレシート デジタルレシート文書は、後に閲覧できるよう消費者（受領者）のデバイスに電子的に送信される。送信メカニズムは、IrDA 送信や Bluetooth、Wi-Fi などがあるがこれらに限定されるものではない。受領者のデバイスとしては携帯電話や PDA、ノート型コンピューターなどがある。

(25)

シナリオ：消費者が携帯電話で支払し、RFID を通じて直接、電話にレシートを受け取る概要消費者は、携帯電話で支払し、サインして決済が終わると、POSがレシートを返信する。消費者は、決済認証の情報や電子署名と一緒に携帯電話に表示されたレシートを確認する。シナリオ記述

スージーは、Her Favorite Storeで新しい財布を35ユーロで買い、SMSアカウントで支払います。そしてレシート(555) 123-4567に送ってもらいます。 データ 購入した店舗店舗名称住所電話番号ロゴ顧客の氏名、希望する連絡先顧客ID 購入日購入商品個数価格合計金額税金 支払 ― モバイルウォレット 電子署名 認証コード 合計 ARTS XML に適合した XML の例 –消費者が携帯電話で支払し、RFID を通 じて直接、電話にレシートを受け取る:

(26)

<TypeCode>RetailStore</TypeCode>

<AddressLine TypeCode="Street">123 Main Street</AddressLine> <City>Mustang</City> <Territory>Oklahoma</Territory> <PostalCode>12345</PostalCode> </Address> <Telephone> <AreaCode>555</AreaCode> <LocalNumber>1234567</LocalNumber> </Telephone> </BusinessUnit>

<FileName>My Favorite Store.gif</FileName> </Logo> <SequenceNumber>50</SequenceNumber> <POSLogDateTime>2006-05-04T18:13:51.0Z</POSLogDateTime> <RetailTransaction> <LineItem> <Sale>

<Tender TenderType="Mobile"> <Amount>35.00</Amount> <Authorization> <AuthorizationCode>asdfasdf</AuthorizationCode> <Signature>asdfasdf</Signature> </Authorization> </Tender> <SequenceNumber>2</SequenceNumber> </LineItem>

<CustomerID>CustomerID8</CustomerID> <Name>Suzy Queue</Name> <TelephoneNumber> <AreaCode>555</AreaCode> <LocalNumber>1234567</LocalNumber> </TelephoneNumber> </Customer> </RetailTransaction> </Transaction> </DigitalReceipt>

(27)

11.2 ユースケース：マーケティングとマーチャンダイジング

図7：マーケティングとマーチャンダイジング デジタルレシート文書は、後にマーケティングやマーチャンダイジングのトレンドを探るデータマイニングに備えて保管施設に送られる。このデータマイニングは事業者横断的に行われるものであるため、特定事業者のストレージモデルは問題とならない。シナリオ：自動的な買い物リスト概要自動的な買い物リストを作成するためにデジタルレシートを使用する。シナリオ記述フレッドは食料品の買い物に行く準備をし、彼のコンピューターから買い物リストを取得した。 データ 基本的なレシートデータトランザクション日付商品情報 UPC 数量 ARTS XML に適合した XML の例 –自動的な買い物リスト: <?xml version="1.0" encoding="UTF-8"?>

Point of Sale Third-Party Data Mining _Server Storage Facility

(28)

FixVersion="0">

<ItemID Name="Bread" Type="SKU">123</ItemID> <ExtendedAmount>1.50</ExtendedAmount> <Quantity>3</Quantity> </Sale> <SequenceNumber>50</SequenceNumber> </LineItem> </RetailTransaction> </Transaction> </DigitalReceipt> シナリオ：生鮮品の自動的な買い物リスト概要生鮮品の自動的な買い物リストを作成するためにデジタルレシートを使用する。シナリオ記述 データ 基本的なレシートデータトランザクション日付商品情報 UPC 数量消費期限

(29)

ARTS XML に適合した XML の例 –生鮮品の自動的な買い物リスト:

<?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

(30)

シナリオ：クーポンの取得概要顧客に適切なクーポンを提供するためにデジタルレシートを使用するシナリオ記述マイ・スペシャル・ストアはジョーの電話に MP3 プレイヤー購入のレシートと一緒に、通常価格 100 ドルの新しいヘッドフォンセットを 10%割引するクーポンを送信した。 データ 基本的なレシートデータトランザクション日付商品情報 UPC 数量クーポン情報ロゴバーコード/GTIN/クーポンコード説明有効期限 ARTS XML に適合した XML の例 –クーポンを含んだデジタルレシートを 受け取る: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

<UnitID Name="My Special Store">UnitID0</UnitID> </BusinessUnit>

<LogoBinary>ZGVmYXVsdA==</LogoBinary> </Logo> <SequenceNumber>50</SequenceNumber> <POSLogDateTime>2006-05-04T18:13:51.0Z</POSLogDateTime> <RetailTransaction>  <LineItem>

(31)

<Sale> <ItemID>123</ItemID> <Description>MP3 Player</Description> <ExtendedAmount>20.00</ExtendedAmount> </Sale> <SequenceNumber>1</SequenceNumber> </LineItem>

<LineItem> <Tender> <Amount>20.00</Amount> </Tender> <SequenceNumber>2</SequenceNumber> </LineItem>

<LineItem>

<LineItem>

<Sale>

<ItemID Type="GTIN">456343454356456</ItemID> <Description>Headphones</Description> <RegularSalesUnitPrice>100.00</RegularSalesUnitPrice> </Sale> <SequenceNumber>2</SequenceNumber> </LineItem> <Customer> <CustomerID>CustomerID8</CustomerID> <Name> <Name>Joe Cool</Name> </Name> </Customer> </RetailTransaction> </Transaction> </DigitalReceipt>

(32)

シナリオ：デジタルレシートに埋め込まれた調査の完了概要デジタルレシートに埋め込まれた調査を完了するためにデジタルレシートを使用する。シナリオ記述スージーはお気に入りの店で$5.00 のシャツを購入して、購入した体験についての調査に回答するように依頼された。 データ 基本的なレシートデータトランザクション日付調査調査へのリンク記述言語調査コード ARTS XML に適合した XML の例 –デジタルレシートに埋め込まれた調査 の完了: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

(33)

</LineItem> <Customer>

<CustomerID>CustomerID8</CustomerID> </Customer>

<Survey SurveyLink="www.survey.com"> <SurveyCode>123</SurveyCode> </Survey> </RetailTransaction> </Transaction> </DigitalReceipt> シナリオ：埋め込まれたリベート情報(海外事例) 概要デジタルレシートにリベート情報を含める。シナリオ記述

フレッドジョーンズはBest Electronics Storeにて250ドルで新しいラップトップを買い、メーカーから20.00ドルのリベートを得た。 データ 基本的なレシートデータトランザクション日付アイテムの情報リベートアイテムへのリンクリベートID リベート情報（今のところは拡張としてセットしているが、より詳細はリベートをサポートしたデータモデルのアップデートに合わせて次のリリースに加えられる） ARTS XML に適合した XML の例 –埋め込まれたリベート情報: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

(34)

<Sale>

</Rebate>

<Total CurrencyCode="USD">250.00</Total> <Customer> <CustomerID>CustomerID8</CustomerID> </Customer> </RetailTransaction> </Transaction> </DigitalReceipt>

(35)

11.3 ユースケース：購入証明

図8: 購入証明 デジタルレシート文書は、消費者への購入証明としての提示に備えた、後々の抽出のために事業者のシステムに保存される。このテクノロジーの用途としては、返品の承認、クーポン情報、メーカー登録などがある。安全なインフラストラクチャーや、承認、否認への対応は本ワークチームの対象外であるが、購入証明の用途では十分な対応が求められる。シナリオ：消費者が返品を要求する概要消費者はデジタルレシートとともにアイテムを返品する。店員はレシートナンバーをスキャンし元本のオリジナルのレシートを取り出す。消費者はバーコード表示が可能なスマートフォンアプリにデジタルレシートを格納する。情報は確実性のために最終的には小売のネットワークに存在する。小売業者はデジタルレシートにある店舗番号、トランザクション番号、日付、時刻を使ってデータを検索できる。しかしこの例ではデジタルレシートに含まれているバーコードを使っている。シナリオ記述概要参照 データ レシート番号（バーコード番号）

Point of Sale Storage FacilityThird-Party Proof of PurchaseClient

(36)

ARTS XML に適合した XML の例 –消費者が返品を要求(GTIN):

FixVersion="0">

</DigitalReceipt>

ARTS XML に適合した XML の例 –消費者が返品を要求(SKU):

FixVersion="0">

(37)

シナリオ：消費者が返品と返品レシートを要求する概要一旦返品が処理されると、返品情報を含む新しいレシートが発行される。シナリオ記述スージーは$20のシャツと$40の靴をStore_Aで購入した。彼女はそれから靴を返品し、返品レシートを受領した。 データ アイテム返品情報元取引レシートデータ→Transaction Link 合計払戻金 ARTS XML に適合した XML の例 –消費者が返品と返品レシートを要求す る: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

(38)

(39)

シナリオ：消費者が商品の交換を要求する概要消費者が商品をデジタルレシートと共に交換し、店舗側は取引元レシートを引出す為にそのレシート番号（バーコード）をスキャンする。シナリオ記述ジョーはシャツを返品したいと思っており、彼は携帯電話上にレシート番号を含むデジタルレシートを保持している。店舗ではレシート番号をスキャンし、全レシートを検索して、元の購入品を照会する。 データ レシート番号（バーコード番号） ARTS XML に適合した XML の例 –消費者が商品の交換を要求する: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

<Transaction MajorVersion="6" MinorVersion="0" FixVersion="0"> <BusinessUnit> <UnitID>100</UnitID> </BusinessUnit> <SequenceNumber>75645</SequenceNumber> <POSLogDateTime>2007-05-04T18:13:51.0Z</POSLogDateTime> <ReceiptDateTime>2006-05-04T18:13:51.0Z</ReceiptDateTime> <ReceiptNumber TypeCode="UPC-A">124124124</ReceiptNumber> </Transaction> </DigitalReceipt> シナリオ：消費者が商品の交換と新しいレシートを要求する概要一旦交換処理がされると、払い戻しまたは新規販売情報を含む新たなレシートが発行されるシナリオ記述ディックは$40のテーブルを安い$10のテーブルに交換を望んだ。彼は交換がなされたことと払戻金($30)を受領したことを示すレシートを受け取った。

(40)

データ 返品アイテム情報アイテムリンク（Itemlink）アイテム販売情報元取引レシート番号→Transaction Link 合計支払（払戻金/販売） ARTS XML に適合した XML の例 –消費者が商品の交換と新しいレシート を要求する: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

<SequenceNumber>2</SequenceNumber> </TransactionLink> </Return> <SequenceNumber>1</SequenceNumber> </LineItem> <LineItem> <Sale> <ItemID>1234</ItemID> <ExtendedAmount>10.00</ExtendedAmount> </Sale> <SequenceNumber>2</SequenceNumber> </LineItem> <LineItem>

(41)

(42)

11.4 ユースケース：クレジットカード係争解決

図9: クレジットカード係争解決 デジタルレシート文書は、サードパーティーの企業への購入証明としての提示に備えた後々の検索のために、事業者のシステムに保存される。支払係争が発生した場合には、事業者はデジタルレシートを呼び出し、支払いが正当かつ承認を得たものであることを証明するに十分な情報を提供する。安全なインフラストラクチャーや、承認、否認への対応は本ワークチームの対象外であるが、クレジットカード係争解決の用途では十分な対応が求められる。シナリオ：顧客が銀行を通じて取引金額に異議を唱えた概要顧客が取引金額に対する異議を、銀行に対して行う。銀行は、販売者に取引の確認を依頼する。販売者は、デジタルレシートを銀行に提供する。シナリオ記述ジョーは、５ドルの真新しい青色のシャツを、クレジットカードを使って購入した。店舗から５０ドルの請求されていることを見つけた。 データ レシート番号トランザクション番号取引日時店舗合計金額支払情報認証番号支払金額

(43)

ARTS XML に適合した XML の例 –顧客が銀行を通じて取引金額に異議を 唱えた:

FixVersion="0">

</Tender>

</Transaction> </DigitalReceipt>

(44)

11.5 ユースケース：ファイナンスアプリケーションへの自動入力

図10：ファイナンスアプリケーションへの自動入力 デジタルレシート文書は、後々のファイナンスアプリケーションへの自動入力に備えて消費者に送信される。ファイナンスアプリケーションとしては、Zaim やレシーピや MoneyForward のような家計簿アプリケーションと、会計王や勘定奉行のような事業用財務アプリケーションなどがある。このユースケースでは、 Open Financial Exchange（OFX)のような既存のメッセージングインフラストラクチャーも対応可能である。シナリオ：顧客が自宅で一般的なアプリケーションで購買記録を付ける（例：会計ソフトウェア、電子メールクライアント）概要顧客が商品を購入すると、電子メールアドレスまたは携帯電話にレシートが送られる。会計ソフトウェアや電子メールクライアントで自宅に連携している。シナリオ記述スージーは、５ドルの青いシャツを現金で購入した。彼女の携帯電話に（レシート読み取りアプリによって読み取られた）レシートが送られる。レシートは、会計ソフトや電子メールクライアントで自宅のコンピューターに連携する。 データ 購入店舗情報

(45)

店舗名店舗住所店舗電話番号店舗ロゴ顧客名、連絡方法顧客番号取引日時購入商品商品点数商品金額合計金額税金現金支払金額合計（支払金額） ARTS XML に適合した XML の例 –顧客が自宅で購買記録を付ける: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

<TypeCode>RetailStore</TypeCode>

<AddressLine>123 Main Street</AddressLine> <City>My Town</City>

<Territory>Territory</Territory> <PostalCode>5555555</PostalCode> </Address>

<Telephone TypeCode="Work"> <AreaCode>405</AreaCode> <LocalNumber>5551234</LocalNumber> </Telephone> </BusinessUnit> <Logo LogoFormat="JPG"> <FileName>www.herstore.com/HerStore.jpg</FileName> </Logo> <SequenceNumber>100</SequenceNumber>

(46)

<Sale>

(47)

11.6 デジタルクーポン

/

クーポン利用の追跡

図11：デジタルクーポン/クーポン利用の追跡 デジタルレシート文書には、取引に適用されるクーポンや、消費者がクーポンを受け取る必要があるなどのデータを含むデジタルクーポンについての情報が含まれる。クーポン及びクーポンの利用情報は、消費者の購入した物品に直接リンクされることがある。シナリオ：メーカークーポンの適用情報を参照する概要デジタルレシートを利用して、メーカークーポンが適用されたトランザクションを参照する。シナリオ記述タミーは5ドルと税金が0.25ドルの青いシャツを購入した。彼女は支払の一部として0.5ドルをメーカークーポンで支払い、4.75ドルを現金で支払った。 データ レシート基本情報取引日時購入商品情報支払クーポン適用情報ロゴ

(48)

バーコード／GTIN／クーポンコード説明関連商品 ARTS XML に適合した XML の例 –メーカークーポンの適用情報を参照す る: <?xml version="1.0" encoding="UTF-8"?>

FixVersion="0">

<FileName>www.herstore.com/HerStore.jpg</FileName> </Logo>

<Sale>

(49)

</Tender>