• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特17条の2、3項新規事項追加の補正 取り消して特許、登録 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1339396
審判番号 不服2018-533  
総通号数 222 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-06-29 
種別 拒絶査定不服の審決 
審判請求日 2018-01-16 
確定日 2018-04-24 
事件の表示 特願2017- 29730「信号処理方法、および信号処理プログラム」拒絶査定不服審判事件〔、請求項の数(8)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本願は,平成29年2月21日を出願日とする出願であって,同年5月9日付けで拒絶理由通知(同年同月16日発送)がされ,同年同月30日付けで意見書が提出されるとともに手続補正がされ,同年6月9日付けで最後の拒絶理由通知(同年同月13日発送)がされ,同年9月12日付けで意見書が提出されるとともに手続補正がされたが,同年10月6日付けで前記平成29年9月12日付け手続補正を却下する旨の補正の却下の決定がなされるとともに拒絶査定(同年10月17日謄本送達,以下,「原査定」という。)がされ,これに対し,平成30年1月16日付けで拒絶査定不服審判の請求がされたものである。


第2 平成29年10月6日付けの補正の却下の決定及び原査定の概要

1.平成29年10月6日付けの補正の却下の決定の概要は以下のとおりである。

平成29年10月6日付けの手続補正により補正された請求項1には,ブロックチェーンネットワークにおいて承認条件が満たされていることを確認する際に,ブロードキャストされた如何なる電子署名を用いるのかについて何ら特定されていないところ,当初明細書等には,ブロックチェーンネットワーク130のノード132が承認条件が満たされていることを確認する際に,電子署名ES2以外のブロードキャストされた電子署名(例えば電子署名ES1)を用いる点について記載も示唆も為されておらず,この点は当業者にとって当初明細書等の記載事項及び出願時の技術常識から明らかな事項でもないから,本件補正は,当初明細書等に記載した事項の範囲内においてしたものでない。

2.原査定(平成29年10月6日付け拒絶査定)の理由の概要は次のとおりである。

(1)理由1 特許法第36条第6項第2号(明確性)について

請求項1-8に記載された「受信した前記承認信号の承認に基づき,前記トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし,前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する」は,「することによって・・・する」という部分が日本語として曖昧であり,技術的範囲が不明確である。

請求項1-8に記載された「トランザクション」は,送受信可能なデータであるのか,実行可能な処理であるのか不明であるから,技術的内容が不明確である。

(2)理由2 特許法第29条第2項(進歩性)について

本願請求項1-8に係る発明は,引用文献1に記載された発明において,引用文献2-3に記載された周知技術,及び,引用文献4-6に記載された周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。
本願請求項1-8に係る発明は,引用文献2に記載された発明において,引用文献4-6に記載された周知技術,及び,電子署名を付加して送信する周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。
本願請求項1-8に係る発明は,引用文献3に記載された発明において,引用文献4-6に記載された周知技術,及び,電子署名を付加して送信する周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。
本願請求項1-8に係る発明は,引用文献7に記載された発明において,引用文献4-6に記載された周知技術,及び,電子署名を付加して送信する周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。
本願請求項1-8に係る発明は,引用文献8に記載された発明において,引用文献4-6に記載された周知技術,及び,電子署名を付加して送信する周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。
本願請求項1-8に係る発明は,引用文献9に記載された発明において,引用文献4-6に記載された周知技術,及び,電子署名を付加して送信する周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。
本願請求項1-8に係る発明は,引用文献10に記載された発明において,引用文献4-6に記載された周知技術,及び,電子署名を付加して送信する周知技術を採用することで,当業者が容易に為し得たことであるから,特許法第29条第2項の規定により特許を受けることができない。

＜引用文献等一覧＞
1.米国特許出願公開第2015/0206106号明細書
2.特開2010-237731号公報
3.特開2007-316959号公報
4.特開2016-170530号公報
5.特開2016-208347号公報
6.特許第6042011号公報
7.特開2009-163472号公報
8.特開2009-169914号公報
9.特開2009-230257号公報
10.特開2009-301189号公報


第3 本願発明

本願請求項1-8に係る発明(以下,それぞれ「本願発明1」-「本願発明8」という。)は,平成29年5月30日付けの手続補正で補正された特許請求の範囲の請求項1-8に記載された事項により特定される発明であり,以下のとおりの発明である。

「 【請求項1】
複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を前記複数のノードの少なくとも一つに送信する手順と,
前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と,
受信した前記承認信号の承認に基づき,前記トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし,前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順とを含む信号処理方法。
【請求項2】
前記承認信号は前記ノードにおける電子署名の付加により生成される,請求項1に記載の信号処理方法。
【請求項3】
前記承認信号を受信する手順において受信される前記承認信号が,前記複数のノードのうちの前記一定割合に満たない場合には,前記トランザクションを破棄する,請求項1に記載の信号処理方法。
【請求項4】
前記承認信号は,前記トランザクション,および前記トランザクションから生成された電子署名を含み,
前記承認は,受信した前記承認信号に含まれる前記電子署名の総数によって判断される,請求項1に記載の信号処理方法。
【請求項5】
複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を,前記複数のノードの一つから前記複数のノードの他の少なくとも一つに送信する手順と,
前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順と,
受信した前記承認信号の承認に基づき,前記トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし,前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順を前記複数のノードに実行させるように構成される信号処理プログラム。
【請求項6】
電子署名を付加することにより前記承認信号を生成することを前記複数のノードに実行させるように構成される,請求項5に記載の信号処理プログラム。
【請求項7】
前記承認信号を受信する手順において受信される前記承認信号が,前記複数のノードのうちの前記一定割合に満たない場合には,前記トランザクションを破棄する,請求項5に記載の信号処理プログラム。
【請求項8】
前記承認は,受信した前記承認信号に含まれる前記電子署名の総数によって判断される,請求項6に記載の信号処理プログラム。」


第4 引用文献,引用発明等

1.引用文献1について
原査定の拒絶理由に引用された,米国特許出願公開第2015/0206106号明細書(以下,「引用文献1」という。)には図面とともに次の事項が記載されている。(下線は当審により付与。以下同じ。)

ア.「[0007] Towards these objects and other objects that are made obvious in light of the present disclosure, an invented method and invented system are provided comprising an invented software/computer/firmware module that creates and applies contract/credit certificates with verifiable and objective terms based on a trade request between two or more parties. The invented module of the of the method of the present invention (hereinafter, “the invented method”) may be further adapted to monitor crypto-digital instrument networks, to verify performance of the expected terms and/or notify a credit issuing party as to the status, e.g., a complete/not complete status, of a contract, credit certificate, or other electronic document.」
(当審訳:「[0007] 現在開示されている観点でこれらの目的及び他の目的を明らかにするために,発明に係る方法及びシステムが提供され,それは,発明に係るソフトウェア/コンピュータ/ファームウェアのモジュールを含み,それは,2つまたはそれ以上の当事者間の取引リクエストに基づく検証可能かつ客観的な条件を伴ったコントラクト/信用保証を,生成し用いるものである。本発明(以下,“発明に係る方法”)の方法に係る発明のモジュールは,さらにデジタル暗号化されたネットワーク手段を監視することに適用され,また,期待される条件の履行を検証し,及び/または,信用発行の当事者に対し,コントラクト,信用保証,または他の電子文書の状態,例えば,完了/未完了の状態について通知することに適用されるだろう。」)

イ.「[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. Additionally, maintaining confidentiality on CDI networks typically requires use of various transaction-masking procedures which may add additional time to for each transaction. It is well known that time is a major barrier in these transactions as traders wish to agree on a price in volatile markets requiring rapid response on behalf of the trader. However, the time effects involved in waiting for the various payment methods may cause deals to be cancelled if market conditions move against one of the participants.
[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] 取引の相手当事者は,取引活動における機密性を維持することを望む場合が多い。プライバシーを維持することは,典型的には,追加の中間における人を必要とし,本発明に従って解決され,及び/または,取り除かれるような,全ての追加的な相手当事者によるリスクを加えることになる。さらに,CDIネットワークの機密性を維持することは,典型的には,各トランザクションに付加時間を加えてもよい様々なトランザクションのマスク手続を用いることを必要とする。取引業者が迅速な応答を求める流動性の高い市場において自身の代わりに価格合意を希望する場合には,時間は,これらのトランザクションにおける主要な障壁となることはよく知られている事項である。しかしながら,市場状況が参加者のうちの一人に反して動く場合には,様々な支払い方法について待機することに含まれる時間的影響は,相殺される取引を生じるかもしれない。
[0045] ここで全般的に図を,特に図1と2を参照すると,ここで開示されている発明は,所与の取引について,合意の時間及び最初の実績を,決済の時間から分離する方法を利用することが示され,それにより取引業者が,上記の問題を克服することを可能にする。同時に,この取引方法は,当事者が取引の全ての要素の完了に基づいて決済の保証とともに実行することを可能とする。」)

ウ.「[0058] Referring now generally to the Figures, and particularly to FIG. 4 , FIG. 4 is a network diagram of an electronic communications network 400 (hereinafter, “the 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 first private ledger 402 may be any type of private ledger known in the art, including, but not limited to a financial institution such as a bank, a credit union or a securities brokerage, a domain name registrar, and/or a holder of a portfolio of mortgages or other financial securities. 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] ここで全般的に図を,特に図4を参照すると,図4は,電子コミュニケーションネットワーク400(以下,“ネットワーク”)のネットワーク図であり,第1のプライベートレジャー402,第2のプライベートレジャー404,パブリックレジャー406,典型的な第1のユーザデバイス408,典型的な第2のユーザデバイス410,インターネット411,複数のモジュール412.A?412.Eを含むトランザクションシステム412,そしてタイトルレジストリーサーバ414を含むものである。第1のプライベートレジャー402は,従来知られているどのようなタイプのプライベートレジャーであるかもしれず,銀行のような金融機関に限定されるものではなく,信用組合や,保証仲買業,ドメインネームレジスタ,そして/または,モーゲージや他の金融的保証のポートフォリオホルダーをも含むものである。パブリックレジャー406は,好ましくはCFIネットワークであり,そして,多くのノードN.1?N.Nを複数含むであろうし,それらは各々,好ましくは同じパブリックレジャーの複製,例えば,アクセス可能なブロックチェーンBC.01?BC.NまたはビットコインのブロックチェーンBTC.01?BTC.Nを,維持し動的に更新する。」)

