【事件の表示】
　特願２０１７−　２９７３０「信号処理方法、および信号処理プログラム」拒絶査定不服審判事件〔、請求項の数（８）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　
　本願は，平成２９年２月２１日を出願日とする出願であって，同年５月９日付けで拒絶理由通知（同年同月１６日発送）がされ，同年同月３０日付けで意見書が提出されるとともに手続補正がされ，同年６月９日付けで最後の拒絶理由通知（同年同月１３日発送）がされ，同年９月１２日付けで意見書が提出されるとともに手続補正がされたが，同年１０月６日付けで前記平成２９年９月１２日付け手続補正を却下する旨の補正の却下の決定がなされるとともに拒絶査定（同年１０月１７日謄本送達，以下，「原査定」という。）がされ，これに対し，平成３０年１月１６日付けで拒絶査定不服審判の請求がされたものである。
　
　
第２　平成２９年１０月６日付けの補正の却下の決定及び原査定の概要
　
１．平成２９年１０月６日付けの補正の却下の決定の概要は以下のとおりである。
　
　平成２９年１０月６日付けの手続補正により補正された請求項１には，ブロックチェーンネットワークにおいて承認条件が満たされていることを確認する際に，ブロードキャストされた如何なる電子署名を用いるのかについて何ら特定されていないところ，当初明細書等には，ブロックチェーンネットワーク１３０のノード１３２が承認条件が満たされていることを確認する際に，電子署名ＥＳ２以外のブロードキャストされた電子署名（例えば電子署名ＥＳ１）を用いる点について記載も示唆も為されておらず，この点は当業者にとって当初明細書等の記載事項及び出願時の技術常識から明らかな事項でもないから，本件補正は，当初明細書等に記載した事項の範囲内においてしたものでない。
　
２．原査定（平成２９年１０月６日付け拒絶査定）の理由の概要は次のとおりである。
　
（１）理由１　特許法第３６条第６項第２号（明確性）について
　
　請求項１−８に記載された「受信した前記承認信号の承認に基づき，前記トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし，前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する」は，「することによって・・・する」という部分が日本語として曖昧であり，技術的範囲が不明確である。
　
　請求項１−８に記載された「トランザクション」は，送受信可能なデータであるのか，実行可能な処理であるのか不明であるから，技術的内容が不明確である。
　
（２）理由２　特許法第２９条第２項（進歩性）について
　
　本願請求項１−８に係る発明は，引用文献１に記載された発明において，引用文献２−３に記載された周知技術,及び，引用文献４−６に記載された周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
　本願請求項１−８に係る発明は，引用文献２に記載された発明において，引用文献４−６に記載された周知技術，及び，電子署名を付加して送信する周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
　本願請求項１−８に係る発明は，引用文献３に記載された発明において，引用文献４−６に記載された周知技術，及び，電子署名を付加して送信する周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
　本願請求項１−８に係る発明は，引用文献７に記載された発明において，引用文献４−６に記載された周知技術，及び，電子署名を付加して送信する周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
　本願請求項１−８に係る発明は，引用文献８に記載された発明において，引用文献４−６に記載された周知技術，及び，電子署名を付加して送信する周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
　本願請求項１−８に係る発明は，引用文献９に記載された発明において，引用文献４−６に記載された周知技術，及び，電子署名を付加して送信する周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
　本願請求項１−８に係る発明は，引用文献１０に記載された発明において，引用文献４−６に記載された周知技術，及び，電子署名を付加して送信する周知技術を採用することで，当業者が容易に為し得たことであるから，特許法第２９条第２項の規定により特許を受けることができない。
＜引用文献等一覧＞
１．米国特許出願公開第２０１５／０２０６１０６号明細書
２．特開２０１０−２３７７３１号公報
３．特開２００７−３１６９５９号公報
４．特開２０１６−１７０５３０号公報
５．特開２０１６−２０８３４７号公報
６．特許第６０４２０１１号公報
７．特開２００９−１６３４７２号公報
８．特開２００９−１６９９１４号公報
９．特開２００９−２３０２５７号公報
１０．特開２００９−３０１１８９号公報
　
第３　本願発明
　
　本願請求項１−８に係る発明（以下，それぞれ「本願発明１」−「本願発明８」という。）は，平成２９年５月３０日付けの手続補正で補正された特許請求の範囲の請求項１−８に記載された事項により特定される発明であり，以下のとおりの発明である。
　
「　　【請求項１】
　複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を前記複数のノードの少なくとも一つに送信する手順と，
　前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と，
　受信した前記承認信号の承認に基づき，前記トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし，前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順とを含む信号処理方法。
　　【請求項２】
　前記承認信号は前記ノードにおける電子署名の付加により生成される，請求項１に記載の信号処理方法。
　　【請求項３】
　前記承認信号を受信する手順において受信される前記承認信号が，前記複数のノードのうちの前記一定割合に満たない場合には，前記トランザクションを破棄する，請求項１に記載の信号処理方法。
　　【請求項４】
　前記承認信号は，前記トランザクション，および前記トランザクションから生成された電子署名を含み，
　前記承認は，受信した前記承認信号に含まれる前記電子署名の総数によって判断される，請求項１に記載の信号処理方法。
　　【請求項５】
　複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を，前記複数のノードの一つから前記複数のノードの他の少なくとも一つに送信する手順と，
　前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と，
　受信した前記承認信号の承認に基づき，前記トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし，前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順を前記複数のノードに実行させるように構成される信号処理プログラム。
　　【請求項６】
　電子署名を付加することにより前記承認信号を生成することを前記複数のノードに実行させるように構成される，請求項５に記載の信号処理プログラム。
　　【請求項７】
　前記承認信号を受信する手順において受信される前記承認信号が，前記複数のノードのうちの前記一定割合に満たない場合には，前記トランザクションを破棄する，請求項５に記載の信号処理プログラム。
　　【請求項８】
　前記承認は，受信した前記承認信号に含まれる前記電子署名の総数によって判断される，請求項６に記載の信号処理プログラム。」
　
　
第４　引用文献，引用発明等
　
１．引用文献１について
　原査定の拒絶理由に引用された，米国特許出願公開第２０１５／０２０６１０６号明細書（以下，「引用文献１」という。）には図面とともに次の事項が記載されている。（下線は当審により付与。以下同じ。）
　
ア．「［0007］　Towards these objects and other objects that are made obvious in light of the present disclosure, an 
invented method
module that creates and applies contract/credit certificates with verifiable and objective terms based on a trade request between two or more parties
further adapted to monitor crypto-digital instrument networks
（当審訳：「［0007］　現在開示されている観点でこれらの目的及び他の目的を明らかにするために，
発明に係る方法
モジュール
２つまたはそれ以上の当事者間の取引リクエストに基づく検証可能かつ客観的な条件を伴ったコントラクト／信用保証を，生成し用いるものである
さらにデジタル暗号化されたネットワーク手段を監視することに適用され
　
イ．「［0044］　
Counter-parties to a trade often wish to maintain confidentiality in their trading activity. Maintaining privacy typically requires additional middle men and adds additional counter-party risk all of which is solved and/or eliminated in accordance with the present invention
time effects
［0045］　Referring now generally to the Figures, and particularly to FIG. 1 and FIG. 2 , the invention disclosed herein is shown to utilize a method that separates the time of agreement and initial performance of a given trade, from the time of settlement, thereby allowing trading parties to overcome the above problems. At the same time, this method of trading allows parties to transact with the guarantee of settlement upon completion of all elements for that trade.」
（当審訳：「［0044］　
取引の相手当事者は，取引活動における機密性を維持することを望む場合が多い。プライバシーを維持することは，典型的には，追加の中間における人を必要とし，本発明に従って解決され，及び／または，取り除かれるような，全ての追加的な相手当事者によるリスクを加えることになる
時間的影響
［0045］　ここで全般的に図を，特に図１と２を参照すると，ここで開示されている発明は，所与の取引について，合意の時間及び最初の実績を，決済の時間から分離する方法を利用することが示され，それにより取引業者が，上記の問題を克服することを可能にする。同時に，この取引方法は，当事者が取引の全ての要素の完了に基づいて決済の保証とともに実行することを可能とする。」）
　
ウ．「［0058］　Referring now generally to the Figures, and particularly to FIG. 4 , FIG. 4 is a network diagram of an 
electronic communications network 400
comprising a first private ledger 402 , a second private ledger 404 , a public ledger system 406 , an exemplary first user device 408 , an exemplary second user device 410 , the Internet 411 , a transaction system 412 comprising a plurality of modules 412.A- 412.E, and a title registry server 414
The public ledger 406 is preferably a CFI network, and may be or comprise a plurality or multiplicity of nodes N.1-N.N. that each preferably maintain and dynamically update copies of a same public ledger, e.g., an accessible Blockchain BC.01 -BC.N or the BITCOIN BLOCKCHAIN BTC.01 -BTC.N
（当審訳：「［0058］　ここで全般的に図を，特に図４を参照すると，図４は，
電子コミュニケーションネットワーク４００
第１のプライベートレジャー４０２，第２のプライベートレジャー４０４，パブリックレジャー４０６，典型的な第１のユーザデバイス４０８，典型的な第２のユーザデバイス４１０，インターネット４１１，複数のモジュール４１２．Ａ〜４１２．Ｅを含むトランザクションシステム４１２，そしてタイトルレジストリーサーバ４１４を含む
パブリックレジャー４０６は，好ましくはＣＦＩネットワークであり，そして，多くのノードＮ．１〜Ｎ．Ｎを複数含むであろうし，それらは各々，好ましくは同じパブリックレジャーの複製，例えば，アクセス可能なブロックチェーンＢＣ．０１〜ＢＣ．ＮまたはビットコインのブロックチェーンＢＴＣ．０１〜ＢＴＣ．Ｎを，維持し動的に更新する
　
エ．「［0064］　Referring now generally to the Figures, and particularly to FIG. 5 , FIG. 5 is a 
process chart describing a preferred implementation of the invented method
a first user Alice of the first user device 408 applies a first applications software 500
and a second user Bob of the second user device 410 applies a second applications software 502
to mutually agree upon and enable execution of a transfer of assets for funds
（当審訳：「［0064］　ここで全般的に図を，特に図５を参照すると，図５は，
発明である方法の好ましい実装を記述したプロセスチャートである
第１のユーザデバイス４０８の第１のユーザであるアリスは，第１のアプリケーションソフトウェア５００
を導入し，第２のユーザデバイス４１０の第２のユーザであるボブは，第２のアプリケーションソフトウェア５０２
を導入して，互いに合意し，ファンドのための資産の移動を実行できるようにする
　
オ．「［0074］　Referring now generally to the Figures, and particularly to FIG. 10 , FIG. 10 is a flowchart of a yet additional aspect of the invented method whereby a procedure is performed within a funds transfer, or “bank dash” 1000 , within the first private ledger 402 . In one preferred embodiment of the invented method the first private ledger 402 is maintained by a financial institution, such as a bank. 
In step 10.02 a first contract 130 is created. In step 10.04  the first contract 130 is transmitted to the electronic device of the first user device  408 . In step 10.06
the first private ledger 402 may receive the first contract 130 with the signature of the first user device 408 affixed thereto. In step 10.08 the first private ledger 402 saves the contract to local storage. In step 10.10 the first private ledger 402 requests credit approval from the credit and payment system 412.D for the desired transaction. In step 10.12 the first private ledger 402 determines whether approval has been received from the credit and payment system 412.D. When the determination in step 10.12 is negative, the transaction is declined
［0075］　Alternatively, 
when the determination in step 10.12 is positive, the first private ledger 402 writes the first contract 130 to itself, the second private ledger 404 and/or to the public ledger 406 in step 10.16 . In step 10.18 the first private ledger 402 determines whether a public transaction, or an event related to a public transaction has appeared in the public ledger 406 . When the determination in step 10.18 is negative, the first private ledger 402 proceeds to step 10.20 and waits for a public transaction to appear. In the alternative, when the determination in step 10.18 is positive, the first private ledger 402 advances to step 10.22 , wherein the first private ledger 402 pays the accounts held in either the public ledger 406 , the second private ledger 404 or the first private ledger 402 . In step 10.24 the first private ledger 402 records the proof of payment from the proof of payment module 412.C
（当審訳：「［0074］　ここで全般的に図を，特に図１０を参照すると，図１０は，発明である方法の追加的観点のフローチャートであり，それによって，手続きが，ファンドの転送の範囲で，または，“バンクダッシュ”１０００が，第１のプライベートレジャー４０２の範囲で，実行される。方法である発明のある好ましい実施例では，第１のプライベートレジャー４０２は，金融機関，例えば銀行によって維持される。
ステップ１０．０２では，第１のコントラクト１３０が生成される。ステップ１０．０４では，第１のコントラクト１３０は，第１のユーザデバイス４０８の電子デバイスに転送される。ステップ１０．０６では，第１のプライベートレジャー４０２は，第１のユーザデバイス４０８の署名がそこに添付された第１のコントラクト１３０を受信するだろう。ステップ１０．０８では，第１のプライベートレジャー４０２は，そのコントラクトをローカルストレージに保存する。ステップ１０．１０では，第１のプライベートレジャー４０２は，要求されたトランザクションのための信用及び支払いシステム４１２．Ｄからの信用承認を要求する。ステップ１０．１２では，第１のプライベートレジャー４０２は，信用及び支払いシステム４１２．Ｄから承認を受信したか否かを判断する。ステップ１０．１２での判断が否の場合には，トランザクションは破棄され
［0075］　それに対し，
ステップ１０．１２での判断が正の場合には，第１のプライベートレジャー４０２は，第１のコントラクトを自身や，第２のプライベートレジャー４０４，かつ／または，パブリックレジャー４０６に，ステップ１０．１６において書き込む。ステップ１０．１８において，第１のプライベートレジャー４０２は，パブリックトランザクション，または，パブリックトランザクションに関連したイベントがパブリックレジャー４０６に発生したか否かを判断する。ステップ１０．１８での判断が否の場合には，第１のプライベートレジャー４０２はステップ１０．２２へと始めて，そして，パブリックトランザクションが発生するまで待機する。それに対し，ステップ１０．１８での判断が正の場合には，第１のプライベートレジャー４０２はステップ１０．２２に進み，そこで第１のプライベートレジャー４０２は，パブリックレジャー４０６，第２のプライベートレジャー４０４，または第１のプライベートレジャー４０２のいずれかに保持された勘定を支払う。ステップ１０．２４において，第１のプライベートレジャー４０２は，支払保証モジュール４１２．Ｃからの支払保証を記録する
　
　上記ア．ないしオ．の記載から，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
　
　「モジュールが，２つまたはそれ以上の当事者間の取引リクエストに基づく検証可能かつ客観的な条件を伴ったコントラクト／信用保証を生成し用い，さらに，デジタル暗号化されたネットワーク手段を監視するための方法であって，
　電子コミュニケーションネットワークは，第１のプライベートレジャー，第２のプライベートレジャー，パブリックレジャー，第１のユーザデバイス，第２のユーザデバイス，インターネット，複数のモジュールを含むトランザクションシステム，及び，タイトルレジストリーサーバを含み，
　パブリックレジャーは，多くのノードを複数含み，それらは各々，例えば，アクセス可能なブロックチェーンまたはビットコインのブロックチェーンである同じパブリックレジャーの複製を維持し動的に更新するものであり，
　第１のユーザデバイスの第１のユーザが，第１のアプリケーションソフトウェアを導入し，第２のユーザデバイスの第２のユーザが，第２のアプリケーションソフトウェアを導入して，互いに合意し，ファンドのための資産の移動を実行できるようにするものであって，
　第１のコントラクトが生成され，
　第１のコントラクトが第１のユーザデバイスの電子デバイスに転送され，
　第１のプライベートレジャーが，第１のユーザデバイスの署名がそこに添付された第１のコントラクトを受信し，
　第１のプライベートレジャーが，そのコントラクトをローカルストレージに保存し，
　第１のプライベートレジャーが，要求されたトランザクションのための信用及び支払いシステムからの信用承認を要求し，
　第１のプライベートレジャーが，信用及び支払いシステムから承認を受信したか否かを判断し，当該判断が否の場合には，トランザクションが破棄され，当該判断が正の場合には，第１のプライベートレジャーは，第１のコントラクトを自身や，第２のプライベートレジャー，かつ／または，パブリックレジャーに書き込み，
　第１のプライベートレジャーが，パブリックトランザクション，または，パブリックトランザクションに関連したイベントがパブリックレジャーに発生したか否かを判断し，当該判断が否の場合には，第１のプライベートレジャーは，パブリックトランザクションが発生するまで待機し，当該判断が正の場合には，第１のプライベートレジャーは，パブリックレジャー，第２のプライベートレジャー，または第１のプライベートレジャーのいずれかに保持された勘定を支払い，
　第１のプライベートレジャーが，支払保証モジュールからの支払保証を記録する，
　方法。」
　
２．引用文献２について
　原査定の拒絶理由に引用された，特開２０１０−２３７７３１号公報（以下，「引用文献２」という。）には図面とともに次の事項が記載されている。
　
カ．「【００３３】
　次に，この様な
決済システム２１を用いて取引をする例
【００３４】
　まず，利用者１１はＡＴＭ２２に取引開始４１の操作をすると同時にＩＣカード２３をＡＴＭ２２に入れる。それによりＡＴＭ２２はＩＣカード読み込み４２を行うが，その後必要に応じて決済が必要な各種取引の操作を行う。そこでＩＣカード２３に予めデータとして保持している各承認者のメールアドレスを含んだ承認者リストを取り込んでそれをＡＴＭ２２にて利用者１１に対して承認者リスト表示４３を行う。
【００３５】
　
利用者１１は，ＡＴＭ２２の承認者リスト表示４３に基づいて承認者選択４４をＡＴＭ２２を操作することにより行う
これにより決済システム２１内の情報処理部３２では承認者１２に承認の可否を求めるメール作成４６を行い，情報伝達部３１により承認者１２へメール送信４７を行う
【００３６】
　
メール送信４７を受信した承認者１２は，端末２５を用いてネットワーク２４を介して決済システム２１にサーバー接続４９を行い，決済の可否の操作を行う。承認する場合
承認者１２は端末２５を用いて口座番号と暗証番号入力５０を決済システム２１に送る
決済システム２１内ではこの口座番号と暗証番号入力５０を情報伝達部３１で受け取り，認証部３３に送る
暗証番号確認５１と承認者確認５２が両方確認された場合
認証部３３から送られた認証結果をもとに情報処理部から送られた取引情報に基づいてデータベース３５に適宜アクセスを行って決済部３４で決済を行い
　
キ．「【００４５】
　また，この決済システムは，承認者に選ばれたメールアドレスに取引情報（利用者名，振込先名，取引金額）が記載されたメールを作成し，送信を行うのが一般的であるが，他の構成も可能である。
【００４６】
　この場合，メールには，取引内容と取引承認を行うためのＵＲＬを記載する構成が考えられる。この場合，メール受信者である承認者は該当のＵＲＬに接続し，口座番号と暗証番号を入力することで取引を承認とすることとなる。なお，ＵＲＬへの接続，情報の伝達には暗号化された通信方式を用いるのが好ましい。
　・・・（中略）・・・
【００５１】
　以上の説明において，承認を行う第三者は，複数でも良いが，
複数の人物が承認を行う場合は，全員の承認を取引の必須条件としても良く，また，複数の人物が承認を行う場合は，承認を得た人物や数によって，振込み額を変化させても良い
　
　したがって，上記引用文献２には次の技術事項（以下，「引用文献２技術事項」という。）が記載されていると認められる。
　
　「決済システム２１を用いて取引をする方法であって，
　利用者１１が，ＡＴＭ２２の承認者リスト表示４３に基づいて承認者選択４４をＡＴＭ２２を操作することにより，決済システム２１内の情報処理部３２で，承認者１２に承認の可否を求めるメール作成４６を行い，情報伝達部３１により承認者１２へメール送信４７を行い，
　メール送信４７を受信した承認者１２は，端末２５を用いてネットワーク２４を介して決済システム２１にサーバー接続４９を行い，決済の可否の操作を行い，承認する場合には，承認者１２は端末２５を用いて口座番号と暗証番号入力５０を決済システム２１に送り，
　決済システム２１内ではこの口座番号と暗証番号入力５０を情報伝達部３１で受け取り，認証部３３において，暗証番号確認５１と承認者確認５２が両方確認された場合には，決済部３４で決済を行うものであり，
　複数の人物が承認を行う場合は，複全員の承認を取引の必須条件としても良く，また，承認を得た人物や数によって，振込み額を変化させても良い，
　方法。」
　
３．引用文献３について
　原査定の拒絶理由に引用された，特開２００７−３１６９５９号公報（以下，「引用文献３」という。）には図面とともに次の事項が記載されている。
　
ク．「【課題を解決するための手段】
【０００８】
　本発明では，
ＡＴＭおよび金融機関の窓口処理における金銭振り込み
【０００９】
　こうすることにより，閾値以上の金額を口座に振り込む場合には，第三者による振り込み承認処理が必要となる。この結果，第三者によって振り込み先口座の照査，および振り込み金額の照査が行われる。
【００１０】
　なお，閾値未満の金額を口座に振り込む場合には，第三者による振り込み承認処理は必要なく，直ちに該当口座へ振り込み処理が行われる。
【００１１】
　本発明の第三者への振り込み承認要求通知手段は，Ｅメール，携帯電話等の即座に対応可能な方法を用いることができ，
顧客が振り込みを行うと，Ｅメールならば，承認者のメールアドレスへ承認要求を求めるメールが送付され
【００１２】
　
承認要求のために通知された情報が妥当なものであった場合，承認者はＡＴＭや銀行窓口で振り込み承認を行う
【００１３】
　承認入力方法は，承認者ＩＤとパスワードとの組み合わせによるものや，手のひら静脈認証や指静脈認証等による生体認証技術を使用したものを利用することが好ましい。
【００１４】
　本発明は，
ＡＴＭや銀行窓口での振り込み承認の他に，Ｅメールでの返信
を利用しての振り込み承認が可能である
【００１５】
　Ｅメールでの返信による振り込み承認を行う場合や，Ｗｅｂサイトを利用して振り込み承認を行う場合には，承認者ＩＤとパスワードとの組み合わせ入力によるものや，事前に登録しておいたＰＣ，携帯端末機器等の限定された端末からの承認入力のみを有効とすることが好ましい。
【００１６】
　電話での応答による振り込み承認の場合には，承認者ＩＤとパスワードとの組み合わせ入力によるものや，声紋判定技術を利用することが好ましい。
【００１７】
　
本発明の第三者による承認者は，予め複数人を登録しておくことができる。承認者を一人のみ登録した場合には，その承認者一人が承認すればよい。承認者を複数人登録した場合には，そのうちの一人のみ承認すればよい設定にもできるが，複数人または全ての承認者が承認しなければならない設定にもできる。例えば，承認者がすぐに対応できないことが想定される場合には，複数人を登録しておき，そのうちの一人が承認すればよい設定にしておくことが好ましい
【００１８】
　本発明では，複数人の承認者を設定した場合には，承認者への承認要求順序を設定することが可能である。優先順序を設定した場合には，最初に最高位の承認者に承認要求通知が行われ，その承認者が予め設定された時間までに承認を行わなかった場合に，次の順位の承認者に承認要求通知が行われる。その承認者が予め設定された時間までに承認を行わなかった場合，その下位の承認者に承認要求通知が行われる。こうすることにより，最終的には一人の承認のみでよく，かつ，承認者が不在の場合でも，次に権限のある者が承認を行うことができる。
【００１９】
　
第三者の承認者が振り込みを承認した場合には，該当口座への振り込み処理が行われ，振り込みした顧客と第三者の承認者へ振り込み手続き完了通知が行われる
　
　したがって，上記引用文献３には次の技術事項（以下，「引用文献３技術事項」という。）が記載されていると認められる。
　
　「ＡＴＭおよび金融機関の窓口処理における金銭振り込みを行わせる方法であって
　顧客が振り込みを行うと，Ｅメールとして，承認者のメールアドレスへ承認要求を求めるメールが送付され，
　承認要求のために通知された情報が妥当なものであった場合，承認者はＡＴＭや銀行窓口で振り込み承認を行うものであって，当該承認は，ＡＴＭや銀行窓口での振り込み承認の他に，Ｅメールでの返信を利用しての振り込み承認が可能であり，
　上記承認者は，予め複数人を登録しておくことができ，承認者を一人のみ登録した場合には，その承認者一人が承認すればよく，また，承認者を複数人登録した場合には，そのうちの一人のみ承認すればよい設定にもできるが，複数人または全ての承認者が承認しなければならない設定にもでき，例えば，承認者がすぐに対応できないことが想定される場合には，複数人を登録しておき，そのうちの一人が承認すればよい設定にしておくことが好ましいものであり，
　第三者の承認者が振り込みを承認した場合には，該当口座への振り込み処理が行われ，振り込みした顧客と第三者の承認者へ振り込み手続き完了通知が行われる，
　方法。」
　
４．引用文献４について
　原査定の拒絶理由に引用された，特開２０１６−１７０５３０号公報（以下，「引用文献４」という。）には図面とともに次の事項が記載されている。
ケ．「【０００２】
　近年，円やドルといった現実の貨幣による物品の取引だけでなく，電子マネー等の仮想通貨を用いた商取引が行われている。非特許文献１には，ビットコインと呼ばれる仮想通貨を用いて取引を行う技術について開示されている。
　ビットコインによる取引では，ハッシュ関数と公開鍵暗号方式とを用いて，取引データの完全性が担保されている。暗号化を用いて行われた取引（以下，ビットコインの取引を「
トランザクション
ビットコインを利用する全端末に対してブロードキャストで配信される。配信されたトランザクションは，マイナー（発掘者）と呼ばれる端末ソフトウェアによって正当性が検証され，承認されると発掘されたブロックにまとめられ，ブロックチェーンと呼ばれる台帳に記録される
５．引用文献５について
　原査定の拒絶理由に引用された，特開２０１６−２０８３４７号公報（以下，「引用文献５」という。）には図面とともに次の事項が記載されている。
コ．「【００４５】
　図１１は，著作物データが埋め込まれたトランザクションＴＸをブロードキャストする様子を示す図である。図１１に示すように，
トランザクションＴＸが分散ネットワーク内にブロードキャストされた後，分散ネットワーク内の端末装置２０のうちいずれかの装置は，直近のブロックの生成時刻から現ブロックの生成を開始する時刻までの間に蓄積したトランザクションＴＸをまとめて１つのブロックに生成する。これによって，分散ネットワーク内の端末装置２０が記憶するブロックチェーンが更新される
　
６．引用文献６について
　原査定の拒絶理由に引用された，特許第６０４２０１１号公報（以下，「引用文献６」という。）には図面とともに次の事項が記載されている。
　
サ．「【００７７】
　
ブロックチェーン技術
取引内容を示すトランザクションを，連続性が担保されているブロックと呼ばれる情報に格納し，参加者全員にブロードキャストし，受け取ったブロックをそれまでのブロックで構成されるブロックチェーンに基づき検証し，正当性が得られたブロックに含まれるトランザクションに基づき，取引を実行する技術
　
７．引用文献７について
　原査定の拒絶理由に引用された，特開２００９−１６３４７２号公報（以下，「引用文献７」という。）には図面とともに次の事項が記載されている。
　
シ．「【００９０】
　次に，フローチャートおよび画面の例を参照して，
予約者からの予約の受付の処理
【００９１】
　図４は，ユーザＡである予約者からの予約を受け付ける，サーバ１１による予約者受付の処理の例（第１の実施の形態）を説明するフローチャートである。
【００９２】
　ステップＳ１１において，予約受付処理部１０７は，Webサーバ機能１０１に，インターネット１２を介して，宿泊の予約を行うための画面（以下，宿泊予約申込画面と称する）を表示させる宿泊予約画面データを，ユーザＡの端末装置１４である端末装置１４−１に送信させる。すなわち，Webサーバ機能１０１は，通信部５９に，インターネット１２を介して，端末装置１４−１宛てに宿泊予約画面データを送信させる。
【００９３】
　図５は，宿泊予約画面データを受信した端末装置１４−１に表示される宿泊予約申込画面の例を示す図である。
【００９４】
　宿泊予約申込画面には，予約しようとする宿泊施設Ａ乃至宿泊施設Ｎのいずれかの名前，シングルまたはツインなどの予約する部屋のタイプを示す部屋タイプ，宿泊施設Ａ乃至宿泊施設Ｎのいずれかに手続きして入室する日付を示すチェックイン，泊施設Ａ乃至宿泊施設Ｎのいずれかから，料金を精算して，引き払う日付を示すチェックアウト，宿泊を予約する人数を示す申込人数，予約する部屋の数を示す申込部屋数，および料金が表示される。
【００９５】
　図５の宿泊予約申込画面の例において，○○ホテル大宮である，宿泊施設Ａ乃至宿泊施設Ｎのいずれかの名前，ツインである部屋タイプ，2007年10月11日（木）であるチェックイン，2007年10月12日（金）であるチェックアウト，2人（大人：2人  子供：0人）である申込人数，１部屋である申込部屋数，17000円である料金が表示されている。
【００９６】
　また，宿泊予約申込画面には，予約者の情報を入力するためのフィールドが配置されている。すなわち，宿泊予約申込画面には，予約者の住所の郵便番号を入力するフィールド，予約者の住所を入力するフィールド，予約者の氏名を入力するフィールド，予約者の電話番号を入力するフィールド，および予約者のメールアドレスを入力するフィールドが配置されている。
【００９７】
　さらに，宿泊予約申込画面には，いますぐクレジットカードで決済するか，または宿泊するとき現地で決済するかを選択するラジオボタンが配置されている。
【００９８】
　
予約者は，宿泊予約申込画面のそれぞれのフィールドに，郵便番号，住所，氏名，電話番号，メールアドレスをそれぞれ入力し，決済の方法を指定するラジオボタンのいずれかを選択して，通常の予約をする場合には，通常の予約を指示するボタン
をクリックし
【００９９】
　
通常の予約を指示するボタンがクリックされると，端末装置１４−１は，
予約者の情報を，インターネット１２を介してサーバ１１に送信する
【０１００】
　一方，同伴者承認後予約を指示するボタンがクリックされると，端末装置１４−１は，同伴者承認後予約を示す情報と共に，宿泊予約申込画面のそれぞれのフィールドに入力された，郵便番号，住所，氏名，電話番号，およびメールアドレスからなる，予約者の情報を，インターネット１２を介してサーバ１１に送信する。
【０１０１】
　なお，宿泊予約申込画面に，後からクレジットカードで決済することを指示するラジオボタンを設けて，後からクレジットカードで決済することを選択できるようにしてもよい。例えば，後からクレジットカードで決済することが選択され，同伴者承認後予約が指示された場合，同伴者の承認が得られた時点においてクレジットカードで決済するようにすれば，後述するように，予約をやり直す場合であっても，決済の処理が簡単になる。
【０１０２】
　ステップＳ１２において，
予約受付処理部１０７は，Webサーバ機能１０１に，インターネット１２を介して端末装置１４−１から送信されてくる，宿泊予約申込画面から入力された情報を受信させる
【０１０３】
　Webサーバ機能１０１は，受信した情報を予約受付処理部１０７に供給する。
【０１０４】
　ステップＳ１３において，
予約受付処理部１０７は，端末装置１４−１において入力され，送信されてきた情報を参照して，同伴者承認後予約であるか否かを判定し，同伴者承認後予約であると判定された場合
同伴者の情報を入力するための画面
を表示させる
【０１０５】
　言い換えれば，ステップＳ１４において，Webサーバ機能１０１は，通信部５９を制御して，インターネット１２を介して，同伴者情報入力画面データを端末装置１４−１に送信する。
【０１０６】
　図６は，同伴者情報入力画面データを受信した端末装置１４−１に表示される同伴者情報入力画面の例を示す図である。
【０１０７】
　同伴者情報入力画面には，同伴者の情報を入力するためのフィールドが配置されている。すなわち，同伴者情報入力画面には，同伴者の氏名を入力するフィールド，同伴者のメールアドレスを入力するフィールド，および予約者から同伴者へのメッセージを入力するフィールドが配置されている。
【０１０８】
　同伴者承認後予約を継続する場合には，予約者は，同伴者情報入力画面のそれぞれのフィールドに，同伴者の氏名，同伴者のメールアドレス，および同伴者へのメッセージをそれぞれ入力し，同伴者承認後予約の処理の継続を指示するボタン（例えば，図６の下側の２つのボタンのうちの右側の”同伴者承認後予約する”と記載されているボタン）をクリックする。
【０１０９】
　以下，同伴者が，ユーザＢである場合を例に説明する。
【０１１０】
　宿泊予約申込画面に戻る場合には，予約者は，宿泊予約申込画面への戻りを指示するボタン（例えば，図６の下側の２つのボタンのうちの左側の”戻る”と記載されているボタン）をクリックする。
【０１１１】
　宿泊予約申込画面への戻りを指示するボタンがクリックされると，端末装置１４−１は，宿泊予約申込画面への戻りを指示する情報をインターネット１２を介してサーバ１１に送信する。サーバ１１が，端末装置１４−１から，宿泊予約申込画面への戻りを指示する情報を受信すると，サーバ１１による予約者受付の処理は，ステップＳ１１に戻る。
【０１１２】
　一方，
同伴者承認後予約の処理の継続を指示するボタンがクリックされると，端末装置１４−１は，同伴者情報入力画面のそれぞれのフィールドに入力された，同伴者の氏名，同伴者のメールアドレス，および同伴者へのメッセージからなる，同伴者の情報と共に，同伴者承認後予約の処理の継続を指示する情報をインターネット１２を介してサーバ１１に送信する
【０１１３】
　ステップＳ１５において，予約受付処理部１０７は，Webサーバ機能１０１に，インターネット１２を介して端末装置１４−１から送信されてくる，同伴者情報入力画面のそれぞれのフィールドに入力された，同伴者の氏名，同伴者のメールアドレス，および同伴者へのメッセージからなる情報と共に，同伴者承認後予約の処理の継続を指示する情報を受信させる。Webサーバ機能１０１は，受信した情報を予約受付処理部１０７に供給する。
【０１１４】
　予約受付処理部１０７のURL発行部１２１は，今回の同伴者承認後予約の特定のURLを発行する。また，予約受付処理部１０７は，同伴者承認後予約を特定する予約IDに対応付けて，URL発行部１２１で発行されたURL，被予約宿泊施設の名前，予約する部屋のタイプを示す部屋タイプ，被予約宿泊施設に手続きして入室する日付を示すチェックイン，泊施設Ａ乃至宿泊施設Ｎのいずれかから，料金を精算して，引き払う日付を示すチェックアウト，宿泊を予約する人数を示す申込人数，予約する部屋の数を示す申込部屋数，料金，予約者の郵便番号，予約者の住所，予約者の氏名，予約者の電話番号，予約者のメールアドレス，同伴者の氏名，同伴者のメールアドレス，および同伴者へのメッセージを同伴者承認後予約データベース１０６に格納する。
【０１１５】
　ステップＳ１６において，
予約受付処理部１０７は，メール生成部１０５に，同伴者であるユーザＢに対し，承認を促すメール（以下，承認メールと称する）を生成させ，メール送信制御部１０４に，生成された承認メールを送信させる
【０１１６】
　この場合，メール生成部１０５は，予約受付処理部１０７からの指示に応じて，同伴者承認後予約データベース１０６から，同伴者承認後予約を特定する予約ID，URL，予約者の氏名，同伴者の氏名，同伴者のメールアドレス，および同伴者へのメッセージを読み出して，承認を促す承認メールを生成する。そして，メール送信制御部１０４は，メール生成部１０５において生成された承認メールを，インターネット１２を介して通信部５９に送信させる。
　・・・（中略）・・・
【０１２２】
　図４に戻り，ステップＳ１７において，
予約受付処理部１０７は，同伴者承認後予約の対象となる部屋を確保して，サーバ１１による予約者受付の処理は終了する
【０１２３】
　より詳しく説明すれば，予約受付処理部１０７は，宿泊予約データベース１０３に，被予約宿泊施設，日付，および部屋番号で特定される，同伴者承認後予約の対象となる部屋の情報に対応させて，部屋の確保を示す情報を格納させる。
【０１２４】
　一方，ステップＳ１３において，同伴者承認後予約でないと判定された場合，通常の予約なので，手続きは，ステップＳ１８に進み，予約受付処理部１０７は，通常の予約処理を行い，サーバ１１による予約者受付の処理は終了する。この場合，予約受付処理部１０７は，宿泊予約データベース１０３に，被予約宿泊施設，日付，および部屋番号で特定される，通常の予約の対象となる部屋の情報に対応させて，部屋の予約を示す情報を格納する。
　・・・（中略）・・・
【０１６０】
　以上のように，宿泊などのサービスの提供についての予約者による予約であって，そのサービスの提供を受けようとする承認者の承認が求められる予約を受け付けて，承認者に予約の承認を求める承認画面を表示させるための承認画面データを送信し，承認画面から承認者が予約を承認したか否かに応じて予約についての承認の処理を行うようにしたので，予約者が単独で予約し，予約者とは別に，承認者がその予約を承認することができ，サービスの提供を複数人で受ける場合であっても，簡単に予約することができる。
【０１６１】
　例えば，予約者が複数のサービスの提供について予約し，承認者が，最も好ましい，そのうちの１つについて承認するようにすれば，最終的に，承認者から承認された予約のサービスが提供されることになり，事前に，予約者と承認者が好みなどの調整を行わなくとも，簡単に，予約者と承認者の双方が好むサービスを受けることができるようになる。
【０１６２】
　また，予約者が宿泊施設を確保した後に，同伴者に確認し，同伴者が予約を承認した場合に即座に予約を確定することで，例えば，予約者が宿泊施設を調べた後，同伴者に確認を取るまでのタイムログでその宿泊施設が予約不可能になったりすることもない。さらに，同伴者が承認しなかった場合には部屋が開放されるので，他のユーザが予約を行うことも可能となり，旅行代理店側としても効率がよい。」
ス．「【０２０５】
　なお，
商品の購入に３人以上が関係する場合またはサービスの提供を３人以上で受ける場合，全員が承認するか，半数が承認するか，または１人が承認することによって，予約を確定させたり，予約を維持させたりすることができる
　
　したがって，上記引用文献７には次の技術事項（以下，「引用文献７技術事項」という。）が記載されていると認められる。
　
　「予約者からの予約の受付の処理を行う方法であって，
　予約者は，宿泊予約申込画面のそれぞれのフィールドに，郵便番号，住所，氏名，電話番号，メールアドレスをそれぞれ入力し，決済の方法を指定するラジオボタンのいずれかを選択して，通常の予約を指示するボタンをクリックすると，端末装置は，予約者の情報を，インターネットを介してサーバに送信し，
　予約受付処理部は，Webサーバ機能に，インターネットを介して端末装置から送信されてくる，宿泊予約申込画面から入力された情報を受信し，
　予約受付処理部は，端末装置において入力され，送信されてきた情報を参照して，同伴者承認後予約であるか否かを判定し，同伴者承認後予約であると判定された場合，同伴者の情報を入力するための画面を表示させ，
　同伴者承認後予約の処理の継続を指示するボタンがクリックされると，端末装置は，同伴者情報入力画面のそれぞれのフィールドに入力された，同伴者の氏名，同伴者のメールアドレス，および同伴者へのメッセージからなる，同伴者の情報と共に，同伴者承認後予約の処理の継続を指示する情報をインターネットを介してサーバに送信し，
　予約受付処理部は，メール生成部に，同伴者であるユーザＢに対し，承認を促すメール（承認メール）を生成させ，メール送信制御部１に，生成された承認メールを送信させ，
　予約受付処理部１０７は，同伴者承認後予約の対象となる部屋を確保して，サーバ１１による予約者受付の処理は終了する，ものであって
　商品の購入に３人以上が関係する場合またはサービスの提供を３人以上で受ける場合，全員が承認するか，半数が承認するか，または１人が承認することによって，予約を確定させたり，予約を維持させたりすることができる，
　方法。」
８．引用文献８について
　原査定の拒絶理由に引用された，特開２００９−１６９９１４号公報（以下，「引用文献８」という。）には図面とともに次の事項が記載されている。
　
セ．「【００６１】
　（メンバー追加処理のフローチャート）
　次に，図１２のフローチャートと，図１３〜１５の表示画面の例を参照して，本発明の実施形態に係る
グループメンバーの追加処理工程
【００６２】
　まず，
グループに所属するメンバー（招待者ユーザＡ）が，他のユーザ（被招待者Ｙ）をそのグループに参加させたい場合は，図６（Ａ）のグループトップページで「友達を呼ぶ」４５を選択して，図１３（Ａ）のメンバー追加画面を表示させる。この画面で，被招待者Ｙのニックネーム，コメント（承認依頼文），ユーザＩＤ，及びメールアドレスを各入力欄６３〜６６に入力して送信ボタン６７を押すと（ステップＳ１），前記メンバーリクエスト受付手段３０がその情報を取得して，メンバー追加申込を受け付ける
【００６３】
　メンバー追加申込を受け付けると，図１３（Ｂ）の確認画面が表示され，この画面で招待者が「送信する」ボタン６８を押すと，前記グループ情報更新手段３２が被招待者Ｙを当該グループに仮登録すると共に（ステップＳ３），招待者Ａのユーザ端末４に図１３（Ｃ）の仮登録完了画面を表示させる（ステップＳ４）。また，前記通知手段３１が，グループＩＤに基づいて前記グループ情報格納部２２から全ての所属メンバー（Ｂ）とメールアドレスを検索し（ステップＳ５），メンバー総数（ｎ０）をメモリにセットする。次いで，この
通知手段３１が，招待者Ａ及び被招待者Ｙのニックネームと，招待者Ａが図１３（Ａ）のメンバー追加画面で入力した承認依頼文と，メンバー追加承認待ち一覧画面（図１４（Ａ））のＵＲＬと，を含む承認依頼メールを生成して全てのメンバーのアドレス宛に送信する
【００６４】
　
メンバーＢが，送信されたメールに含まれるＵＲＬをクリックするか，マイページから前記「承認待ち」４０を選択すると，図１４（Ａ）のメンバー追加承認待ち一覧画面が表示される。この画面で，メンバーＢが「承認する」ボタン６９か「承認しない」ボタン７０を押すと（ステップＳ８），メンバー追加承認確認画面（図１４（Ｂ）参照）が表示される（ステップＳ９）。この画面で，メンバーＢが「確認」ボタン７１を押すと，メンバー追加承認結果画面（図１４（Ｃ）に遷移すると共に，この承認結果が本システム１に送信される
【００６５】
　そして，前記グループ情報更新手段３２が，グループ情報格納部２２の当該メンバーＢの項目に登録されていた前記承認待ちフラグを削除して前記承認待ちリストから除外する（ステップＳ１１）。これにより，このメンバーＢについては，図１４（Ａ）のメンバー追加承認待ち一覧から当該グループの承認待ちが削除される。
【００６６】
　受信した回答が「承認」である場合は（ステップＳ１２のＮｏ），「承認人数（ｎ１）」に１を加算する（ｎ１→ｎ１＋１）。これらの処理（ステップＳ１０〜Ｓ１２）を，メンバー全員から回答を受信するまで（ｎ１＝ｎ０）継続する（ステップＳ１３）。
【００６７】
　
メンバー全員から承認されると（ステップＳ１３のＹｅｓ），通知手段３１が招待者Ａ及び被招待者Ｙのニックネームとグループ名と図１５（Ｂ）の招待グループ一覧画面のＵＲＬを含む招待メール（図１５（Ａ））を生成し，被招待者Ｙのメールアドレス宛に送信する（ステップＳ１４）。また，被招待者Ｙのマイページ（図５（Ｂ）参照）において，「グループに招待されています！」４１が表示される
【００６８】
　被招待者Ｙが，マイページから，若しくは前記招待メールのＵＲＬから図１５（Ｂ）の入力画面にアクセスし，「参加する」ボタン７２か「参加しない」ボタン７３を押し，かつ図１５（Ｃ）の確認画面で「送信」ボタン７４を押すと，図１５（Ｄ）の結果確認画面が表示される（ステップＳ１７）。図１５（Ｃ）（Ｄ）は，「参加する」場合を示しているが，「参加しない」場合も同様の画面が表示される。
【００６９】
　また，本システム１が被招待者Ｙからの回答を受信し，ユーザ情報更新手段２７に受け渡す（ステップＳ１８）。受信した回答が「参加する」である場合は（ステップＳ１９のＹｅｓ），ユーザ情報更新手段２７は，グループ情報格納部２２において被招待者Ｙについて登録されていた仮登録フラグ（図４の「tmp_reg_flg」）を削除してユーザ情報格納部２１及びグループ情報格納部２２に登録年月日を登録し本登録に移行する（ステップＳ２０）。また，通知手段３１が，招待者Ａを含むメンバー全員に，図１３（Ｄ）及び図１４（Ｄ）に示すメンバー追加通知メールを送信する（ステップＳ２１，Ｓ２２）。また，被招待者Ｙにも，グループのトップページのＵＲＬを含む「メンバー登録完了メール」（図１５（Ｅ)）が送信される。
【００７０】
　一方，上記ステップＳ１０でメンバーＢから受信した回答が「承認しない」であった場合には（ステップＳ１２のＹｅｓ），前記グループ情報更新手段３２が，「非承認人数（ｎ２）」に１を加算する（ｎ２→ｎ２＋１）。本発明は，
グループメンバーの全員の承認を条件にしているため，この非承認人数（ｎ２）が１になった時点で被招待者Ｙはグループに招待されず
【００７１】
　また，上記ステップＳ１８で受信した被招待者Ｙからの回答が「参加しない」である場合は（ステップＳ１９のＮｏ），グループメンバーによる非承認と同様に，グループ情報格納部２２の仮登録フラグ：１を削除して（ステップＳ２３），招待者Ａを含むグループメンバー全員に「承認結果」を送信する（ステップＳ２１，Ｓ２２）。この場合の「承認結果」は，図１３（Ｅ）及び図１４（Ｅ）に示すように，被招待者Ｙが参加しなかった理由がメンバーの非承認によるものか被招待者Ｙの拒否によるものかを特定できないような文面になっている。そのため，招待者や承認したメンバーは，被招待者Ｙがグループに追加されなかったという結果しか知ることはできない。これにより，メンバー同士及び被招待者とメンバーの間の人間関係を損なうことがない。また，被招待者Ｙにも，確認のため，同様の「承認結果」が送信される（図１５（Ｆ）参照）。」
　
　したがって，上記引用文献８には次の技術事項（以下，「引用文献８技術事項」という。）が記載されていると認められる。
　
　「グループメンバーの追加のための方法であって
　グループに所属するメンバー（招待者ユーザＡ）が，他のユーザ（被招待者Ｙ）をそのグループに参加させたい場合に，グループトップページで「友達を呼ぶ」を選択して，メンバー追加画面を表示させ，この画面で，被招待者Ｙのニックネーム，コメント（承認依頼文），ユーザＩＤ，及びメールアドレスを各入力欄に入力して送信ボタンを押すと，前記メンバーリクエスト受付手段がその情報を取得して，メンバー追加申込を受け付け，
　通知手段が，招待者Ａ及び被招待者Ｙのニックネームと，招待者Ａがメンバー追加画面で入力した承認依頼文と，メンバー追加承認待ち一覧画面のＵＲＬと，を含む承認依頼メールを生成して全てのメンバーのアドレス宛に送信し，
　メンバーＢが，送信されたメールに含まれるＵＲＬをクリックするか，マイページから前記「承認待ち」を選択すると，メンバー追加承認待ち一覧画面が表示され，この画面で，メンバーＢが「承認する」ボタンか「承認しない」ボタンを押すと，メンバー追加承認確認画面が表示され，この画面で，メンバーＢが「確認」ボタンを押すと，メンバー追加承認結果画面に遷移すると共に，この承認結果が本システムに送信され，
　メンバー全員から承認されると，通知手段が招待者Ａ及び被招待者Ｙのニックネームとグループ名との招待グループ一覧画面のＵＲＬを含む招待メールを生成し，被招待者Ｙのメールアドレス宛に送信し，それによって，被招待者Ｙのマイページにおいて，「グループに招待されています！」が表示される，ものであり，
　グループメンバーの全員の承認を条件にしているため，この非承認人数が１になった時点で被招待者Ｙはグループに招待されない，
　方法。」
９．引用文献９について
　原査定の拒絶理由に引用された，特開２００９−２３０２５７号公報（以下，「引用文献９」という。）には図面とともに次の事項が記載されている。
　
ソ．「【００１４】
〔第１実施形態〕
　以下，図面を用いて本発明の実施形態を説明する。本発明の承認システムは，図１に示すように，端末Ｃが通信ネットワーク（以下，ネットワークと称する）Ｎを介して，サーバＳと接続されている。前記ネットワークＮは，企業や学校等の限られた施設内において情報を物理的に送るケーブルと，ＬＡＮスイッチやハブ等でなる中継機器を備えたＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access with Collision Detection）方式のイーサネット（Ethernet）（商標）型のＬＡＮとして構成されたものであるが，このネットワークＮとしてイーサネット型のＬＡＮ以外に，インターネットの技術を用いたイントラネットで構築されたものや，ＷＡＮ（Wide Area Network）の技術によって構築されるものでも良い。
【００１５】
　サーバＳは，汎用コンピュータ１で構成されており，ディスプレイ２，入力機器３（キーボード３ａ，マウス３ｂ）を備えている。また，端末Ｃは，コンピュータ本体４で構成されており，ディスプレイ５，および入力機器６（キーボード６ａ，マウス６ｂ）が接続されている。
【００１６】
　図２は，本発明の承認システムを構成するサーバＳと端末Ｃの機能ブロック図を示している。操作者の使用する端末Ｃ（以下，操作者端末Ｃｏと称する）は，ネットワークＮを介してサーバＳと様々な情報を送受信するためのネットワークＩ／Ｆ１０，端末Ｃにおける様々な操作を表す操作情報を生成し，サーバＳに送信する操作情報生成部１１，サーバＳからの操作の承認結果を受信する承認可否受信部１２を備えている。
【００１７】
　通常，操作情報生成部１１，および承認可否受信部１２は，その処理を実行する手段（プログラムやモジュール等）がハードウェアに読み込まれることでその処理が実行されるが，これらをハードウェアとの組み合わせにより構成しても良いし，ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【００１８】
　操作情報生成部１１は，操作者端末Ｃｏにおいて行われる操作を検知し，検知した操作が所定の操作であれば操作情報を生成し，ネットワークＩ／Ｆ１０およびネットワークＮを介して，操作情報をサーバＳに送信している。なお，本実施形態において，操作情報には，少なくとも操作の対象であるファイルを特定可能なファイル識別情報および端末Ｃを特定可能な端末識別情報が含まれている。なお，ファイル識別情報として，ファイル名，ファイルの絶対パス，ファイルのハッシュ値や個々のファイルに排他的に割り振られた数字等を用いることができ，端末識別情報として，端末名，ＩＰアドレス，ＭＡＣアドレス，個々の端末Ｃに排他的に割り当てられた数字等を用いることができる。また，所定の操作とはファイルの保存，移動，削除等をいうが，他の操作を所定の操作としても構わない。また，操作情報の生成のタイミングは，上述のタイミングに限定されるものではなく，操作が行われたタイミング等，他のタイミングで生成しても構わない。この場合には，生成した操作情報が所定の操作であればサーバＳに送信される，又は逐次サーバＳに送信し，サーバＳにおいて所定の処理であるか否かが判定される構成とすることができる。
【００１９】
　承認可否受信部１２は，サーバＳからの承認結果をネットワークＩ／Ｆ１０を介して取得し，承認結果に基づく制御を実行する。
【００２０】
　承認者の使用する端末Ｃ（以下，承認者端末Ｃａと称する）は，ネットワークＮを介してサーバＳと様々な情報を送受信するためのネットワークＩ／Ｆ３０，サーバＳからの承認依頼を受信する承認依頼受信部３１，承認依頼受信部３１により受信された承認依頼に対する承認の可否をサーバＳに送信する承認可否送信部３２を備えている。
【００２１】
　通常，承認依頼受信部３１および承認可否送信部３２は，その処理を実行する手段（プログラムやモジュール等）がハードウェアに読み込まれることでその処理が実行されるが，これらをハードウェアとの組み合わせにより構成しても良いし，ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【００２２】
　なお，各端末Ｃは，操作者端末Ｃｏおよび承認者端末Ｃａの機能部を備えることにより，操作者端末Ｃｏおよび承認者端末Ｃａのいずれとしても機能することができる。
【００２３】
　サーバＳは，ネットワークＮを介して端末Ｃと様々な情報を送受信するためのネットワークＩ／Ｆ２０，操作者端末Ｃｏから送信される操作情報を取得する操作情報取得部２１，操作に係る承認者のユーザ識別情報を少なくとも含む承認者情報を取得し，その承認者に対して承認依頼を送信する承認依頼部２２，承認を依頼した承認者からの承認結果（以下，承認者承認結果と称する）を受信する承認結果受信部２３，承認者情報および承認結果に基づく集計を行い，集計結果を生成する集計部２４，操作情報および集計結果に基づき操作の承認可否（以下，判定承認結果と称する）を判定する承認可否判定部２５，承認可否判定部２５の判定承認結果に基づき所定の制御を行う制御部２６を備えている。
【００２４】
　通常，操作情報取得部２１，承認依頼部２２，承認結果受信部２３，集計部２４，承認可否判定部２５，および制御部２６は，その処理を実行する手段（プログラムやモジュール等）がハードウェアに読み込まれることでその処理が実行されるが，これらをハードウェアとの組み合わせにより構成しても良いし，ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【００２５】
　操作情報取得部２１は，ネットワークＮおよびネットワークＩ／Ｆ２０を介して操作者端末Ｃｏから送信される操作情報を取得し，取得した操作情報を承認依頼部２２に送る。
【００２６】
　承認依頼部２２は，操作情報取得部２１から操作情報を取得し，その操作情報に含まれるファイル識別情報に基づき，ファイル操作に対する承認者のユーザ識別情報を含む承認者情報を取得し，その承認者に対して承認依頼を送信する。また，取得した承認者情報は，操作情報と共に集計部２４に渡される。なお，本実施形態における承認者情報には少なくとも承認者を特定可能なユーザ識別情報を含んでおり，ユーザ識別情報とは，ユーザ名やその他ユーザを一意に特定可能なユーザ毎に排他的に割り振られた数字等を用いることができる。
【００２７】
　承認結果受信部２３は，承認依頼部２２から送信された承認依頼に対する承認者承認結果を受信し，受信した承認者承認結果を逐次集計部２４に渡している。
【００２８】
　集計部２４は，承認依頼部２２から操作情報および承認者情報を取得し，承認結果受信部２３からは逐次承認者承認結果を受け取っており，所定の条件を満たした際に，承認者情報および承認者承認結果に基づき集計を行い，集計結果を生成する。生成された集計結果は，操作情報と共に承認可否判定部２５に渡される。このように，所定の条件を充足した際に集計部２４を機能させる構成とすることにより，全承認者からの承認者承認結果の受信を待つ必要がなくなるため，迅速な承認の可否決定が可能となる。なお，本実施形態では，所定の条件として，承認依頼部２２から承認依頼が送信されてからの経過時間，承認結果受信部２３が受信した承認者承認結果の件数，承認依頼部２２により特定された承認者の数に対する承認結果受信部２３が受信した承認者承認結果の件数の割合等を用いるが，他の条件を用いて構わない。
【００２９】
　承認可否判定部２５は，集計部２４から取得した操作情報および集計結果に基づき操作に係る承認の可否を判定する。承認可否判定部２５は，承認の可否を判定する際に，操作情報に基づき，承認の可否を判定する閾値ＴＨを変更する構成とすると好適である。例えば，操作情報に係る操作の内容，操作情報に係る操作の対象であるファイルの機密度や操作情報に係る操作者の権限に基づき，閾値ＴＨを変更する。具体的には，操作の内容がコピーのように元のファイルに対する影響が小さい場合や，ファイルの機密度が低い場合，操作者がそのファイルの作成者である等の場合には，閾値ＴＨを低く設定し，承認が得られやすくし，逆に操作の内容がファイルの削除のように元のファイルに対する影響が大きい場合，ファイルの機密度が高い場合や操作者の権限が低い場合などには，閾値ＴＨを高く設定し，承認が得られにくくする。このようにして，判定された判定承認結果は，操作情報と共に制御部２６に渡される。
【００３０】
　承認可否判定部２５から操作情報および判定承認結果を取得した制御部２６は，操作情報に含まれる端末識別情報を有する操作者端末Ｃｏに対して，判定承認結果に基づく制御を指示する。
【００３１】
　次に，図３のフローチャートを用いて，本発明の
承認システムの処理
操作者端末Ｃｏにおいて操作者により操作が行われると
操作情報が生成される
【００３２】
　
操作情報を取得した操作情報取得部２１は，取得した操作情報を承認依頼部２２に渡す。操作情報取得部２１から操作情報を取得した承認依頼部２２は，操作情報に含まれるファイル識別情報に基づき，操作情報に係る操作に対する承認を依頼すべき承認者を特定する
【００３３】
　承認依頼部２２は，同時に，上述のように特定された承認者の権限を取得する。本実施形態では，操作情報に係る操作の対象としてのファイルに対して，各々のユーザの権限が設定されており，権限テーブル（図示せず）に管理されているものとする。したがって，権限テーブルに対して，ファイル識別情報とユーザ識別情報をキーとして検索することにより，権限を取得することができる。もちろん，他の方法により権限を取得しても構わない。例えば，承認者テーブルに各ユーザのユーザ識別情報と関連付けて役職や勤続年数が管理されており，これらの情報に基づき権限を決定する。また，各々のユーザの権限をファイル毎に異ならせるのではなく，固定的に設定しておいても構わない。なお，本発明においては，権限は必須ではないため，権限を取得せずとも以降の処理を行うことは可能である。
【００３４】
　また，本実施形態では，資産情報テーブル（図示せず）に，ユーザ識別情報と端末識別情報とが関連付けて管理されているため，ユーザ識別情報をキーとして資産情報テーブルを検索することにより，端末Ｃを特定することができる。すなわち，上述の処理により特定された承認者のユーザ識別情報に基づき，当該承認者の承認者端末Ｃａを特定することができる。もちろん，他の方法により端末Ｃを特定しても構わない。なお，承認者端末Ｃａを特定することに代えて，承認者のメールアドレス等の承認者の連絡先を特定しても構わない。メールアドレスを用いた場合には，メールを用いて承認を依頼することができる。
【００３５】
　
承認依頼部２２は，このようにして得られた承認者のユーザ識別情報，権限，および承認者端末Ｃａの端末識別情報とから承認者情報を生成し
【００３６】
　
承認依頼部２２は，同時に，承認依頼情報を取得し，上述の処理により特定された承認者に対して，承認依頼として送信する
【００３７】
　
承認依頼部２２から承認依頼を受信した承認依頼受信部３１は，承認者に対して，承認依頼情報に含まれるファイル識別情報を有するファイルに対する操作の承認依頼を受信した旨を通知し，承認の可否の入力を促す
【００３８】
　承
認者が，これに対して承認の可否を入力すると，承認可否送信部３２により承認の可否が承認者承認結果としてサーバＳに送信され，承認結果受信部２３により承認者承認結果が受信される
【００３９】
　
承認結果受信部２３から承認者承認結果を取得した集計部２４は，所定の条件が充足されたか否かを監視しており（＃１１），所定の条件が充足されるまで，承認結果受信部２３からの承認者承認結果を取得し続ける（＃１１のNo分岐）。一方，所定の条件が充足されると（＃１１のYes分岐），集計部２４は，承認依頼部２２から取得した承認者情報と承認結果受信部２３から取得した承認者承認結果に基づく集計を行い，集計結果を生成する
　・・・（中略）・・・
【００４１】
　
集計部２４から操作情報および集計結果を取得した操作可否判定部２５は，これらに基づき操作の可否を判定する
【００４２】
　次に，承認可否決定部２５は，このようにして決定された閾値ＴＨと集計結果を比較することにより，最終的な承認の可否を判定し（＃１４），判定承認結果として操作情報と共に制御部２６に渡す。
【００４３】
　上述の処理により判定された判定承認結果と操作情報を取得した制御部２６は，操作情報に含まれている端末識別情報に基づき操作者端末Ｃｏを特定し，特定した操作者端末Ｃｏに対して，判定承認結果を送信する（＃１５）。
【００４４】
　
制御部２６から判定承認結果を受け取った承認可否受信部１２は，判定承認結果が許可であれば，保留していた操作を実行する
　
　したがって，上記引用文献９には次の技術事項（以下，「引用文献９技術事項」という。）が記載されていると認められる。
　
　「承認システムにおける処理方法であって，
　操作者端末Ｃｏにおいて操作者により所定の操作が行われると，操作情報が生成され，
　操作情報を取得した操作情報取得部は，取得した操作情報を承認依頼部に渡し，
　承認依頼部は，操作情報に含まれるファイル識別情報に基づき，操作情報に係る操作に対する承認を依頼すべき承認者を特定し，
　承認依頼部は，得られた承認者のユーザ識別情報，権限，および承認者端末Ｃａの端末識別情報とから承認者情報を生成し，同時に，承認依頼情報を取得し，特定された承認者に対して，承認依頼として送信し，
　承認依頼部から承認依頼を受信した承認依頼受信部は，承認者に対して，承認依頼情報に含まれるファイル識別情報を有するファイルに対する操作の承認依頼を受信した旨を通知し，承認の可否の入力を促し，
　承認者が，これに対して承認の可否を入力すると，承認可否送信部により承認の可否が承認者承認結果としてサーバに送信され，承認結果受信部により承認者承認結果が受信され，
　承認結果受信部から承認者承認結果を取得した集計部は，所定の条件が充足されたか否かを監視し，所定の条件が充足されるまで，承認結果受信部からの承認者承認結果を取得し続け，所定の条件が充足されると，集計部は，承認依頼部から取得した承認者情報と承認結果受信部から取得した承認者承認結果に基づく集計を行い，集計結果を生成し，
　集計部から操作情報および集計結果を取得した操作可否判定部は，これらに基づき操作の可否を判定し，
　制御部から判定承認結果を受け取った承認可否受信部は，判定承認結果が許可であれば，保留していた操作を実行する，
　方法。」
１０．引用文献１０について
　原査定の拒絶理由に引用された，特開２００９−３０１１８９号公報（以下，「引用文献１０」という。）には図面とともに次の事項が記載されている。
　
タ．「【００４６】
　次に，前述のステップ２０８で実行する
承認処理
【００４７】
　承認処理では，まず，
仮登録・更新通知部１７が文書管理システムのシステム管理者に仮登録・更新があった旨を通知する
【００４８】
　また，システム管理者が承認と非承認の判断を行う場合，その判断材料として文書の登録・更新要求を行った情報処理装置２１−１等の利用環境を通知に含めるようにすることもできる。利用環境は，登録・更新部１４が文書の登録・更新要求とともに受け付ける，または，文書の登録・更新要求を受け付ける際に取得するもので，オペレーティングシステムの種別やバージョン，利用しているアプリケーションソフトウェア（例えば，ウェブブラウザ）の種別やバージョン等がある。この場合にシステム管理者に送信されるメールは，例えば，図８（ｂ）に示すように，利用環境が含まれることとなる。
【００４９】
　仮登録・更新通知部１７が文書管理システムのシステム管理者に仮登録・更新があった旨を通知した結果，
システム管理者が文書管理装置１０にアクセスし，仮登録・更新承認部１８に対して「承認」の応答を行うと（ステップ２８２でＹＥＳ），これを受けた仮登録・更新通知部１７が，文書の登録または更新を要求した登録者と承認者に，仮登録・更新があった旨を通知する
【００５０】
　その結果，登録者と承認者の両者から「承認」の応答が得られると（ステップ２８４でＹＥＳ），これを受けた仮登録・更新反映部１９は，文書仮登録リポジトリ１６に仮登録・更新されている該当文書を文書リポジトリ１５に正規に登録・更新し，仮登録・更新を本登録・更新として反映し（ステップ２８５），承認処理を終了する。
【００５１】
　一方，
仮登録・更新反映部１９は，システム管理者の承認を得られなかった場合や（ステップ２８２でＮＯ），登録者と承認者の少なくとも一方から承認を得られなかった場合には（ステップ２８４でＮＯ），文書仮登録リポジトリ１６に仮登録・更新されている該当文書の反映を却下し（ステップ２８６），承認処理を終了する
【００５２】
　なお，
承認者には，グループを設定したり，複数の者を設定したりすることもでき，この場合には，いずれか一人の承認，全員の承認，一定の人数以上の承認，承認者数が非承認者数よりも多い，承認者が一定数以上でかつ非承認者数が一定する以下であるなど，様々な条件を仮登録・更新の本登録・更新へ反映する際に判断基準として利用することができる
【００５３】
　また，承認者を登録者に対して設定するのではなく，文書に対して承認者を設定したり，登録者と文書の両者に設定することも可能である。」　
　したがって，上記引用文献１０には次の技術事項（以下，「引用文献１０技術事項」という。）が記載されていると認められる。
　
　「承認処理のための方法であって，
　仮登録・更新通知部が文書管理システムのシステム管理者に仮登録・更新があった旨を通知し，
　システム管理者が文書管理装置にアクセスし，仮登録・更新承認部に対して「承認」の応答を行うと，これを受けた仮登録・更新通知部が，文書の登録または更新を要求した登録者と承認者に，仮登録・更新があった旨を通知し，
　登録者と承認者の両者から「承認」の応答が得られると，これを受けた仮登録・更新反映部は，文書仮登録リポジトリに仮登録・更新されている該当文書を文書リポジトリに正規に登録・更新し，仮登録・更新を本登録・更新として反映し，承認処理を終了する，ものであって，
　承認者には，グループを設定したり，複数の者を設定したりすることもでき，この場合には，いずれか一人の承認，全員の承認，一定の人数以上の承認，承認者数が非承認者数よりも多い，承認者が一定数以上でかつ非承認者数が一定する以下であるなど，様々な条件を仮登録・更新の本登録・更新へ反映する際に判断基準として利用することができる，
　方法。」
　
第５　対比・判断
　
１．本願発明１について
（１）引用発明に対する進歩性について
ア．対比
　本願発明１と引用発明とを対比する。
　
　引用発明は，「第１のプライベートレジャーが，第１のユーザデバイスの署名がそこに添付された第１のコントラクトを受信し」た後に，「第１のプライベートレジャーが，信用及び支払いシステムから承認を受信したか否かを判断し」，「当該判断が正の場合には，第１のプライベートレジャーは，第１のコントラクトを自身や，第２のプライベートレジャー，かつ／または，パブリックレジャーに書き込み」，次いで，「第１のプライベートレジャーが，パブリックトランザクション，または，パブリックトランザクションに関連したイベントがパブリックレジャーに発生したか否かを判断し」，「当該判断が正の場合には，第１のプライベートレジャーは，パブリックレジャー，第２のプライベートレジャー，または第１のプライベートレジャーのいずれかに保持された勘定を支払」うものであり，この場合の「第１のコントラクト」の転送は，「勘定」の「支払」を実行させるための処理依頼といえることから，引用発明における当該「第１のコントラクト」のパブリックレジャーへの書き込みのための転送は，本願発明１における「トランザクション」の送信に相当するといえ，また，引用発明において「第１のユーザデバイスの署名」が上記「第１のコントラクト」に添付されて転送されることも，本願発明１において「トランザクションの電子署名」が「トランザクション」とともに送信されることに相当するといえ，さらに，転送の契機について，引用発明における「信用及び支払いシステムからの信用承認」は，本願発明１における「承認」に相当するといえる。
　また，引用発明の「パブリックレジャー」は，「多くのノードを複数含み，それらは各々，例えば，アクセス可能なブロックチェーンまたはビットコインのブロックチェーンである同じパブリックレジャーの複製を維持し動的に更新するものであ」るから，本願発明１の「ブロックチェーンネットワーク」に相当する構成を有するといえ，また，引用発明は，上記「パブリックレジャー」の中に「ブロックチェーン」及びそれを構成する「ブロック」に相当する構成をも有するといえる。そして，上述のとおり，引用発明の「第１のコントラクト」の転送は，「勘定」の「支払」を実行させるための処理依頼であるから，引用発明も，「第１のコントラクト」及び「第１のユーザデバイスの署名」の転送によって，“トランザクションを実行する”ものであるといえる。
　そうすると，後記する点において相違するものの，本願発明１の「受信した前記承認信号の承認に基づき，前記トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし，前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順」と，引用発明の「第１のプライベートレジャーが，第１のユーザデバイスの署名がそこに添付された第１のコントラクトを受信し」た後に，「第１のプライベートレジャーが，信用及び支払いシステムから承認を受信したか否かを判断し」，「当該判断が正の場合には，第１のプライベートレジャーは，第１のコントラクトを自身や，第２のプライベートレジャー，かつ／または，パブリックレジャーに書き込み」，次いで，「第１のプライベートレジャーが，パブリックトランザクション，または，パブリックトランザクションに関連したイベントがパブリックレジャーに発生したか否かを判断し」，「当該判断が正の場合には，第１のプライベートレジャーは，パブリックレジャー，第２のプライベートレジャー，または第１のプライベートレジャーのいずれかに保持された勘定を支払」うことは，“承認に基づき，トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークに送信することによって，前記トランザクションを実行する手順”である点において共通するといえる。
　
　上記の対比によれば，本願発明１と引用発明とは次の点で一致し，そして相違する。
　
［一致点］
　承認に基づき，トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークに送信することによって，前記トランザクションを実行する手順を含む信号処理方法。
　
（相違点ａ）
　本願発明１は，「複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を前記複数のノードの少なくとも一つに送信する手順」を有するのに対し，
　引用発明は，そのような手順を有することは特定されていない点。
　
（相違点ｂ）
　本願発明１は，「前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順」を有するのに対し，
　引用発明は，そのような手順を有することは特定されていない点。
　
（相違点ｃ）
　承認に基づき，トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークに送信することによって，前記トランザクションを実行する手順に関し，
　本願発明１では，「承認」が「受信した承認信号」の承認であり，トランザクションおよび前記トランザクションの電子署名の「送信」が「ブロードキャスト」であり，かつ，トランザクションおよび前記トランザクションの電子署名をブロックチェーンネットワークに送信した後に，「トランザクションに関する情報を含むブロックをブロックチェーンに追加」し，それによって前記トランザクションを実行するという手順となっているのに対し，
　引用発明では，そのような特定はされていない点。
　
イ．相違点についての判断
　事案に鑑みて，上記相違点ｂ及びｃについて先に検討する。
　
　本願発明１の「受信した前記承認信号の承認に基づき，前記トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし，前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順」との記載における，「トランザクション」とともに「ブロードキャスト」され，その後の「トランザクションに関する情報を含むブロック」の「ブロックチェーン」への「追加」及び「トランザクション」の「実行」に用いられる，「電子署名」が，具体的にどのようなものを含むかについては，請求項の記載のみからは必ずしも明らかではないものの，本願明細書の，
　
　「　【００２６】
２．３　承認要求（Ｓ１０２）
　トランズアクションが作成されたのち，トランズアクションの承認段階へ移行する。具体的には図４に示すように，第１の通信端末１１０＿１は，承認要求信号をユーザグループ内の他のユーザが保有する通信端末１１０へ送信する（Ｓ１２０）。・・・（中略）・・・図４では，第１の通信端末１１０＿１を除く通信端末１１０のすべてに承認要求信号が送信される例が示されているが，後述するように，通信端末１１０のうちの一部に承認要求信号を選択的に送信してもよい。また，
第１の通信端末１１０＿１に対して自己送信してもよい
　・・・（中略）・・・
　　【００２８】
２．４　承認（Ｓ１０４）
　トランズアクションを受信した通信端末１１０のユーザは，トランズアクションを承認する，あるいは承認しないという行為のいずれかを選択する（Ｓ１０４）。
承認が選択された場合
電子署名ＥＳ２が生成される
　　【００４０】
　例えば第１の通信端末１１０＿１は，受信した承認信号に含まれる電子署名の数が承認条件を満たすか否かを判断する。
承認条件が満たされたと判断された場合，トランズアクション，電子署名ＥＳ１，および受けとった電子署名をブロックチェーンネットワーク１３０へブロードキャストする
　　【００４１】
　
ブロードキャストが行われたのち，トランズアクションの検証が行われる
　　【００４２】
　通信端末１１０からブロードキャストされた各電子署名は，ノード１３２において対応する公開鍵を用いて復号化される。復号化されて生成されるトランズアクションとオリジナルのトランズアクションを照合することで，トランズアクションの正当性がノード１３２によって判断される。また
ノード１３２は，承認条件が満たされているかどうかを検証する。例えばブロードキャストされた電子署名の数がトランズアクションに記される承認条件に適合する，すなわち，署名に必要な電子署名の数と同一以上であることを検証する
　との記載を踏まえると，他のユーザから受信した承認信号に含まれる電子署名（ＥＳ２）と，自己が生成または自己に送信した電子署名（ＥＳ１），の両方を指すものと解することができ，これは，上記第２の１．における補正の却下の決定での「電子署名ＥＳ２以外のブロードキャストされた電子署名（例えば電子署名ＥＳ１）」についての指摘に対する審判請求書での主張とも整合するものであり，そうすると，相違点ｃに係る構成によれば，本願発明１は，承認信号の承認に基づくＥ１とＥ２を含む「電子署名」がトランザクションとともにブロードキャストされると，それにより，「トランザクションに関する情報を含むブロックをブロックチェーンに追加」することがなされ，トランザクションの実行がなされるという構成となっているといえる。
　また，相違点ｂに係る構成によれば，本願発明１は，承認のための上記承認信号を，「承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノード」，すなわち，「データ」を「共有」する「グループ」を構成する「複数のノード」の中で「承認要求信号」を受信する「ノード」の，さらに「一定割合に相当するノード」のみから受信する構成となっており，当該「一定割合に相当するノード」から受信した「承認信号」の承認に基づき，上記相違点ｃに係る構成のとおり，Ｅ１とＥ２を含む「電子署名」がブロードキャストされ，それにより，ブロックのブロックチェーンへの追加がなされ，トランザクションの実行がなされることになる。
　そして，上記相違点ｂ及びｃに係る構成を備えることで，本願発明１は，「承認権限を持たないユーザも共有されるデータに対してどのような処理が行われうるかを知ることができる」（本願明細書の段落【００３６】）との効果を奏しているものと解される。
　
　それに対し，引用発明は，「パブリックレジャー」へ転送される「第１のユーザデバイスの署名」が，具体的にどのような署名を含み，「パブリックレジャー」内の「ブロックチェーン」に対する処理にどのように寄与しているのか何ら特定されていないから，上記相違点ｃに係る構成について開示も示唆もされていない。承認についても，常に「信用及び支払いシステム」から受信するよう構成されており，それによって，当事者間の取引において，機密性及びプライバシーを維持しつつ，時間的影響から来る問題を克服する，という効果（上記第４の１．イ．）を奏しているものと解されることから，上記相違点ｂに係る構成についての開示も示唆もない。
　また，引用発明において，上記「信用及び支払いシステム」からの承認を，ノードに相当する取引に関し共有関係にあるユーザのうち一定割合からの承認信号による承認に変更することは，上記効果を損うことからして引用発明に動機付けがあるとはいえず，また，単なる設計変更によりなし得たものとすることもできない。
　そうすると，引用文献１の他の記載，引用文献２ないし１０に記載された事項を参酌しても，引用発明に基づいて，相違点ｂ及びｃに係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
　
　そして，上記相違点ｂ及びｃに係る本願発明１の構成が，引用発明に開示も示唆もなく，引用文献１の他の記載，引用文献２ないし１０に記載された事項を参酌しても，引用発明に基づいて，相違点ｂ及びｃに係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえないことは上記に示したとおりである。
　
　したがって，本願発明１は，相違点ａを検討するまでもなく，当業者であっても引用発明，引用文献１ないし１０に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　
（２）引用文献２，３，７ないし１０技術事項に対する進歩性について
　原査定の理由に鑑み，引用文献２，３，７ないし１０技術事項に対する進歩性についても，以下で検討する。
　
ア．引用文献２技術事項について
　本願発明１と，上記第４の２．における引用文献２技術事項とを対比すると，引用文献２技術事項は，そもそも，承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト，及び，その後のブロックのブロックチェーンへの追加について何ら言及がないことから，少なくとも，本願発明１の構成に関し上記（１）のア．における引用発明との〈相違点ｃ〉と共通する相違点，において相違し，そして，上記（１）のイ．の判断内容も踏まえると，引用文献２の他の記載，引用文献１，３ないし１０に記載された事項を参酌しても，引用文献２技術事項に基づいて，上記相違点に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
　
イ．引用文献３技術事項について
　本願発明１と，上記第４の３．における引用文献３技術事項とを対比すると，引用文献３技術事項は，そもそも，承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト，及び，その後のブロックのブロックチェーンへの追加について何ら言及がないことから，少なくとも，本願発明１の構成に関し上記（１）のア．における引用発明との〈相違点ｃ〉と共通する相違点，において相違し，そして，上記（１）のイ．の判断内容も踏まえると，引用文献３の他の記載，引用文献１，２，４ないし１０に記載された事項を参酌しても，引用文献３技術事項に基づいて，上記相違点に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
　
ウ．引用文献７技術事項について
　本願発明１と，上記第４の７．における引用文献７技術事項とを対比すると，引用文献７技術事項は，そもそも，承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト，及び，その後のブロックのブロックチェーンへの追加について何ら言及がないことから，少なくとも，本願発明１の構成に関し上記（１）のア．における引用発明との〈相違点ｃ〉と共通する相違点，において相違し，そして，上記（１）のイ．の判断内容も踏まえると，引用文献７の他の記載，引用文献１ないし６，８ないし１０に記載された事項を参酌しても，引用文献７技術事項に基づいて，上記相違点に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
　
エ．引用文献８技術事項について
　本願発明１と，上記第４の８．における引用文献８技術事項とを対比すると，引用文献８技術事項は，そもそも，承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト，及び，その後のブロックのブロックチェーンへの追加について何ら言及がないことから，少なくとも，本願発明１の構成に関し上記（１）のア．における引用発明との〈相違点ｃ〉と共通する相違点，において相違し，そして，上記（１）のイ．の判断内容も踏まえると，引用文献８の他の記載，引用文献１ないし７，９，１０に記載された事項を参酌しても，引用文献８技術事項に基づいて，上記相違点に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
オ．引用文献９技術事項について
　本願発明１と，上記第４の９．における引用文献９技術事項とを対比すると，引用文献９技術事項は，そもそも，承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト，及び，その後のブロックのブロックチェーンへの追加について何ら言及がないことから，少なくとも，本願発明１の構成に関し上記（１）のア．における引用発明との〈相違点ｃ〉と共通する相違点，において相違し，そして，上記（１）のイ．の判断内容も踏まえると，引用文献９の他の記載，引用文献１ないし８，１０に記載された事項を参酌しても，引用文献９技術事項に基づいて，上記相違点に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
　
カ．引用文献１０技術事項について
　本願発明１と，上記第４の１０．における引用文献１０技術事項とを対比すると，引用文献１０技術事項は，そもそも，承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト，及び，その後のブロックのブロックチェーンへの追加について何ら言及がないことから，少なくとも，本願発明１の構成に関し上記（１）のア．における引用発明との〈相違点ｃ〉と共通する相違点，において相違し，そして，上記（１）のイ．の判断内容も踏まえると，引用文献１０の他の記載，引用文献１ないし９に記載された事項を参酌しても，引用文献１０技術事項に基づいて，上記相違点に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
（３）まとめ
　以上から，本願発明１は，当業者であっても引用文献１ないし１０に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　
２．本願発明２−８について
　本願発明２ないし４は，本願発明１を更に限定したものであるので，同様に，当業者であっても引用文献１ないし１０に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　また，本願発明５は，本願発明１を別のカテゴリーで表現するものであり，同様に，当業者であっても引用文献１ないし１０に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　また，本願発明６ないし８は，本願発明５をそれぞれ更に限定したものであるので，同様に，当業者であっても引用文献１ないし１０に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　
　　
第６　原査定についての判断
　
１．特許法第３６条第６項第２号（明確性）について
　原査定では，請求項１−８に記載された「受信した前記承認信号の承認に基づき，前記トランザクション，および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし，前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する」は，「することによって・・・する」という部分が日本語として曖昧であり，技術的範囲が不明確である，との理由を示しているが，平成２９年９月１２日付けの意見書における，「このトランザクション（処理依頼）に関する情報を含むブロックをブロックチェーンに追加する行為がトランザクションの実行を意味します」との主張を踏まえれば，上記「ブロックをブロックチェーンに追加すること」が「トランザクションの実行」を意味することが明確であるから，請求項１−８に係る発明は明確である。
　また，原査定では，請求項１−８に記載された「トランザクション」は，送受信可能なデータであるのか，実行可能な処理であるのか不明であるから，技術的内容が不明確である，との理由を示しているが，平成２９年９月１２日付けの意見書における，『本願明細書においては，トランザクションとは「依頼処理」であり』との主張を踏まえれば，上記「トランザクション」という記載は，「依頼処理」という意味であることが明確であるから，請求項１−８に係る発明は明確である。
　
２．特許法第２９条第２項（進歩性）について
　上記「第５　対比・判断」の（１）イ．で検討のとおりであり，したがって，原査定の理由２を維持することはできない。
　
　
第７　むすび
　
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。