• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 1項3号刊行物記載 特許、登録しない。 G06Q
審判 査定不服 5項独立特許用件 特許、登録しない。 G06Q
審判 査定不服 2項進歩性 特許、登録しない。 G06Q
管理番号 1391359
総通号数 12 
発行国 JP 
公報種別 特許審決公報 
発行日 2022-12-28 
種別 拒絶査定不服の審決 
審判請求日 2021-04-16 
確定日 2022-11-01 
事件の表示 特願2019−531092「資産移転方法および装置、ならびに電子デバイス」拒絶査定不服審判事件〔令和 1年12月 5日国際公開、WO2019/231952、令和 2年 7月30日国内公表、特表2020−522765〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2019年(令和元年) 5月29日(パリ条約による優先権主張外国庁受理2018年(平成30年) 5月29日、中国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
令和 元年 8月 6日 :翻訳文提出
令和 2年 7月30日付け:拒絶理由通知書
令和 2年 9月17日 :意見書、手続補正書の提出
令和 2年12月11日付け:拒絶査定
令和 3年 4月16日 :審判請求書、手続補正書の提出

第2 令和3年4月16日にされた手続補正についての補正の却下の決定
[補正の却下の決定の結論]
令和3年4月16日にされた手続補正(以下「本件補正」という。)を却下する。

[理由]
1 本件補正について
(1)本件補正により、特許請求の範囲の請求項1の記載は、次のとおり補正された(下線部は、補正箇所である。)。
「資産を移転するためのコンピュータで実行される方法であって、
ブロックチェーン内のブロックチェーンノードによって、前記ブロックチェーンに関連付けられたブロックチェーンメンバーに資産を移転するための資産移転要求を検出するステップであって、前記資産が、指定されたブロックチェーン資産タイプのものであり、かつ前記ブロックチェーンの指定されたアンカーによって発行され、前記指定されたアンカーが、等価値のオフチェーン資産を前記指定されたブロックチェーン資産タイプの資産に変換するように構成される、ステップと、
前記ブロックチェーン内の異なるアンカーに対して前記ブロックチェーンメンバーによって構成された異なる最大信用資産限度を含む記録されたデータに基づいて、最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず、かつ前記指定された資産タイプに対応していることを、前記ブロックチェーンノードによって決定するステップであって、所与のアンカーおよび所与のブロックチェーン資産タイプに対する最大信用資産限度が、前記所与のブロックチェーン資産タイプの資産の前記最大信用資産限度をオフチェーン資産に変換するための、前記所与のアンカー内の前記ブロックチェーンメンバーの信用を示す、ステップと、
前記最大信用資産限度が、前記指定されたアンカーに対して構成されておらず、かつ前記指定されたブロックチェーン資産に対応するとの、前記ブロックチェーンノードによる決定に応答して、前記ブロックチェーンノードによる前記資産への前記資産移転要求の適用を禁止するステップと、
前記ブロックチェーンノードによって、前記最大信用資産限度が存在すると決定したことに応答して、前記ブロックチェーンメンバーによって構成された前記最大信用資産限度を取得するステップと、
前記資産移転要求によって示される前記資産の第1の額、および前記ブロックチェーンメンバーによってすでに保有され、前記指定されたアンカーによって発行され、前記指定された資産タイプである資産の第2の額を、前記ブロックチェーンノードによって取得するステップと、
前記ブロックチェーンノードによって、前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であるか否かを判定するステップと、
前記ブロックチェーンノードによって、前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であると判定したことに応答して、前記資産移転要求に基づいて資産移転を実行するステップとを含む、
方法。」

(2)本件補正前の特許請求の範囲
本件補正前の、令和2年9月17日にされた手続補正による特許請求の範囲の請求項1の記載は、次のとおりである。
「資産を移転するためのコンピュータで実行される方法であって、
ブロックチェーン内のブロックチェーンノードによって、前記ブロックチェーンに関連付けられたブロックチェーンメンバーに資産を移転するための資産移転要求を検出するステップであって、前記資産が、指定されたブロックチェーン資産タイプのものであり、かつ前記ブロックチェーンの指定されたアンカーによって発行され、前記指定されたアンカーが、等価値のオフチェーン資産を前記指定されたブロックチェーン資産タイプの資産に変換するように構成される、ステップと、
前記ブロックチェーン内の異なるアンカーに対して前記ブロックチェーンメンバーによって構成された異なる最大信用資産限度を含む記録されたデータに基づいて、最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず、かつ前記指定された資産タイプに対応していることを、前記ブロックチェーンノードによって決定するステップであって、所与のアンカーおよび所与のブロックチェーン資産タイプに対する最大信用資産限度が、前記所与のブロックチェーン資産タイプの資産の前記最大信用資産限度をオフチェーン資産に変換するための、前記所与のアンカー内の前記ブロックチェーンメンバーの信用を示す、ステップと、
前記最大信用資産限度が、前記指定されたアンカーに対して構成されておらず、かつ前記指定されたブロックチェーン資産に対応するとの、前記ブロックチェーンノードによる決定に応答して、
前記ブロックチェーンノードによる前記資産への前記資産移転要求の適用を禁止するステップとを含む、
方法。」

なお、本件補正前の請求項2の記載は、次のとおりである。
「前記最大信用資産限度が存在するとき、前記ブロックチェーンメンバーによって構成された前記最大信用資産限度を、前記ブロックチェーンノードによって取得するステップと、
前記資産移転要求によって示される前記資産の第1の額、および前記ブロックチェーンメンバーによってすでに保有され、前記指定されたアンカーによって発行され、前記指定された資産タイプである資産の第2の額を、前記ブロックチェーンノードによって決定するステップと、
前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であるとき、前記資産移転要求が資産移転実施に適用されるのを、前記ブロックチェーンノードによって可能にするステップとをさらに含む、
請求項1に記載の方法。」

2 補正の適否
本件補正は、補正前の請求項1に、補正前の請求項2に記載された事項にさらに「前記ブロックチェーンメンバーによって構成された前記最大信用資産限度」の「取得」が「前記ブロックチェーンノードによって、前記最大信用資産限度が存在すると決定したことに応答して」なされる旨の限定を付加するものであって、当該付加された事項は、当初明細書の段落【0020】〜【0021】、【0028】に記載されているから、新規事項を追加するものではなく、特許法第17条の2第3項に違反するものではない。また、同第4項に違反するものでもない。
また、上記の限定の付加は、発明特定事項を限定するものであるとともに、補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるといえる。よって、本件補正は、特許法17条の2第5項2号に掲げる特許請求の範囲の減縮を目的とするものに該当する。
そこで、本件補正後の請求項1に係る発明(以下、「本件補正発明」という。)が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について、以下、検討する。

(1)本件補正発明
本件補正発明は、上記1(1)に記載したとおりのものである。

(2)引用文献の記載及び引用発明
ア 引用文献1に記載されている事項
原査定の拒絶の理由で引用された本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である、Stellar developers Guides,[online],Stellar Development Foundation,2017年4月15日,全頁,[令和2年7月30日検索],インターネット(以下、「引用文献1」という。)は、「Stellar Network」の開発者向けガイドに関するウェブページであり、当該ウェブページ及び当該ガイドを構成する各見出し部分のリンク先となるウェブページには、以下の事項が記載されている。(なお、下線は当審で付した。)

a 「Stellar Network Overview」に記載されている事項
(a)「Using the Stellar network, you can build mobile wallets, banking tools, smart devices that pay for themselves, and just about anything else you can dream up involving payments! Even though Stellar is a complex distributed system, working with it doesn’t need to be complicated.」
(当審訳:ステラネットワークを使用すると、モバイルウォレット、バンキングツール、自己負担のスマートデバイスなど、支払いに関連して思いつく限りのあらゆるものを構築できます。ステラは複雑な分散システムですが、ステラを用いた作業に複雑さは必要ありません。)

(b)「Big Picture: The Stellar Network
The Stellar network is a worldwide collection of Stellar Cores, each maintained by different people and organizations. The distributed nature of the network makes it reliable and safe.
All these Stellar Cores−the network of nodes−eventually agree on sets of transactions. Each transaction on the network costs a small fee: 100 stroops (0.00001 XLM). This fee helps prevent bad actors from spamming the network.」
(当審訳:全体像:ステラネットワーク
ステラネットワークは、世界中のステラコアの集合体であり、それぞれがさまざまな人々や組織によって維持されています。ネットワークは分散しているため、信頼性と安全性が高くなります。
これらすべてのステラコア(ノードのネットワーク)は、最終的に一連のトランザクションに同意します。ネットワーク上の各トランザクションには、100ストループ(0.00001 XLM)という少額の手数料がかかります。この手数料は、悪意のある人物がネットワークをスパムするのを防ぐのに役立ちます。)

b 「Create an Account」に記載されている事項
「The first thing you’ll need to do anything on the Stellar network is an account. Accounts hold all your money inside Stellar and allow you to send and receive payments−in fact, pretty much everything in Stellar is in some way tied to an account.」
(当審訳:ステラネットワークであなたが最初に行う必要があるのは、アカウントです。アカウントはステラ内であなたのすべてのお金を保持し、あなたの支払いの送受信を可能にします。実際、ステラのほとんどすべてが何らかの形でアカウントに関連付けられています。)

c 「Send and Receive Money」に記載されている事項
(a)「Send Payments
Actions that change things in Stellar, like sending payments, changing your account, or making offers to trade various kinds of currencies, are called operations. In order to actually perform an operation, you create a transaction, which is just a group of operations accompanied by some extra information, like what account is making the transaction and a cryptographic signature to verify that the transaction is authentic.」
(当審訳:支払いの送信
支払いの送信、アカウントの変更、さまざまな種類の通貨の取引のオファーなど、ステラで物事を変更するアクションは、操作と呼ばれます。実際に操作を実行するには、トランザクションを作成します。トランザクションは、トランザクションを実行しているアカウントや、トランザクションが本物であることを確認するための暗号署名など、いくつかの追加情報を伴う操作のグループです。)

(b)「Building a Transaction
Stellar stores and communicates transaction data in a binary format called XDR. Luckily, the Stellar SDKs provide tools that take care of all that. Here’s how you might send 10 lumens to another account:」
(当審訳:トランザクションの構築
ステラは、トランザクションデータをXDRと呼ばれるバイナリ形式で保存および通信します。幸いなことに、Stellar SDKは、これらすべてを処理するツールを提供しています。10ルーメンを別のアカウントに送信する方法は次のとおりです。)

(c)「2. Load data for the account you are sending from. An account can only perform one transaction at a time and has something called a sequence number, which helps Stellar verify the order of transactions. A transaction’s sequence number needs to match the account’s sequence number, so you need to get the account’s current sequence number from the network.」
(当審訳:2.送信元のアカウントのデータを読み込みます。アカウントは一度に1つのトランザクションしか実行できず、シーケンス番号と呼ばれるものがあり、これは、ステラがトランザクションの順序を確認するのに役立ちます。トランザクションのシーケンス番号はアカウントのシーケンス番号と一致する必要があるため、ネットワークからアカウントの現在のシーケンス番号を取得する必要があります。)

(d)「3. Start building a transaction. This requires an account object, not just an account ID, because it will increment the account’s sequence number.」
(当審訳:3.トランザクションの構築を開始します。これには、アカウントIDだけでなく、アカウントオブジェクトが必要です。これは、アカウントのシーケンス番号をインクリメントするためです。)

(e)「4. Add the payment operation to the account. Note that you need to specify the type of asset you are sending−Stellar’s “native” currency is the lumen, but you can send any type of asset or currency you like, from dollars to bitcoin to any sort of asset you trust the issuer to redeem (more details below). For now, though, we’ll stick to lumens, which are called “native” assets in the SDK:」
(当審訳:4.アカウントに支払い操作を追加します。送信する資産のタイプを指定する必要があることに注意してください。ステラの「ネイティブ」通貨はルーメンですが、ドルからビットコインや発行者が償還すると信頼できるあらゆる種類の資産(詳細は以下を参照)まで、所望のどんなタイプの資産または通貨でも送信できます。ただし、ここでは、SDKでは「ネイティブ」資産と呼ばれるルーメンを取り上げます。)

(f)「6. Now that the transaction has all the data it needs, you have to cryptographically sign it using your secret seed. This proves that the data actually came from you and not someone impersonating you.」
(当審訳:6.トランザクションに必要なすべてのデータが含まれるようになったので、あなたは秘密シードを使用して暗号で署名する必要があります。これは、データが実際にあなたからのものであり、誰かがあなたになりすましているのではないことを証明しています。)

(g)「7. And finally, send it to the Stellar network!」
(当審訳:7.そして最後に、それをステラネットワークに送信してください!)

d 「Architecture」に記載されている事項
(a)「Anchors are entities that people trust to hold their deposits and issue credits into the Stellar network for those deposits. All money transactions in the Stellar network (except lumens) occur in the form of credit issued by anchors, so anchors act as a bridge between existing currencies and the Stellar network. Most anchors are organizations like banks, savings institutions, farmers’ coops, central banks, and remittance companies.」
(当審訳:アンカーは、人々が預託したものを保持し、それらの預託についてステラネットワークにクレジットを発行することについて人々が信頼するエンティティです。ステラネットワークでのすべての金銭取引(ルーメンを除く)は、アンカーによって発行されたクレジットの形で行われるため、アンカーは現行通貨とステラネットワークの間のブリッジとして機能します。ほとんどのアンカーは、銀行、貯蓄機関、農民協同組合、中央銀行、送金会社などの組織です。)

(b)「Customer Accounts
There are two simple ways to account for your customers’ funds:
1. Maintain a Stellar account for each customer. When a customer deposits money with your institution, you should pay an equivalent amount of your custom asset into the customer’s Stellar account from your base account. When a customer needs to obtain physical currency from you, deduct the equivalent amount of your custom asset from their Stellar account.
This approach simplifies bookkeeping by utilizing the Stellar network instead of your own internal systems. It can also allow your customers a little bit more control over how their account works in Stellar.」
(当審訳:顧客アカウント
顧客の資金を計上する2つの簡単な方法があります。
1.各顧客のステラアカウントを維持します。顧客があなたの機関にお金を預けるとき、あなたのベースアカウントから顧客のステラアカウントに同等の量のあなたのカスタム資産を支払う義務があなたに生じることになります。顧客があなたから現金通貨を取得する必要がある場合は、彼らのステラアカウントから同等の量のカスタム資産を差し引くことになります。
このアプローチは、独自の内部システムの代わりにステラネットワークを利用することにより、帳簿を簡素化します。また、顧客はアカウントがステラでどのように機能するかをもう少し制御できるようになります。)

e 「Assets」に記載されている事項
(a)「Assets
The Stellar distributed network can be used to track, hold, and transfer any type of asset: dollars, euros, bitcoin, stocks, gold, and other value. Any asset on the network can be traded and exchanged with any other.
Other than lumens (see below), all assets have
・Asset type: e.g. USD or BTC
・Issuer: the account that created the asset」
(当審訳:資産
ステラの分散ネットワークは、ドル、ユーロ、ビットコイン、株式、金、その他の価値のあるあらゆる種類の資産を追跡、保有、移動するために使用することができます。ネットワーク上のどの資産も、他の資産と取引・交換することができます。
ルーメン以外(下記参照)のすべての資産は
・資産タイプ:例:USDまたはBTC
・発行者:その資産を作成したアカウント
を有します。)

(b)「Trustlines
When you hold assets in Stellar, you’re actually holding credit from a particular issuer. The issuer has agreed that it will trade you its credit on the Stellar network for the corresponding asset−e.g., fiat currency, precious metal−outside of Stellar. Let’s say that Scott issues oranges as credit on the network. If you hold orange credits, you and Scott have an agreement based on trust, or a trustline: you both agree that when you give Scott an orange credit, he gives you an orange.
When you hold an asset, you must trust the issuer to properly redeem its credit. Since users of Stellar will not want to trust just any issuer, accounts must explicitly trust an issuing account before they’re able to hold the issuer’s credit. In the example above, you must explicitly trust Scott before you can hold orange credits.
To trust an issuing account, you create a trustline. Trustlines are entries that persist in the Stellar ledger. They track the limit for which your account trusts the issuing account and the amount of credit from the issuing account that your account currently holds.」
(当審訳:トラストライン
あなたがステラで資産を保有している場合、あなたは実際には特定の発行者に対する信用を保有しています。発行者は、ステラネットワーク上で彼らの信用供与するものと、例えば、法定通貨や貴金属等のステラ外部の対応する資産とを交換することに同意しています。例えば、スコットがネットワーク上のクレジットとしてオレンジを発行するとします。あなたがオレンジのクレジットを持っている場合、あなたとスコットは、信頼またはトラストラインに基づいて同意しているのであり、つまり、あなた方は、お互いに、あなたがスコットにオレンジのクレジットを与えると、スコットもあなたにオレンジを与えるという同意をしているのです。
あなたがある資産を保有する場合、あなたは、そのクレジットを発行者が適切に償還すると信頼する必要があります。ステラのユーザは単なる発行者を信頼することを望まないため、アカウントは発行者のクレジットを保有する前に、発行者のアカウントを明示的に信頼する必要があります。上記の例では、オレンジのクレジットを保有する前に、スコットを明示的に信頼する必要があります。
発行アカウントを信頼するには、トラストラインを作成します。トラストラインは、ステラ台帳に永続的に保持されるエントリです。それら(トラストライン)はあなたのアカウントが発行アカウントを信頼している限度額と、あなたのアカウントが現在保有している発行アカウントからのクレジットの量を追跡します。)

(c)「Lumens(XLM)
Lumens(XLM) are the native currency of the network. A lumen is the only asset type that can be used on the Stellar network that doesn’t require an issuer or a trustline. Any account can hold lumens. You can trade lumens for other assets in the network.」
(当審訳:ルーメン(XLM)
ルーメン(XLM)は、ステラネットワークのネイティブ通貨です。ルーメンは、ステラネットワーク上で使用できる唯一の資産で、発行者やトラストラインを必要としません。どのようなアカウントでもルーメンを保有することができます。ルーメンは、ネットワーク上で他の資産と交換することができます。)

(d)「Anchors: issuing assets
Any account can issue assets on the Stellar network. Entities that issue assets are called anchors. Anchors can be run by individuals, small businesses, local communities, nonprofits, organizations, etc. Any type of financial institution−a bank, a payment processor−can be an anchor.
Each anchor has an issuing account from which it issues the asset.
As an anchor, when you issue an asset, you give it an asset code. Assets are uniquely identified by the asset code and the issuer. Ultimately, it’s up to the issuer to set the asset code. By convention, however, currencies should be represented by the appropriate ISO 4217 code. For stocks and bonds, use the appropriate ISIN number. For your orange, goat, favor, or beer anchors, you’re on your own−invent an appropriate code!」
(当審訳:アンカー:資産の発行
どのアカウントでもステラネットワークで資産を発行できます。資産を発行するエンティティはアンカーと呼ばれます。アンカーは、個人、中小企業、地域コミュニティ、非営利団体、組織などが運営できます。銀行、決済代行業者など、あらゆる種類の金融機関がアンカーになることができます。
各アンカーには、資産を発行する発行アカウントがあります。
アンカーとして、資産を発行するときに、資産コードを付与します。資産は、資産コードと発行者によって一意に識別されます。最終的に、資産コードを設定するのは発行者次第です。ただし、慣例により、通貨は適切なISO4217コードで表す必要があります。株式および債券については、適切なISIN番号を使用してください。オレンジ、ヤギ、好物、またはビールのアンカーについては、自分で適切なコードを作成してください。)

f 「Distributed Exchange」に記載されている事項
(a)「In addition to supporting the issuing and movement of assets, the Stellar network also acts as a decentralized distributed exchange of any type of asset that people have added to the network. Its ledger stores both balances held by user accounts and offers that user accounts make to buy or sell assets.」
(当審訳:ステラネットワークは、資産の発行と移動をサポートするだけでなく、人々がネットワークに追加したあらゆる種類の資産の分散型取引所としても機能します。その台帳は、ユーザアカウントが保持する残高と、ユーザアカウントが資産を売買するために行うオファーの両方を格納します。)

(b)「Offers
An account can make offers to buy or sell assets using the Manage Offer operation. In order to make an offer, the account must hold the asset it wants to sell. Similarly, the account must trust the issuer of the asset it’s trying to buy.」
(当審訳:オファー
アカウントは、オファー管理の操作を使用して資産を売買するオファーを行うことができます。オファーを行うには、アカウントが売りたい資産を保持している必要があります。同様に、アカウントは、買おうとしている資産の発行者を信頼する必要があります。)

g 「Ledger」に記載されている事項
(a)「A ledger represents the state of the Stellar universe at a given point in time. It contains the list of all the accounts and balances, all the orders in the distributed exchange, and any other data that persists.
The first ledger in the history of the network is called the genesis ledger.
Every Stellar Consensus Protocol (SCP) round, the network reaches consensus on which transaction set to apply to the last closed ledger; when the new set is applied, a new “last closed ledger” is defined.
Each ledger is cryptographically linked to a unique previous ledger, creating a historical ledger chain that goes back to the genesis ledger.
We define the sequence number of a ledger recursively:
・Genesis ledger has sequence number 1
・Ledger directly following a ledger with sequence number n has sequence number n+1」
(当審訳:台帳は、特定の時点でのステラ世界の状態を表します。これには、すべてのアカウントと残高、分散型取引所のすべての注文、および永続するその他のデータのリストが含まれています。
ネットワークの履歴の中で最初の台帳は、ジェネシス台帳と呼ばれます。
Stellar Consensus Protocol(SCP)ラウンドごとに、最後に閉じた台帳にどのトランザクションセットを適用するかについて、ネットワークの合意を得ます。新しいセットが適用されると、新しい「最後に閉じた台帳」が定義されます。
各台帳は、一意の直前の台帳に暗号でリンクされ、ジェネシス台帳に遡る履歴台帳チェーンを作成します。
台帳のシーケンス番号を再帰的に定義します。
・ジェネシス台帳のシーケンス番号は1です
・シーケンス番号nの台帳の直後の台帳のシーケンス番号はn+1です。)

(b)「Ledger header
Every ledger has a ledger header. This header has references to the actual data within the ledger as well as a reference to the previous ledger. References here are cryptographic hashes of the content being referenced−the hashes behave like pointers in typical data structures but with added security guarantees.
You can think of the historical ledger chain as a linked list of ledger headers:
[Genesis] <---- [LedgerHeader_1] <----- … <---- [LedgerHeader_n]
See the protocol file for the object definitions. src/xdr/Stellar-ledger.x
Every ledger header has the following fields:
・Version: Protocol version of this ledger.
・Previous Ledger Hash: Hash of the previous ledger. Forms a chain of ledgers stretching back to the genesis ledger.
・SCP value: During consensus all the nodes in the network run SCP and come to agreement about a particular value. This value is stored here and in the next three fields (transaction set hash, close time, and upgrades).
・Transaction set hash: Hash of the transaction set that was applied to the previous ledger.
・Close time: When the network closed this ledger. UNIX timestamp.
・Upgrades: How the network adjusts the base fee and moves to a new protocol version. This field is usually empty. For more info, see versioning.
・Transaction set result hash: Hash of the results of applying the transaction set. This data is not, strictly speaking, necessary for validating the results of the transactions. However, this data makes it easier for entities to validate the result of a given transaction without having to apply the transaction set to the previous ledger.
・Bucket list hash: Hash of all the objects in this ledger. The data structure that contains all the objects is called the bucket list.
・Ledger sequence: The sequence number of this ledger.
・Total coins: Total number of lumens in existence.
・Fee pool: Number of lumens that have been paid in fees. This number will be added to the inflation pool and reset to 0 the next time inflation runs. Note this is denominated in lumens, even though a transaction’s fee field is in stroops.
・Inflation sequence: Number of times inflation has been run.
・ID pool: The last used global ID. These IDs are used for generating objects.
・Maximum Number of Transactions: The maximum number of transactions the validators have agreed to process in a given ledger. If more transactions are submitted than this number, the validators will include those with the highest fees.
・Base fee: The fee the network charges per operation in a transaction. This field is in stroops, which are 1/10,000,000th of a lumen.
・Base reserve: The reserve the network uses when calculating an account’s minimum balance.
・Skip list: Hashes of ledgers in the past. Allows you to jump back in time in the ledger chain without walking back ledger by ledger. There are 4 ledger hashes stored in the skip list. Each slot contains the oldest ledger that is mod of either 50 5000 50000 or 500000 depending on index skipList[0] mod(50), skipList[1] mod(5000), etc.」
(当審訳:台帳ヘッダ
すべての台帳には台帳ヘッダがあります。このヘッダには、直前の台帳への参照だけでなく、その台帳内の実データへの参照があります。ここでの参照は、参照されているコンテンツの暗号化ハッシュです。ハッシュは、一般的なデータ構造ではポインタのように動作しますが、セキュリティが保証されています。
履歴台帳チェーンは、台帳ヘッダのリンクリストとみなすことができます。
[ジェネシス]<----[台帳ヘッダ1]<-----…<----[台帳ヘッダn]
オブジェクト定義については、プロトコルファイルを参照してください。 src/xdr/Stellar-ledger.x
すべての台帳ヘッダには、次のフィールドがあります。
・バージョン:この台帳のプロトコルバージョン。
・直前の台帳ハッシュ:直前の台帳のハッシュ。ジェネシス台帳に遡る台帳のチェーンを形成します。
・SCP値:コンセンサス中に、ネットワーク内のすべてのノードがSCPを実行し、特定の値について合意します。この値は、ここと次の3つのフィールド(トランザクションセットハッシュ、クローズ時間、およびアップグレード)に保存されます。
・トランザクションセットハッシュ:直前の台帳に適用されたトランザクションセットのハッシュ。
・クローズ時間:ネットワークがこの台帳を閉じた時。 UNIXタイムスタンプ。
・アップグレード:ネットワークが基本手数料を調整し、新しいプロトコルバージョンに移行する方法。このフィールドは通常空です。詳細については、バージョン管理を参照してください。
・トランザクションセット結果ハッシュ:トランザクションセットを適用した結果のハッシュ。このデータは、厳密に言えば、トランザクションの結果を検証するために必要ではありません。ただし、このデータにより、エンティティは、トランザクションセットを直前の台帳に適用しなくても、特定のトランザクションの結果を簡単に検証できます。
・バケットリストハッシュ:この台帳内のすべてのオブジェクトのハッシュ。すべてのオブジェクトを含むデータ構造は、バケットリストと呼ばれます。
・台帳シーケンス:この台帳のシーケンス番号。
・コインの総数:存在するルーメンの総数。
・手数料プール:手数料で支払われたルーメンの数。この数値はインフレプールに追加され、次にインフレが実行されるときに0にリセットされます。トランザクションの手数料フィールドがストループを用いている場合でも、これはルーメン単位で表示されることに注意してください。
・インフレーションシーケンス:インフレーションが実行された回数。
・IDプール:最後に使用されたグローバルID。これらのIDは、オブジェクトの生成に使用されます。
・トランザクションの最大数:バリデーターが特定の台帳で処理することに同意したトランザクションの最大数。この数よりも多くのトランザクションが送信された場合、バリデーターには最も高い手数料のトランザクションが含まれます。
・基本手数料:トランザクションの操作ごとにネットワークが請求する手数料。このフィールドは、ルーメンの1/10,000,000分の1のストループになっています。
・基本予備金:アカウントの最小残高を計算するときにネットワークが使用する予備金。
・スキップリスト:過去の台帳のハッシュ。台帳で台帳を遡ることなく、台帳チェーンで時間を遡ることができます。スキップリストには4つの台帳ハッシュが保存されています。各スロットには、インデックスskipList [0] mod(50)、skipList [1] mod(5000)などに応じて50500050000または500000のmodである最も古い台帳が含まれています。)

(c)「Ledger Entries
The ledger is a collection of entries. Currently there are 4 types of ledger entries. They’re specified in src/xdr/Stellar-ledger-entries.x.

Account entry
This entry represents an account. In Stellar, everything is built around accounts: transactions are performed by accounts, and accounts control the access rights to balances.
Other entries are add-ons, owned by a main account entry. With every new entry attached to the account, the minimum balance in XLM goes up for the account. For details, see fees and minimum balance.

Trustline entry
Trustlines are lines of credit the account has given a particular issuer in a specific currency.
Trustline entries define the rules around the use of this currency. Rules can be defined by the user−e.g., setting a balance limit to limit risk−or by the issuer−e.g., an authorized flag.

Offer entry
Offers are entries that an account creates in the orderbook. They are a way to automate simple trading inside the Stellar network. For more on offers, refer to the distributed exchange documentation.

Data entry
Data entries are key value pairs attached to an account. They allow account controllers to attach arbitrary data to their account. It provides a flexible extension point to add application specific data into the ledger.」
(当審訳:台帳エントリ
台帳はエントリの集まりです。現在、4種類の台帳エントリがあります。それらはsrc/xdr/Stellar-ledger-entries.xで指定されています。

アカウントエントリ
このエントリはアカウントを表します。ステラでは、すべてがアカウントを中心に構築されています。トランザクションはアカウントによって実行され、アカウントは残高へのアクセス権を制御します。
その他のエントリは、メインアカウントエントリが所有するアドオンです。アカウントに新しいエントリが添付されるたびに、XLMの最小残高がアカウントに対して増加します。詳しくは、手数料と最低残高をご覧ください。

トラストラインエントリ
トラストラインは、アカウントが特定の発行者に特定の通貨で付与した信用供与です。
トラストラインエントリは、この通貨の使用に関するルールを定義します。ルールは、リスクを制限するために残高制限を設定するなど、ユーザが定義することも、承認されたフラグなどの発行者が定義することもできます。

オファーエントリ
オファーは、アカウントがオーダーブックに作成するエントリです。これらは、ステラネットワーク内の単純な取引を自動化する方法です。オファーの詳細については、分散型取引所のドキュメントを参照してください。

データエントリ
データエントリは、アカウントに関連付けられたキーと値のペアです。アカウントコントローラーは、アカウントに任意のデータを添付できます。アプリケーション固有のデータを台帳に追加するための柔軟な拡張ポイントを提供します。)

h「List of Operations」に記載されている事項
(a)「Payment
Sends an amount in a specific asset to a destination account.
Threshold: Medium
Result: PaymentResult
Parameters:


Possible errors:


(当審訳:支払い
特定の資産の金額を宛先アカウントに送信します。
しきい値:中
結果:PaymentResult
パラメータ:


起こりうるエラー:



「起こりうるエラー」の表によれば、支払い操作において起こりうるエラーとして、「ソースアカウント(送信者)は、送信しようとしている資産の発行者を信頼していません。」という状態を示す「PAYMENT_SRC_NO_TRUST」、「受信者は、送信されている資産の発行者を信頼していません。」という状態を示す「PAYMENT_NO_TRUST」、及び「受信アカウントは、特定のクレジットについてのみ資産の発行者を信頼します。このトランザクションが成功した場合、受信者の信頼制限を超えます。」という状態を示す「PAYMENT_LINE_FULL」が、それぞれ定義されている。

(b)「Change Trust
Creates, updates, or deletes a trustline. For more on trustlines, please refer to the assets documentation.
Threshold: Medium
Result: ChangeTrustResult
Parameters:


Possible errors:


(当審訳:信頼の変更
トラストラインを作成、更新、または削除します。トラストラインの詳細については、資産を参照してください。
しきい値:中
結果:ChangeTrustResult
パラメータ:


起こりうるエラー:



「パラメータ」の表によれば、信頼の変更操作におけるパラメータとして、資産タイプの「Line」と整数タイプの「Limit」が設けられ、「Line」は「トラストラインの資産。例えば、ユーザがアンカーに対してトラストラインを200米ドルまで供与する場合、そのLineはUSD:anchorになります。」、「Limit」は「トラストラインの限度。前の例では、Limitは200になります。」と、それぞれ説明されている。

i 「Transactions」に記載されている事項
(a)「Transactions are commands that modify the ledger state. Among other things, Transactions are used to send payments, enter orders into the distributed exchange, change settings on accounts, and authorize another account to hold your currency. If you think of the ledger as a database, then transactions are SQL commands.」
(当審訳:トランザクションは、台帳の状態を変更するコマンドです。とりわけ、トランザクションは、支払いの送信、分散型取引所への注文の入力、アカウントの設定の変更、および別のアカウントに通貨の保持を許可するために使用されます。台帳をデータベースと考えると、トランザクションはSQLコマンドです。)

(b)「4. Propagating: Once stellar-core receives a transaction, either given to it by a user or another stellar-core, it does preliminary checks to see if the transaction is valid. Among other checks, it makes sure that the transaction is correctly formed and the source account has enough to cover the transaction fee. Stellar-core doesn’t check things that require inspecting the state of the ledger beyond looking up the source account−e.g., that the destination account to which the transaction is trying to send exists, that the account has enough of this asset to sell, that it’s a valid path. If the preliminary checks pass, then stellar-core propagates the transaction to all the other servers to which it’s connected. In this way, a valid transaction is flooded to the whole Stellar network.」
(当審訳:4.伝播:ステラコアは、ユーザまたは別のステラコアから与えられたトランザクションを受信すると、トランザクションが有効かどうかを確認するための予備チェックを行います。とりわけ、トランザクションが正しく形成され、ソースアカウントがトランザクション手数料をカバーするのに十分であることを確認します。ステラコアは、ソースアカウントを検索すること以外には、たとえば、トランザクションが送信しようとしている宛先アカウントが存在すること、アカウントが売るための十分なこの資産を有すること、それが有効なパスであることなどの、台帳の状態を検査する必要があるものをチェックしません。予備チェックに合格すると、ステラコアはトランザクションを接続先の他のすべてのサーバに伝播します。このようにして、有効なトランザクションがステラネットワーク全体に流されます。)

(c)「5. Including in a transaction set: When it’s time to close the ledger, stellar-core takes all the transactions it has heard about since last ledger close and collects them into a transaction set. If it hears about any incoming transactions now, it puts them aside for next ledger close.
Stellar-core nominates the transaction set it has collected. SCP resolves the differences between the various transaction sets proposed and decides on the one transaction set that the network will apply.」
(当審訳:5.トランザクションセットに含める:台帳を閉じるとき、ステラコアは、最後に台帳を閉じて以降に通知のあったすべてのトランザクションを取得し、それらをトランザクションセットに収集します。今、トランザクションの通知があった場合、次に台帳を閉じるときに処理するため、それらを保存しておきます。
ステラコアは、収集したトランザクションセットを指定します。SCPは、提案されたさまざまなトランザクションセット間の違いを解決し、ネットワークが適用する1つのトランザクションセットを決定します。)

j 「Issuing Assets」に記載されている事項
(a)「Issuing Assets
One of Stellar’s most powerful features is the ability to trade any kind of asset, like US dollars, Nigerian naira, bitcoins, special coupons, or just about anything you like.
This works in Stellar because an asset is really just a credit from a particular account. When you trade US dollars on the Stellar network, you don’t actually trade US dollars−you trade US dollars credited from a particular account. Often, that account will be a bank, but if your neighbor had a banana plant, they might issue banana assets that you could trade with other people.
Every asset type (except lumens) is defined by two properties:
asset_code: a short identifier of 1-12 letters or numbers, such as USD, or EUR. It can be anything you like, even AstroDollars.
asset_issuer: the ID of the account that issues the asset.
In the Stellar SDK, assets are represented with the Asset class:」
(当審訳:資産の発行
ステラの最も強力な機能の1つは、米ドル、ナイジェリアナイラ、ビットコイン、特別クーポンなど、あらゆる種類の資産を取引できることです。
これは、資産は実際には特定のアカウントからの単なるクレジットであるため、ステラで機能します。ステラネットワークで米ドルを取引する場合、実際には米ドルを取引するのではなく、特定のアカウントから入金された米ドルを取引します。多くの場合、そのアカウントは銀行になりますが、隣人がバナナの木を持っている場合、他の人と取引できるバナナの資産を発行する可能性があります。
すべての資産タイプ(ルーメンを除く)は、次の2つのプロパティによって定義されます。
Asset_code:USDやEUR、などの1〜12文字または数字の短い識別子。AstroDollarsのようなあなたが好きな何でもよい。
Asset_issuer:資産を発行するアカウントのID。
Stellar SDKでは、資産はAssetクラスで表されます。


(b)「Issuing a New Asset Type
To issue a new type of asset, all you need to do is choose a code. It can be any combination of up to 12 letters or numbers, but you should use the appropriate ISO 4217 code (e.g. USD for US dollars) or ISIN for national currencies or securities. Once you’ve chosen a code, you can begin paying people using that asset code. You don’t need to do anything to declare your asset on the network.
However, other people can’t receive your asset until they’ve chosen to trust it. Because a Stellar asset is really a credit, you should trust that the issuer can redeem that credit if necessary later on. You might not want to trust your neighbor to issue banana assets if they don’t even have a banana plant, for example.
An account can create a trustline, or a declaration that it trusts a particular asset, using the change trust operation. A trustline can also be limited to a particular amount. If your banana-growing neighbor only has a few plants, you might not want to trust them for more than about 200 bananas.
Note: each trustline increases an account’s minimum balance by 10 lumens (the base reserve). For more details, see the fees guide.
Once you’ve chosen an asset code and someone else has created a trustline for your asset, you’re free to start making payment operations to them using your asset. If someone you want to pay doesn’t trust your asset, you might also be able to use the distributed exchange.」
(当審訳:新しい資産タイプの発行
新しいタイプの資産を発行するために必要なことは、コードを選択するだけです。最大12文字または数字の任意の組み合わせにすることができますが、適切なISO 4217コード(例えば、米ドルに対してはUSD)または国の通貨または証券の場合はISINを使用する必要があります。コードを選択したら、その資産コードを使用して人々に支払いを開始できます。ネットワーク上で資産を宣言するために何もする必要はありません。
ただし、他の人は、あなたの資産を信頼することを選択するまで、あなたの資産を受け取ることはできません。ステラ資産は実際にはクレジットであるため、発行者が後で必要に応じてそのクレジットを償還することができることを信頼する必要があります。たとえば、隣人がバナナの木さえ持っていない場合は、隣人がバナナの資産を発行することを信頼しない方がいいかもしれません。
アカウントは、信頼の変更操作を使用して、トラストライン、言い換えればアカウントが特定の資産を信頼するという宣言を作成できます。トラストラインを特定の金額に制限することもできます。バナナを栽培している隣人が数本のバナナの木しか持っていない場合は、約200本以上のバナナを信頼しないようにすることができます。
注:各トラストラインは、アカウントの最小残高を10ルーメン(基本予備金)ずつ増やします。詳細については、手数料ガイドを参照してください。
いったん、あなたが資産コードを選択し、他の誰かがあなたの資産のトラストラインを作成したら、あなたはあなたの資産を使用して彼らへの支払い操作を自由に開始できます。支払いたい人があなたの資産を信頼していない場合は、分散型取引所を使用できる可能性もあります。)

イ 引用文献1に記載された発明
上記アの摘記事項から、引用文献1には、次の技術的事項が記載されている。
(ア)上記アのa(a)〜(b)、bの記載から、引用文献1には、世界中のステラコアの集合体である分散システムのステラネットワークにおいて、ネットワークのノードであるステラコアのそれぞれがさまざまな人々や組織によって維持されており、ステラネットワークを使用すると、モバイルウォレット、バンキングツールなど、支払いに関連するものを構築でき、ステラネットワークでアカウントを作成することにより、アカウントはステラ内ですべてのお金を保持し、支払いの送受信を可能にする方法である、ステラネットワークによる支払いの送受信を可能にする方法が、記載されている。

(イ)上記アのc(a)〜(g)、e(a)〜(c)、i(a)〜(c)の記載から、引用文献1に記載のステラネットワークでは、ネイティブ通貨として、ルーメンを有するものであり、支払いの送信や、さまざまな種類の通貨の取引のオファーなどの操作を実行するためにトランザクションを作成する必要があり、当該トランザクションのデータはXDRと呼ばれるバイナリ形式で保存および通信され、送信元のアカウントのデータを読み込んだ後で、送信する資産のタイプを指定した支払い操作をアカウントに追加することによりトランザクションが構築され、トランザクションに必要なすべてのデータが含まれた後、秘密シードを使用して暗号で署名されてステラネットワークに送信され、ステラコアは、ユーザまたは別のステラコアからトランザクションを受信すると、トランザクションが有効かどうかを確認するための予備チェックを行い、予備チェックに合格すると、トランザクションを接続先の他のすべてのサーバに伝播し、台帳を閉じるとき、最後に台帳を閉じて以降に通知のあったすべてのトランザクションを取得し、それらをトランザクションセットに収集するものである。

(ウ)上記アのg(a)〜(b)の記載から、引用文献1に記載のステラネットワークの各台帳は、一意の直前の台帳に暗号でリンクされ、ネットワークの履歴の中で最初の台帳であるジェネシス台帳に遡る履歴台帳チェーンを作成し、ジェネシス台帳のシーケンス番号を1とし、シーケンス番号nの台帳の直後の台帳のシーケンス番号をn+1とすることにより、台帳のシーケンス番号が再帰的に定義されており、すべての台帳は、直前の台帳への参照だけでなく、その台帳内の実データへの参照を有する台帳ヘッダを持ち、ここでの参照は、参照されているコンテンツの暗号化ハッシュであり、そのハッシュは、一般的なデータ構造におけるポインタのような動作に加え、セキュリティが保証されており、履歴台帳チェーンは、台帳ヘッダのリンクリストとみなせ、すべての台帳ヘッダには、この台帳のシーケンス番号と、ジェネシス台帳に遡る台帳のチェーンを形成する直前の台帳ハッシュのフィールドを有する。

(エ)上記アのd(a)〜(b)、e(d)の記載から、引用文献1に記載のステラネットワークでは、資産を発行するエンティティであるアンカーは、銀行、決済代行業者など、あらゆる種類の金融機関がなることができ、アンカーが資産を発行するときに、資産コードを付与し、資産は資産コードと発行者によって一意に識別されるものであり、ステラネットワークでのすべての金銭取引は、アンカーによって発行されたクレジットの形で行われ、アンカーは現行通貨とステラネットワークの間のブリッジとして機能し、顧客が機関にお金を預けるとき、機関のベースアカウントから顧客のステラアカウントに同等の量の機関のカスタム資産が支払われ、顧客が機関から現金通貨を取得する場合は、ステラアカウントから同等の量のカスタム資産が差し引かれるものである。

(オ)上記アのd(a)、e(b)、g(c)、j(b)の記載から、引用文献1に記載のステラネットワークのユーザは、ステラネットワーク上のクレジットを法定通貨や貴金属等のステラ外部の対応する資産と交換する特定の発行者(アンカー)からのクレジットを保有することにより資産を保有し、資産を保有する場合、ステラ台帳に保持されるエントリであって、アカウントが特定の発行者に特定の通貨で付与した信用供与であるトラストラインを作成することにより、発行者を信頼する必要があり、ユーザの資産を使用して他のユーザへの支払い操作を行うためには、ユーザが資産コードを選択し、他のユーザがユーザの資産のトラストラインを作成する必要がある。

(カ)上記アのf(a)、g(c)、h(b)、j(a)〜(b)の記載から、引用文献1に記載のステラネットワークは、人々がネットワークに追加したあらゆる種類の資産の分散型取引所としても機能し、その台帳は、トラストラインエントリを保持するほか、ユーザアカウントが保持する残高と、ユーザアカウントが資産を売買するために行うオファーの両方を格納し、トラストラインエントリは、この通貨の使用に関し、リスクを制限するための残高制限の設定のルールを、ユーザが定義することが可能であり、アカウントは、信頼の変更操作を使用して、特定の資産を信頼するという宣言や、トラストラインを特定の金額に制限することができ、例えば、ユーザがアンカーに対してトラストラインを200米ドルまで供与する場合、USDやEURなどの識別子である「Asset_code」と、資産を発行するアカウントのIDである「Asset_issuer」の、2つのプロパティによって定義される資産タイプのパラメータである「Line」を「USD:anchor」に、整数タイプのパラメータである「Limit」を「200」に定義する。

(キ)上記アのe(b)、f(b)、h(a)の記載から、引用文献1に記載のステラネットワークにおいて、アカウントは、オファー管理の操作を使用して資産を売買するオファーを行うには、アカウントが売りたい資産を保持している必要があり、同様に、買おうとしている資産の発行者を信頼する必要があり、トラストラインはユーザのアカウントが発行アカウントを信頼している限度額と当該ユーザのアカウントが現在保有している発行アカウントからのクレジットの量を追跡し、特定の資産の金額を宛先アカウントに送信する支払い操作において、起こりうるエラーとして、「ソースアカウント(送信者)は、送信しようとしている資産の発行者を信頼していません。」という状態を示す「PAYMENT_SRC_NO_TRUST」、「受信者は、送信されている資産の発行者を信頼していません。」という状態を示す「PAYMENT_NO_TRUST」、及び「受信アカウントは、特定のクレジットについてのみ資産の発行者を信頼します。このトランザクションが成功した場合、受信者の信頼制限を超えます。」という状態を示す「PAYMENT_LINE_FULL」が、それぞれ定義されている。

上記(ア)〜(キ)を総合すると、引用文献1には、次の発明(以下、「引用発明」という。)が記載されている。
「世界中のステラコアの集合体である分散システムのステラネットワークにおいて、ネットワークのノードであるステラコアのそれぞれがさまざまな人々や組織によって維持されており、ステラネットワークを使用して、モバイルウォレット、バンキングツールなど、支払いに関連するものを構築し、ステラネットワークでアカウントを作成することにより、アカウントがステラ内にすべてのお金を保持し、支払いの送受信を可能にする方法であって、(ア)
ステラネットワークでは、ネイティブ通貨として、ルーメンを有するものであり、支払いの送信や、さまざまな種類の通貨の取引のオファーなどの操作を実行するためにトランザクションを作成する必要があり、当該トランザクションのデータはXDRと呼ばれるバイナリ形式で保存および通信され、送信元のアカウントのデータを読み込んだ後で、送信する資産のタイプを指定した支払い操作をアカウントに追加することによりトランザクションが構築され、トランザクションに必要なすべてのデータが含まれた後、秘密シードを使用して暗号で署名されてステラネットワークに送信され、ステラコアは、ユーザまたは別のステラコアからトランザクションを受信すると、トランザクションが有効かどうかを確認するための予備チェックを行い、予備チェックに合格すると、トランザクションを接続先の他のすべてのサーバに伝播し、台帳を閉じるとき、最後に台帳を閉じて以降に通知されたすべてのトランザクションを取得し、それらをトランザクションセットに収集し、(イ)
ステラネットワークの各台帳は、一意の直前の台帳に暗号でリンクされ、ネットワークの履歴の中で最初の台帳であるジェネシス台帳に遡る履歴台帳チェーンを作成し、ジェネシス台帳のシーケンス番号を1とし、シーケンス番号nの台帳の直後の台帳のシーケンス番号をn+1とすることにより、台帳のシーケンス番号が再帰的に定義されており、すべての台帳は、直前の台帳への参照だけでなく、その台帳内の実データへの参照を有する台帳ヘッダを持ち、ここでの参照は、参照されているコンテンツの暗号化ハッシュであり、そのハッシュは、一般的なデータ構造におけるポインタのような動作に加え、セキュリティが保証されており、履歴台帳チェーンは、台帳ヘッダのリンクリストとみなせ、すべての台帳ヘッダには、この台帳のシーケンス番号と、ジェネシス台帳に遡る台帳のチェーンを形成する直前の台帳ハッシュのフィールドを有し、(ウ)
資産を発行するエンティティであるアンカーは、銀行、決済代行業者など、あらゆる種類の金融機関がなることができ、アンカーが資産を発行するときに、資産コードを付与し、資産は資産コードと発行者によって一意に識別されるものであり、ステラネットワークでのすべての金銭取引は、アンカーによって発行されたクレジットの形で行われ、アンカーは現行通貨とステラネットワークの間のブリッジとして機能し、顧客が機関にお金を預けるとき、機関のベースアカウントから顧客のステラアカウントに同等の量の機関のカスタム資産が支払われ、顧客が機関から現金通貨を取得する場合は、ステラアカウントから同等の量のカスタム資産が差し引かれ、(エ)
ステラネットワークのユーザは、ステラネットワーク上のクレジットを法定通貨や貴金属等のステラ外部の対応する資産と交換する特定の発行者(アンカー)からのクレジットを保有することにより資産を保有し、資産を保有する場合、ステラ台帳に保持されるエントリであって、アカウントが特定の発行者に特定の通貨で付与した信用供与であるトラストラインを作成することにより、発行者を信頼する必要があり、ユーザの資産を使用して他のユーザへの支払い操作を行うためには、ユーザが資産コードを選択し、他のユーザがユーザの資産のトラストラインを作成する必要があり、(オ)
ステラネットワークは、人々がネットワークに追加したあらゆる種類の資産の分散型取引所としても機能し、その台帳は、トラストラインエントリを保持するほか、ユーザアカウントが保持する残高と、ユーザアカウントが資産を売買するために行うオファーの両方を格納し、トラストラインエントリは、この通貨の使用に関し、リスクを制限するための残高制限の設定のルールを、ユーザが定義することが可能であり、アカウントは、信頼の変更操作を使用して、特定の資産を信頼するという宣言や、トラストラインを特定の金額に制限することができ、例えば、ユーザがアンカーに対してトラストラインを200米ドルまで供与する場合、USDやEURなどの識別子である「Asset_code」と、資産を発行するアカウントのIDである「Asset_issuer」の、2つのプロパティによって定義される資産タイプのパラメータである「Line」を「USD:anchor」に、整数タイプのパラメータである「Limit」を「200」に定義し、(カ)
アカウントは、オファー管理の操作を使用して資産を売買するオファーを行うには、アカウントが売りたい資産を保持している必要があり、同様に、買おうとしている資産の発行者を信頼する必要があり、トラストラインはユーザのアカウントが発行アカウントを信頼している限度額と当該ユーザのアカウントが現在保有している発行アカウントからのクレジットの量を追跡し、特定の資産の金額を宛先アカウントに送信する支払い操作において、起こりうるエラーとして、「ソースアカウント(送信者)は、送信しようとしている資産の発行者を信頼していません。」という状態を示す「PAYMENT_SRC_NO_TRUST」、「受信者は、送信されている資産の発行者を信頼していません。」という状態を示す「PAYMENT_NO_TRUST」、及び「受信アカウントは、特定のクレジットについてのみ資産の発行者を信頼します。このトランザクションが成功した場合、受信者の信頼制限を超えます。」という状態を示す「PAYMENT_LINE_FULL」が、それぞれ定義されている、(キ)
ステラネットワークによる支払いの送受信を可能にする方法。」

(3)引用発明との対比
ア 対比
本件補正発明と引用発明とを、以下で対比する。

(ア)
あ ブロックチェーンとは、一定量のデータをブロックとしてまとめ、ブロックを鎖状(チェーン状)につなげたデータ構造をとり、チェーンを構成する後続のブロックに、1つ前に生成されたブロックのハッシュ値を格納することにより、改ざん耐性に優れたデータ構造のことである。そして、このブロックチェーンはBitcoinなどの仮想通貨の取引履歴の台帳に採用されており、仮想通貨の管理では、取引履歴を管理する台帳をブロックチェーンで構成し、ネットワーク上で複数のノードに台帳を保持した分散台帳とすることにより、取引履歴の改ざん耐性を高めている。そして、このようなネットワークでの取引履歴を分散台帳により管理する仕組みのことが、一般的には、「ブロックチェーン」と呼ばれている。
そこで、引用発明の「ステラネットワーク」について検討する。
引用発明の「ステラネットワーク」は、ネイティブ通貨としてルーメンを有するから、仮想通貨を管理するネットワークである。
「ステラネットワーク」は、「ステラコア」というネットワークノードで構成された分散システムであり、ステラコアは、台帳を管理するものである。
ステラコアは、台帳を閉じるとき、最後に台帳を閉じて以降に通知されたすべてのトランザクションを取得し、それらをトランザクションセットに収集するから、このトランザクションのセットは台帳を閉めるごとにトランザクションデータをブロックとしてまとめたものであり、このトランザクションをまとめたブロックが次々と台帳として記録されていく。また、ステラネットワークの各台帳は、一意の直前の台帳に暗号でリンクされており、ネットワークの履歴の中で最初の台帳であるジェネシス台帳のシーケンス番号を1とし、シーケンス番号nの台帳の直後の台帳のシーケンス番号をn+1とすることにより、台帳のシーケンス番号を再帰的に定義しており、すべての台帳が有する台帳ヘッダには、この台帳のシーケンス番号と、ジェネシス台帳に遡る台帳のチェーンを形成する直前の台帳ハッシュのフィールドを有する。
そうすると、引用発明の「ステラネットワーク」においては、仮想通貨の取引履歴を複数のノードにおいて分散台帳として管理し、台帳には時系列でトランザクションをまとめたブロックが記録され、台帳のブロックの前後関係は、台帳ヘッダに格納された、台帳の時系列による前後関係を特定し得るシーケンス番号と、ジェネシス台帳に遡る台帳のチェーンを形成する直前の台帳ハッシュで、紐付けるから、引用発明の「ステラネットワーク」は、ネットワークでの取引履歴を、チェーンを構成する後続のブロックに、1つ前に生成されたブロックのハッシュ値を格納した分散台帳により管理する仕組みの「ブロックチェーン」であることは明らかである。
よって、引用発明の「ステラネットワーク」は、本件補正発明の「ブロックチェーン」に相当する。
そして、引用発明の「ステラネットワーク」は、ネットワークのノードである「ステラコア」と、現行通貨とステラネットワークの間のブリッジとなる「アンカー」を含む構成であるが、引用発明の「ステラコア」は、トランザクションの台帳を管理するから、本件補正発明の「ブロックチェーンノード」に相当し、引用発明の「アンカー」は、銀行、決済代行業者などの金融機関であり、資産を発行するエンティティであるから、本件補正発明の「アンカー」に相当するものである。
い 引用発明の「ユーザ」は、ステラネットワーク上で、ユーザアカウントに資産を保有し、ユーザの資産を使用して他のユーザへの支払い操作を行うから、本件補正発明の「ブロックチェーンメンバー」に相当する。
う 引用発明の「トランザクション」は、「支払いの送信や、さまざまな種類の通貨の取引のオファーなどの操作を実行するために」作成されるものであるから、本件補正発明の「資産を移転するための資産移転要求」に相当する。
え 本件補正発明の「オフチェーン資産」とは、ブロックチェーン資産でない資産のことであり、現金、通貨等がこれに該当するから、引用発明の「現行通貨」及び「現金通貨」は、本件補正発明の「オフチェーン資産」に相当する。
お 本件補正発明の「最大信用資産限度」は、本願明細書の段落【0035】の記載によると、「トラストライン」のことであり、メンバーがアンカーに対して資産タイプごとに別々に設定することができ、アンカーがメンバーのブロックチェーン資産をオフチェーン資産に変換することができるブロックチェーン資産の限度額を示すものであり、一方、引用発明の「トラストライン」は、ユーザが定義した、「通貨の使用に関し、リスクを制限するための残高制限の設定のルール」であるから、引用発明の「トラストライン」は、本件補正発明の「最大信用資産限度」に相当する。
また、引用発明の「台帳」は、トラストラインを特定の金額に制限するトラストラインエントリを保持するから、引用発明のトラストラインのエントリを有する「ステラ台帳」(または「台帳」)は、本件補正発明の「最大信用資産限度を含む記録されたデータ」に相当する。
か 引用発明は、ステラネットワークを使用して、ステラネットワークで作成されたアカウントがお金を保持し、支払いの送受信を行う、ステラネットワークによる支払いの送受信を可能にする方法であり、引用発明の「支払いの送受信を行う」ことは、本件補正発明の「資産を移転する」ことに相当する。
また、引用発明の「ステラネットワーク」の「ステラコア」はネットワークのノードであるから、「ステラコア」における処理は「コンピュータ」で実行されることは明らかである。
よって、引用発明の「ステラネットワークによる支払いの送受信を可能にする方法」は、本件補正発明と同様の「資産を移転するためのコンピュータで実行される方法」といえる。

(イ)引用発明の「トランザクション」は、ユーザが、ユーザの資産を使用して他のユーザへの支払い操作を行うときに作成され、トランザクションは、「ステラコア」によって受信されるから、引用発明の、「ステラコア」の「コンピュータ」における、ユーザがそのユーザの資産を使用して他のユーザへの支払い操作を行うときに作成される「資産を移転するための資産移転要求(トランザクション)」を「受信」することは、本件補正発明の「ブロックチェーン内のブロックチェーンノードによって、前記ブロックチェーンに関連付けられたブロックチェーンメンバーに資産を移転するための資産移転要求を検出するステップ」に相当する。
さらに、引用発明の「ステラネットワーク」では、アンカーが資産コードを付与して資産の発行を行う発行者であり、ユーザが自らの資産を使用して他のユーザへの支払い操作を行うためには、ユーザはアンカーの付与した資産コードを選択する必要があり、さらに、資産コードを選択すれば、選択された資産コードに対応する(ウ)で後述する「Asset_code」を「トラストライン」において定義する「Asset_issuer」に対応するアンカーのいずれかが指定されたことになるから、引用発明の「資産コード」は、本件補正発明の「指定されたブロックチェーン資産タイプ」に相当し、引用発明のこのような「資産」は、本件補正発明と同様に「前記資産が、指定されたブロックチェーン資産タイプのものであり、かつ前記ブロックチェーンの指定されたアンカーによって発行され」るものである。
また、引用発明の「カスタム資産」は、ユーザが「お金」を銀行、決済代行業者などの機関である「アンカー」に預けたり、「アンカー」から取得するときに、アンカーのベースアカウントとの間で交換されるものであり、アンカーにより資産コードが付与された資産であることは明らかである。そうすると、引用発明の「アンカー」は、等価値の「お金」をアンカーで指定された資産コードを有する資産に変換するものといえる。
よって、引用発明の「アンカー」が、等価値の「お金」をアンカーで指定された資産コードを有する資産に変換することは、本件補正発明の「アンカーが、等価値のオフチェーン資産を前記指定されたブロックチェーン資産タイプの資産に変更される」ことに相当する。
したがって、引用発明の「ステラネットワーク」の「ステラコア」が、ユーザによる、ユーザの資産を使用して他のユーザへの支払い操作を行うときに作成される「トランザクション」を受信する処理であって、前記資産が、等価値の「お金」をアンカーで指定された資産コードを有する資産に変換するように構成されていることは、本件補正発明の「ブロックチェーン内のブロックチェーンノードによって、前記ブロックチェーンに関連付けられたブロックチェーンメンバーに資産を移転するための資産移転要求を検出するステップであって、前記資産が、指定されたブロックチェーン資産タイプのものであり、かつ前記ブロックチェーンの指定されたアンカーによって発行され、前記指定されたアンカーが、等価値のオフチェーン資産を前記指定されたブロックチェーン資産タイプの資産に変換するように構成される、ステップ」に相当する。

(ウ)引用発明において、「トラストライン」は、ユーザがアンカーに対して、200米ドルのように資産タイプや特定の金額を制限する指定をして、台帳のトラストエントリに記録されるものであり、アンカー、トラストラインの制限はユーザが任意に設定するものであるから、引用発明の、アンカーに対してユーザによって任意に指定されたトラストラインをトラストラインエントリに記録した台帳は、本件補正発明の「前記ブロックチェーン内の異なるアンカーに対して前記ブロックチェーンメンバーによって構成された異なる最大信用資産限度を含む記録されたデータ」に相当する。
また、引用発明のステラコアは、トランザクションを受信すると、トランザクションが有効かどうかを確認するための予備チェックを行うものであり、トランザクションには、支払いの送信の操作を実行するためのものが含まれているところ、支払いの操作に関して起こりうるエラーとして、「ソースアカウント(送信者)は、送信しようとしているアセットの発行者を信頼していません。」という状態を示す「PAYMENT_SRC_NO_TRUST」、及び「受信者は、送信されている資産の発行者を信頼していません。」という状態を示す「PAYMENT_NO_TRUST」が定義されており、これらは特定のアンカーを信頼するために作成すべき「トラストライン」が、支払いの送信元や受信者によって作成されていないことを示す。よって、引用発明の「PAYMENT_SRC_NO_TRUST」エラー、「PAYMENT_NO_TRUST」エラーとなる状態は、本件補正発明の「前記指定された資産タイプに対応し」た「最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず」という状態に相当する。
そして、引用発明の「トラストライン」は、(ユーザの)アカウントが特定の発行者(アンカー)に「特定の通貨」で付与した信用供与であり、(ユーザの)アカウントは、信頼の変更操作を使用して、特定の資産を信頼するという宣言を行い、例えば、ユーザがアンカーに対してトラストラインを200米ドルまで供与する場合、トラストラインの資産タイプのパラメータである「Line」を「USD:anchor」に、整数タイプのパラメータである「Limit」を「200」に定義するものである。ここで、資産タイプのパラメータは、USDやEURなどの識別子である「Asset_code」と、資産を発行するアカウントのIDである「Asset_issuer」の、2つのプロパティによって定義されており、トラストラインの資産タイプのパラメータである「Line」を「USD:anchor」に定義することにより、識別子「USD」で表される米ドルを「特定の通貨」として設定しているから、引用発明の「トラストライン」の設定対象となる「特定の通貨」は、本件補正発明の「指定された資産タイプ」に相当し、引用発明の「ステラコア」が、特定の資産の金額を宛先アカウントに送信する支払い操作のトランザクションが有効かどうかを確認するために行う「予備チェック」において、ユーザのアカウントが発行アカウントを信頼する制限(トラストライン)と当該ユーザのアカウントが現在保持している発行アカウントからのクレジットの量を追跡し、トラストラインに設定された「特定の通貨」について、ソースのアカウントが送信しようとしている資産の発行者を信頼しているか、受信者が送信されている資産の発行者を信頼しているかをチェックすることは、本件補正発明の「前記ブロックチェーン内の異なるアンカーに対して前記ブロックチェーンメンバーによって構成された異なる最大信用資産限度を含む記録されたデータに基づいて、最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず、かつ前記指定された資産タイプに対応していることを、前記ブロックチェーンノードによって決定するステップ」に相当する。
さらに、引用発明の「トラストライン」が、ユーザの「アカウント」によって「特定の発行者に特定の通貨で付与」されたものであり、「クレジットを法定通貨や貴金属等のステラ外部の対応する資産と交換する」アンカーを信頼するために、資産タイプのパラメータである「Line」と、トラストラインを特定の金額に制限するためのパラメータである「Limit」を有するものであることは、本件補正発明の「所与のアンカーおよび所与のブロックチェーン資産タイプに対する最大信用資産限度が、前記所与のブロックチェーン資産タイプの資産の前記最大信用資産限度をオフチェーン資産に変換するための、前記所与のアンカー内の前記ブロックチェーンメンバーの信用を示す」ことに相当する。
したがって、引用発明の「ステラコア」によって行われる「予備チェック」における上記のトラストラインと当該ユーザのアカウントが現在保持している発行アカウントからのクレジットの量を追跡し、トラストラインに設定された「特定の通貨」について、ソースのアカウントが送信しようとしている資産の発行者を信頼しているか、受信者が送信されている資産の発行者を信頼しているかをチェックすることは、本件補正発明の「前記ブロックチェーン内の異なるアンカーに対して前記ブロックチェーンメンバーによって構成された異なる最大信用資産限度を含む記録されたデータに基づいて、最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず、かつ前記指定された資産タイプに対応していることを、前記ブロックチェーンノードによって決定するステップであって、所与のアンカーおよび所与のブロックチェーン資産タイプに対する最大信用資産限度が、前記所与のブロックチェーン資産タイプの資産の前記最大信用資産限度をオフチェーン資産に変換するための、前記所与のアンカー内の前記ブロックチェーンメンバーの信用を示す、ステップ」に相当する。

(エ)上記(ウ)に示した事から、引用発明の、トランザクションによる支払いの送信の操作において、トラストラインに設定された「特定の通貨」について、起こりうるエラーとして定義される「PAYMENT_SRC_NO_TRUST」及び「PAYMENT_NO_TRUST」は、本件補正発明の「指定された資産タイプに対応し」た「最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず」という状態を示すものである。そして、引用発明の「ステラコア」が「予備チェック」を行った結果、「PAYMENT_SRC_NO_TRUST」及び「PAYMENT_NO_TRUST」のエラー状態の発生を検出した場合には、トランザクションによる支払いの送信の操作による支払いが行われないこと、すなわち、支払いの送信を禁止することは明らかである。
したがって、引用発明の「ステラコア」が「トラストライン」に基づいて、「特定の通貨」について、「PAYMENT_SRC_NO_TRUST」及び「PAYMENT_NO_TRUST」のエラーを検出して、トランザクションによる支払いの送信の操作による支払いの送信を禁止する処理は、本件補正発明の「前記最大信用資産限度が、前記指定されたアンカーに対して構成されておらず、かつ前記指定されたブロックチェーン資産に対応するとの、前記ブロックチェーンノードによる決定に応答して、前記ブロックチェーンノードによる前記資産への前記資産移転要求の適用を禁止するステップ」に相当する。

(オ)引用発明では、上記(ウ)の決定の結果、「PAYMENT_SRC_NO_TRUST」及び「PAYMENT_NO_TRUST」をエラーとして検出しなかった場合であっても、支払いの送信の操作において起こりうるエラーとして、「受信アカウントは、特定のクレジットについてのみ資産の発行者を信頼します。このトランザクションが成功した場合、受信者の信頼制限を超えます。」という状態を示す「PAYMENT_LINE_FULL」が定義されており、これは、受信者または受信アカウントにより設定された「トラストライン」の限度額に関しても、支払いの送信の可否の判断に利用することを意味するものであるから、「トラストライン」が設定されている場合に、限度額に関して支払いの送信の可否の判断のために「トラストライン」を取得することは明らかである。
してみると、引用発明の「ステラコア」が、上記(ウ)の決定の結果、支払いの送信元と受信者の双方で「トラストライン」が設定されていると判断した場合に、受信アカウントにより設定された「トラストライン」を取得する処理は、本件補正発明の「前記ブロックチェーンノードによって、前記最大信用資産限度が存在すると決定したことに応答して、前記ブロックチェーンメンバーによって構成された前記最大信用資産限度を取得するステップ」に相当する。

イ 一致点及び相違点
上記ア(ア)〜(オ)によれば、本件補正発明と引用発明との一致点、相違点は、次のとおりである。
[一致点]
「資産を移転するためのコンピュータで実行される方法であって、
ブロックチェーン内のブロックチェーンノードによって、前記ブロックチェーンに関連付けられたブロックチェーンメンバーに資産を移転するための資産移転要求を検出するステップであって、前記資産が、指定されたブロックチェーン資産タイプのものであり、かつ前記ブロックチェーンの指定されたアンカーによって発行され、前記指定されたアンカーが、等価値のオフチェーン資産を前記指定されたブロックチェーン資産タイプの資産に変換するように構成される、ステップと、
前記ブロックチェーン内の異なるアンカーに対して前記ブロックチェーンメンバーによって構成された異なる最大信用資産限度を含む記録されたデータに基づいて、最大信用資産限度が、前記指定されたアンカーに対して前記ブロックチェーンメンバーによって構成されておらず、かつ前記指定された資産タイプに対応していることを、前記ブロックチェーンノードによって決定するステップであって、所与のアンカーおよび所与のブロックチェーン資産タイプに対する最大信用資産限度が、前記所与のブロックチェーン資産タイプの資産の前記最大信用資産限度をオフチェーン資産に変換するための、前記所与のアンカー内の前記ブロックチェーンメンバーの信用を示す、ステップと、
前記最大信用資産限度が、前記指定されたアンカーに対して構成されておらず、かつ前記指定されたブロックチェーン資産に対応するとの、前記ブロックチェーンノードによる決定に応答して、前記ブロックチェーンノードによる前記資産への前記資産移転要求の適用を禁止するステップと、
前記ブロックチェーンノードによって、前記最大信用資産限度が存在すると決定したことに応答して、前記ブロックチェーンメンバーによって構成された前記最大信用資産限度を取得するステップとを含む、
方法。」

[相違点]
本件補正発明は、「前記資産移転要求によって示される前記資産の第1の額、および前記ブロックチェーンメンバーによってすでに保有され、前記指定されたアンカーによって発行され、前記指定された資産タイプである資産の第2の額を、前記ブロックチェーンノードによって取得するステップと、前記ブロックチェーンノードによって、前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であるか否かを判定するステップと、前記ブロックチェーンノードによって、前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であると判定したことに応答して、前記資産移転要求に基づいて資産移転を実行するステップ」を有するのに対し、引用発明は、これらのステップを有するか定かではない点。

(4)相違点についての判断
以下、相違点について検討する。
ア 相違点について
上記(3)ア(オ)で示したように、引用発明の「ステラコア」は、支払いの操作に関して起こりうるエラーとして、「受信アカウントは、特定のクレジットについてのみ資産の発行者を信頼します。このトランザクションが成功した場合、受信者の信頼制限を超えます。」という状態を示す「PAYMENT_LINE_FULL」が定義されていることから、当該トランザクションによる支払いの送信操作が「PAYMENT_LINE_FULL」で定義されたエラーの状態に該当するか否かについて、判断するものである。ここで、「PAYMENT_LINE_FULL」として定義されるエラーの状態である「このトランザクションが成功した場合、受信者の信頼制限を超えます。」とは、受信者側において、このトランザクションが成功した場合、すなわち支払いを受信した場合に、「受信者の信頼制限」、すなわち受信アカウントによって設定された「トラストライン」による、特定の通貨における取引金額の制限を超えてしまうことを意味することは明らかである。そして、上記(3)ア(ウ)で示したように、ユーザがアンカーに対してトラストラインを200米ドルまで供与する場合の例においては、トラストラインの資産タイプのパラメータである「Line」を「USD:anchor」に、整数タイプのパラメータである「Limit」を「200」に定義することにより、識別子「USD」で表される米ドルを「特定の通貨」とし、その「取引金額の制限」を「200」に設定しているから、「PAYMENT_LINE_FULL」で定義されたエラーの状態における「受信者の信頼制限を超えます。」とは、トランザクションが成功した場合に200米ドルを超えてしまうことを意味する。
また、引用発明において、ステラ台帳に保持される「トラストライン」は、「ユーザのアカウントが発行アカウントを信頼する制限」と「当該ユーザのアカウントが現在保持している発行アカウントからのクレジットの量」を追跡するものであり、前者の「ユーザのアカウントが発行アカウントを信頼する制限」は、受信者において上記の「受信者の信頼制限」に対応し、上記の例における「200米ドル」に対応するところ、後者の「当該ユーザのアカウントが現在保持している発行アカウントからのクレジットの量」は、受信者が支払いを受信した場合には、支払いの受信に係るクレジットの量と、受信者のアカウントが当該支払いを受信する前からすでに保有していたクレジットの量を加算した合計、すなわち、上記の例においては、受信者が受信した米ドルによる支払いに係るクレジットの量と、当該支払いを受信する前からすでに保有していた米ドルによるクレジットの量の合計を意味することは明らかであり、支払いの受信に係るクレジットの量は、本件補正発明の「資産移転要求によって示される前記資産の第1の額」に、受信者のアカウントが当該支払いを受信する前からすでに保有していたクレジットの量は、本件補正発明の「ブロックチェーンメンバーによってすでに保有され、前記指定されたアンカーによって発行され、前記指定された資産タイプである資産の第2の額」に、それぞれ相当する。
してみると、引用発明の「ステラコア」において、特定の資産の金額を宛先アカウントに送信する支払い操作における受信者側の「ユーザのアカウントが発行アカウントを信頼する制限」と「当該ユーザのアカウントが現在保持している発行アカウントからのクレジットの量」を追跡する処理を、「前記資産移転要求によって示される前記資産の第1の額、および前記ブロックチェーンメンバーによってすでに保有され、前記指定されたアンカーによって発行され、前記指定された資産タイプである資産の第2の額を、前記ブロックチェーンノードによって取得するステップ」とし、引用発明の「PAYMENT LINE FULL」エラーの状態となるか否かを判断すること、すなわち、送信される資産の金額を受信者が受信することにより、受信者の保有するクレジットの総量が受信者のトラストラインに設定された制限を超えるか否かを判断することを、「ブロックチェーンノードによって、前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であるか否かを判定するステップ」とすることは、当業者が容易に想到し得たことである。
そして、引用発明において、支払いの受信に係るクレジットの量と、受信者のアカウントが当該支払いを受信する前からすでに保有していたクレジットの量を加算した合計が、「受信者の信頼制限」を超える場合に、「PAYMENT_LINE_FULL」で定義されたエラーであると判断されるところ、当該エラーが検出された場合、上記の例においては、受信者が受信した米ドルによる支払いに係るクレジットの量と、当該支払いを受信する前からすでに保有していた米ドルによるクレジットの量の合計が200米ドルを超える場合には、支払いがエラー、すなわち、支払いが行われず、そうでない場合、すなわち、クレジットの量の合計が受信者の信頼制限以下、上記の例では200米ドル以下の場合に支払いが行われることは明らかである。
よって、引用発明は、受信者の保有するクレジットの総量が受信者のトラストラインに設定された制限を超える場合は、当該支払いの送信を実行するための「トランザクション」による支払いの送信をエラーとして行わず、受信者の保有するクレジットの総量が受信者のトラストラインに設定された制限以下の場合は、当該トランザクションによる支払いの送信を行うことにより、「前記ブロックチェーンノードによって、前記第1の額と前記第2の額の合計が前記最大信用資産限度以下であると判定したことに応答して、前記資産移転要求に基づいて資産移転を実行するステップ」とすることは、当然の帰結にすぎない。

イ 作用効果について
そして、上記の相違点を総合的に勘案しても、本件補正発明の奏する作用効果は、引用発明の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

ウ むすび
したがって、本件補正発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。

3 補正の却下の決定についてのむすび
よって、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので、同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって、上記補正の却下の決定の結論のとおり決定する。

第3 本願発明について
1 本願発明
令和3年4月16日にされた手続補正は上記のとおり却下されたので、本願の請求項1から11に係る発明は、令和2年9月17日の手続補正書により補正された特許請求の範囲の請求項1から11に記載された事項により特定されるものであるところ、その請求項1に係る発明(以下、「本願発明」という。)は、その請求項1に記載された事項により特定される、前記第2[理由]1(2)に記載のとおりのものである。

2 原査定の拒絶の理由
原査定(令和2年12月11日付け拒絶査定)の拒絶の理由1は、この出願の請求項1から11に係る発明は、その出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1に記載された発明であるから、特許法第29条第1項第3号の規定により特許を受けることができない、というものである。

引用文献1:Stellar developers Guides,[online],Stellar Development Foundation,2017年4月15日,全頁,[令和2年7月30日検索],インターネット

3 引用文献
原査定の拒絶の理由で引用された引用文献1及びその記載事項は、前記第2の[理由]2(2)に記載したとおりである。

4 対比・判断
本願発明は、前記第2の[理由]2で検討した本件補正発明から、本件補正による限定事項、すなわち、補正前の請求項2に記載された事項にさらに「前記ブロックチェーンメンバーによって構成された前記最大信用資産限度」の「取得」が「前記ブロックチェーンノードによって、前記最大信用資産限度が存在すると決定したことに応答して」なされる旨を加えた事項、を削除したものである。
そうすると、前記第2の[理由]2(3)ア(ア)〜(エ)に記載したとおり、本願発明と引用発明との間に相違点はない。
してみると、本願発明は、引用文献1に記載された発明であるから、特許法第29条第1項第3号に掲げる発明に該当する。

第4 むすび
以上のとおり、本願発明は、特許法第29条第1項第3号に掲げる発明に該当することから、特許を受けることができないものであり、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
よって、結論のとおり審決する。
 
別掲 (行政事件訴訟法第46条に基づく教示) この審決に対する訴えは、この審決の謄本の送達があった日から30日(附加期間がある場合は、その日数を附加します。)以内に、特許庁長官を被告として、提起することができます。

審判長 高瀬 勤
出訴期間として在外者に対し90日を附加する。
 
審理終結日 2022-05-30 
結審通知日 2022-06-06 
審決日 2022-06-20 
出願番号 P2019-531092
審決分類 P 1 8・ 113- Z (G06Q)
P 1 8・ 575- Z (G06Q)
P 1 8・ 121- Z (G06Q)
最終処分 02   不成立
特許庁審判長 高瀬 勤
特許庁審判官 相崎 裕恒
古川 哲也
発明の名称 資産移転方法および装置、ならびに電子デバイス  
代理人 飯田 雅人  
代理人 ▲高▼橋 史生  

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