エ.「[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. The process chart describes a process by which one or more (in this instance, two) individuals may exchange a cryptocurrency for fiat currency, which process may be facilitated by a private ledger 402 , in this instance, a bank. In the first step, a first user Alice of the first user device 408 applies a first applications software 500 (hereinafter “first user app” 500 ) and a second user Bob of the second user device 410 applies a second applications software 502 (hereinafter “second user app” 502 ) to mutually agree upon and enable execution of a transfer of assets for funds.」
(当審訳:「[0064] ここで全般的に図を,特に図5を参照すると,図5は,発明である方法の好ましい実装を記述したプロセスチャートである。そのプロセスチャートは,それによって,1人またはそれ以上(この実体では2)の個人が,暗号化された通貨を認可された通貨に交換するであろうプロセスについて記述しており,そのプロセスは,プライベートレジャー402,この事例では銀行,によって,容易になるであろう。第1のステップにおいて,第1のユーザデバイス408の第1のユーザであるアリスは,第1のアプリケーションソフトウェア500(以下,“第1のユーザアプリ”500)を導入し,第2のユーザデバイス410の第2のユーザであるボブは,第2のアプリケーションソフトウェア502(以下,“第2のユーザアプリ”502)を導入して,互いに合意し,ファンドのための資産の移動を実行できるようにするだろう。」)

オ.「[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 of (当審注:「of」は誤記と解される。)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, and t (当審注:「t」は誤記と解される。)the first private ledger 402 advances to step 10.26 , wherein the bank dash 1000 executes alternate processes.
[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. In step 10.26 the first private ledger 402 executes alternate processes.」
(当審訳:「[0074] ここで全般的に図を,特に図10を参照すると,図10は,発明である方法の追加的観点のフローチャートであり,それによって,手続きが,ファンドの転送の範囲で,または,“バンクダッシュ”1000が,第1のプライベートレジャー402の範囲で,実行される。方法である発明のある好ましい実施例では,第1のプライベートレジャー402は,金融機関,例えば銀行によって維持される。ステップ10.02では,第1のコントラクト130が生成される。ステップ10.04では,第1のコントラクト130は,第1のユーザデバイス408の電子デバイスに転送される。ステップ10.06では,第1のプライベートレジャー402は,第1のユーザデバイス408の署名がそこに添付された第1のコントラクト130を受信するだろう。ステップ10.08では,第1のプライベートレジャー402は,そのコントラクトをローカルストレージに保存する。ステップ10.10では,第1のプライベートレジャー402は,要求されたトランザクションのための信用及び支払いシステム412.Dからの信用承認を要求する。ステップ10.12では,第1のプライベートレジャー402は,信用及び支払いシステム412.Dから承認を受信したか否かを判断する。ステップ10.12での判断が否の場合には,トランザクションは破棄され,第1のプライベートレジャー402は,ステップ10.26に進み,そこでは,バンクダッシュ1000は,代わりのプロセスを実行する。
[0075] それに対し,ステップ10.12での判断が正の場合には,第1のプライベートレジャー402は,第1のコントラクトを自身や,第2のプライベートレジャー404,かつ/または,パブリックレジャー406に,ステップ10.16において書き込む。ステップ10.18において,第1のプライベートレジャー402は,パブリックトランザクション,または,パブリックトランザクションに関連したイベントがパブリックレジャー406に発生したか否かを判断する。ステップ10.18での判断が否の場合には,第1のプライベートレジャー402はステップ10.22へと始めて,そして,パブリックトランザクションが発生するまで待機する。それに対し,ステップ10.18での判断が正の場合には,第1のプライベートレジャー402はステップ10.22に進み,そこで第1のプライベートレジャー402は,パブリックレジャー406,第2のプライベートレジャー404,または第1のプライベートレジャー402のいずれかに保持された勘定を支払う。ステップ10.24において,第1のプライベートレジャー402は,支払保証モジュール412.Cからの支払保証を記録する。ステップ10.26において,第1のプライベートレジャー402は代わりの処理を実行する。」)

上記ア.ないしオ.の記載から,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。

「モジュールが,2つまたはそれ以上の当事者間の取引リクエストに基づく検証可能かつ客観的な条件を伴ったコントラクト/信用保証を生成し用い,さらに,デジタル暗号化されたネットワーク手段を監視するための方法であって,
電子コミュニケーションネットワークは,第1のプライベートレジャー,第2のプライベートレジャー,パブリックレジャー,第1のユーザデバイス,第2のユーザデバイス,インターネット,複数のモジュールを含むトランザクションシステム,及び,タイトルレジストリーサーバを含み,
パブリックレジャーは,多くのノードを複数含み,それらは各々,例えば,アクセス可能なブロックチェーンまたはビットコインのブロックチェーンである同じパブリックレジャーの複製を維持し動的に更新するものであり,
第1のユーザデバイスの第1のユーザが,第1のアプリケーションソフトウェアを導入し,第2のユーザデバイスの第2のユーザが,第2のアプリケーションソフトウェアを導入して,互いに合意し,ファンドのための資産の移動を実行できるようにするものであって,
第1のコントラクトが生成され,
第1のコントラクトが第1のユーザデバイスの電子デバイスに転送され,
第1のプライベートレジャーが,第1のユーザデバイスの署名がそこに添付された第1のコントラクトを受信し,
第1のプライベートレジャーが,そのコントラクトをローカルストレージに保存し,
第1のプライベートレジャーが,要求されたトランザクションのための信用及び支払いシステムからの信用承認を要求し,
第1のプライベートレジャーが,信用及び支払いシステムから承認を受信したか否かを判断し,当該判断が否の場合には,トランザクションが破棄され,当該判断が正の場合には,第1のプライベートレジャーは,第1のコントラクトを自身や,第2のプライベートレジャー,かつ/または,パブリックレジャーに書き込み,
第1のプライベートレジャーが,パブリックトランザクション,または,パブリックトランザクションに関連したイベントがパブリックレジャーに発生したか否かを判断し,当該判断が否の場合には,第1のプライベートレジャーは,パブリックトランザクションが発生するまで待機し,当該判断が正の場合には,第1のプライベートレジャーは,パブリックレジャー,第2のプライベートレジャー,または第1のプライベートレジャーのいずれかに保持された勘定を支払い,
第1のプライベートレジャーが,支払保証モジュールからの支払保証を記録する,
方法。」

2.引用文献2について
原査定の拒絶理由に引用された,特開2010-237731号公報(以下,「引用文献2」という。)には図面とともに次の事項が記載されている。

カ.「【0033】
次に,この様な決済システム21を用いて取引をする例を以下示す。
【0034】
まず,利用者11はATM22に取引開始41の操作をすると同時にICカード23をATM22に入れる。それによりATM22はICカード読み込み42を行うが,その後必要に応じて決済が必要な各種取引の操作を行う。そこでICカード23に予めデータとして保持している各承認者のメールアドレスを含んだ承認者リストを取り込んでそれをATM22にて利用者11に対して承認者リスト表示43を行う。
【0035】
利用者11は,ATM22の承認者リスト表示43に基づいて承認者選択44をATM22を操作することにより行う。ATM22では,利用者11からの承認者選択44がされると,決済が必要な取引情報と承認者のメールアドレス送信45を決済システム21に行う。この場合,決済システム21内ではその情報伝達部31にて取引情報と承認者のメールアドレス送信45を受信し,情報処理部32に送る。これにより決済システム21内の情報処理部32では承認者12に承認の可否を求めるメール作成46を行い,情報伝達部31により承認者12へメール送信47を行う。
【0036】
メール送信47を受信した承認者12は,端末25を用いてネットワーク24を介して決済システム21にサーバー接続49を行い,決済の可否の操作を行う。承認する場合で説明すれば,承認者12は端末25を用いて口座番号と暗証番号入力50を決済システム21に送る。決済システム21内ではこの口座番号と暗証番号入力50を情報伝達部31で受け取り,認証部33に送る。認証部33では適宜データベース35とアクセスし,暗証番号確認51を行い,確認で出来たなら承認者確認52を行い,この結果を情報処理部32および決済部32に送る。以下暗証番号確認51と承認者確認52が両方確認された場合で説明すれば,情報処理部53では取引完了メールを作成し,情報伝達部31にて取引完了メール送信53を利用者11および承認者12に対して送信する。以上の動作が終了した場合,情報処理部32にて認証部33から送られた認証結果をもとに情報処理部から送られた取引情報に基づいてデータベース35に適宜アクセスを行って決済部34で決済を行い,取引完了54処理を行う。」

キ.「【0045】
また,この決済システムは,承認者に選ばれたメールアドレスに取引情報(利用者名,振込先名,取引金額)が記載されたメールを作成し,送信を行うのが一般的であるが,他の構成も可能である。
【0046】
この場合,メールには,取引内容と取引承認を行うためのURLを記載する構成が考えられる。この場合,メール受信者である承認者は該当のURLに接続し,口座番号と暗証番号を入力することで取引を承認とすることとなる。なお,URLへの接続,情報の伝達には暗号化された通信方式を用いるのが好ましい。
・・・(中略)・・・
【0051】
以上の説明において,承認を行う第三者は,複数でも良いが,複数の人物が承認を行う場合は,全員の承認を取引の必須条件としても良く,また,複数の人物が承認を行う場合は,承認を得た人物や数によって,振込み額を変化させても良い。」

したがって,上記引用文献2には次の技術事項(以下,「引用文献2技術事項」という。)が記載されていると認められる。

「決済システム21を用いて取引をする方法であって,
利用者11が,ATM22の承認者リスト表示43に基づいて承認者選択44をATM22を操作することにより,決済システム21内の情報処理部32で,承認者12に承認の可否を求めるメール作成46を行い,情報伝達部31により承認者12へメール送信47を行い,
メール送信47を受信した承認者12は,端末25を用いてネットワーク24を介して決済システム21にサーバー接続49を行い,決済の可否の操作を行い,承認する場合には,承認者12は端末25を用いて口座番号と暗証番号入力50を決済システム21に送り,
決済システム21内ではこの口座番号と暗証番号入力50を情報伝達部31で受け取り,認証部33において,暗証番号確認51と承認者確認52が両方確認された場合には,決済部34で決済を行うものであり,
複数の人物が承認を行う場合は,複全員の承認を取引の必須条件としても良く,また,承認を得た人物や数によって,振込み額を変化させても良い,
方法。」

3.引用文献3について
原査定の拒絶理由に引用された,特開2007-316959号公報(以下,「引用文献3」という。)には図面とともに次の事項が記載されている。

ク.「【課題を解決するための手段】
【0008】
本発明では,ATMおよび金融機関の窓口処理における金銭振り込みにおいて,顧客は予め第三者による振り込み承認者を設定しておく。また,第三者による承認が必要となる振り込み金額の閾値を設定しておく。加えて,振り込み処理が完了した時および承認者が振り込みを承認しなかった時に通知される顧客の連絡先も設定しておく。
【0009】
こうすることにより,閾値以上の金額を口座に振り込む場合には,第三者による振り込み承認処理が必要となる。この結果,第三者によって振り込み先口座の照査,および振り込み金額の照査が行われる。
【0010】
なお,閾値未満の金額を口座に振り込む場合には,第三者による振り込み承認処理は必要なく,直ちに該当口座へ振り込み処理が行われる。
【0011】
本発明の第三者への振り込み承認要求通知手段は,Eメール,携帯電話等の即座に対応可能な方法を用いることができ,顧客が振り込みを行うと,Eメールならば,承認者のメールアドレスへ承認要求を求めるメールが送付され,携帯電話ならば,承認者の登録電話番号へ承認要求を求める電話が入る。どの場合にも,振り込みを行う顧客名,振り込み先口座,振り込み先名称,振り込み金額等有用な情報を通知する。
【0012】
承認要求のために通知された情報が妥当なものであった場合,承認者はATMや銀行窓口で振り込み承認を行うことができる。
【0013】
承認入力方法は,承認者IDとパスワードとの組み合わせによるものや,手のひら静脈認証や指静脈認証等による生体認証技術を使用したものを利用することが好ましい。
【0014】
本発明は,ATMや銀行窓口での振り込み承認の他に,Eメールでの返信,電話での応答,Webサイト等を利用しての振り込み承認が可能である。
【0015】
Eメールでの返信による振り込み承認を行う場合や,Webサイトを利用して振り込み承認を行う場合には,承認者IDとパスワードとの組み合わせ入力によるものや,事前に登録しておいたPC,携帯端末機器等の限定された端末からの承認入力のみを有効とすることが好ましい。
【0016】
電話での応答による振り込み承認の場合には,承認者IDとパスワードとの組み合わせ入力によるものや,声紋判定技術を利用することが好ましい。
【0017】
本発明の第三者による承認者は,予め複数人を登録しておくことができる。承認者を一人のみ登録した場合には,その承認者一人が承認すればよい。承認者を複数人登録した場合には,そのうちの一人のみ承認すればよい設定にもできるが,複数人または全ての承認者が承認しなければならない設定にもできる。例えば,承認者がすぐに対応できないことが想定される場合には,複数人を登録しておき,そのうちの一人が承認すればよい設定にしておくことが好ましい。
【0018】
本発明では,複数人の承認者を設定した場合には,承認者への承認要求順序を設定することが可能である。優先順序を設定した場合には,最初に最高位の承認者に承認要求通知が行われ,その承認者が予め設定された時間までに承認を行わなかった場合に,次の順位の承認者に承認要求通知が行われる。その承認者が予め設定された時間までに承認を行わなかった場合,その下位の承認者に承認要求通知が行われる。こうすることにより,最終的には一人の承認のみでよく,かつ,承認者が不在の場合でも,次に権限のある者が承認を行うことができる。
【0019】
第三者の承認者が振り込みを承認した場合には,該当口座への振り込み処理が行われ,振り込みした顧客と第三者の承認者へ振り込み手続き完了通知が行われる。」

したがって,上記引用文献3には次の技術事項(以下,「引用文献3技術事項」という。)が記載されていると認められる。

「ATMおよび金融機関の窓口処理における金銭振り込みを行わせる方法であって
顧客が振り込みを行うと,Eメールとして,承認者のメールアドレスへ承認要求を求めるメールが送付され,
承認要求のために通知された情報が妥当なものであった場合,承認者はATMや銀行窓口で振り込み承認を行うものであって,当該承認は,ATMや銀行窓口での振り込み承認の他に,Eメールでの返信を利用しての振り込み承認が可能であり,
上記承認者は,予め複数人を登録しておくことができ,承認者を一人のみ登録した場合には,その承認者一人が承認すればよく,また,承認者を複数人登録した場合には,そのうちの一人のみ承認すればよい設定にもできるが,複数人または全ての承認者が承認しなければならない設定にもでき,例えば,承認者がすぐに対応できないことが想定される場合には,複数人を登録しておき,そのうちの一人が承認すればよい設定にしておくことが好ましいものであり,
第三者の承認者が振り込みを承認した場合には,該当口座への振り込み処理が行われ,振り込みした顧客と第三者の承認者へ振り込み手続き完了通知が行われる,
方法。」

4.引用文献4について
原査定の拒絶理由に引用された,特開2016-170530号公報(以下,「引用文献4」という。)には図面とともに次の事項が記載されている。

ケ.「【0002】
近年,円やドルといった現実の貨幣による物品の取引だけでなく,電子マネー等の仮想通貨を用いた商取引が行われている。非特許文献1には,ビットコインと呼ばれる仮想通貨を用いて取引を行う技術について開示されている。
ビットコインによる取引では,ハッシュ関数と公開鍵暗号方式とを用いて,取引データの完全性が担保されている。暗号化を用いて行われた取引(以下,ビットコインの取引を「トランザクション」とも呼ぶ)は,ビットコインを利用する全端末に対してブロードキャストで配信される。配信されたトランザクションは,マイナー(発掘者)と呼ばれる端末ソフトウェアによって正当性が検証され,承認されると発掘されたブロックにまとめられ,ブロックチェーンと呼ばれる台帳に記録される。」

5.引用文献5について
原査定の拒絶理由に引用された,特開2016-208347号公報(以下,「引用文献5」という。)には図面とともに次の事項が記載されている。

コ.「【0045】
図11は,著作物データが埋め込まれたトランザクションTXをブロードキャストする様子を示す図である。図11に示すように,トランザクションTXが分散ネットワーク内にブロードキャストされた後,分散ネットワーク内の端末装置20のうちいずれかの装置は,直近のブロックの生成時刻から現ブロックの生成を開始する時刻までの間に蓄積したトランザクションTXをまとめて1つのブロックに生成する。これによって,分散ネットワーク内の端末装置20が記憶するブロックチェーンが更新される。なお,トランザクションTXからブロックを生成する処理に時間を要するため,ブロックチェーンの更新には,ある程度(例えば10分程度)の遅延が生じる。すなわち,著作物保護支援装置100は,ユーザから時刻認証の要求を受けてから,時刻認証が完了するまで遅延時間を要する。」

6.引用文献6について
原査定の拒絶理由に引用された,特許第6042011号公報(以下,「引用文献6」という。)には図面とともに次の事項が記載されている。

サ.「【0077】
ブロックチェーン技術とは,例えば,非特許文献2に記載されているように,ある金融業務に関する取引内容を示すトランザクションを,連続性が担保されているブロックと呼ばれる情報に格納し,参加者全員にブロードキャストし,受け取ったブロックをそれまでのブロックで構成されるブロックチェーンに基づき検証し,正当性が得られたブロックに含まれるトランザクションに基づき,取引を実行する技術である。」

7.引用文献7について
原査定の拒絶理由に引用された,特開2009-163472号公報(以下,「引用文献7」という。)には図面とともに次の事項が記載されている。

シ.「【0090】
次に,フローチャートおよび画面の例を参照して,予約者からの予約の受付の処理を説明する。
【0091】
図4は,ユーザAである予約者からの予約を受け付ける,サーバ11による予約者受付の処理の例(第1の実施の形態)を説明するフローチャートである。
【0092】
ステップS11において,予約受付処理部107は,Webサーバ機能101に,インターネット12を介して,宿泊の予約を行うための画面(以下,宿泊予約申込画面と称する)を表示させる宿泊予約画面データを,ユーザAの端末装置14である端末装置14-1に送信させる。すなわち,Webサーバ機能101は,通信部59に,インターネット12を介して,端末装置14-1宛てに宿泊予約画面データを送信させる。
【0093】
図5は,宿泊予約画面データを受信した端末装置14-1に表示される宿泊予約申込画面の例を示す図である。
【0094】
宿泊予約申込画面には,予約しようとする宿泊施設A乃至宿泊施設Nのいずれかの名前,シングルまたはツインなどの予約する部屋のタイプを示す部屋タイプ,宿泊施設A乃至宿泊施設Nのいずれかに手続きして入室する日付を示すチェックイン,泊施設A乃至宿泊施設Nのいずれかから,料金を精算して,引き払う日付を示すチェックアウト,宿泊を予約する人数を示す申込人数,予約する部屋の数を示す申込部屋数,および料金が表示される。
【0095】
図5の宿泊予約申込画面の例において,○○ホテル大宮である,宿泊施設A乃至宿泊施設Nのいずれかの名前,ツインである部屋タイプ,2007年10月11日(木)であるチェックイン,2007年10月12日(金)であるチェックアウト,2人(大人:2人 子供:0人)である申込人数,1部屋である申込部屋数,17000円である料金が表示されている。
【0096】
また,宿泊予約申込画面には,予約者の情報を入力するためのフィールドが配置されている。すなわち,宿泊予約申込画面には,予約者の住所の郵便番号を入力するフィールド,予約者の住所を入力するフィールド,予約者の氏名を入力するフィールド,予約者の電話番号を入力するフィールド,および予約者のメールアドレスを入力するフィールドが配置されている。
【0097】
さらに,宿泊予約申込画面には,いますぐクレジットカードで決済するか,または宿泊するとき現地で決済するかを選択するラジオボタンが配置されている。
【0098】
予約者は,宿泊予約申込画面のそれぞれのフィールドに,郵便番号,住所,氏名,電話番号,メールアドレスをそれぞれ入力し,決済の方法を指定するラジオボタンのいずれかを選択して,通常の予約をする場合には,通常の予約を指示するボタン(例えば,図5の下側の2つのボタンのうちの左側の”予約する”と記載されているボタン)をクリックし,同伴者の承認を得た後に予約をする場合には,同伴者の承認を得た後の予約(以下,同伴者承認後予約と称する)を指示するボタン(例えば,図5の下側の2つのボタンのうちの右側の”同伴者承認後予約する”と記載されているボタン)をクリックする。
【0099】
通常の予約を指示するボタンがクリックされると,端末装置14-1は,通常の予約を示す情報と共に,宿泊予約申込画面のそれぞれのフィールドに入力された,郵便番号,住所,氏名,電話番号,およびメールアドレスからなる,予約者の情報を,インターネット12を介してサーバ11に送信する。
【0100】
一方,同伴者承認後予約を指示するボタンがクリックされると,端末装置14-1は,同伴者承認後予約を示す情報と共に,宿泊予約申込画面のそれぞれのフィールドに入力された,郵便番号,住所,氏名,電話番号,およびメールアドレスからなる,予約者の情報を,インターネット12を介してサーバ11に送信する。
【0101】
なお,宿泊予約申込画面に,後からクレジットカードで決済することを指示するラジオボタンを設けて,後からクレジットカードで決済することを選択できるようにしてもよい。例えば,後からクレジットカードで決済することが選択され,同伴者承認後予約が指示された場合,同伴者の承認が得られた時点においてクレジットカードで決済するようにすれば,後述するように,予約をやり直す場合であっても,決済の処理が簡単になる。
【0102】
ステップS12において,予約受付処理部107は,Webサーバ機能101に,インターネット12を介して端末装置14-1から送信されてくる,宿泊予約申込画面から入力された情報を受信させる。すなわち,Webサーバ機能101は,通信部59に,インターネット12を介して端末装置14-1から送信されてくる,宿泊予約申込画面から入力された情報を受信させる。
【0103】
Webサーバ機能101は,受信した情報を予約受付処理部107に供給する。
【0104】
ステップS13において,予約受付処理部107は,端末装置14-1において入力され,送信されてきた情報を参照して,同伴者承認後予約であるか否かを判定し,同伴者承認後予約であると判定された場合,手続きは,ステップS14に進み,予約受付処理部107は,Webサーバ機能101に,インターネット12を介して,同伴者の情報を入力するための画面(以下,同伴者情報入力画面と称する)を表示させるデータである同伴者情報入力画面データを,ユーザAの端末装置14である端末装置14-1に送信させる。
【0105】
言い換えれば,ステップS14において,Webサーバ機能101は,通信部59を制御して,インターネット12を介して,同伴者情報入力画面データを端末装置14-1に送信する。
【0106】
図6は,同伴者情報入力画面データを受信した端末装置14-1に表示される同伴者情報入力画面の例を示す図である。
【0107】
同伴者情報入力画面には,同伴者の情報を入力するためのフィールドが配置されている。すなわち,同伴者情報入力画面には,同伴者の氏名を入力するフィールド,同伴者のメールアドレスを入力するフィールド,および予約者から同伴者へのメッセージを入力するフィールドが配置されている。
【0108】
同伴者承認後予約を継続する場合には,予約者は,同伴者情報入力画面のそれぞれのフィールドに,同伴者の氏名,同伴者のメールアドレス,および同伴者へのメッセージをそれぞれ入力し,同伴者承認後予約の処理の継続を指示するボタン(例えば,図6の下側の2つのボタンのうちの右側の”同伴者承認後予約する”と記載されているボタン)をクリックする。
【0109】
以下,同伴者が,ユーザBである場合を例に説明する。
【0110】
宿泊予約申込画面に戻る場合には,予約者は,宿泊予約申込画面への戻りを指示するボタン(例えば,図6の下側の2つのボタンのうちの左側の”戻る”と記載されているボタン)をクリックする。
【0111】
宿泊予約申込画面への戻りを指示するボタンがクリックされると,端末装置14-1は,宿泊予約申込画面への戻りを指示する情報をインターネット12を介してサーバ11に送信する。サーバ11が,端末装置14-1から,宿泊予約申込画面への戻りを指示する情報を受信すると,サーバ11による予約者受付の処理は,ステップS11に戻る。
【0112】
一方,同伴者承認後予約の処理の継続を指示するボタンがクリックされると,端末装置14-1は,同伴者情報入力画面のそれぞれのフィールドに入力された,同伴者の氏名,同伴者のメールアドレス,および同伴者へのメッセージからなる,同伴者の情報と共に,同伴者承認後予約の処理の継続を指示する情報をインターネット12を介してサーバ11に送信する。
【0113】
ステップS15において,予約受付処理部107は,Webサーバ機能101に,インターネット12を介して端末装置14-1から送信されてくる,同伴者情報入力画面のそれぞれのフィールドに入力された,同伴者の氏名,同伴者のメールアドレス,および同伴者へのメッセージからなる情報と共に,同伴者承認後予約の処理の継続を指示する情報を受信させる。Webサーバ機能101は,受信した情報を予約受付処理部107に供給する。
【0114】
予約受付処理部107のURL発行部121は,今回の同伴者承認後予約の特定のURLを発行する。また,予約受付処理部107は,同伴者承認後予約を特定する予約IDに対応付けて,URL発行部121で発行されたURL,被予約宿泊施設の名前,予約する部屋のタイプを示す部屋タイプ,被予約宿泊施設に手続きして入室する日付を示すチェックイン,泊施設A乃至宿泊施設Nのいずれかから,料金を精算して,引き払う日付を示すチェックアウト,宿泊を予約する人数を示す申込人数,予約する部屋の数を示す申込部屋数,料金,予約者の郵便番号,予約者の住所,予約者の氏名,予約者の電話番号,予約者のメールアドレス,同伴者の氏名,同伴者のメールアドレス,および同伴者へのメッセージを同伴者承認後予約データベース106に格納する。
【0115】
ステップS16において,予約受付処理部107は,メール生成部105に,同伴者であるユーザBに対し,承認を促すメール(以下,承認メールと称する)を生成させ,メール送信制御部104に,生成された承認メールを送信させる。
【0116】
この場合,メール生成部105は,予約受付処理部107からの指示に応じて,同伴者承認後予約データベース106から,同伴者承認後予約を特定する予約ID,URL,予約者の氏名,同伴者の氏名,同伴者のメールアドレス,および同伴者へのメッセージを読み出して,承認を促す承認メールを生成する。そして,メール送信制御部104は,メール生成部105において生成された承認メールを,インターネット12を介して通信部59に送信させる。
・・・(中略)・・・
【0122】
図4に戻り,ステップS17において,予約受付処理部107は,同伴者承認後予約の対象となる部屋を確保して,サーバ11による予約者受付の処理は終了する。すなわち,予約受付処理部107は,宿泊予約データベース103に,同伴者承認後予約の対象となる部屋の予約の状態として,部屋の確保を示す情報を格納させる。
【0123】
より詳しく説明すれば,予約受付処理部107は,宿泊予約データベース103に,被予約宿泊施設,日付,および部屋番号で特定される,同伴者承認後予約の対象となる部屋の情報に対応させて,部屋の確保を示す情報を格納させる。
【0124】
一方,ステップS13において,同伴者承認後予約でないと判定された場合,通常の予約なので,手続きは,ステップS18に進み,予約受付処理部107は,通常の予約処理を行い,サーバ11による予約者受付の処理は終了する。この場合,予約受付処理部107は,宿泊予約データベース103に,被予約宿泊施設,日付,および部屋番号で特定される,通常の予約の対象となる部屋の情報に対応させて,部屋の予約を示す情報を格納する。
・・・(中略)・・・
【0160】
以上のように,宿泊などのサービスの提供についての予約者による予約であって,そのサービスの提供を受けようとする承認者の承認が求められる予約を受け付けて,承認者に予約の承認を求める承認画面を表示させるための承認画面データを送信し,承認画面から承認者が予約を承認したか否かに応じて予約についての承認の処理を行うようにしたので,予約者が単独で予約し,予約者とは別に,承認者がその予約を承認することができ,サービスの提供を複数人で受ける場合であっても,簡単に予約することができる。
【0161】
例えば,予約者が複数のサービスの提供について予約し,承認者が,最も好ましい,そのうちの1つについて承認するようにすれば,最終的に,承認者から承認された予約のサービスが提供されることになり,事前に,予約者と承認者が好みなどの調整を行わなくとも,簡単に,予約者と承認者の双方が好むサービスを受けることができるようになる。
【0162】
また,予約者が宿泊施設を確保した後に,同伴者に確認し,同伴者が予約を承認した場合に即座に予約を確定することで,例えば,予約者が宿泊施設を調べた後,同伴者に確認を取るまでのタイムログでその宿泊施設が予約不可能になったりすることもない。さらに,同伴者が承認しなかった場合には部屋が開放されるので,他のユーザが予約を行うことも可能となり,旅行代理店側としても効率がよい。」

ス.「【0205】
なお,商品の購入に3人以上が関係する場合またはサービスの提供を3人以上で受ける場合,全員が承認するか,半数が承認するか,または1人が承認することによって,予約を確定させたり,予約を維持させたりすることができる。」

したがって,上記引用文献7には次の技術事項(以下,「引用文献7技術事項」という。)が記載されていると認められる。

「予約者からの予約の受付の処理を行う方法であって,
予約者は,宿泊予約申込画面のそれぞれのフィールドに,郵便番号,住所,氏名,電話番号,メールアドレスをそれぞれ入力し,決済の方法を指定するラジオボタンのいずれかを選択して,通常の予約を指示するボタンをクリックすると,端末装置は,予約者の情報を,インターネットを介してサーバに送信し,
予約受付処理部は,Webサーバ機能に,インターネットを介して端末装置から送信されてくる,宿泊予約申込画面から入力された情報を受信し,
予約受付処理部は,端末装置において入力され,送信されてきた情報を参照して,同伴者承認後予約であるか否かを判定し,同伴者承認後予約であると判定された場合,同伴者の情報を入力するための画面を表示させ,
同伴者承認後予約の処理の継続を指示するボタンがクリックされると,端末装置は,同伴者情報入力画面のそれぞれのフィールドに入力された,同伴者の氏名,同伴者のメールアドレス,および同伴者へのメッセージからなる,同伴者の情報と共に,同伴者承認後予約の処理の継続を指示する情報をインターネットを介してサーバに送信し,
予約受付処理部は,メール生成部に,同伴者であるユーザBに対し,承認を促すメール(承認メール)を生成させ,メール送信制御部1に,生成された承認メールを送信させ,
予約受付処理部107は,同伴者承認後予約の対象となる部屋を確保して,サーバ11による予約者受付の処理は終了する,ものであって
商品の購入に3人以上が関係する場合またはサービスの提供を3人以上で受ける場合,全員が承認するか,半数が承認するか,または1人が承認することによって,予約を確定させたり,予約を維持させたりすることができる,
方法。」

8.引用文献8について
原査定の拒絶理由に引用された,特開2009-169914号公報(以下,「引用文献8」という。)には図面とともに次の事項が記載されている。

セ.「【0061】
(メンバー追加処理のフローチャート)
次に,図12のフローチャートと,図13?15の表示画面の例を参照して,本発明の実施形態に係るグループメンバーの追加処理工程を説明する。以下の例では,招待される者(被招待者:Y)も既に本サービスへのユーザ登録が完了しており,ユーザIDが付与されているものとする。また,図12では,図面の煩雑を避けて説明を簡略化するために,参加の承認を求めるグループのメンバーを1人だけ(B)表示している。ここで,図13は招待者であるユーザ(A)の端末4に表示される画面の例,図14は,グループのメンバーであるユーザ(B)の端末4に表示される画面の例,図15は,被招待者であるユーザ(Y)の端末4に表示される画面の例を夫々示している。
【0062】
まず,グループに所属するメンバー(招待者ユーザA)が,他のユーザ(被招待者Y)をそのグループに参加させたい場合は,図6(A)のグループトップページで「友達を呼ぶ」45を選択して,図13(A)のメンバー追加画面を表示させる。この画面で,被招待者Yのニックネーム,コメント(承認依頼文),ユーザID,及びメールアドレスを各入力欄63?66に入力して送信ボタン67を押すと(ステップS1),前記メンバーリクエスト受付手段30がその情報を取得して,メンバー追加申込を受け付ける(ステップS2)。ここで,ニックネームはメールアドレス等と異なりユニーク情報ではないため,単独では被招待者を特定できない。そのため,ニックネームを入力させる場合には,該当するニックネームのユーザを所属グループやユーザID等と共に一覧表示させて,ユーザ(招待者)に選択させるのが好ましい。
【0063】
メンバー追加申込を受け付けると,図13(B)の確認画面が表示され,この画面で招待者が「送信する」ボタン68を押すと,前記グループ情報更新手段32が被招待者Yを当該グループに仮登録すると共に(ステップS3),招待者Aのユーザ端末4に図13(C)の仮登録完了画面を表示させる(ステップS4)。また,前記通知手段31が,グループIDに基づいて前記グループ情報格納部22から全ての所属メンバー(B)とメールアドレスを検索し(ステップS5),メンバー総数(n0)をメモリにセットする。次いで,この通知手段31が,招待者A及び被招待者Yのニックネームと,招待者Aが図13(A)のメンバー追加画面で入力した承認依頼文と,メンバー追加承認待ち一覧画面(図14(A))のURLと,を含む承認依頼メールを生成して全てのメンバーのアドレス宛に送信する(ステップS6)。また,グループ情報更新手段32が,グループ情報格納部22の各メンバーのフィールド(図4の「un_appr_flg」)に「承認待ち」フラグ:1を設定する。これにより,メンバーがマイページ(図5(B))にアクセスすると,「メンバー追加承認待ち」40が表示される(ステップS7)。
【0064】
メンバーBが,送信されたメールに含まれるURLをクリックするか,マイページから前記「承認待ち」40を選択すると,図14(A)のメンバー追加承認待ち一覧画面が表示される。この画面で,メンバーBが「承認する」ボタン69か「承認しない」ボタン70を押すと(ステップS8),メンバー追加承認確認画面(図14(B)参照)が表示される(ステップS9)。この画面で,メンバーBが「確認」ボタン71を押すと,メンバー追加承認結果画面(図14(C)に遷移すると共に,この承認結果が本システム1に送信される(ステップS10)。なお,図14(B)(C)は,「承認する」場合を示しているが,「承認しない」場合も同様の画面が表示される。
【0065】
そして,前記グループ情報更新手段32が,グループ情報格納部22の当該メンバーBの項目に登録されていた前記承認待ちフラグを削除して前記承認待ちリストから除外する(ステップS11)。これにより,このメンバーBについては,図14(A)のメンバー追加承認待ち一覧から当該グループの承認待ちが削除される。
【0066】
受信した回答が「承認」である場合は(ステップS12のNｏ),「承認人数(n1)」に1を加算する(n1→n1+1)。これらの処理(ステップS10?S12)を,メンバー全員から回答を受信するまで(n1=n0)継続する(ステップS13)。
【0067】
メンバー全員から承認されると(ステップS13のYeｓ),通知手段31が招待者A及び被招待者Yのニックネームとグループ名と図15(B)の招待グループ一覧画面のURLを含む招待メール(図15(A))を生成し,被招待者Yのメールアドレス宛に送信する(ステップS14)。また,被招待者Yのマイページ(図5(B)参照)において,「グループに招待されています!」41が表示される(ステップS15)。このように,メンバー全員の承認がない限り被招待者Yには何も通知されないため,被招待者Yは何れかのメンバーによって招待が承認されなかったとしても,それを知ることもない。
【0068】
被招待者Yが,マイページから,若しくは前記招待メールのURLから図15(B)の入力画面にアクセスし,「参加する」ボタン72か「参加しない」ボタン73を押し,かつ図15(C)の確認画面で「送信」ボタン74を押すと,図15(D)の結果確認画面が表示される(ステップS17)。図15(C)(D)は,「参加する」場合を示しているが,「参加しない」場合も同様の画面が表示される。
【0069】
また,本システム1が被招待者Yからの回答を受信し,ユーザ情報更新手段27に受け渡す(ステップS18)。受信した回答が「参加する」である場合は(ステップS19のYeｓ),ユーザ情報更新手段27は,グループ情報格納部22において被招待者Yについて登録されていた仮登録フラグ(図4の「tmp_reg_flg」)を削除してユーザ情報格納部21及びグループ情報格納部22に登録年月日を登録し本登録に移行する(ステップS20)。また,通知手段31が,招待者Aを含むメンバー全員に,図13(D)及び図14(D)に示すメンバー追加通知メールを送信する(ステップS21,S22)。また,被招待者Yにも,グループのトップページのURLを含む「メンバー登録完了メール」(図15(E))が送信される。
【0070】
一方,上記ステップS10でメンバーBから受信した回答が「承認しない」であった場合には(ステップS12のYeｓ),前記グループ情報更新手段32が,「非承認人数(n2)」に1を加算する(n2→n2+1)。本発明は,グループメンバーの全員の承認を条件にしているため,この非承認人数(n2)が1になった時点で被招待者Yはグループに招待されず,グループ情報格納部22の仮登録も削除される(ステップS23)。ただ,メンバー全員や被招待者Yからの回答を受信するのに十分な期間を置かずに「被招待者は不参加」の結果が通知されると,招待者Aが,承認しなかったメンバーを予測できたり,何れかのメンバーが承認しなかったことを認識できる可能性がある。そのため,非承認の回答を受信した(n2=1,2…)時点では直ちに非承認結果を通知せず,メンバー全員や被招待者Yからの回答を受信するのに十分な期間の経過を待って,「承認結果」を送信するのが好ましい。
【0071】
また,上記ステップS18で受信した被招待者Yからの回答が「参加しない」である場合は(ステップS19のNｏ),グループメンバーによる非承認と同様に,グループ情報格納部22の仮登録フラグ:1を削除して(ステップS23),招待者Aを含むグループメンバー全員に「承認結果」を送信する(ステップS21,S22)。この場合の「承認結果」は,図13(E)及び図14(E)に示すように,被招待者Yが参加しなかった理由がメンバーの非承認によるものか被招待者Yの拒否によるものかを特定できないような文面になっている。そのため,招待者や承認したメンバーは,被招待者Yがグループに追加されなかったという結果しか知ることはできない。これにより,メンバー同士及び被招待者とメンバーの間の人間関係を損なうことがない。また,被招待者Yにも,確認のため,同様の「承認結果」が送信される(図15(F)参照)。」

したがって,上記引用文献8には次の技術事項(以下,「引用文献8技術事項」という。)が記載されていると認められる。

「グループメンバーの追加のための方法であって
グループに所属するメンバー(招待者ユーザA)が,他のユーザ(被招待者Y)をそのグループに参加させたい場合に,グループトップページで「友達を呼ぶ」を選択して,メンバー追加画面を表示させ,この画面で,被招待者Yのニックネーム,コメント(承認依頼文),ユーザID,及びメールアドレスを各入力欄に入力して送信ボタンを押すと,前記メンバーリクエスト受付手段がその情報を取得して,メンバー追加申込を受け付け,
通知手段が,招待者A及び被招待者Yのニックネームと,招待者Aがメンバー追加画面で入力した承認依頼文と,メンバー追加承認待ち一覧画面のURLと,を含む承認依頼メールを生成して全てのメンバーのアドレス宛に送信し,
メンバーBが,送信されたメールに含まれるURLをクリックするか,マイページから前記「承認待ち」を選択すると,メンバー追加承認待ち一覧画面が表示され,この画面で,メンバーBが「承認する」ボタンか「承認しない」ボタンを押すと,メンバー追加承認確認画面が表示され,この画面で,メンバーBが「確認」ボタンを押すと,メンバー追加承認結果画面に遷移すると共に,この承認結果が本システムに送信され,
メンバー全員から承認されると,通知手段が招待者A及び被招待者Yのニックネームとグループ名との招待グループ一覧画面のURLを含む招待メールを生成し,被招待者Yのメールアドレス宛に送信し,それによって,被招待者Yのマイページにおいて,「グループに招待されています!」が表示される,ものであり,
グループメンバーの全員の承認を条件にしているため,この非承認人数が1になった時点で被招待者Yはグループに招待されない,
方法。」

9.引用文献9について
原査定の拒絶理由に引用された,特開2009-230257号公報(以下,「引用文献9」という。)には図面とともに次の事項が記載されている。

ソ.「【0014】
〔第1実施形態〕
以下,図面を用いて本発明の実施形態を説明する。本発明の承認システムは,図1に示すように,端末Cが通信ネットワーク(以下,ネットワークと称する)Nを介して,サーバSと接続されている。前記ネットワークNは,企業や学校等の限られた施設内において情報を物理的に送るケーブルと,LANスイッチやハブ等でなる中継機器を備えたCSMA/CD(Carrier Sense Multiple Access with Collision Detection)方式のイーサネット(Ethernet)(商標)型のLANとして構成されたものであるが,このネットワークNとしてイーサネット型のLAN以外に,インターネットの技術を用いたイントラネットで構築されたものや,WAN(Wide Area Network)の技術によって構築されるものでも良い。
【0015】
サーバSは,汎用コンピュータ1で構成されており,ディスプレイ2,入力機器3(キーボード3a,マウス3b)を備えている。また,端末Cは,コンピュータ本体4で構成されており,ディスプレイ5,および入力機器6(キーボード6a,マウス6b)が接続されている。
【0016】
図2は,本発明の承認システムを構成するサーバSと端末Cの機能ブロック図を示している。操作者の使用する端末C(以下,操作者端末Cｏと称する)は,ネットワークNを介してサーバSと様々な情報を送受信するためのネットワークI/F10,端末Cにおける様々な操作を表す操作情報を生成し,サーバSに送信する操作情報生成部11,サーバSからの操作の承認結果を受信する承認可否受信部12を備えている。
【0017】
通常,操作情報生成部11,および承認可否受信部12は,その処理を実行する手段(プログラムやモジュール等)がハードウェアに読み込まれることでその処理が実行されるが,これらをハードウェアとの組み合わせにより構成しても良いし,ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【0018】
操作情報生成部11は,操作者端末Cｏにおいて行われる操作を検知し,検知した操作が所定の操作であれば操作情報を生成し,ネットワークI/F10およびネットワークNを介して,操作情報をサーバSに送信している。なお,本実施形態において,操作情報には,少なくとも操作の対象であるファイルを特定可能なファイル識別情報および端末Cを特定可能な端末識別情報が含まれている。なお,ファイル識別情報として,ファイル名,ファイルの絶対パス,ファイルのハッシュ値や個々のファイルに排他的に割り振られた数字等を用いることができ,端末識別情報として,端末名,IPアドレス,MACアドレス,個々の端末Cに排他的に割り当てられた数字等を用いることができる。また,所定の操作とはファイルの保存,移動,削除等をいうが,他の操作を所定の操作としても構わない。また,操作情報の生成のタイミングは,上述のタイミングに限定されるものではなく,操作が行われたタイミング等,他のタイミングで生成しても構わない。この場合には,生成した操作情報が所定の操作であればサーバSに送信される,又は逐次サーバSに送信し,サーバSにおいて所定の処理であるか否かが判定される構成とすることができる。
【0019】
承認可否受信部12は,サーバSからの承認結果をネットワークI/F10を介して取得し,承認結果に基づく制御を実行する。
【0020】
承認者の使用する端末C(以下,承認者端末Caと称する)は,ネットワークNを介してサーバSと様々な情報を送受信するためのネットワークI/F30,サーバSからの承認依頼を受信する承認依頼受信部31,承認依頼受信部31により受信された承認依頼に対する承認の可否をサーバSに送信する承認可否送信部32を備えている。
【0021】
通常,承認依頼受信部31および承認可否送信部32は,その処理を実行する手段(プログラムやモジュール等)がハードウェアに読み込まれることでその処理が実行されるが,これらをハードウェアとの組み合わせにより構成しても良いし,ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【0022】
なお,各端末Cは,操作者端末Cｏおよび承認者端末Caの機能部を備えることにより,操作者端末Cｏおよび承認者端末Caのいずれとしても機能することができる。
【0023】
サーバSは,ネットワークNを介して端末Cと様々な情報を送受信するためのネットワークI/F20,操作者端末Cｏから送信される操作情報を取得する操作情報取得部21,操作に係る承認者のユーザ識別情報を少なくとも含む承認者情報を取得し,その承認者に対して承認依頼を送信する承認依頼部22,承認を依頼した承認者からの承認結果(以下,承認者承認結果と称する)を受信する承認結果受信部23,承認者情報および承認結果に基づく集計を行い,集計結果を生成する集計部24,操作情報および集計結果に基づき操作の承認可否(以下,判定承認結果と称する)を判定する承認可否判定部25,承認可否判定部25の判定承認結果に基づき所定の制御を行う制御部26を備えている。
【0024】
通常,操作情報取得部21,承認依頼部22,承認結果受信部23,集計部24,承認可否判定部25,および制御部26は,その処理を実行する手段(プログラムやモジュール等)がハードウェアに読み込まれることでその処理が実行されるが,これらをハードウェアとの組み合わせにより構成しても良いし,ロジック等を組み合わせたハードウェアのみで構成しても構わない。
【0025】
操作情報取得部21は,ネットワークNおよびネットワークI/F20を介して操作者端末Cｏから送信される操作情報を取得し,取得した操作情報を承認依頼部22に送る。
【0026】
承認依頼部22は,操作情報取得部21から操作情報を取得し,その操作情報に含まれるファイル識別情報に基づき,ファイル操作に対する承認者のユーザ識別情報を含む承認者情報を取得し,その承認者に対して承認依頼を送信する。また,取得した承認者情報は,操作情報と共に集計部24に渡される。なお,本実施形態における承認者情報には少なくとも承認者を特定可能なユーザ識別情報を含んでおり,ユーザ識別情報とは,ユーザ名やその他ユーザを一意に特定可能なユーザ毎に排他的に割り振られた数字等を用いることができる。
【0027】
承認結果受信部23は,承認依頼部22から送信された承認依頼に対する承認者承認結果を受信し,受信した承認者承認結果を逐次集計部24に渡している。
【0028】
集計部24は,承認依頼部22から操作情報および承認者情報を取得し,承認結果受信部23からは逐次承認者承認結果を受け取っており,所定の条件を満たした際に,承認者情報および承認者承認結果に基づき集計を行い,集計結果を生成する。生成された集計結果は,操作情報と共に承認可否判定部25に渡される。このように,所定の条件を充足した際に集計部24を機能させる構成とすることにより,全承認者からの承認者承認結果の受信を待つ必要がなくなるため,迅速な承認の可否決定が可能となる。なお,本実施形態では,所定の条件として,承認依頼部22から承認依頼が送信されてからの経過時間,承認結果受信部23が受信した承認者承認結果の件数,承認依頼部22により特定された承認者の数に対する承認結果受信部23が受信した承認者承認結果の件数の割合等を用いるが,他の条件を用いて構わない。
【0029】
承認可否判定部25は,集計部24から取得した操作情報および集計結果に基づき操作に係る承認の可否を判定する。承認可否判定部25は,承認の可否を判定する際に,操作情報に基づき,承認の可否を判定する閾値THを変更する構成とすると好適である。例えば,操作情報に係る操作の内容,操作情報に係る操作の対象であるファイルの機密度や操作情報に係る操作者の権限に基づき,閾値THを変更する。具体的には,操作の内容がコピーのように元のファイルに対する影響が小さい場合や,ファイルの機密度が低い場合,操作者がそのファイルの作成者である等の場合には,閾値THを低く設定し,承認が得られやすくし,逆に操作の内容がファイルの削除のように元のファイルに対する影響が大きい場合,ファイルの機密度が高い場合や操作者の権限が低い場合などには,閾値THを高く設定し,承認が得られにくくする。このようにして,判定された判定承認結果は,操作情報と共に制御部26に渡される。
【0030】
承認可否判定部25から操作情報および判定承認結果を取得した制御部26は,操作情報に含まれる端末識別情報を有する操作者端末Cｏに対して,判定承認結果に基づく制御を指示する。
【0031】
次に,図3のフローチャートを用いて,本発明の承認システムの処理の流れを説明する。まず,操作者端末Cｏにおいて操作者により操作が行われると操作情報生成部11により検知され(#01),所定の操作か否かが判定される(#02)。この操作が,所定操作の場合には(#02のYes分岐),操作情報生成部11により操作が保留されると共に,操作情報が生成される(#03,#04)。生成された操作情報は,ネットワークI/F10を介してネットワークNに送出される。ネットワークNに送出された操作情報は,ネットワークI/F20を介して,操作情報取得部21により取得される(#05)。
【0032】
操作情報を取得した操作情報取得部21は,取得した操作情報を承認依頼部22に渡す。操作情報取得部21から操作情報を取得した承認依頼部22は,操作情報に含まれるファイル識別情報に基づき,操作情報に係る操作に対する承認を依頼すべき承認者を特定する。本実施形態では,承認者テーブル(図示せず)にファイル識別情報と承認者のユーザ識別情報とが関連付けて管理されており,ファイル識別情報をキーとして承認者テーブルを検索することにより承認者を特定することができるものとするが,他の方法により承認者を特定しても構わない。例えば,承認者テーブルに各ユーザのユーザ識別情報と関連付けて,部署やグループ等の所属情報が管理されており,操作者端末Cｏの操作者と同じ部署やグループのユーザを承認者とする。この場合には,操作情報に操作者のユーザ識別情報が含まれており,それを利用することができる。
【0033】
承認依頼部22は,同時に,上述のように特定された承認者の権限を取得する。本実施形態では,操作情報に係る操作の対象としてのファイルに対して,各々のユーザの権限が設定されており,権限テーブル(図示せず)に管理されているものとする。したがって,権限テーブルに対して,ファイル識別情報とユーザ識別情報をキーとして検索することにより,権限を取得することができる。もちろん,他の方法により権限を取得しても構わない。例えば,承認者テーブルに各ユーザのユーザ識別情報と関連付けて役職や勤続年数が管理されており,これらの情報に基づき権限を決定する。また,各々のユーザの権限をファイル毎に異ならせるのではなく,固定的に設定しておいても構わない。なお,本発明においては,権限は必須ではないため,権限を取得せずとも以降の処理を行うことは可能である。
【0034】
また,本実施形態では,資産情報テーブル(図示せず)に,ユーザ識別情報と端末識別情報とが関連付けて管理されているため,ユーザ識別情報をキーとして資産情報テーブルを検索することにより,端末Cを特定することができる。すなわち,上述の処理により特定された承認者のユーザ識別情報に基づき,当該承認者の承認者端末Caを特定することができる。もちろん,他の方法により端末Cを特定しても構わない。なお,承認者端末Caを特定することに代えて,承認者のメールアドレス等の承認者の連絡先を特定しても構わない。メールアドレスを用いた場合には,メールを用いて承認を依頼することができる。
【0035】
承認依頼部22は,このようにして得られた承認者のユーザ識別情報,権限,および承認者端末Caの端末識別情報とから承認者情報を生成し(#08),集計部24に渡す。
【0036】
承認依頼部22は,同時に,承認依頼情報を取得し,上述の処理により特定された承認者に対して,承認依頼として送信する(#09)。本実施形態では,承認依頼情報には,少なくとも,承認依頼に係るファイル識別情報が含まれている。
【0037】
承認依頼部22から承認依頼を受信した承認依頼受信部31は,承認者に対して,承認依頼情報に含まれるファイル識別情報を有するファイルに対する操作の承認依頼を受信した旨を通知し,承認の可否の入力を促す。このとき,ダイアログウィンドウ等を表示し,承認の可否を入力可能に構成すると,承認者の負担が軽減でき,好適である。また,承認依頼情報に承認依頼に係る操作の内容を含めておき,承認者に通知する構成とすると,承認者が,いかなる操作に対して承認を求められているかを認識できるため好適である。
【0038】
承認者が,これに対して承認の可否を入力すると,承認可否送信部32により承認の可否が承認者承認結果としてサーバSに送信され,承認結果受信部23により承認者承認結果が受信される(#10)。承認者承認結果を受信した承認結果受信部23は,逐次承認者承認結果を集計部24に渡す。
【0039】
承認結果受信部23から承認者承認結果を取得した集計部24は,所定の条件が充足されたか否かを監視しており(#11),所定の条件が充足されるまで,承認結果受信部23からの承認者承認結果を取得し続ける(#11のNo分岐)。一方,所定の条件が充足されると(#11のYes分岐),集計部24は,承認依頼部22から取得した承認者情報と承認結果受信部23から取得した承認者承認結果に基づく集計を行い,集計結果を生成する(#12)。
・・・(中略)・・・
【0041】
集計部24から操作情報および集計結果を取得した操作可否判定部25は,これらに基づき操作の可否を判定する。操作可否判定部25は,まず,操作情報に基づき閾値THを決定する(#13)。本実施形態では,閾値THは,上述したように,操作情報から得られる,操作の内容,ファイルの機密度,操作者の権限等に基づき決定されるが,これらに限定されるものではなく,本発明の目的を達成できる範囲において,操作情報に基づき取得できる情報であれば,他の情報に基づき閾値THを決定しても構わない。例えば,操作者の権限に応じて閾値THを下げる等である。操作者がファイルに対して高い権限を持っている場合に,閾値THを下げると,承認が得られやすくなるため,迅速な承認が得られるため好適である。また,承認者に操作者が含まれている場合に,閾値THを変化させても構わない。このような場合に,操作者が承認者に含まれていない場合と同じ閾値THに基づき操作の可否を判定すると,操作者自身が承認者であるにも拘らず,操作が承認されず,操作の遅延を招く恐れがある。そのため,操作者が承認者に含まれている場合には,閾値THを下げることにより,操作の承認を得られやすくすると好適である。
【0042】
次に,承認可否決定部25は,このようにして決定された閾値THと集計結果を比較することにより,最終的な承認の可否を判定し(#14),判定承認結果として操作情報と共に制御部26に渡す。
【0043】
上述の処理により判定された判定承認結果と操作情報を取得した制御部26は,操作情報に含まれている端末識別情報に基づき操作者端末Cｏを特定し,特定した操作者端末Cｏに対して,判定承認結果を送信する(#15)。
【0044】
制御部26から判定承認結果を受け取った承認可否受信部12は,判定承認結果が許可であれば,保留していた操作を実行する。一方,判定結果が不許可であれば,保留していた操作は破棄される(#16)。」

したがって,上記引用文献9には次の技術事項(以下,「引用文献9技術事項」という。)が記載されていると認められる。

「承認システムにおける処理方法であって,
操作者端末Cｏにおいて操作者により所定の操作が行われると,操作情報が生成され,
操作情報を取得した操作情報取得部は,取得した操作情報を承認依頼部に渡し,
承認依頼部は,操作情報に含まれるファイル識別情報に基づき,操作情報に係る操作に対する承認を依頼すべき承認者を特定し,
承認依頼部は,得られた承認者のユーザ識別情報,権限,および承認者端末Caの端末識別情報とから承認者情報を生成し,同時に,承認依頼情報を取得し,特定された承認者に対して,承認依頼として送信し,
承認依頼部から承認依頼を受信した承認依頼受信部は,承認者に対して,承認依頼情報に含まれるファイル識別情報を有するファイルに対する操作の承認依頼を受信した旨を通知し,承認の可否の入力を促し,
承認者が,これに対して承認の可否を入力すると,承認可否送信部により承認の可否が承認者承認結果としてサーバに送信され,承認結果受信部により承認者承認結果が受信され,
承認結果受信部から承認者承認結果を取得した集計部は,所定の条件が充足されたか否かを監視し,所定の条件が充足されるまで,承認結果受信部からの承認者承認結果を取得し続け,所定の条件が充足されると,集計部は,承認依頼部から取得した承認者情報と承認結果受信部から取得した承認者承認結果に基づく集計を行い,集計結果を生成し,
集計部から操作情報および集計結果を取得した操作可否判定部は,これらに基づき操作の可否を判定し,
制御部から判定承認結果を受け取った承認可否受信部は,判定承認結果が許可であれば,保留していた操作を実行する,
方法。」

10.引用文献10について
原査定の拒絶理由に引用された,特開2009-301189号公報(以下,「引用文献10」という。)には図面とともに次の事項が記載されている。

タ.「【0046】
次に,前述のステップ208で実行する承認処理の動作について説明する。図7は,承認処理の流れの一例を示すフローチャートである。
【0047】
承認処理では,まず,仮登録・更新通知部17が文書管理システムのシステム管理者に仮登録・更新があった旨を通知する(ステップ281)。この通知は,例えば,仮登録・更新通知部17が図8(a)に示すような内容のメールをシステム管理者に送信することで行われる。システム管理者は,通常,文書に対する承認の権限を有さず,また,機密文書等のシステム管理者であってもアクセスすることが好ましくない文書が登録されることもあるため,システム管理者向けの通知には,文書の内容にかかわる記載は無く,システム管理者は,セキュリティの観点からのみ,承認と非承認の判断を行う。
【0048】
また,システム管理者が承認と非承認の判断を行う場合,その判断材料として文書の登録・更新要求を行った情報処理装置21-1等の利用環境を通知に含めるようにすることもできる。利用環境は,登録・更新部14が文書の登録・更新要求とともに受け付ける,または,文書の登録・更新要求を受け付ける際に取得するもので,オペレーティングシステムの種別やバージョン,利用しているアプリケーションソフトウェア(例えば,ウェブブラウザ)の種別やバージョン等がある。この場合にシステム管理者に送信されるメールは,例えば,図8(b)に示すように,利用環境が含まれることとなる。
【0049】
仮登録・更新通知部17が文書管理システムのシステム管理者に仮登録・更新があった旨を通知した結果,システム管理者が文書管理装置10にアクセスし,仮登録・更新承認部18に対して「承認」の応答を行うと(ステップ282でYES),これを受けた仮登録・更新通知部17が,文書の登録または更新を要求した登録者と承認者に,仮登録・更新があった旨を通知する(ステップ283)。この通知は,例えば,仮登録・更新通知部17が図9に示すような内容のメールを承認者に送信することで行われる。承認者は,例えば,図10に示すように,登録者となるユーザに対しての承認者が予め設定されており,この承認者は,文書の登録・更新を許可する権限を有する者である。登録者と承認者は,いずれも,文書の内容についても確認することができる権限を有するため,登録者と承認者が文書管理装置10にアクセスし,仮登録・更新承認部18に対して応答を行う際,仮登録・更新承認部18は,必要に応じて文書仮登録リポジトリ16から該当する文書を取得して登録者や承認者に提示する。
【0050】
その結果,登録者と承認者の両者から「承認」の応答が得られると(ステップ284でYES),これを受けた仮登録・更新反映部19は,文書仮登録リポジトリ16に仮登録・更新されている該当文書を文書リポジトリ15に正規に登録・更新し,仮登録・更新を本登録・更新として反映し(ステップ285),承認処理を終了する。
【0051】
一方,仮登録・更新反映部19は,システム管理者の承認を得られなかった場合や(ステップ282でNO),登録者と承認者の少なくとも一方から承認を得られなかった場合には(ステップ284でNO),文書仮登録リポジトリ16に仮登録・更新されている該当文書の反映を却下し(ステップ286),承認処理を終了する。
【0052】
なお,承認者には,グループを設定したり,複数の者を設定したりすることもでき,この場合には,いずれか一人の承認,全員の承認,一定の人数以上の承認,承認者数が非承認者数よりも多い,承認者が一定数以上でかつ非承認者数が一定する以下であるなど,様々な条件を仮登録・更新の本登録・更新へ反映する際に判断基準として利用することができる。
【0053】
また,承認者を登録者に対して設定するのではなく,文書に対して承認者を設定したり,登録者と文書の両者に設定することも可能である。」

したがって,上記引用文献10には次の技術事項(以下,「引用文献10技術事項」という。)が記載されていると認められる。

「承認処理のための方法であって,
仮登録・更新通知部が文書管理システムのシステム管理者に仮登録・更新があった旨を通知し,
システム管理者が文書管理装置にアクセスし,仮登録・更新承認部に対して「承認」の応答を行うと,これを受けた仮登録・更新通知部が,文書の登録または更新を要求した登録者と承認者に,仮登録・更新があった旨を通知し,
登録者と承認者の両者から「承認」の応答が得られると,これを受けた仮登録・更新反映部は,文書仮登録リポジトリに仮登録・更新されている該当文書を文書リポジトリに正規に登録・更新し,仮登録・更新を本登録・更新として反映し,承認処理を終了する,ものであって,
承認者には,グループを設定したり,複数の者を設定したりすることもでき,この場合には,いずれか一人の承認,全員の承認,一定の人数以上の承認,承認者数が非承認者数よりも多い,承認者が一定数以上でかつ非承認者数が一定する以下であるなど,様々な条件を仮登録・更新の本登録・更新へ反映する際に判断基準として利用することができる,
方法。」


第5 対比・判断

1.本願発明1について

(1)引用発明に対する進歩性について

ア.対比
本願発明1と引用発明とを対比する。

引用発明は,「第1のプライベートレジャーが,第1のユーザデバイスの署名がそこに添付された第1のコントラクトを受信し」た後に,「第1のプライベートレジャーが,信用及び支払いシステムから承認を受信したか否かを判断し」,「当該判断が正の場合には,第1のプライベートレジャーは,第1のコントラクトを自身や,第2のプライベートレジャー,かつ/または,パブリックレジャーに書き込み」,次いで,「第1のプライベートレジャーが,パブリックトランザクション,または,パブリックトランザクションに関連したイベントがパブリックレジャーに発生したか否かを判断し」,「当該判断が正の場合には,第1のプライベートレジャーは,パブリックレジャー,第2のプライベートレジャー,または第1のプライベートレジャーのいずれかに保持された勘定を支払」うものであり,この場合の「第1のコントラクト」の転送は,「勘定」の「支払」を実行させるための処理依頼といえることから,引用発明における当該「第1のコントラクト」のパブリックレジャーへの書き込みのための転送は,本願発明1における「トランザクション」の送信に相当するといえ,また,引用発明において「第1のユーザデバイスの署名」が上記「第1のコントラクト」に添付されて転送されることも,本願発明1において「トランザクションの電子署名」が「トランザクション」とともに送信されることに相当するといえ,さらに,転送の契機について,引用発明における「信用及び支払いシステムからの信用承認」は,本願発明1における「承認」に相当するといえる。
また,引用発明の「パブリックレジャー」は,「多くのノードを複数含み,それらは各々,例えば,アクセス可能なブロックチェーンまたはビットコインのブロックチェーンである同じパブリックレジャーの複製を維持し動的に更新するものであ」るから,本願発明1の「ブロックチェーンネットワーク」に相当する構成を有するといえ,また,引用発明は,上記「パブリックレジャー」の中に「ブロックチェーン」及びそれを構成する「ブロック」に相当する構成をも有するといえる。そして,上述のとおり,引用発明の「第1のコントラクト」の転送は,「勘定」の「支払」を実行させるための処理依頼であるから,引用発明も,「第1のコントラクト」及び「第1のユーザデバイスの署名」の転送によって,“トランザクションを実行する”ものであるといえる。
そうすると,後記する点において相違するものの,本願発明1の「受信した前記承認信号の承認に基づき,前記トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし,前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順」と,引用発明の「第1のプライベートレジャーが,第1のユーザデバイスの署名がそこに添付された第1のコントラクトを受信し」た後に,「第1のプライベートレジャーが,信用及び支払いシステムから承認を受信したか否かを判断し」,「当該判断が正の場合には,第1のプライベートレジャーは,第1のコントラクトを自身や,第2のプライベートレジャー,かつ/または,パブリックレジャーに書き込み」,次いで,「第1のプライベートレジャーが,パブリックトランザクション,または,パブリックトランザクションに関連したイベントがパブリックレジャーに発生したか否かを判断し」,「当該判断が正の場合には,第1のプライベートレジャーは,パブリックレジャー,第2のプライベートレジャー,または第1のプライベートレジャーのいずれかに保持された勘定を支払」うことは,“承認に基づき,トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークに送信することによって,前記トランザクションを実行する手順”である点において共通するといえる。

上記の対比によれば,本願発明1と引用発明とは次の点で一致し,そして相違する。

[一致点]
承認に基づき,トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークに送信することによって,前記トランザクションを実行する手順を含む信号処理方法。

(相違点a)
本願発明1は,「複数のノードにより構成されるグループにおいて共有されるデータに対するトランザクションの実行に対する承認要求信号を前記複数のノードの少なくとも一つに送信する手順」を有するのに対し,
引用発明は,そのような手順を有することは特定されていない点。

(相違点b)
本願発明1は,「前記承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノードより承認信号を受信する手順」を有するのに対し,
引用発明は,そのような手順を有することは特定されていない点。

(相違点c)
承認に基づき,トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークに送信することによって,前記トランザクションを実行する手順に関し,
本願発明1では,「承認」が「受信した承認信号」の承認であり,トランザクションおよび前記トランザクションの電子署名の「送信」が「ブロードキャスト」であり,かつ,トランザクションおよび前記トランザクションの電子署名をブロックチェーンネットワークに送信した後に,「トランザクションに関する情報を含むブロックをブロックチェーンに追加」し,それによって前記トランザクションを実行するという手順となっているのに対し,
引用発明では,そのような特定はされていない点。

イ.相違点についての判断
事案に鑑みて,上記相違点b及びcについて先に検討する。

本願発明1の「受信した前記承認信号の承認に基づき,前記トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし,前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する手順」との記載における,「トランザクション」とともに「ブロードキャスト」され,その後の「トランザクションに関する情報を含むブロック」の「ブロックチェーン」への「追加」及び「トランザクション」の「実行」に用いられる,「電子署名」が,具体的にどのようなものを含むかについては,請求項の記載のみからは必ずしも明らかではないものの,本願明細書の,

「 【0026】
2.3 承認要求(S102)
トランズアクションが作成されたのち,トランズアクションの承認段階へ移行する。具体的には図4に示すように,第1の通信端末110_1は,承認要求信号をユーザグループ内の他のユーザが保有する通信端末110へ送信する(S120)。・・・(中略)・・・図4では,第1の通信端末110_1を除く通信端末110のすべてに承認要求信号が送信される例が示されているが,後述するように,通信端末110のうちの一部に承認要求信号を選択的に送信してもよい。また,第1の通信端末110_1に対して自己送信してもよい。
・・・(中略)・・・
【0028】
2.4 承認(S104)
トランズアクションを受信した通信端末110のユーザは,トランズアクションを承認する,あるいは承認しないという行為のいずれかを選択する(S104)。承認が選択された場合,承認するユーザ(ここでは便宜上,第2のユーザとする)の保有する通信端末(ここでは便宜上,第2の通信端末とする)110_2内で生成される秘密鍵114_2によってトランズアクションが暗号化され,電子署名ES2が生成される ・・・(中略)・・・
【0040】
例えば第1の通信端末110_1は,受信した承認信号に含まれる電子署名の数が承認条件を満たすか否かを判断する。承認条件が満たされたと判断された場合,トランズアクション,電子署名ES1,および受けとった電子署名をブロックチェーンネットワーク130へブロードキャストする(S128)。・・・(後略)
【0041】
ブロードキャストが行われたのち,トランズアクションの検証が行われる。図5(A)に示すように,ブロックチェーンネットワーク130の各ノード132の記憶装置には,これまでにブロードキャストされた過去のトランズアクションをまとめたブロック140が格納されている。これらのブロック140は生成順に連結されて時系列を作る。新たなトランズアクションはブロックチェーンネットワーク130内で検証され,トランズアクションの正当性が確認されると,このトランズアクションを含む新たなブロック140が生成される。新たにに生成されたブロック(図5(A)ではブロック140_3)は,これまでに生成されたブロック(ブロック140_1,ブロック140_2)に連結され,これによりブロックチェーンの更新が行われ,トランズアクションが実行される。
【0042】
通信端末110からブロードキャストされた各電子署名は,ノード132において対応する公開鍵を用いて復号化される。復号化されて生成されるトランズアクションとオリジナルのトランズアクションを照合することで,トランズアクションの正当性がノード132によって判断される。またノード132は,承認条件が満たされているかどうかを検証する。例えばブロードキャストされた電子署名の数がトランズアクションに記される承認条件に適合する,すなわち,署名に必要な電子署名の数と同一以上であることを検証する。あるいは,ブロードキャストされた電子署名が,トランズアクションで規定される承認権限者の電子署名であるか否かを検証する。この検証プロセスの結果トランズアクションが正当であり,かつ,承認条件が満たされていると判断されたのち,ブロックチェーンの更新が開始される。」

との記載を踏まえると,他のユーザから受信した承認信号に含まれる電子署名(ES2)と,自己が生成または自己に送信した電子署名(ES1),の両方を指すものと解することができ,これは,上記第2の1.における補正の却下の決定での「電子署名ES2以外のブロードキャストされた電子署名(例えば電子署名ES1)」についての指摘に対する審判請求書での主張とも整合するものであり,そうすると,相違点cに係る構成によれば,本願発明1は,承認信号の承認に基づくE1とE2を含む「電子署名」がトランザクションとともにブロードキャストされると,それにより,「トランザクションに関する情報を含むブロックをブロックチェーンに追加」することがなされ,トランザクションの実行がなされるという構成となっているといえる。
また,相違点bに係る構成によれば,本願発明1は,承認のための上記承認信号を,「承認要求信号を受信した前記複数のノードのうちの一定割合に相当するノード」,すなわち,「データ」を「共有」する「グループ」を構成する「複数のノード」の中で「承認要求信号」を受信する「ノード」の,さらに「一定割合に相当するノード」のみから受信する構成となっており,当該「一定割合に相当するノード」から受信した「承認信号」の承認に基づき,上記相違点cに係る構成のとおり,E1とE2を含む「電子署名」がブロードキャストされ,それにより,ブロックのブロックチェーンへの追加がなされ,トランザクションの実行がなされることになる。
そして,上記相違点b及びcに係る構成を備えることで,本願発明1は,「承認権限を持たないユーザも共有されるデータに対してどのような処理が行われうるかを知ることができる」(本願明細書の段落【0036】)との効果を奏しているものと解される。

それに対し,引用発明は,「パブリックレジャー」へ転送される「第1のユーザデバイスの署名」が,具体的にどのような署名を含み,「パブリックレジャー」内の「ブロックチェーン」に対する処理にどのように寄与しているのか何ら特定されていないから,上記相違点cに係る構成について開示も示唆もされていない。承認についても,常に「信用及び支払いシステム」から受信するよう構成されており,それによって,当事者間の取引において,機密性及びプライバシーを維持しつつ,時間的影響から来る問題を克服する,という効果(上記第4の1.イ.)を奏しているものと解されることから,上記相違点bに係る構成についての開示も示唆もない。
また,引用発明において,上記「信用及び支払いシステム」からの承認を,ノードに相当する取引に関し共有関係にあるユーザのうち一定割合からの承認信号による承認に変更することは,上記効果を損うことからして引用発明に動機付けがあるとはいえず,また,単なる設計変更によりなし得たものとすることもできない。
そうすると,引用文献1の他の記載,引用文献2ないし10に記載された事項を参酌しても,引用発明に基づいて,相違点b及びcに係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

そして,上記相違点b及びcに係る本願発明1の構成が,引用発明に開示も示唆もなく,引用文献1の他の記載,引用文献2ないし10に記載された事項を参酌しても,引用発明に基づいて,相違点b及びcに係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえないことは上記に示したとおりである。

したがって,本願発明1は,相違点aを検討するまでもなく,当業者であっても引用発明,引用文献1ないし10に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。

(2)引用文献2,3,7ないし10技術事項に対する進歩性について
原査定の理由に鑑み,引用文献2,3,7ないし10技術事項に対する進歩性についても,以下で検討する。

ア.引用文献2技術事項について
本願発明1と,上記第4の2.における引用文献2技術事項とを対比すると,引用文献2技術事項は,そもそも,承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト,及び,その後のブロックのブロックチェーンへの追加について何ら言及がないことから,少なくとも,本願発明1の構成に関し上記(1)のア.における引用発明との〈相違点c〉と共通する相違点,において相違し,そして,上記(1)のイ.の判断内容も踏まえると,引用文献2の他の記載,引用文献1,3ないし10に記載された事項を参酌しても,引用文献2技術事項に基づいて,上記相違点に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

イ.引用文献3技術事項について
本願発明1と,上記第4の3.における引用文献3技術事項とを対比すると,引用文献3技術事項は,そもそも,承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト,及び,その後のブロックのブロックチェーンへの追加について何ら言及がないことから,少なくとも,本願発明1の構成に関し上記(1)のア.における引用発明との〈相違点c〉と共通する相違点,において相違し,そして,上記(1)のイ.の判断内容も踏まえると,引用文献3の他の記載,引用文献1,2,4ないし10に記載された事項を参酌しても,引用文献3技術事項に基づいて,上記相違点に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

ウ.引用文献7技術事項について
本願発明1と,上記第4の7.における引用文献7技術事項とを対比すると,引用文献7技術事項は,そもそも,承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト,及び,その後のブロックのブロックチェーンへの追加について何ら言及がないことから,少なくとも,本願発明1の構成に関し上記(1)のア.における引用発明との〈相違点c〉と共通する相違点,において相違し,そして,上記(1)のイ.の判断内容も踏まえると,引用文献7の他の記載,引用文献1ないし6,8ないし10に記載された事項を参酌しても,引用文献7技術事項に基づいて,上記相違点に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

エ.引用文献8技術事項について
本願発明1と,上記第4の8.における引用文献8技術事項とを対比すると,引用文献8技術事項は,そもそも,承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト,及び,その後のブロックのブロックチェーンへの追加について何ら言及がないことから,少なくとも,本願発明1の構成に関し上記(1)のア.における引用発明との〈相違点c〉と共通する相違点,において相違し,そして,上記(1)のイ.の判断内容も踏まえると,引用文献8の他の記載,引用文献1ないし7,9,10に記載された事項を参酌しても,引用文献8技術事項に基づいて,上記相違点に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

オ.引用文献9技術事項について
本願発明1と,上記第4の9.における引用文献9技術事項とを対比すると,引用文献9技術事項は,そもそも,承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト,及び,その後のブロックのブロックチェーンへの追加について何ら言及がないことから,少なくとも,本願発明1の構成に関し上記(1)のア.における引用発明との〈相違点c〉と共通する相違点,において相違し,そして,上記(1)のイ.の判断内容も踏まえると,引用文献9の他の記載,引用文献1ないし8,10に記載された事項を参酌しても,引用文献9技術事項に基づいて,上記相違点に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

カ.引用文献10技術事項について
本願発明1と,上記第4の10.における引用文献10技術事項とを対比すると,引用文献10技術事項は,そもそも,承認後のトランザクション及び電子署名のブロックチェーンネットワークへのブロードキャスト,及び,その後のブロックのブロックチェーンへの追加について何ら言及がないことから,少なくとも,本願発明1の構成に関し上記(1)のア.における引用発明との〈相違点c〉と共通する相違点,において相違し,そして,上記(1)のイ.の判断内容も踏まえると,引用文献10の他の記載,引用文献1ないし9に記載された事項を参酌しても,引用文献10技術事項に基づいて,上記相違点に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

(3)まとめ
以上から,本願発明1は,当業者であっても引用文献1ないし10に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。

2.本願発明2-8について
本願発明2ないし4は,本願発明1を更に限定したものであるので,同様に,当業者であっても引用文献1ないし10に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。
また,本願発明5は,本願発明1を別のカテゴリーで表現するものであり,同様に,当業者であっても引用文献1ないし10に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。
また,本願発明6ないし8は,本願発明5をそれぞれ更に限定したものであるので,同様に,当業者であっても引用文献1ないし10に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。


第6 原査定についての判断

1.特許法第36条第6項第2号(明確性)について
原査定では,請求項1-8に記載された「受信した前記承認信号の承認に基づき,前記トランザクション,および前記トランザクションの電子署名をブロックチェーンネットワークにブロードキャストし,前記トランザクションに関する情報を含むブロックをブロックチェーンに追加することによって前記トランザクションを実行する」は,「することによって・・・する」という部分が日本語として曖昧であり,技術的範囲が不明確である,との理由を示しているが,平成29年9月12日付けの意見書における,「このトランザクション(処理依頼)に関する情報を含むブロックをブロックチェーンに追加する行為がトランザクションの実行を意味します」との主張を踏まえれば,上記「ブロックをブロックチェーンに追加すること」が「トランザクションの実行」を意味することが明確であるから,請求項1-8に係る発明は明確である。
また,原査定では,請求項1-8に記載された「トランザクション」は,送受信可能なデータであるのか,実行可能な処理であるのか不明であるから,技術的内容が不明確である,との理由を示しているが,平成29年9月12日付けの意見書における,『本願明細書においては,トランザクションとは「依頼処理」であり』との主張を踏まえれば,上記「トランザクション」という記載は,「依頼処理」という意味であることが明確であるから,請求項1-8に係る発明は明確である。

2.特許法第29条第2項(進歩性)について
上記「第5 対比・判断」の(1)イ.で検討のとおりであり,したがって,原査定の理由2を維持することはできない。


第7 むすび

以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2018-04-09 
出願番号 特願2017-29730(P2017-29730)
審決分類 P 1 8・ 561- WY (G06F)
P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 金沢 史明  
特許庁審判長 辻本 泰隆
特許庁審判官 須田 勝巳
仲間 晃
登録日 2018-05-25 
登録番号 特許第6341491号(P6341491)
発明の名称 信号処理方法、および信号処理プログラム  
代理人 特許業務法人高橋・林アンドパートナーズ  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