▶ テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-07-20
(45)【発行日】2022-07-28
(54)【発明の名称】電子手形管理方法及び装置並びに記憶媒体
(51)【国際特許分類】
G06Q 40/00 20120101AFI20220721BHJP
G06Q 20/06 20120101ALI20220721BHJP
G06Q 20/38 20120101ALI20220721BHJP
【ＦＩ】
G06Q40/00 430
G06Q20/06
G06Q20/38 310
【請求項の数】
18
(21)【出願番号】P 2019526479
(86)(22)【出願日】2018-03-06
(65)【公表番号】
(43)【公表日】2019-12-26
(86)【国際出願番号】 CN2018078171
(87)【国際公開番号】W WO2018161903
(87)【国際公開日】2018-09-13
【審査請求日】2019-05-17
【審判番号】
【審判請求日】2021-05-07
(31)【優先権主張番号】201710142464.X
(32)【優先日】2017-03-10
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】514187420
【氏名又は名称】テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】グオ，ルイ
(72)【発明者】
【氏名】リ，マオカイ
(72)【発明者】
【氏名】ジャン，ジアンジュン
(72)【発明者】
【氏名】ツー，ハイタオ
(72)【発明者】
【氏名】ジャオ，チー
(72)【発明者】
【氏名】ワン，ゾンユー
(72)【発明者】
【氏名】リアン，ジュン
(72)【発明者】
【氏名】ジュ，ダウェイ
(72)【発明者】
【氏名】リウ，ビンファ
【合議体】
【審判長】高瀬 勤
【審判官】渡邊 聡
【審判官】古川 哲也
(56)【参考文献】
【文献】特開２００３－２５６６５１（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１７／００１１３６５（ＵＳ，Ａ１）
【文献】中国特許出願公開第１０６１２７５７８（ＣＮ，Ａ）
【文献】手形決済 ＩＴで省力化 「フィンテック」実証実験 三菱ＵＦＪ銀，東京読売新聞，２０１６．０８．２９，朝刊，第２頁
【文献】赤羽 喜治，ブロックチェーン 仕組みと理論，株式会社リックテレコム，２０１６．１０．２８，初版，ｐ．１０６
【文献】鳥谷部 明寛，スマートコントラクト本格入門，株式会社技術評論社，２０１７．０３．０１，初版，ｐ．４６
(58)【調査した分野】(Int.Cl.，ＤＢ名)
G06Q20/06
G06Q20/38
G06Q40/00
(57)【特許請求の範囲】
【請求項1】
電子手形管理システムに用いられる電子手形管理方法であって、最初の手形情報を携帯する第１のユーザからの手形発行要求を受信することと、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を前記電子手形管理システムにおけるアカウントテーブルに記憶することと、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成することと、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信することとを含み、前記アカウントテーブルはブロックチェーンに記憶され、
前記第２のブロックを生成することは、前記手形発行要求、前記最初の手形情報、前記第１の手形アカウント、及び前記第１のユーザの署名情報に対して特徴値計算を行うことによりブロック本体特徴値を取得し、前記ブロック本体特徴値と前記第１のブロックのブロックヘッダ特徴値とを第２のブロックのブロックヘッダに記憶することを含む、電子手形管理方法。
【請求項2】
前記第１のユーザへ発行成功メッセージを送信した後、前記第１の手形アカウントを携帯する前記第１のユーザの手形取引要求を受信した場合、前記第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うことと、
手形取引が成功した場合、前記アカウントテーブルにおける手形アカウントを更新して、前記ブロックチェーンに、前記第１のユーザの手形取引を記録するためのブロックと、前記第２のユーザの手形取引を記録するためのブロックとを生成することと、
前記第２のユーザへ取引成功メッセージを送信することとをさらに含む請求項１に記載の方法。
【請求項3】
前記第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うことは、前記第２のユーザに前記第１の手形アカウントの受け取りのサインを行うように指示するための第１の受け取りサインの要求メッセージを前記第２のユーザへ送信することと、
前記第２のユーザの第１の受け取りサインの確認メッセージを受信した場合、手形取引が成功したと決定することと、
前記第２のユーザの第１の受け取りサインの拒否メッセージを受信した場合、手形取引が失敗したと決定することとを含む請求項２に記載の方法。
【請求項4】
前記手形取引が成功した場合、前記アカウントテーブルにおける手形アカウントを更新することは、手形取引が成功した場合、前記アカウントテーブルにおける前記第１の手形アカウントと前記第２のユーザの第２の手形アカウントとを更新することを含み、
前記ブロックチェーンに、前記第１のユーザの手形取引を記録するためのブロックと、前記第２のユーザの手形取引を記録するためのブロックとを生成することは、
前記ブロックチェーンに、前記第１のユーザの今回の手形取引イベントを記録するための第３のブロックと、前記第２のユーザの今回の手形の受け取りサインのイベントを記録するための第４のブロックとを生成することを含む、請求項２に記載の方法。
【請求項5】
前記第１のユーザの手形取引要求を受信した場合、前記第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うことは、前記第１のユーザの手形取引要求を受信した場合、前記手形取引要求が全額手形取引要求であれば、前記第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うことを含む、請求項２に記載の方法。
【請求項6】
前記第１のユーザの手形取引要求を受信した場合、前記第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うことは、前記第１のユーザの手形取引要求を受信した場合、前記手形取引要求が一部手形取引要求であれば、前記一部手形取引要求に携帯される取引資産情報に基づいて、前記アカウントテーブルにおいて、前記第１のユーザに対応する第３の手形アカウントを生成することと、
前記第２のユーザに一部の前記第１の手形アカウントの受け取りのサインを行うように指示するための第２の受け取りサインの要求メッセージを前記第２のユーザへ送信することとを含み、
それに応じて、前記手形取引が成功した場合、前記アカウントテーブルにおける手形アカウントを更新することは、
前記第２のユーザの第２の受け取りサインの確認メッセージを受信した場合、前記アカウントテーブルにおける前記第１の手形アカウント、前記第３の手形アカウント及び前記第２のユーザの第４の手形アカウントを更新することを含み、
前記ブロックチェーンに、前記第１のユーザの手形取引を記録するためのブロックと、前記第２のユーザの手形取引を記録するためのブロックとを生成することは、
前記ブロックチェーンに、前記第１のユーザの今回の手形取引イベントを記録するための第６のブロックと、前記第２のユーザの今回の手形の受け取りサインのイベントを記録するための第７のブロックとを生成することを含む、請求項２に記載の方法。
【請求項7】
前記第２のユーザの第２の受け取りサインの拒否メッセージを受信した場合、前記アカウントテーブルから前記第３の手形アカウントを削除することをさらに含む、請求項６に記載の方法。
【請求項8】
前記手形取引要求は、手形譲渡要求又は手形割引要求である、請求項２に記載の方法。
【請求項9】
前記第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行う前に、前記手形取引要求が手形割引要求である場合、前記電子手形管理システムにおける各ユーザへ前記第１の手形アカウントに対応する手形入札メッセージを送信することと、
前記第１の手形アカウントに対して入札が最も高いユーザを前記第２のユーザとすることとをさらに含む、請求項８に記載の方法。
【請求項10】
前記第１のユーザへ発行成功メッセージを送信した後、前記第１の手形アカウントが換金期限の満期になったことを検出した場合、前記第１のユーザへ手形換金要求を送信することと、
前記第１のユーザの換金確認メッセージを受信した場合、前記第１のユーザのために前記第１の手形アカウントに対応する資産を換金することと、
換金過程が成功した場合、前記アカウントテーブルにおいて前記第１の手形アカウントを更新して、前記換金確認メッセージと直前のブロックのブロックヘッダ特徴値とに基づいて、第５のブロックを生成することと、
前記第１のユーザへ換金成功メッセージを送信することとをさらに含む、請求項１に記載の方法。
【請求項11】
手形取引の取引フローに基づいて、前記アカウントテーブルにおける前記第１の手形アカウントのアカウント情報におけるアカウント状態を変更することをさらに含み、前記アカウント状態は、譲渡済み状態、割引済み状態、換金済み状態及び正常保有状態を含む、請求項２～１０のいずれか一項に記載の方法。
【請求項12】
手形取引過程において対話するメッセージには、メッセージ送信ユーザが前記メッセージに対して署名した署名情報がさらに携帯されている、請求項１～１０のいずれか一項に記載の方法。
【請求項13】
前記第１のユーザからの手形発行要求を受信した後、前記最初の手形情報における手形識別子に基づいて、前記手形識別子に対応する商業手形情報を照会することと、
前記商業手形情報が前記最初の手形情報と一致すれば、前記最初の手形情報に基づいて前記第１のユーザに対応する第１の手形アカウントを生成するステップを実行することとをさらに含む、請求項１～１０のいずれか一項に記載の方法。
【請求項14】
手形取引要求を受信した場合、前記手形取引要求に携帯される手形アカウントに基づいて、前記手形取引要求と前記手形アカウントとが一致するか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了すること、或いは、前記第１の手形アカウントが換金期限の満期になったことを検出した場合、前記第１の手形アカウントが換金条件を満たすか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了することをさらに含む、請求項２～１０のいずれか一項に記載の方法。
【請求項15】
いずれかのユーザから受け取りサイン対象の手形アカウントの受け取りサインの拒否メッセージを受信した場合、前記ユーザの受け取りサインの拒否メッセージを前記アカウントテーブルにおける前記受け取りサイン対象の手形アカウントへと更新すること、或いは、いずれかのユーザから換金対象の手形アカウントに対する換金拒否メッセージを受信した場合、前記ユーザの換金拒否メッセージを前記アカウントテーブルにおける前記換金対象の手形アカウントへと更新することをさらに含む、請求項２～１０のいずれか一項に記載の方法。
【請求項16】
少なくとも１つの命令、少なくとも１つのプログラム、コードセット又は命令セットが実行されることにより請求項１～１５のいずれか一項に記載の電子手形管理方法を実現する１つ又は複数のモジュールを含む電子手形管理装置。
【請求項17】
１つ以上のプロセッサと、少なくとも１つの命令、少なくとも１つのプログラム、コードセット又は命令セットを記憶するためのメモリとを含み、前記少なくとも１つの命令、前記少なくとも１つのプログラム、前記コードセット又は命令セットは、前記プロセッサによりロードして実行されることにより、請求項１～１５のいずれか一項に記載の電子手形管理方法を実現する電子手形管理装置。
【請求項18】
プロセッサによりロードされて実行されることにより請求項１～１５のいずれか一項に記載の電子手形管理方法を実現する少なくとも１つの命令、少なくとも１つのプログラム、コードセット又は命令セットが記憶されている記憶媒体。【発明の詳細な説明】
【背景技術】
【0001】
＜関連出願＞
本願は、２０１７年３月１０日付けで中国国家知識産権局に出願され、出願番号が２０１７１０１４２４６４．Ｘであり、発明の名称が「電子手形管理方法及び装置」である中国特許出願に基づく優先権を主張しており、その内容はすべて本願のリファレンスに組み込まれる。
本願は、２０１７年３月１０日付けで中国国家知識産権局に出願され、出願番号が２０１７１０１４２４６４．Ｘであり、発明の名称が「電子手形管理方法及び装置」である中国特許出願に基づく優先権を主張しており、その内容はすべて本願のリファレンスに組み込まれる。
【0002】
＜技術分野＞
本発明の実施例は、ネットワークの技術分野に関し、特に電子手形管理方法及び装置並びに記憶媒体に関する。
本発明の実施例は、ネットワークの技術分野に関し、特に電子手形管理方法及び装置並びに記憶媒体に関する。
【0003】
＜背景技術＞
ネットワーク技術の発展に伴い、電子手形、電子証明書などのネットワーク派生物が生まれた。電子手形とは、データメッセージの形式で記憶された手形をいう。電子手形は、主に商業貿易に応用され、商業貿易において譲渡、割引又は質入れなどを行うことができる。例えば、企業ユーザＡは、企業ユーザＢから１バッチの商品を購入し、企業ユーザＡはまだ企業ユーザＢに対応する金額を支払っていないが、企業ユーザＢは依然として、売掛金情報、手形保有者情報、振出日及び満期日などを含む企業ユーザＡと企業ユーザＢとの間の取引情報を記録している電子手形をインターネット銀行を介して取得できる。企業ユーザＢは該電子手形の保有者として、インターネット銀行を介して該電子手形に対して譲渡、割引又は質入れを行うことができる。
ネットワーク技術の発展に伴い、電子手形、電子証明書などのネットワーク派生物が生まれた。電子手形とは、データメッセージの形式で記憶された手形をいう。電子手形は、主に商業貿易に応用され、商業貿易において譲渡、割引又は質入れなどを行うことができる。例えば、企業ユーザＡは、企業ユーザＢから１バッチの商品を購入し、企業ユーザＡはまだ企業ユーザＢに対応する金額を支払っていないが、企業ユーザＢは依然として、売掛金情報、手形保有者情報、振出日及び満期日などを含む企業ユーザＡと企業ユーザＢとの間の取引情報を記録している電子手形をインターネット銀行を介して取得できる。企業ユーザＢは該電子手形の保有者として、インターネット銀行を介して該電子手形に対して譲渡、割引又は質入れを行うことができる。
【0004】
本発明の実施例を実現する過程において、発明者は、
関連技術に、少なくとも、ネットワーク自体が悪意のあるユーザに侵入される安全上の問題が存在し、従って、電子手形の取引情報が悪意をもって改竄される可能性が高いため、電子手形の安全性及び信頼性が低いという問題が存在していることを発見した。
関連技術に、少なくとも、ネットワーク自体が悪意のあるユーザに侵入される安全上の問題が存在し、従って、電子手形の取引情報が悪意をもって改竄される可能性が高いため、電子手形の安全性及び信頼性が低いという問題が存在していることを発見した。
【発明の概要】
【0005】
関連技術に存在する電子手形の安全性及び信頼性が低いという問題を解決するために、本発明の実施例は、電子手形管理方法及び装置並びに記憶媒体を提供する。前記技術的解決手段は以下のとおりである。
【0006】
一態様において、電子手形管理システムに応用される電子手形管理方法であって、
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信することと、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を前記電子手形管理システムにおけるアカウントテーブルに記憶することと、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成することと、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信することとを含む電子手形管理方法を提供する。
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信することと、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を前記電子手形管理システムにおけるアカウントテーブルに記憶することと、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成することと、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信することとを含む電子手形管理方法を提供する。
【0007】
一態様において、
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信するための受信モジュールと、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶するためのアカウント生成モジュールと、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成するためのブロック生成モジュールと、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信するための送信モジュールとを含む電子手形管理装置を提供する。
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信するための受信モジュールと、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶するためのアカウント生成モジュールと、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成するためのブロック生成モジュールと、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信するための送信モジュールとを含む電子手形管理装置を提供する。
【0008】
一態様において、１つ以上のプロセッサと、少なくとも１つの命令、少なくとも１つのプログラム、コードセット又は命令セットを記憶するためのメモリとを含み、前記少なくとも１つの命令、前記少なくとも１つのプログラム、前記コードセット又は命令セットは、前記プロセッサによりロードされ、且つ、
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信し、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶し、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成し、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信するという動作を実行する電子手形管理装置を提供する。
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信し、
前記最初の手形情報に基づいて、前記第１のユーザに対応する第１の手形アカウントを生成し、前記第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶し、
前記手形発行要求、前記第１の手形アカウント、及び前記電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、前記第１のユーザの手形発行イベントを記録するための前記第２のブロックを生成し、
前記第１の手形アカウントを携帯する発行成功メッセージを前記第１のユーザへ送信するという動作を実行する電子手形管理装置を提供する。
【0009】
一態様において、前記プロセッサによりロードされて実行されることにより上述のような電子手形管理方法を実現する少なくとも１つの命令、少なくとも１つのプログラム、コードセット又は命令セットが記憶されている記憶媒体を提供する。
【0010】
本発明の実施例は、第１のユーザの最初の手形情報に基づいて、アカウントテーブルにおいて第１のユーザに対応する第１の手形アカウントを生成するだけではなく、第１のユーザからの手形発行要求、第１の手形アカウント及びブロックチェーン内の第１のブロックのブロックヘッダ特徴値に基づいて、第２のブロックを生成するので、アカウントテーブルによりアカウント情報を管理できるだけではなく、ブロックチェーン内の前後ブロック間の関連関係に基づいて、ブロックにおけるいずれの情報が改竄される場合にも次のブロックにより検出でき、悪意のあるユーザが発行された電子手形を改竄するか又は否認することを回避し、それにより取引情報の安全性及び信頼性を保証する。
【図面の簡単な説明】
【0011】
本発明の実施例における技術的解決手段をより明確に説明するために、以下、実施例の説明に必要な図面を簡単に説明するが、明らかに、以下の説明における図面は本発明のいくつかの実施例に過ぎず、当業者にとって、創造的な労働を行わず、これらの図面に基づいて他の図面を取得することができる。
【図1】本発明の実施例に係る電子手形管理の実施環境の概略図である。
【図2】本発明の実施例に係る電子手形管理方法の概略図である。
【図3】本発明の実施例に係る元のデータ情報の記入インタフェースである。
【図4】本発明の実施例に係る登録インタフェースである。
【図5】本発明の実施例に係るユーザ登録のフローチャートである。
【図6】本発明の実施例に係る手形発行のフローチャートである。
【図7】本発明の実施例に係る手形譲渡のフローチャートである。
【図8】本発明の実施例に係る手形割引のフローチャートである。
【図9】本発明の実施例に係る手形分割のフローチャートである。
【図10A】本発明の実施例に係る手形換金のフローチャートである。
【図10B】本発明の実施例に係る手形取引のフローチャートである。
【図10C】本発明の実施例に係る手形取引のフローチャートである。
【図11】本発明の実施例に係る電子手形管理装置のブロック図である。
【図12】本発明の実施例に係る電子手形管理装置のブロック図である。
【図13】本発明の実施例に係る電子手形管理装置のブロック図である。
【図14】本発明の実施例に係る電子手形管理装置のブロック図である。
【図15】本発明の実施例に係る電子手形管理装置のブロック図である。
【図16】本発明の実施例に係る電子手形管理装置１６００のブロック図である。
【発明を実施するための形態】
【0012】
本発明の実施例の目的、技術的解決手段及び利点をより明確にするために、以下、図面を参照しながら本発明の実施形態をさらに詳細に説明する。
【0013】
図１は本発明の実施例に係る電子手形管理方法の実施環境の概略図である。図１に示すように、該実施環境は電子手形管理システムであり、かつ該電子手形管理システムと該電子手形管理システムにおけるユーザ１０１は、同一のブロックチェーンをそれぞれ記憶でき、該ブロックチェーンは、いずれも様々な情報がそれぞれ時間順に記憶されている複数のブロックで構成される。本発明の実施例において、各ブロックは１回の取引に関する情報を記憶できる。該電子手形管理システムは、ユーザ１０１の電子手形を管理し、例えば、電子手形を発行するか又は取引して、発行及び取引過程において取引情報をブロックチェーンのブロックに記憶する。ユーザ１０１は、電子手形管理システムと対話することにより、電子手形を発行するか又は他のユーザと取引を行い、該ユーザ１０１は具体的にはサプライヤユーザ、個人ユーザ、企業ユーザ又は銀行ユーザなどであってもよい。取引過程において、ユーザ１０１が使用する電子装置はノートパソコン、デスクトップパソコン、スマートフォンなどであってもよい。
【0014】
実際に、該電子手形管理システムは少なくとも２つのノードを含むことができ、少なくとも２つのノードは少なくとも２つのサーバ１０２を含むことができ、さらにゲートウェイ１０３などを含むことができ、該電子手形管理システムは、ＤＡＭ（Ｄｉｇｉｔ Ａｓｓｅｔ Ｍａｎａｇｅｍｅｎｔ、電子手形管理システム）であってもよい。該少なくとも２つのサーバ１０２は、ブロックチェーン技術に基づいて各ユーザの電子手形を管理するために用いられ、ゲートウェイ１０３は、ユーザ１０１とＤＡＭとの間のアクセスサービスを提供するために用いられてもよいし、本実施環境における記帳ノードとして、取引過程における取引情報を記憶して、定時に更新するために用いられてもよい。それにより実施環境における他のノードは取引情報を共有することができ、各ノードは取引情報のために一致性証明を提供でき、取引情報の安全性を向上させる。例えば、１回の手形譲渡過程が完了する場合、該記帳ノードは各ノードのノード識別子（例えばネットワークアドレス）に基づいて取引情報を各ノードのブロックチェーンへ共有できる。サーバ１０２はゲートウェイ１０３を介してユーザ１０１と対話することにより、ユーザ１０１の電子手形を管理できる。電子手形管理システムの実際の動作過程において、さらに銀行システム１０４との対話に関連し、銀行システム１０４は真の商業手形情報を提供し、それによりユーザの提出した元の手形情報の真偽を検証する。
【0015】
該電子手形管理システムは、１本のブロックチェーンを記憶するほか、ある電子手形を識別するための少なくとも１つの手形アカウントと、対応する該電子手形を説明するためのアカウント状態、アカウント残高のようなアカウント情報とが記憶されるアカウントテーブルを記憶でき、該アカウントテーブルは取引に応じて更新されてもよく、したがって取引過程において電子手形を動的に更新する方法を実現する。
【0016】
実際には、アカウント情報の安全性を保証するために、アカウントテーブルにおけるアカウント情報は毎回の取引過程に伴ってブロックチェーンに記憶されてもよく、すなわち前記アカウントテーブルはブロックチェーンに記憶される。ブロックチェーンにおける情報を変更できないため、取引過程においてアカウント情報を更新する必要があるたびに、元のアカウント情報を変更することなく、更新されたアカウント情報を新たなブロックに記憶する。
【0017】
説明すべきこととして、上記電子手形システムはＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、ハイパーテキスト転送プロトコル）プロトコルのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ、アプリケーションプログラミングインタフェース）インタフェースに基づくことができ、該ＡＰＩインタフェースは双方向証明書検証を採用して、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ(登録商標) Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ、ＪａｖａＳｃｒｉｐｔオブジェクト表記言語）データのＰＯＳＴ呼び出しをサポートして、ＪＳＯＮデータを統一的に返信する。複数の文字セットの符号化による異常を回避するために、該電子手形システムの文字符号化はＵＴＦ－８（８－ｂｉｔ Ｕｎｉｃｏｄｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｆｏｒｍａｔ、８ビットユニコード変換フォーマット）符号化を統一的に使用することができる。ＪａｖａＳｃｒｉｐｔは直訳式スクリプト言語である。ＰＯＳＴ呼び出しはＨＴＴＰプロトコルにおける重要な構成要素であり、宛先サーバへ更新要求を送信するために用いられる。該電子手形管理システムはさらにＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ、楕円曲線デジタル署名アルゴリズム）などの署名アルゴリズムを用いて、取引時にユーザが開始したメッセージに対して署名できる。該署名アルゴリズムは以下の２つのパラメータ部分に分けることができる。第１の部分はサービスパラメータであり、該サービスパラメータは開始ユーザが自分の秘密鍵で署名し、ＤＡＭプラットフォームがユーザの公開鍵を用いて検証する必要がある。第２の部分はプロトコルパラメータであり、該プロトコルパラメータはｈｔｔｐｓ開始の要求者（ゲートウェイ／開発能力を有する関与者）が自分の秘密鍵で署名し、ＤＡＭプラットフォームが要求者の公開鍵を用いて検証する必要がある。
【0018】
【0019】
２０１において、最初の手形情報を携帯する第１のユーザからの手形発行要求を受信する。
【0020】
該第１のユーザとは該電子手形管理システムに登録されたいずれかのユーザをいい、個人ユーザ、企業ユーザ又は銀行ユーザなどに限定されない。最初の手形情報とはユーザの保有する商業手形の手形情報をいい、少なくとも該最初の手形情報の手形識別子を含み、該商業手形の資産情報、振出日、満期日、ユーザの銀行アカウント番号、預金銀行及び発行資産情報などをさらに含むことができる。図３に示すとおり、本発明の実施例は、元のデータ情報の記入インタフェースを提供し、該元のデータ情報の記入インタフェースは、上記複数の手形情報を記入する入力ボックスなどを提供することにより、ユーザが確認して提出した後に各入力ボックスからユーザの入力した情報を取得し、さらに電子手形管理システムへ送信する。
【0021】
本発明の実施例において、電子手形取引の安全性を確保するために、取引実名制を採用でき、いずれかのユーザが該電子手形管理システムに登録される場合に該ユーザの身分情報を提供でき、例えば、個人ユーザは自分の身分証番号を提供でき、企業ユーザは自分の企業コードを提供できる。ユーザは電子手形管理システムの提供する登録インタフェースに登録情報を記入して、電子手形管理システムに登録要求を提出できる。図４に示すとおり、本発明の実施例は、企業フルネーム入力ボックス、組織機構コード入力ボックス、銀行アカウント番号入力ボックス、口座開設銀行名入力ボックス、企業連絡者入力ボックス、企業電話入力ボックス及び連絡先入力ボックスが表示された登録インタフェースを提供し、ユーザが各入力ボックスに入力した情報に基づいて、「企業フルネームがサプライヤＢであり、組織機構コードが０５２６６３４－７であり、企業連絡者が王五であり、連絡先電話が１８８８８８３３３７７であり、連絡先が天津市Ａ区Ｂ路である」などのユーザの身分情報、「銀行アカウント番号が６２１１１１１１１８８８８２３３３３であり、口座開設銀行名が建設銀行である」などの銀行アカウント情報などを取得できる。図５に示すとおり、本発明の実施例は、ユーザ登録のフローチャートを提供する。電子手形管理システムはユーザの登録要求を受信すると、公安機関などに行って登録要求に携帯されている身分情報が真であるか否かを検証でき、真でなければ、該ユーザの登録を拒否し、真であれば、該ユーザの登録を許可し、該ユーザのために１対の鍵を生成し、該１対の鍵の秘密鍵をユーザに返信し、公開鍵をユーザのアイデンティティを検証するために電子手形管理システムによって記憶する。
【0022】
実際のシーンにおいて、該第１のユーザからの手形発行要求をユーザが電子手形管理システムの提供したクライアント端末又はウェブページでトリガして生成して、電子手形管理システムのゲートウェイへ送信することにより、該ゲートウェイは第１のユーザからの手形発行要求を受信できる。ゲートウェイはチェック及び隔離の役割を果たすことができるため、情報の安全性を向上させることができる。
【0023】
２０２において、最初の手形情報に基づいて、第１のユーザに対応する第１の手形アカウントを生成して、第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶する。
【0024】
該ステップにおいて、第１の手形アカウントは第１のユーザのために発行した電子手形を識別するために用いられ、それは、例えばハッシュ値などの、該電子手形を一意に識別するための特徴値であってもよく、該第１の手形アカウントのアカウント情報は該電子手形を説明するために用いられるが、手形保有者情報、資産情報、振出日、満期日、アカウント状態、取引結果などの情報に限定されない。手形保有者情報、資産情報、振出日、満期日は直接的に最初の手形情報に基づいて取得でき、取引結果は、受け取りサインの拒否メッセージのような、後続の取引過程において追加されるものであってもよく、アカウント状態は、正常保有状態として設定できる。説明すべきこととして、電子手形管理システムは、手形取引の取引フローに基づいて、アカウントテーブルにおける第１の手形アカウントのアカウント情報におけるアカウント状態を変更でき、該アカウント状態は、譲渡済み状態、割引済み状態、換金済み状態及び正常保有状態などを含む。
【0025】
実際に、該商業手形の真偽を確保するために、ステップ２０１の後に、電子手形管理システムは、最初の手形情報における手形識別子に基づいて、手形識別子に対応する商業手形情報を照会でき、商業手形情報が最初の手形情報と一致すれば、本ステップ２０２を実行する。該手形識別子は一般的に手形番号である。照会時に、電子手形管理システムは、ＥＣＤＳ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｉａｌ Ｄｒａｆｔ Ｓｙｓｔｅｍ、電子商業手形システム）のような銀行システムに該手形識別子に対応する商業手形情報を照会でき、商業手形情報を成功に照会して、該商業手形情報が第１のユーザにより記入された最初の手形情報と一致すれば、ステップ２０２を実行でき、そうでなければ、第１のユーザからの手形発行要求を拒否できる。
【0026】
説明すべきこととして、本発明の実施例は、第１のユーザの商業手形に基づいて、該商業手形に対応する電子手形を発行し、発行時に様々な方式を採用でき、例えば、該商業手形に一致する電子手形を直接的に発行してもよく、ユーザにより商業手形を電子手形管理システムへ譲渡するか又は質入れ、電子手形管理システムを振出人とし、該商業手形と対等である電子手形を発行してもよい。
【0027】
実際のシーンにおいて、手形アカウントの生成過程は、手形管理システムにおけるサーバによりアカウントテーブル内で完了でき、それにより手形アカウントによりユーザの電子手形を管理する。
【0028】
２０３において、手形発行要求、第１の手形アカウント、及び電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、第１のユーザの手形発行イベントを記録するための第２のブロックを生成する。
【0029】
該ステップにおいて、電子手形管理システムはブロックチェーンから第１のブロックを取得し、次に第１のブロックのブロックヘッダにおける全ての情報を取得して、該第１のブロックのブロックヘッダにおける全ての情報に基づいて、第１のブロックのブロックヘッダ特徴値を取得して、第２のブロックのブロック本体内に記憶される手形発行要求のイベント情報を取得し、その後該手形発行要求のイベント情報及び第１の手形アカウントに対して特徴値計算を行い、第２のブロックのブロック本体特徴値を取得し、さらに、第１のブロックのブロックヘッダ特徴値、第２のブロックのブロック本体特徴値（さらにバージョン番号、難度値及びタイムスタンプを含むことができる）を第２のブロックのブロックヘッダに記憶できる。本発明の実施例はさらに手形発行要求のイベント情報及び第１の手形アカウントを第２のブロックのブロック本体に記憶し、それにより第２のブロックを生成する。このような処理方式を採用することにより、第２のブロックと第１のブロックとは第１のブロックのブロックヘッダ特徴値により関連し、したがってブロックチェーン内のブロックを直列接続するという目的を達成して、ブロックにおける任意の情報の改竄は、いずれもブロックのブロックヘッダに記憶された直前のブロックのブロックヘッダ特徴値をトレースすることにより検出でき、それにより取引情報の安全性を保証する。
【0030】
イベント情報は、イベントタイプ（例えば、手形発行要求イベント及び取引要求イベント）及び今回のイベントに関する資産情報を含むことができ、後続の取引過程におけるイベント情報はそれと同様である。
【0031】
説明すべきこととして、後続に取引情報から証拠を取得することを容易にし、悪意のあるユーザが取引情報を否認するか又は改竄することを防止するために、手形取引過程において対話されるメッセージには、メッセージ送信ユーザがメッセージに対して署名した署名情報をさらに携帯してもよい。ユーザが署名する時に使用する秘密鍵は電子手形管理システムにより発行され、各ユーザはいずれも一意の１対の鍵に対応し、該１対の鍵のうちの公開鍵は電子手形管理システムにより記憶され、それにより電子手形管理システムがユーザのアイデンティティを検証できる。該ステップにおいて、商業手形を電子手形管理システムに質入れるか又は譲渡する過程は１回の取引過程としてもよいので、手形発行要求は該第１のユーザの署名情報を携帯してもよい。第２のブロックを生成する場合、電子手形管理システムは手形発行要求のイベント情報、最初の手形情報、第１の手形アカウント及び該署名情報に対しても特徴値計算を行い、ブロック本体特徴値を取得し、さらに該ブロック本体特徴値、第１のブロックのブロックヘッダ特徴値などの情報を第２のブロックのブロックヘッダに記憶でき、電子手形システムはさらに手形発行要求のイベント情報、最初の手形情報、第１の手形アカウント及び該署名情報をいずれも第２のブロックのブロック本体に記憶できる。以下の手形取引過程において対話されるメッセージには同様に、送信ユーザの該メッセージの署名情報を携帯してもよい。
【0032】
実際のシーンにおいて、ブロックの生成過程は手形管理システムにおけるサーバによりブロックチェーンで完了でき、それにより今回の手形発行イベントを記録する。
【0033】
２０４において、第１の手形アカウントを携帯する発行成功メッセージを第１のユーザへ送信する。
【0034】
実際のシーンにおいて、該ステップは、電子手形管理システムにおけるサーバにより発行成功メッセージをゲートウェイへ送信し、さらにゲートウェイにより発行成功メッセージを第１のユーザへ送信することであってもよく、それにより第１のユーザは発行成功メッセージを受信すると、発行成功メッセージに携帯される手形アカウントにより対応してアカウント情報を閲覧できる。
【0035】
上記発行過程に基づいて、図６に示すとおり、本発明の実施例は手形発行のフローチャートを提供する。該手形発行フローにおいて、ユーザが電子手形管理システムに入力した最初の手形情報を取得して、ステップ２０２の商業手形情報を照会する過程により、該最初の手形情報を監査でき、監査に合格すれば、今回の発行イベントをブロックに書き込み、それにより発行過程を完了でき、監査に合格しなければ、発行が失敗したと決定し、ユーザに発行過程を再起動するように通知できる。
【0036】
上記内容は電子手形の発行過程であり、手形取引過程において、さらに手形譲渡、手形割引などの過程に関連し、以下に手形取引過程を説明する。
【0037】
２０５において、前記第１のユーザの手形取引要求を受信した場合、手形取引要求が全額手形取引要求であれば、第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行う。
【0038】
該手形取引要求とは、ユーザが保有する電子手形に基づいて他のユーザと取引を行う要求をいう。例えば、該手形取引要求は手形譲渡要求又は手形割引要求である。該手形取引要求はさらに取引を要求する取引資産情報と第１のユーザの該手形取引要求の署名情報を携帯でき、該取引資産情報は第１のユーザが今回の取引において取引しようとする資産金額を指示するために用いられ、該署名情報は、後続に取引情報から証拠を取得する時に第１のユーザのアイデンティティを検証するため、電子手形管理システムにより今回の取引が成功した場合にブロックチェーンに記憶されてもよい。第２のユーザとは電子手形管理システム内の第１のユーザ以外のあるユーザをいい、該第２のユーザは、第１のユーザに基づいて決定でき、例えば、第１のユーザが手形取引要求を開始する時に記入した第２のユーザのユーザ識別子に基づいて決定できる。
【0039】
該ステップにおいて、電子手形管理システムは該手形取引要求を受信すると、手形取引要求に携帯される第１の手形アカウントと手形取引要求に携帯される取引資産情報により、手形取引要求のタイプを決定できる。例えば、手形取引要求のタイプは以下の方法を用いて決定できる。電子手形管理システムは手形取引要求に携帯される第１の手形アカウントに基づいて、第１の手形アカウントに対応する資産情報を照会して、該資産情報に対応する資産金額を手形取引要求に携帯される取引資産情報に対応する取引資産金額と比較でき、両者が等しければ、手形取引要求のタイプを全額手形取引要求として決定し、さらに第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うことができる。
【0040】
手形取引要求のタイプを決定すると、電子手形管理システムは手形取引過程を行うことができる。該手形取引過程は具体的に、電子手形管理システムが、第１の手形アカウントの受け取りのサインを行うように指示するための第１の受け取りサインの要求メッセージを第２のユーザへ送信し、第２のユーザの第１の受け取りサインの確認メッセージを受信した場合、手形取引が成功したと決定でき、第２のユーザの第１の受け取りサインの拒否メッセージを受信した場合、手形取引が失敗したと決定できることである。
【0041】
第１の受け取りサインの要求メッセージにさらに第１の手形アカウントを携帯してもよい。第１の受け取りサインの要求に携帯される第１の手形アカウントに基づいて、第２のユーザは該第１の手形アカウントにより第１の手形アカウントのアカウント情報などを閲覧でき、それにより受け取りサインされる第１の手形アカウントを照合できる。該第１の受け取りサインの確認メッセージは第２のユーザの第１の受け取りサインの確認メッセージの署名情報を携帯でき、該署名情報は、後続に取引情報から証拠を取得する時に第２のユーザのアイデンティティを検証するため、電子手形管理システムにより今回の取引が成功した場合にブロックチェーンに記憶されてもよい。上記具体的な過程において、第２のユーザは第１の受け取りサインの要求を受信すると、受け取りサインするか否かを自ら選択でき、受け取りサインすることを決定すれば、第１の受け取りサインの確認メッセージを電子手形管理システムへ送信できる。上記手形取引フローは手形譲渡フローに応用でき、手形取引要求が手形割引要求である場合、第２のユーザはさらに受け取りサインする前又は後の任意の時刻にオフラインで第１のユーザへ振り込むことにより、割引フローを完了できる。
【0042】
説明すべきこととして、取引が成功した場合に第２のユーザが受け取りサインする過程を容易にするために、電子手形管理システムは手形取引要求を受信した後、アカウントテーブルにおいて第２のユーザのために対応する第２の手形アカウントを生成でき、該第２の手形アカウントは第２のユーザが受け取りサインする電子手形を識別するために用いられ、この時、該第２の手形アカウントのアカウント情報における手形保有者情報は第２のユーザのユーザ識別子であってもよく、アカウント情報における他の情報は一時的に設定されなくてもよいか、又はデフォルト値に設定されてもよい。
【0043】
当然のことながら、今回の取引を合法的に行うために、電子手形管理システムは手形取引要求を受信した場合、手形取引要求に携帯される手形アカウントに基づいて、手形取引要求と手形アカウントとが一致するか否かをチェックし、一致すれば、今回の取引を継続し、一致しなければ、今回の取引を終了できる。
【0044】
以上のチェック過程において、電子手形管理システムは手形アカウントのアカウント情報のうちの少なくとも１つの情報に基づいてチェックできる。例えば、手形アカウントのアカウント情報における資産情報に基づいて、手形取引要求に携帯される取引資産情報と該資産情報とが一致するか否かをチェックできる。例えば、取引資産情報の資産金額が該資産情報の資産金額以下であれば、該手形取引要求が合理的であることを説明し、手形取引要求が手形アカウントに一致したことを決定し、そうでなければ、両者が一致しないことを決定する。また例えば、手形アカウントのアカウント情報における満期日に基づいて、手形取引要求の要求時間と該満期日とが一致するか否かをチェックできる。例えば、該手形取引要求の要求時間が満期日を過ぎなければ、該手形取引要求が合理的であることを説明し、手形取引要求が手形アカウントに一致したことを決定でき、そうでなければ、両者が一致しないことを決定できる。また、電子手形管理システムはさらに手形アカウントのアカウント情報におけるアカウント状態に基づいてチェックでき、アカウント状態が正常保有状態である場合、手形取引要求が手形アカウントに一致したことを決定でき、アカウント状態が正常保有状態以外のアカウント状態である場合に、両者が一致しないことを決定できる。当然のことながら、今回の取引の合理性をさらに向上させるために、上記情報が全て手形取引要求と一致する場合にのみ、手形取引要求が手形アカウントに対応したことを決定し、そうでない場合、手形取引要求が該手形アカウントと一致しないことを決定してもよい。
【0045】
手形取引要求が手形割引要求である場合に、資産の流通効率を向上させ、かつ第１のユーザの利益を最大限に保証するために、電子手形管理システムは取引を行うステップの前に第１のユーザのために手形入札を開始してもよい。手形入札過程は、手形取引要求が手形割引要求であることを決定した場合、電子手形管理システムが該電子手形管理システムにおける各ユーザへ第１の手形アカウントに対応する手形入札メッセージを送信して、入札フィードバック情報に基づいて第１の手形アカウントに対して入札が最も高いユーザを第２のユーザとすることである。
【0046】
手形入札の解決手段において、電子手形管理システムは手形割引要求に携帯される第１の手形アカウントに基づいて、第１の手形アカウントを携帯する手形入札メッセージを生成でき、該手形入札メッセージは、第１のユーザのユーザ識別子、第１の手形アカウントのアカウント情報における資産情報及び満期日を含むことができる。さらに、電子手形管理システムはプッシュなどの方式で手形入札メッセージを各ユーザへ送信できる。電子手形管理システムは今回の手形入札過程において各ユーザの該手形入札メッセージに対するフィードバック情報を取得でき、該フィードバック情報はユーザが割引を承諾した金額情報を少なくとも含むことにより、電子手形管理システムはそのうちの割引を承諾した金額の最も高いユーザを第２のユーザとできる。当然のことながら、手形入札過程において入札時間を設定すべきであり、該入札時間は、第１のユーザ又は電子手形管理システムによって設定されてもよいが、満期日を過ぎることができない。
【0047】
実際のシーンにおいて、ユーザはクライアント端末を介して該手形取引要求を電子手形管理システムにおけるゲートウェイへ送信し、ゲートウェイを介して該手形取引要求を手形管理システムにおけるサーバへ送信できることにより、サーバは該手形取引要求に基づいてユーザに取引サービスを提供する。当然のことながら、手形入札過程において、ゲートウェイにより手形入札を開始して、第２のユーザを決定し、さらに第２のユーザのユーザ識別子及び第１のユーザの手形取引要求をサーバへ送信してもよい。
【0048】
２０６において、手形取引が成功した場合、アカウントテーブルにおける手形アカウントを更新して、ブロックチェーンに、第１のユーザの手形取引を記録するためのブロックと、第２のユーザの手形取引を記録するためのブロックとを生成する。
【0049】
本発明の実施例において、取引過程を明確に記録するために、電子手形管理システムは手形取引が成功した場合、アカウントテーブルにおける取引双方の手形アカウントを更新できる。また毎回の取引を明確に記録し、悪意のあるユーザが取引を否認するか又は改竄することを回避するために、電子手形管理システムはさらに手形取引を記録するためのブロックを生成できる。本発明の実施例は、手形アカウントの更新及びブロックの生成の具体的な過程を限定しない。例えば、手形取引が成功した場合、電子手形管理システムはアカウントテーブルにおける第１の手形アカウントと第２のユーザの第２の手形アカウントとを更新して、ブロックチェーンに第３のブロックと第４のブロックとを生成できる。第３のブロックは第１のユーザの今回の手形取引イベントを記録するために用いられ、第４のブロックは第２のユーザの今回の手形の受け取りサインのイベントを記録するために用いられる。
【0050】
手形アカウントを更新する場合、手形取引要求が手形譲渡要求であることを例とし、電子手形管理システムは第１の手形アカウントのアカウント情報の手形状態を譲渡済み状態に変更でき、それにより該第１の手形アカウントにより識別された電子手形が既に譲渡されたことを示して、既に生成された第２の手形アカウントのアカウント情報における資産情報を元の第１の手形アカウントに対応する資産情報に設定し（第２の手形アカウントがまだ生成されなければ、この時に生成してもよい）、第２の手形アカウントのアカウント情報におけるアカウント状態を正常保有状態とする。
【0051】
該ブロックの生成過程は第２のブロックの生成過程と同様であり、該第３のブロックのブロック本体に手形取引要求のイベント情報、第１の手形アカウント、第１のユーザの手形取引要求の署名情報を記憶でき、該第３のブロックのブロックヘッダに直前のブロックのブロックヘッダ特徴値及び第３のブロックのブロック本体特徴値などを記憶でき、該第４のブロックのブロック本体に第１の受け取りサインの確認メッセージのイベント情報、第２の手形アカウント、第２のユーザの第１の受け取りサインの確認メッセージの署名情報を記憶でき、第４のブロックのブロックヘッダに直前のブロックのブロックヘッダ特徴値及び該第４のブロックのブロック本体特徴値を記憶できる。
【0052】
該ステップ２０６において関連する手形アカウントの更新過程及びブロックの生成過程は、いずれも電子手形管理システムにおけるサーバにより完了できる。
【0053】
２０７において、第２のユーザへ取引成功メッセージを送信する。
【0054】
上記いずれかの方式に基づいて手形取引が成功した後、電子手形管理システムは第２のユーザへ対応する取引成功メッセージを送信でき、該取引成功メッセージは取引後の第２のユーザに対応する第２の手形アカウント、又は第２のユーザに対応する第４の手形アカウントを携帯できることにより、第２のユーザは既に受け取りサインされた手形アカウントを閲覧できる。当然のことながら、電子手形管理システムはさらに第１のユーザへ対応する取引成功メッセージを送信でき、該取引成功メッセージは取引後の第１の手形アカウント、又は第１の手形アカウント及び第３の手形アカウントを携帯できることにより、第１の手形アカウントは既に取引された第１の手形アカウント、又は残りの資産を記憶した第３の手形アカウントを閲覧する。
【0055】
実際のシーンにおいて、電子手形管理システムにおけるサーバにより該取引成功メッセージをゲートウェイへ送信し、さらにゲートウェイにより該取引成功メッセージをユーザの所在するクライアント端末へ送信できる。
【0056】
上記取引過程に基づいて、手形取引要求が手形譲渡要求であることを例とすれば、図７に示すとおり、本発明の実施例は手形譲渡のフローチャートを提供する。該譲渡フローにおいて、手形管理システムは第１のユーザの手形譲渡要求を受信する場合、該第１のユーザの手形譲渡要求をチェックし、検査チェックに合格すれば、第２のユーザの第２の手形アカウントを生成して、手形受け取りサインの要求を第２のユーザへ送信し、第２のユーザが受け取りサインすることに同意すれば、手形管理システムは第１のユーザと第２のユーザの手形アカウントをそれぞれ更新して、今回の取引情報を記録するブロックを生成し、第２のユーザが受け取りサインすることを拒否すれば、手形管理システムは受け取りサインの拒否メッセージを第１の手形アカウントへと更新する。
【0057】
上記取引過程は手形取引要求が手形割引要求であることを例とすれば、図８に示すとおり、本発明の実施例は手形割引のフローチャートを提供する。該割引フローにおいて、手形管理システムは第１のユーザの手形割引要求を受信した場合、手形入札を開始し、第２のユーザを決定した後、第２のユーザをチェックし、チェックに合格すれば、第２のユーザのために第２の手形アカウントを生成して、手形受け取りサインの要求を第２のユーザへ送信し、第２のユーザが受け取りサインすることに同意すれば、手形管理システムは第１のユーザと第２のユーザの手形アカウントをそれぞれ更新して、今回の取引情報を記録するためのブロックを生成し、第２のユーザが受け取りサインすることを拒否すれば、手形管理システムは受け取りサインの拒否メッセージを第１の手形アカウントへと更新する。
【0058】
実際に、取引方式を豊富にし、資産の流通効率を向上させるために、電子手形管理システムはユーザがその電子手形に対応する全ての資産を取引することをサポートするとともに、ユーザが該電子手形の一部の資産を取引することをサポートする（例えば、あるユーザの保有する電子手形に対応する資産金額が大きい場合、他のユーザと一部の資産を取引できることにより、より多くのユーザは資産能力範囲内で該ユーザと取引を行うことができる）。
【0059】
したがって、以上のステップ２０５－２０７は本発明の実施例の全額手形取引を行う場合の関連ステップであり、上記全額手形取引要求の場合の他に、電子手形管理システムが第１のユーザの手形取引要求を受信した場合、手形取引要求が一部手形取引要求であれば、一部手形取引要求に携帯される取引資産情報に基づいて、アカウントテーブルにおいて第１のユーザに対応する第３の手形アカウントを生成し、さらに一部の第１の手形アカウントを受け取りサインするように指示するための第２の受け取りサインの要求メッセージを第２のユーザへ送信するという可能な場合がある。
【0060】
手形取引要求のタイプを決定する場合に、さらに手形取引要求に携帯される第１の手形アカウントと手形取引要求に携帯される取引資産情報とに基づいて決定できる。例えば、資産情報に対応する資産金額が取引資産情報に対応する取引資産金額より大きければ該手形取引要求が一部手形取引要求であることを決定できるという方法で決定でき、取引成功時に取引双方の受け取りサインの過程を容易にするために、電子手形管理システムはアカウントテーブルにおいて第１のユーザに対応する第３の手形アカウントを生成でき、この時に、該第３の手形アカウントのアカウント情報における手形保有者情報は第１のユーザのユーザ識別子であってもよく、その他の情報は一時的に設定されなくてもよい。その後、電子手形管理システムは第１の手形アカウント及び取引資産情報を携帯する第２の受け取りサインの要求メッセージを第２のユーザへ送信できることにより、第２のユーザは受け取りサイン対象の一部の第１の手形アカウントを照合する。
【0061】
手形取引要求が一部手形取引要求である場合に、電子手形管理システムは、電子手形管理システムが第２のユーザの第２の受け取りサインの確認メッセージを受信した場合にアカウントテーブルにおける第１の手形アカウント、第３の手形アカウント及び第２のユーザの第４の手形アカウントを更新して、ブロックチェーンに、第１のユーザの今回の手形取引イベントを記録するための第６のブロックと、第２のユーザの今回の手形の受け取りサインのイベントを記録するための第７のブロックとを生成するという方式を用いて手形アカウントを更新して、ブロックを生成できる。
【0062】
第２の受け取りサインの確認メッセージは第２のユーザの該第２の受け取りサインの確認メッセージの署名情報を送信でき、該署名情報は、後続に取引情報から証拠を取得する時に第２のユーザのアイデンティティを検証するため、手形取引システムにより今回の取引が成功した場合にブロックチェーンに記憶できる。
【0063】
第１のユーザの一部手形取引要求に携帯される取引資産情報が８０であり、第１の手形アカウントの資産情報が１００であることを例とし、電子手形管理システムは第２のユーザの第２の受け取りサインの確認メッセージを受信した場合、該第２のユーザが８０の資産を受け取りサインすることを確認したと決定し、したがって、電子手形管理システムは第１の手形アカウントの資産情報を０に変更し、アカウント状態を譲渡済み状態に変更し、第３の手形アカウントの資産情報を２０に更新し、アカウント状態を正常保有状態に更新し、第４の手形アカウント（一部手形取引要求を受信した場合に第２のユーザのために生成して、設定できる）の資産情報を８０に更新し、アカウント状態を正常保有状態に更新できる。
【0064】
ブロックの生成過程において、第６のブロックのブロック本体に一部手形取引要求のイベント情報、第１の手形アカウント及び第３の手形アカウント、第１のユーザの一部手形取引要求の署名情報を記憶でき、第６のブロックのブロックヘッダに直前のブロックのブロックヘッダ特徴値及び該第６のブロックのブロック本体特徴値を記憶でき、第７のブロックのブロック本体に第２の受け取りサインの確認メッセージのイベント情報、第４の手形アカウント、第２のユーザの第２の受け取りサインの確認メッセージの署名情報を記憶でき、第７のブロックのブロックヘッダに直前のブロックのブロックヘッダ特徴値及び該第７のブロックのブロック本体特徴値を記憶できる。
【0065】
当然のことながら、第２のユーザは一部の第１の手形アカウントを受け取りサインすることを拒否する可能性があり、該場合に、本発明の実施例は電子手形管理システムの処理方式を具体的に限定しない。例えば、電子手形管理システムは第２のユーザの第２の受け取りサインの拒否メッセージを受信した場合、アカウントテーブルから第３の手形アカウントを削除する。例えば、取引が失敗するため、電子手形管理システムは元の第１の手形アカウントを保持する。当然のことながら、第４の手形アカウントを生成した場合、電子手形管理システムはアカウントテーブルから該第４の手形アカウントを削除してもよい。
【0066】
上記手形分割過程に基づいて、図９に示すとおり、本発明の実施例は手形分割のフローチャートを提供する。該分割フローにおいて、開始者の手形アカウントがＡであり、開始者の残りの手形アカウントがＢであり、領収者の手形アカウントがＣであることを例として説明し、電子手形管理システムは該手形取引要求が全額手形取引要求であることを決定する場合、Ａにおける全ての資産金額をＣに振り込むことができ、電子手形管理システムは該手形取引要求が一部手形取引要求であることを決定する場合、Ｂを生成して、領収者ユーザへ手形受け取りサインの要求を送信でき、領収者ユーザが受け取りサインすることに同意すれば、Ａにおいて取引資産情報と対等である資産金額をＣに振り込み、Ａにおける取引後の残りの資産金額をＢに振り込み、領収者ユーザが受け取りサインすることを拒否すれば、Ａの資産金額を一定に保持すればよく、かつ領収者の受け取りサインの拒否メッセージをＡへと更新する。
【0067】
上記手形取引過程はいずれもユーザ間の対話に関連するのに対して、実際の手形取引過程はさらに電子手形管理システムにより第１のユーザのために換金過程を完了することに関連する。該手形換金フローとしては、電子手形管理システムは第１の手形アカウントが換金期限の満期になったことを検出した場合、第１のユーザへ手形換金要求を送信し、第１のユーザが換金を行うことを確認すれば、換金確認メッセージを返信し、第１のユーザの換金確認メッセージを受信した場合、第１のユーザのために第１の手形アカウントに対応する資産を換金し、換金過程が完了する場合、アカウントテーブルにおける第１の手形アカウントを更新して、換金確認メッセージ及び直前のブロックのブロックヘッダ特徴値に基づいて、第５のブロックを生成し、さらに第１のユーザへ換金成功メッセージを送信する。
【0068】
該換金確認メッセージは第１のユーザの該換金確認メッセージの署名情報を送信でき、該署名情報は、後続に取引情報から証拠を取得する時に第１のユーザのアイデンティティを検証するため、手形取引システムにより今回の換金が成功した場合にブロックチェーンに記憶できる。
【0069】
図１０Ａに示すとおり、本発明の実施例は手形換金のフローチャートを提供し、換金過程において、電子手形管理システムは各手形アカウントの満期日を定時に検出し、満期日に基づいて現在日付が換金期限（満期日の当日又は満期日の１０日前には限定されず）に一致するか否かを決定でき、一致すれば、第１の手形アカウントが換金期限の満期になったことを決定し、電子手形管理システムは第１の手形アカウントを携帯する手形換金要求を第１のユーザへ送信できる。第１のユーザは手形換金要求を受信した場合、第１の手形アカウントのアカウント情報を照合して、電子手形管理システムへ換金確認メッセージを送信できる。電子手形管理システムは換金確認メッセージを受信した場合、直接的に第１のユーザのために現在の第１の手形アカウントに対応する資産金額を換金でき、換金が成功した後、第１のユーザが電子手形管理システムに譲渡した商業手形は電子手形管理システムによって所有される。又は、第１のユーザが商業手形を電子手形管理システムに質入れる場合、電子手形管理システムはまず第１の手形アカウントに基づいてブロックチェーンから最初の手形情報を照会して、最初の手形情報における手形識別子に基づいて商業手形の実際の売掛者を照会し、該実際の売掛者に資産を請求して、請求された資産を第１のユーザに換金する。換金が成功した後、電子手形管理システムはアカウントテーブルにおいて第１の手形アカウントのアカウント情報における手形状態を換金済み状態に変更して、第５のブロックを生成でき、該第５のブロックのブロック本体に換金確認メッセージのイベント情報、第１の手形アカウント、第１のユーザの換金確認メッセージの署名情報を記憶でき、該第５のブロックのブロックヘッダに直前のブロックのブロックヘッダ特徴値及び該第５のブロックのブロック本体特徴値を記憶できる。
【0070】
説明すべきこととして、換金過程の起動時に、システムエラーを回避するために、電子手形管理システムはチェック過程を行ってもよく、例えば、電子手形管理システムは第１の手形アカウントが換金期限の満期になったことを検出した場合、第１の手形アカウントが換金条件を満たすか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了する。換金条件は、第１の手形アカウントのアカウント情報におけるアカウント状態が正常保有状態であり、資産情報が０でないか又は満期日が現在日付より早くないことを含むことができるがそれらに限定されない。
【0071】
また、さらに説明すべきこととして、電子手形管理システムが取引を処理する過程において、いずれもいずれかのユーザから受け取りサイン対象の手形アカウントの受け取りサインの拒否メッセージ又は換金対象の手形アカウントの換金拒否メッセージを受信することがあり、上記のユーザが拒否した場合に、今回の取引が失敗したイベントを明確に記録するために、電子手形管理システムは該受け取りサイン対象の手形アカウント又は換金対象の手形アカウントについて記録することもでき、すなわち、電子手形管理システムはいずれかのユーザの受け取りサイン対象の手形アカウントに対する受け取りサインの拒否メッセージを受信した場合、ユーザの受け取りサインの拒否メッセージをアカウントテーブルにおける受け取りサイン対象の手形アカウントへと更新すること、或いは、電子手形管理システムはいずれかのユーザの換金対象の手形アカウントに対する換金拒否メッセージを受信した場合、ユーザの換金拒否メッセージをアカウントテーブルにおける前記換金対象の手形アカウントへと更新することである。該受け取りサインの拒否メッセージは手形アカウントのアカウント情報における取引結果に記憶できる。
【0072】
実際のシーンにおいて、電子手形管理システムにおけるゲートウェイにより換金期限の検出を行い、かつ換金過程をトリガし、換金開始メッセージをサーバへ送信でき、サーバは該換金開始メッセージを受信した場合、チェック過程を行うことができ、チェックに合格すれば、ゲートウェイへ手形換金要求を送信し、ゲートウェイにより手形換金要求を第１のユーザの所在するクライアント端末へ送信し、該クライアント端末は第１のユーザの換金確認メッセージ又は換金拒否メッセージをゲートウェイへ送信し、ゲートウェイにより第１のユーザの送信したメッセージをサーバへ送信できることにより、サーバは該メッセージに基づいて換金過程を完了する。
【0073】
本発明の実施例は、第１のユーザの最初の手形情報に基づいて、アカウントテーブルにおいて第１のユーザに対応する第１の手形アカウントを生成でき、第１のユーザからの手形発行要求、第１の手形アカウント及びブロックチェーン内の第１のブロックのブロックヘッダ特徴値に基づいて、第２のブロックを生成でき、上記過程によりアカウントテーブルによりアカウント情報を管理できるだけではなく、ブロックチェーン内の前後ブロック間の関連関係に基づいて、ブロックにおけるいずれの情報が改竄される場合にも次のブロックにより検出でき、悪意のあるユーザが発行された電子手形を改竄するか又は否認することを回避し、それにより取引情報の安全性及び信頼性を保証する。
【0074】
本発明の実施例の手形流通過程を具現化するために、以下に図１０Ｂを例として手形取引フローを説明する。該取引フローにおいて、核心企業Ｈは一次サプライヤＮの１バッチの貨物を購入したが、まだ支払わない場合、銀行手形システムにより商業手形を発行して、銀行手形システムにより一次サプライヤＮへ商業手形の受け取りサインの要求を送信でき、一次サプライヤＮは銀行ネットバンキングを介して受け取りサインし、それにより１枚の商業手形を得ることができる。
【0075】
さらに、一次サプライヤＮは、電子手形管理システムへ手形発行要求を送信し、電子手形管理システムにおけるゲートウェイは該手形発行要求を受信した場合、一次サプライヤＮの商業手形の保有者をゲートウェイに変更することを銀行手形システムに申請でき、一次サプライヤＮが商業手形をゲートウェイへ譲渡することに相当し、それに対応し、電子手形管理システムはそれのために電子手形を発行して、発行イベントをブロックチェーンに書き込み、発行が成功したことを決定する。その後に、一次サプライヤＮは電子手形管理システムにより該電子手形を譲渡する、割引する又は分割できる。かつ、電子手形管理システムのゲートウェイは該電子手形の換金期限を自動的に検出でき、換金期限に達すると、ゲートウェイは換金過程を自発的に開始でき、それにより一次サプライヤＮのために電子手形に対応する資産を換金する。
【0076】
実際には、上記取引過程はそれぞれ各ユーザの銀行側の記帳ノードとブロックチェーンプラットフォーム側の記帳ノードでの手形アカウントに基づいて行われ、図１０Ｃに示すように、商業手形の受け取りサイン、商業手形の質入れ、電子手形の譲渡などの過程は、いずれも取引双方としてのユーザの手形アカウントの間の対話に対応する。
【0077】
一方では、電子手形は一旦ブロックチェーンに登録されると、後続の流通段階は元の電子商業手形システムに依存しなくてもよいため、ユーザは、ネットバンキングを有しなくても電子手形システムで電子手形を譲渡するか又は割引でき、また取引時の資産金額は該ユーザの保有する任意の資産金額であってもよく、取引を行うユーザは企業ユーザ、個人ユーザ及び銀行ユーザなどに限定されないことなどにより、電子手形の取引過程において制約が少なく、したがって、非常に高い流通性を有する。他方では、手形分割過程に基づいて、手形は社会的な伝播の形式で取引され、電子手形は、核心企業Ｈ及び一次サプライヤＮから、一次サプライヤＮの商業パートナーである二次サプライヤＭに拡張でき、それにより任意の金額の手形の分割及び支払いを実現する。他方では、電子手形リソースを有する任意のノードはいずれも資産の流通を促進するもの（例えば銀行、核心企業、サプライヤなど及びＣ手形の取引を受け入れることができる手形取引機構）となってもよく、したがって取引過程全体において開放性が高く、資産の流通効率が向上する。他方では、ブロックチェーンの特徴を利用し、分散記憶を達成でき、かつ取引情報もマルチノードに記憶でき、したがって取引情報が改竄されるか又は否認されることを効果的に回避して、全過程をトレースできる。
【0078】
また、本発明の実施例は電子手形を自由に取引するプラットフォームをユーザに提供し、第１のユーザの手形取引要求を受信した場合、第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、双方の自由取引を行うことができ、取引が成功した場合、アカウントテーブルにおける手形アカウントを更新できるだけではなく、ブロックチェーンに、今回の取引を記録するためのブロックを生成し、さらに取引情報の安全性及び信頼性を保証できる。
【0079】
また、本発明の実施例は手形アカウントの更新及びブロックの生成の具体的な過程を提供し、第１のユーザと第２のユーザにそれぞれ対応する手形アカウントを更新することにより、取引双方の手形アカウントを合理的に管理できる。また、第１のユーザの今回の手形取引イベントを記録するための第３のブロックを生成できるだけではなく、第２のユーザの今回の手形の受け取りサインのイベントを記録するための第４のブロックを生成でき、したがって取引双方の今回の取引における各自の役割を合理的に記録して、電子手形の第１のユーザから第２のユーザへの取引過程を十分に具現化できる。
【0080】
また、手形取引方式を豊富にし、資産の流通効率を向上させるために、本発明の実施例は電子手形を分割する具体的な方法を提供し、具体的な分割過程としては、手形取引要求を受信した場合、手形取引要求のタイプを決定し、全額手形取引要求であれば、第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行い、一部手形取引要求であれば、一部手形取引要求に携帯される取引資産情報に基づいて、第１のユーザに対応する第３の手形アカウントを生成し、取引が成功した場合、元の第１の手形アカウントにおける取引資産を第２のユーザの第４の手形アカウントに振り込むのに対し、残りの資産を第３の手形アカウントに振り込むことができ、さらに取引情報をブロックチェーンに記憶でき、最初の電子手形が既に取引され、かつ２つの新たな電子手形に分割された過程を完全に記録するだけではなく、取引情報の安全性を保証する。
【0081】
また、本発明の実施例はユーザが一部の第１の手形アカウントにおける取引資産を受け取りサインすることを拒否した場合の電子手形管理システムの簡便な処理方法を提供し、該方法を用いると第３の手形アカウントを削除することにより、元の第１の手形アカウントのアカウント情報を保持できる。
【0082】
また、手形取引方式を豊富にし、資産の流通効率を向上させ、かつ手形保有ユーザの利益をできるだけ保証するために、手形取引要求が割引取引要求である場合、該ユーザのために電子手形管理システムの各ユーザへ手形入札メッセージを送信して、入札が最も高いユーザを第１のユーザと取引を行う第２のユーザとできる。
【0083】
また、本発明の実施例はさらに第１の手形アカウントが換金期限に達するか否かを知能的に検出でき、かつ第１の手形アカウントが換金期限に達した場合、自発的に第１のユーザのために資産を換金し、それにより第１のユーザのために電子手形について知能的で人に友好な管理を行う。
【0084】
また、後続に取引情報から証拠を取得することを容易にし、悪意のあるユーザが取引情報を否認するか又は改竄することを防止するために、手形取引過程において対話されるメッセージには、メッセージ送信ユーザがメッセージに対して署名した署名情報がさらに携帯されており、それにより証拠を取得する時にユーザの署名情報に基づいてユーザのアイデンティティを公正で効果的に検証できる。
【0085】
また、ユーザの提供する最初の手形情報の正確性を確保するために、本発明の実施例はさらに最初の手形情報における手形識別子に基づいて、対応する商業手形情報を照会でき、これら２つの情報が一致する場合にのみ、第１のユーザのために電子手形を発行する。
【0086】
また、ユーザが不当な取引要求を開始することを回避し、毎回の取引を合法的に行うことを確保するために、本発明の実施例はさらに手形取引要求を受信した場合に手形アカウントのアカウント情報と手形取引要求とが一致するか否かをチェックするか、又は、手形アカウントが換金期限の満期になったことを検出した場合にチェックできる。
【0087】
また、ユーザが手形アカウントを受け取りサインすること又は換金することを拒否しても、本発明の実施例は受け取りサインの拒否メッセージ又は換金拒否メッセージを対応する手形アカウントに記憶し、それにより今回の失敗した取引を明確に記録し、悪意のあるユーザが否認することを防止できる。
【0088】
図１１は本発明の実施例に係る電子手形管理装置のブロック図である。図１１に示すとおり、該装置は具体的に、
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信するための受信モジュール１１０１と、
最初の手形情報に基づいて、第１のユーザに対応する第１の手形アカウントを生成して、第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶するためのアカウント生成モジュール１１０２と、
手形発行要求、第１の手形アカウント、及び電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、第１のユーザの手形発行イベントを記録するための第２のブロックを生成するためのブロック生成モジュール１１０３と、
第１の手形アカウントを携帯する発行成功メッセージを第１のユーザへ送信するための送信モジュール１１０４とを含む。
最初の手形情報を携帯する第１のユーザからの手形発行要求を受信するための受信モジュール１１０１と、
最初の手形情報に基づいて、第１のユーザに対応する第１の手形アカウントを生成して、第１の手形アカウントのアカウント情報を電子手形管理システムにおけるアカウントテーブルに記憶するためのアカウント生成モジュール１１０２と、
手形発行要求、第１の手形アカウント、及び電子手形管理システムにおけるブロックチェーン内の、第２のブロックの直前のブロックである第１のブロックのブロックヘッダ特徴値に基づいて、第１のユーザの手形発行イベントを記録するための第２のブロックを生成するためのブロック生成モジュール１１０３と、
第１の手形アカウントを携帯する発行成功メッセージを第１のユーザへ送信するための送信モジュール１１０４とを含む。
【0089】
本発明の実施例は、第１のユーザの最初の手形情報に基づいて、アカウントテーブルにおいて第１のユーザに対応する第１の手形アカウントを生成するだけではなく、第１のユーザの手形発行要求、第１の手形アカウント及びブロックチェーン内の第１のブロックのブロックヘッダ特徴値に基づいて、第２のブロックを生成するため、アカウントテーブルによりアカウント情報を管理できるだけではなく、ブロックチェーン内の前後ブロック間の関連関係に基づいて、ブロックにおけるいずれの情報が改竄される場合にも次のブロックにより検出でき、悪意のあるユーザが発行された電子手形を改竄するか又は否認することを回避し、それにより取引情報の安全性及び信頼性を保証する。
【0090】
可能な実現方式において、図１１の装置の構成に基づいて、図１２に示すとおり、該装置はさらに、取引モジュール１１０５及びアカウント更新モジュール１１０６を含み、
取引モジュール１１０５は、第１の手形アカウントを携帯する第１のユーザの手形取引要求を受信した場合、第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うために用いられ、
アカウント更新モジュール１１０６は、手形取引が成功した場合、アカウントテーブルにおける手形アカウントを更新して、ブロックチェーンに、第１のユーザの手形取引を記録するためのブロックと、第２のユーザの手形取引を記録するためのブロックとを生成するために用いられ、
送信モジュール１１０４は、第２のユーザへ取引成功メッセージを送信するために用いられる。
取引モジュール１１０５は、第１の手形アカウントを携帯する第１のユーザの手形取引要求を受信した場合、第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うために用いられ、
アカウント更新モジュール１１０６は、手形取引が成功した場合、アカウントテーブルにおける手形アカウントを更新して、ブロックチェーンに、第１のユーザの手形取引を記録するためのブロックと、第２のユーザの手形取引を記録するためのブロックとを生成するために用いられ、
送信モジュール１１０４は、第２のユーザへ取引成功メッセージを送信するために用いられる。
【0091】
可能な実現方式において、送信モジュール１１０４は、第２のユーザに第１の手形アカウントを受け取りサインするように指示するための第１の受け取りサインの要求メッセージを第２のユーザへ送信するために用いられ、
取引モジュール１１０５は、第２のユーザの第１の受け取りサインの確認メッセージを受信した場合、手形取引が成功したと決定し、第２のユーザの第１の受け取りサインの拒否メッセージを受信した場合、手形取引が失敗したと決定するために用いられる。
取引モジュール１１０５は、第２のユーザの第１の受け取りサインの確認メッセージを受信した場合、手形取引が成功したと決定し、第２のユーザの第１の受け取りサインの拒否メッセージを受信した場合、手形取引が失敗したと決定するために用いられる。
【0092】
可能な実現方式において、アカウント更新モジュール１１０６は、手形取引が成功した場合、アカウントテーブルにおける第１の手形アカウントと第２のユーザの第２の手形アカウントとを更新するために用いられ、
ブロック生成モジュール１１０３は、ブロックチェーンに、第１のユーザの今回の手形取引イベントを記録するための第３のブロックと、第２のユーザの今回の手形の受け取りサインのイベントを記録するための第４のブロックとを生成するために用いられる。
ブロック生成モジュール１１０３は、ブロックチェーンに、第１のユーザの今回の手形取引イベントを記録するための第３のブロックと、第２のユーザの今回の手形の受け取りサインのイベントを記録するための第４のブロックとを生成するために用いられる。
【0093】
可能な実現方式において、取引モジュール１１０５は、第１のユーザの手形取引要求を受信した場合、手形取引要求が全額手形取引要求であれば、第１のユーザと第２のユーザとの間のメッセージ対話に基づいて、手形取引を行うために用いられる。
【0094】
可能な実現方式において、アカウント生成モジュール１１０２は、第１のユーザの手形取引要求を受信した場合、手形取引要求が一部手形取引要求であれば、一部手形取引要求に携帯される取引資産情報に基づいて、アカウントテーブルにおいて、第１のユーザに対応する第３の手形アカウントを生成するために用いられ、送信モジュール１１０４は、第２のユーザに一部の第１の手形アカウントの受け取りのサインを行うように指示するための第２の受け取りサインの要求メッセージを第２のユーザへ送信するために用いられ、アカウント更新モジュール１１０６は、第２のユーザの第２の受け取りサインの確認メッセージを受信した場合、アカウントテーブルにおける第１の手形アカウント、第３の手形アカウント及び第２のユーザの第４の手形アカウントを更新するために用いられ、ブロック生成モジュール１１０３は、ブロックチェーンに、第１のユーザの今回の手形取引イベントを記録するための第６のブロックと、第２のユーザの今回の手形の受け取りサインのイベントを記録するための第７のブロックとを生成するために用いられる。
【0095】
可能な実現方式において、アカウント更新モジュール１１０６はさらに、第２のユーザの第２の受け取りサインの拒否メッセージを受信した場合、アカウントテーブルから第３の手形アカウントを削除するために用いられる。
【0096】
可能な実現方式において、手形取引要求は手形譲渡要求又は手形割引要求である。
【0097】
可能な実現方式において、送信モジュール１１０４はさらに、手形取引要求が手形割引要求である場合、電子手形管理システムにおける各ユーザへ第１の手形アカウントに対応する手形入札メッセージを送信するために用いられ、取引モジュール１１０５はさらに、第１の手形アカウントに対して入札が最も高いユーザを第２のユーザとするために用いられる。
【0098】
可能な実現方式において、図１１の装置の構成に基づいて、図１３に示すとおり、該装置はさらに、換金モジュール１１０７を含み、該換金モジュール１１０７は、第１の手形アカウントが換金期限の満期になったことを検出した場合、第１のユーザへ手形換金要求を送信し、第１のユーザの換金確認メッセージを受信した場合、第１のユーザのために第１の手形アカウントに対応する資産を換金し、換金過程が成功した場合、アカウントテーブルにおいて第１の手形アカウントを更新して、換金確認メッセージと直前のブロックのブロックヘッダ特徴値とに基づいて、第５のブロックを生成し、第１のユーザへ換金成功メッセージを送信するために用いられる。
【0099】
可能な実現方式において、アカウント更新モジュール１１０６は、手形取引の取引フローに基づいて、アカウントテーブルにおける第１の手形アカウントのアカウント情報におけるアカウント状態を変更するために用いられ、アカウント状態は、譲渡済み状態、割引済み状態、換金済み状態及び正常保有状態を含む。
【0100】
可能な実現方式において、手形取引過程において対話されるメッセージには、メッセージ送信ユーザがメッセージに対して署名した署名情報がさらに携帯されている。
【0101】
可能な実現方式において、図１１の装置の構成に基づいて、図１４に示すとおり、該装置は、
最初の手形情報における手形識別子に基づいて、手形識別子に対応する商業手形情報を照会するための照会モジュール１１０８をさらに含み、
アカウント生成モジュール１１０２はさらに、商業手形情報が最初の手形情報と一致すれば、最初の手形情報に基づいて第１のユーザに対応する第１の手形アカウントを生成するステップを実行するために用いられる。
最初の手形情報における手形識別子に基づいて、手形識別子に対応する商業手形情報を照会するための照会モジュール１１０８をさらに含み、
アカウント生成モジュール１１０２はさらに、商業手形情報が最初の手形情報と一致すれば、最初の手形情報に基づいて第１のユーザに対応する第１の手形アカウントを生成するステップを実行するために用いられる。
【0102】
可能な実現方式において、図１１の装置の構成に基づいて、図１５に示すとおり、装置は、
手形取引要求を受信した場合、手形取引要求に携帯される手形アカウントに基づいて、手形取引要求と手形アカウントとが一致するか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了するか、或いは、
さらに第１の手形アカウントが換金期限の満期になったことを検出した場合、第１の手形アカウントが換金条件を満たすか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了するためのチェックモジュール１１０９をさらに含む。
手形取引要求を受信した場合、手形取引要求に携帯される手形アカウントに基づいて、手形取引要求と手形アカウントとが一致するか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了するか、或いは、
さらに第１の手形アカウントが換金期限の満期になったことを検出した場合、第１の手形アカウントが換金条件を満たすか否かをチェックし、そうであれば、今回の取引を継続し、そうでなければ、今回の取引を終了するためのチェックモジュール１１０９をさらに含む。
【0103】
可能な実現方式において、アカウント更新モジュール１１０６はさらに、いずれかのユーザから受け取りサイン対象の手形アカウントの受け取りサインの拒否メッセージを受信した場合、ユーザの受け取りサインの拒否メッセージをアカウントテーブルにおける受け取りサイン対象の手形アカウントへと更新するために用いられるか、或いは、
アカウント更新モジュール１１０６はさらに、いずれかのユーザから換金対象の手形アカウントの換金拒否メッセージを受信した場合、ユーザの換金拒否メッセージをアカウントテーブルにおける換金対象の手形アカウントへと更新するために用いられる。
アカウント更新モジュール１１０６はさらに、いずれかのユーザから換金対象の手形アカウントの換金拒否メッセージを受信した場合、ユーザの換金拒否メッセージをアカウントテーブルにおける換金対象の手形アカウントへと更新するために用いられる。
【0104】
上記全ての選択可能な技術的解決手段について、任意の組み合わせを用いて本発明の選択可能な実施例を形成でき、ここで説明を省略する。
【0105】
説明すべきこととして、上記実施例に係る電子手形管理装置は電子手形を管理する場合、上記各機能モジュールの区画のみを例に挙げて説明し、実際の応用において、必要に応じて上記機能を割り当てて異なる機能モジュールにより完了でき、すなわち装置の内部構造を異なる機能モジュールに区画することにより、以上に説明した全て又は一部の機能を完了する。また、上記実施例に係る電子手形管理装置と電子手形管理方法の実施例は同じ構想に属し、その具体的な実現過程は方法の実施例を参照し、ここで説明を省略する。
【0106】
図１６は本発明の実施例に係る電子手形管理装置１６００のブロック図である。例えば、装置１６００はサーバとして提供されてもよい。図１６に示すとおり、装置１６００は、処理アセンブリ１６２２を含み、１つ以上のプロセッサと、処理アセンブリ１６２２により実行可能なアプリケーションプログラムのような命令を記憶するための、メモリ１６３２により代表されるメモリリソースとをさらに含む。メモリ１６３２に記憶されたアプリケーションプログラムはそれぞれ１組の命令に対応する１つ以上のモジュールを含むことができる。また、処理アセンブリ１６２２は、上記実施例における電子手形管理システムが実行する方法を実行するように命令を実行するように構成される。
【0107】
装置１６００は、装置１６００の電源管理を実行するように構成される１つの電源アセンブリ１６２６と、装置１６００をネットワークに接続するように構成される１つの有線又は無線ネットワークインタフェース１６５０と、１つの入出力（Ｉ／Ｏ）インタフェース１６５８とをさらに含むことができる。装置１６００はメモリ１６３２に記憶されたオペレーティングシステム、例えばＷｉｎｄｏｗｓ ＳｅｒｖｅｒＴＭ、Ｍａｃ ＯＳ ＸＴＭ、ＵｎｉｘＴＭ、ＬｉｎｕｘＴＭ、ＦｒｅｅＢＳＤＴＭ又はそれらに類似するものに基づいて動作できる。
【0108】
例示的な実施例において、命令を含む非一時的なコンピュータ読み取り可能な記憶媒体、例えば命令を含むメモリをさらに提供し、上記命令は、サーバ内のプロセッサにより実行されて上記実施例における電子手形管理方法を完了できる。例えば、前記非一時的なコンピュータ読み取り可能な記憶媒体は、ＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ－ＲＯＭ、磁気テープ、フロッピーディスク、及び光データ記憶装置などであってもよい。
【0109】
本発明の実施例は、前記プロセッサによりロードされて実行されることにより上記実施例における電子手形管理方法を実現する少なくとも１つの命令、少なくとも１つのプログラム、コードセット又は命令セットが記憶されている記憶媒体をさらに提供する。
【0110】
上記本発明の実施例の番号は説明のためのものに過ぎず、実施例の優劣を表すものではない。
【0111】
当業者であれば理解できるように、上記実施例の全て又は一部のステップの実現はハードウェアにより完了してもよく、プログラムにより関連するハードウェアを命令することで完了してもよく、プログラムはコンピュータ読み取り可能な記憶媒体に記憶でき、上記で言及した記憶媒体はリードオンリーメモリ、磁気ディスク又は光ディスクなどであってよい。
【0112】
以上は本発明の実施例を限定するためのものではなく、本発明の実施例の精神と原則内で行われるいかなる変更、均等置換え、改善などは、いずれも本発明の実施例の保護範囲内に含まれるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10A】
【図10B】
【図10C】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】