ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06Q 審判 査定不服 2項進歩性 取り消して特許、登録 G06Q |
|---|---|
| 管理番号 | 1385092 |
| 総通号数 | 6 |
| 発行国 | JP |
| 公報種別 | 特許審決公報 |
| 発行日 | 2022-06-24 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2021-11-22 |
| 確定日 | 2022-06-07 |
| 事件の表示 | 特願２０２０−１０４３８３「プログラム、情報処理方法、サーバ、端末」拒絶査定不服審判事件〔令和 ４年 １月 ６日出願公開、特開２０２２− １９７１、請求項の数（２６）〕について、次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
| 理由 |
第１ 手続の経緯 本願は、令和２年６月１７日の出願であって、その手続の経緯は以下のとおりである。 令和２年１２月 ８日：拒絶理由通知書（起案日） 令和３年 ２月 ２日：意見書、手続補正書の提出 令和３年 ８月１２日：拒絶査定（起案日） 令和３年１１月２２日：審判請求書の提出 令和３年１２月２８日：拒絶理由通書（起案日） 令和４年 ３月１０日：意見書、手続補正書の提出 第２ 本願発明 本願請求項１〜２６に係る発明（以下、それぞれ「本願発明１」〜「本願発明２６」という。）は、令和４年３月１０日に提出された手続補正書による補正により補正された特許請求の範囲の請求項１〜２６に記載されたとおりのものであるところ、本願発明１、本願発明１３、本願発明１４、本願発明１５、本願発明１６、本願発明２４、本願発明２５、本願発明２６は以下のとおりのものである。 「【請求項１】 端末と通信するサーバによって実行されるプログラムであって、 第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を前記サーバの制御部によって行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を前記制御部によって行うこととが前記サーバによって実行される。」 「【請求項１３】 端末と通信するサーバの情報処理方法であって、 第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を前記サーバの制御部によって行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を前記制御部によって行うこととを含む。」 「【請求項１４】 端末と通信するサーバであって、 第１ユーザによる送金依頼に関する第１情報を前記端末に送信する通信部と、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を行う制御部とを備える。」 「【請求項１５】 端末と通信するサーバであって、 メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、 前記プロセッサーは、 第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を行うこととを実行する。」 「【請求項１６】 端末によって実行されるプログラムであって、 第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、 前記第１情報に基づく第１表示を前記端末の表示部によって表示することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を前記端末の制御部によって行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を前記制御部によって行うこととが前記端末によって実行され、 前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。」 「【請求項２４】 端末の情報処理方法であって、 第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、 前記第１情報に基づく第１表示を前記端末の表示部によって表示することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を前記端末の制御部によって行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を前記制御部によって行うこととを含み、 前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。」 「【請求項２５】 端末であって、 第１ユーザによる送金依頼に関する第１情報を受信する通信部と、 前記第１情報に基づく第１表示を表示する表示部と、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を行う制御部とを備え、 前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。」 「【請求項２６】 端末であって、 メモリに記憶されたプログラムを読み出し、前記プログラムに基づく処理を実行するプロセッサーを備え、 前記プロセッサーは、 第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、 前記第１情報に基づく第１表示を前記端末の表示部によって表示することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を行うこととを実行し、 前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む。」 なお、本願発明２〜１２は、本願発明１を減縮した発明であり、本願発明１７〜２３は、本願発明１６を減縮した発明である。 第３ 当審において通知した拒絶理由 当審において通知した、令和３年１２月２８日付けの拒絶理由（以下「当審拒絶理由」という。）の概要は、次のとおりのものである。 理由１ 特許法第36条第6項第2号（明確性） 請求項５、６、２２の記載、及び、請求項５を引用して記載した請求項６〜１２、請求項６を引用して記載した請求項７〜１２[W1]の記載は明確でない。 理由２ 特許法第29条第2項（進歩性） この出願の請求項１〜２５に係る発明は、その出願前に日本国内又は外国において、頒布された引用文献１及び引用文献２に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者（以下「当業者」という。）が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献１：Apple Inc.,"Send and receive money with Apple Pay" ,Apple Support ,2020年2月18日,URL= https://web.archive.org/web/20200311065810/https://support.apple.com/en-us/HT207875,オンライン，2021年12月7日検索 引用文献２：Maggie Maloney, "Everything You've Ever Wanted to Know About Venmo Etiquette", TOWN&COUNTRY, 2019年7月11日,Hearst Magazine Media,Inc., URL=https://www.townandcountrymag.com/society/money-and-power/a28244165/venmo-etiquette-guide/,オンライン，2021年12月7日検索 第４ 原査定の理由の概要 請求項１〜２５に係る発明は、引用文献Ａ〜Ｆに基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができない。 引用文献Ａ 特開２０１９−２０４５３６号公報 引用文献Ｂ 特開２０１９−１８５７６７号公報 引用文献Ｃ 特開２０１９−０８７０２６号公報 引用文献Ｄ 特開２０１０−１０８３４２号公報 引用文献Ｅ 特開２００２−０９２４９８号公報 引用文献Ｆ 特開２０１９−１９２０５４号公報 第５ 理由２ 特許法第29条第2項（進歩性）について １ 引用文献、引用発明 （１） 引用文献１について ア 引用文献１の記載事項 当審拒絶理由において、引用した引用文献１には、以下のとおりの記載がある。当審訳注の下線は、注目箇所である。  （当審訳） メッセージアプリで送金する方法 メッセージアプリでApple Payを利用して送金する場合、Apple Cashカードが優先して支払いに使われます。「デモ」をご覧いただくか、以下の手順により送金してください。 iPhoneまたはiPadの場合 １．メッセージアプリを開き、新しい会話を開始するか、既存の会話をタップします。 ２.「Apple Pay」ボタンをタップします。 「Apple Pay」ボタンがない場合は「App Store」ボタンを先にタップします。 ３．送金する金額を選択します。 ４．「支払う」をタップし、「送信」ボタンをタップして支払いの確認またはキャンセルをします。 ５．Face ID、Touch ID、またはパスコードで支払いを確認します。 送金した相手がまだお金を受け取っていない場合は、支払いをキャンセルすることができます。 支払い依頼に応答する １．メッセージアプリで依頼を開きます。 ２．「Apple Pay」ボタンをタップし、金額を選択します。 ３．「支払う」をタップし、支払いを送信し、Face ID、Touch ID、またはパスコードで確認します。 支払い依頼を断るには、メッセージを無視します。  （当審訳） 支払い依頼の送信の方法 Apple Payで支払い依頼を送信すると、相手は「支払う」をタップし、送金額を変更または確認することができます。 iPhoneの場合 １．メッセージアプリで会話を開くか、新規に会話を開始します。 ２．「Apple Pay」ボタンをタップします。 「Apple Pay」ボタンがない場合は、「App Store」のボタンを先にタップします。 ３．金額を選択し、「依頼」をタップします。 ４．依頼を送信します。 端末の表示画面 Hey! How much do I owe you for lunch? $14 Request （当審訳） やあ！昼食代はいくら？ １４ドルを依頼  （当審訳） 支払い方法を選択する １．金額を選択したら、送信ボタンをタップしてください。 ２．Apple Cashカードが自動的に優先して支払いに使用されます。Apple Cashカードで支払うことを選択し、支払いシートにカードが２枚表示された場合は、Apple Cashの残高が支払金額より少なくなっています。残額は、Walletにあるデビットカードのうちいずれか１枚によって支払われます。「矢印」をタップします。 ３．残金の支払いに使うデビットカードを選択します。 Apple Cashの残高がない場合、Walletにあるデビットカードで支払額の全額を支払うことができます。 どのカードが使われているかは、確認画面で確認できます。 イ 引用発明１ 上記アの記載によると、引用文献１には、 「メッセージアプリでApple Payを利用した送金について、 支払い依頼を行う場合、 メッセージアプリで会話を開くか、新規に会話を開始し、 「Apple Pay」ボタンをタップし、金額を選択し、「依頼」をタップすると、相手に支払いの依頼が送信され、 支払い依頼に応答する場合、 支払い依頼の送信を受けた相手は、メッセージアプリで支払い依頼を開き、送金額を変更または確認し、「支払う」ボタンをタップすることにより、支払い依頼者に送金される、 Apple Pay。」 の発明（以下「引用発明１」という。）が記載されている。 （２） 引用文献２について ア 引用文献２の記載事項 当審拒絶理由において、引用した引用文献２には、以下のとおりの記載がある。当審訳注の下線は、注目箇所である。 「Venmo is a quick, easy, and secure way to transfer money between two users. Gone are the days of divvying up bills with cash and-gasp-coins or taking turns "treating" one another to dinner. With Venmo, splitting just about any cost is fair game.」 （当審訳） Venmoは、２人のユーザ間で迅速、簡単、かつ安全に送金を行うことができるツールです。現金や小銭で支払いを分担したり、交互に夕食をごちそうになったりする時代は終わりました。Venmoを使えば、どんな費用でも公平に分割することができます。 「How quickly should you request payment via Venmo? You don't want to seem too eager, but it's important to request payment in a timely manner. The Venmo community set a 48 hour"Venmo lifecycle" standard in a recent survey on etiquette on the app. Most users agreed that it's best practice to send a request for payment within 24 hours of the original transaction. And, if you receive a request, you should do your best to pay it within 24 hours. Overall, the entire transaction should ideally take place within 48 hours. Meier encourages users to request payments as soon as the charge takes place-for example, if you're at a casual restaurant, Meier said you can even request payment on your phone as you pay the check at the table. If you're at a more formal locale where it would be poor etiquette to have your phone out, you can request or send payment as soon as you leave the restaurant.」 （当審訳） Venmoで支払いを依頼する場合、どれくらいのスピードが必要ですか？ あまり熱心すぎると思われるのも困りますが、タイムリーに支払いを依頼することが重要です。Venmoコミュニティは、アプリでのエチケットに関する最近の調査で、４８時間の「Venmoライフサイクル」基準を設定しました。ほとんどのユーザは、最初の取引から２４時間以内に支払いの依頼を送信することがベストプラクティスであることに同意しました。そして、依頼を受け取ったら、２４時間以内に支払うように最善を尽くすべきです。全体としては、４８時間以内に取引全体が行われるのが理想的です。 Meierは、請求が発生したらすぐに支払いを要求することをユーザに推奨し、例えば、カジュアルなレストランで食事をした場合、テーブルで会計をする際に携帯電話で支払いを依頼することもできますと、Meierは言う。フォーマルなレストランでは、携帯電話を持っているのはマナー違反なので、レストランを出てすぐに支払いを依頼したり送信したりすることができます。 「Venmo has a "remind" feature that can send a note to a user who has not completed a payment request. When should you use this function? While it may seem pushy to "remind" another user to fulfill your transaction (AKA pay you back), it's actually a really helpful tool. Venmo users agreed that you can "remind" someone to pay you back within four days of the original request. "It's much more everyday to just sent that remind function," Meier explains. "It kind of takes the awkwardness out of asking for money. So if somebody doesn't pay within four days, I wouldn't wait too much longer because then people really forget." Remember, the remind feature exists for a reason, so don't be afraid to use it.」 （当審訳） Venmoには「リマインド」機能があり、支払い依頼を完了していないユーザにメモを送ることができます。この機能はどのような場合に使うべきでしょうか？ 他のユーザに自分の取引（別名、支払い）を完了するよう「リマインド」するのは強引に思えるかもしれませんが、実際には本当に役に立つツールです。Venmoのユーザは、最初のリクエストから４日以内であれば、誰かに支払いを「リマインド」できることに同意しています。「リマインド機能を使う方が、ずっと日常的です。」とMeierは説明する。「お金を要求するときの気まずさを解消してくれます。もし、誰かが４日以内に支払わないなら、私は、それ以上は待たないでしょう。なぜなら、そのとき、人々は本当に忘れているからです。リマインド機能には理由があるので、恐れずに使ってみてください。 イ 引用発明２ 上記アの記載によると、引用文献２には、 「支払い依頼をされて、支払いを完了していないユーザに対して、 ４日以内に、「リマインド」を行うリマインドのメモを送る機能を有する ２人のユーザ間で送金を行うツール。」の発明（以下「引用発明２」という。）が記載されている。 ２ 本願発明１について （１） 対比 本願発明１と引用発明１とを対比する。 ア 引用発明１において、支払い依頼を行うユーザ、支払い依頼を受けたユーザの端末は、それぞれ、本願発明１の「第１ユーザ」、「端末」に相当する。 イ 引用発明１は、複数の端末間でメッセージアプリでの会話や送金処理を行うものであり、このような会話や送金処理を行う場合、近接の直接の通信でない限り、サーバを介してメッセージアプリでの会話の送受信、送金処理を行うことは技術常識であるから、引用発明１のメッセージアプリでの会話、Apple Payの送金処理においても、端末と通信する通信部を備えたサーバが存在し、サーバの通信部を介して端末と端末との間でデータの送受信を行うことは明らかである。 よって、引用発明１は、本願発明１と同様の「端末と通信するサーバによって実行されるプログラム」を有し、サーバは、当該プログラムによって動作することは明らかである。 ウ 引用発明１において、ユーザの端末は、支払い依頼の送信を受けるから、第１ユーザから支払い依頼に関する情報を受信することは明らかである。 そして、引用発明１の「支払い依頼」、「支払い依頼に関する情報」は、それぞれ、本願発明１の「第１ユーザによる送金依頼」、「第１ユーザによる送金依頼に関する第１情報」に相当する。 上記イを踏まえると、支払い依頼を行うユーザから送信された依頼は、サーバの通信部を介して、支払い依頼を受けるユーザの端末に送信されるから、引用発明１において、ユーザの端末が、第１ユーザから支払い依頼の送信を受けることは、本願発明１の「第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に送信すること」に相当する。 エ 引用発明１において、端末の「支払う」ボタンをタップすることにより、送金処理が行われるから、上記イを踏まえると、引用発明１は、本願発明１と同様に「前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理」が実行されるものである。 （２） 一致点、相違点 上記（１）によると、本願発明１と引用発明１とは、以下の一致点、相違点を有する。 ［一致点］ 端末と通信するサーバによって実行されるプログラムであって、 第１ユーザによる送金依頼に関する第１情報を前記サーバの通信部によって前記端末に 送信することと、 前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行される。 ［相違点］ 本願発明１は、前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく、前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する制御を前記サーバの制御部によって行い、前記送金処理が実行された場合、前記第２情報を前記通信部によって前記端末に送信しない制御を前記制御部によって行うものであるのに対し、引用発明１は、そのような構成を有しない点。 （３） 相違点に対する判断 ア ［相違点］について 支払い依頼に対して、支払者が支払いを完了していない場合、催促などを行うことは一般的に行われている事項であり、引用発明１と同様のユーザ間で送金を行うツールにおいて、引用発明２では、支払い依頼をされて、支払いを完了していないユーザに対して、４日以内に、「リマインド」を行うリマインド機能を有するから、引用発明１に引用発明２のリマインド機能を採用し、送金処理が実行されない場合にリマインドを行い、送金処理が実行された場合にリマインドを行わない構成とすることは当業者が容易に想到し得た事項であるといえる。 しかしながら、引用発明２にはリマインドのメモの送信元を表示することは記載がなく、引用発明１に引用発明２のリマインド機能を採用したとしても、リマインドに係る第２情報を「第１ユーザとは異なる送信元を前記端末に表示させるための」ものとすることは当業者が容易に想到し得た事項であるとはいえいない。 イ 作用効果について 本願発明１は、ユーザに代わって、業務用アカウントを利用するユーザに送金依頼を行わせることが可能となり、ユーザの利便性を向上させることができるという明細書の段落【０１８２】に記載された作用効果を奏するものである。 ウ 小括 したがって、本願発明１は、引用発明１及び引用発明２に基づいて、当業者が容易に発明をすることができたものではない。 ３ 本願発明２〜１２について 本願発明２〜１２は、本願発明１の「前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する」構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 ４ 本願発明１３について 本願発明１３は、本願発明１の「端末と通信するサーバによって実行されるプログラム」を、「端末と通信するサーバの情報処理方法」として記載した発明であり、本願発明１と同様に「前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する」構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 ５ 本願発明１４について 本願発明１４は、本願発明１の「端末と通信するサーバによって実行されるプログラム」を、「端末と通信するサーバ」として記載した発明であり、本願発明１と同様に「前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する」構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 ６ 本願発明１５について 本願発明１５は、本願発明１４の「サーバ」の処理を「サーバが備えるプロセッサ」が行うことを特定した発明であり、本願発明１と同様に「前記第１ユーザとは異なる送信元を前記端末に表示させるための第２情報を前記通信部によって前記端末に送信する」構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 ７ 本願発明１６について （１） 対比 本願発明１６と引用発明１とを対比する。 ア 引用発明１の「Apple Pay」は、携帯端末で動作するアプリケーションであるから、本願発明１６と同様の「端末によって実行されるプログラム」である。 イ 引用発明１の、支払い依頼を行うユーザは、本願発明１６の「第１ユーザ」に相当し、引用発明１の支払い依頼を受けたユーザの端末は、本願発明１６の「端末」に相当する。 ウ 引用発明１において、「Apple Pay」が動作する支払い依頼を受けたユーザの端末は、支払い依頼の送受信やそれに伴う表示を行うから、当該端末が通信部、表示部、制御部を備えていることは明らかである。 エ 引用発明１において、端末は、支払い依頼の送信を受けるから、支払い依頼に関する情報を端末の通信部によって受信し、端末の表示部に支払い依頼を表示することは明らかである。 そして、引用発明１の「支払い依頼」、「支払い依頼に関する情報」、「表示する支払い依頼」は、それぞれ、本願発明１６の「第１ユーザによる送金依頼」、「第１ユーザによる送金依頼に関する第１情報」、「前記第１情報に基づく第１表示」に相当する。 よって、引用発明１において、端末が、支払い依頼の送信を受け、当該端末に支払い依頼が表示されることは、本願発明１６の「第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、前記第１情報に基づく第１表示を前記端末の表示部に表示すること」に相当する。 オ 引用発明１では、端末の「支払う」ボタンをタップすることにより、送金処理が行われるから、引用発明１の送金処理は、端末の制御部が、端末のプログラムにより行うものといえる。 よって、引用発明１において、支払い依頼を受けたユーザが端末を操作することにより、支払い依頼を開いて、「支払う」ボタンをタップし、支払い依頼者に送金することは、本願発明１６の「前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理」に相当する。 （２） 一致点、相違点 上記（１）によると、本願発明１６と引用発明１とは、次の一致点、相違点を有する。 ［一致点］ 端末によって実行されるプログラムであって、 第１ユーザによる送金依頼に関する第１情報を前記端末の通信部によって受信することと、 前記第１情報に基づく第１表示を前記端末の表示部に表示することと、 記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理を行うこと。 ［相違点］ 本願発明１６は、「前記送金依頼に基づく、前記第１ユーザへの送金に関する送金処理が実行されない場合、前記送金依頼に基づく第２表示を前記表示部に表示する制御を前記端末の制御部によって行い、前記送金処理が実行された場合、前記第２表示を前記表示部に表示しない制御を行い」、「前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む」のに対し、引用発明１では、そのような構成を有しない点。 （３） 相違点に対する判断 ア 相違点について 支払い依頼に対して、支払者が支払いを完了していない場合、催促などを行うことは一般的に行われている事項であり、引用発明１と同様のユーザ間で送金を行うツールである引用発明２は、支払い依頼をされて、支払いを完了していないユーザに対して、４日以内に、「リマインド」を行うリマインド機能を有するから、引用発明１に引用発明２のリマインド機能を採用し、リマインドとして、送金処理が実行されない場合に、送金依頼に基づく、第２表示を前記表示部に表示し、送金処理が実行された場合、第２表示を表示部に表示しないように制御する構成することは当業者が容易に想到し得た事項であるといえる。 しかしながら、引用発明２にはリマインドのメモの送信元を表示することは記載がなく、引用発明１に引用発明２のリマインド機能を採用したとしても、リマインドに係る第２表示を「前記第１ユーザとは異なる送信元の情報を含む」ものとすることは当業者が容易に想到し得た事項であるとはいえいない。 イ 作用効果について 本願発明１６は、ユーザに代わって、業務用アカウントを利用するユーザに送金依頼を行わせることが可能となり、ユーザの利便性を向上させることができるという明細書の段落【０１８２】に記載された作用効果を奏するものである。 ウ 小括 したがって、本願発明１６は、引用発明１及び引用発明２に基づいて、当業者が容易に発明をすることができたものではない。 ８ 本願発明１７〜２３について 本願発明１７〜２３は、本願発明１６の表示部に表示される「前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む」構成を備えるものであるから、本願発明１６と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 ９ 本願発明２４について 本願発明２４は、本願発明１６の「端末によって実行されるプログラム」を「端末の情報処理方法」として記載した発明であり、本願発明１６と同様に表示部に表示される「前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む」構成を備えるものであるから、本願発明１６と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 １０ 本願発明２５について 本願発明２５は、本願発明１６の「端末によって実行されるプログラム」を「端末」として記載した発明であり、本願発明１６と同様に表示部に表示される「前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む」構成を備えるものであるから、本願発明１６と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 １１ 本願発明２６について 本願発明２６は、本願発明２５の「端末」の処理を端末が備える「プロセッサ」が行うことを特定した発明であり、本願発明１６と同様に表示部に表示される「前記第２表示は、前記第１ユーザとは異なる送信元の情報を含む」構成を備えるものであるから、本願発明１６と同じ理由により、当業者であっても、引用発明１及び引用発明２に基づいて容易に発明をすることができたものとはいえない。 第６ 理由１ 特許法第36条第6項第2号（明確性）について （１）請求項５について 令和４年３月１０日に提出された手続補正書による補正により、当該補正前の請求項５は削除された。 （２）請求項６について 令和４年３月１０日に提出された手続補正書により補正された請求項５は、当該補正前の請求項６に対応する請求項であり、請求項５において、「第４情報」が「第３情報」と補正されたことにより、請求項５の記載は明確となった。 （３）請求項２２について 「前記第２表示が前記表示部に表示された後、前記送金処理が前記制御部によって行われ ない場合、前記送金依頼に基づく第３表示を前記表示部に表示する制御を行」うことが特定されたため、請求項２２の記載は明確となった。 （４）上記（１）〜（３）のとおり、当審拒絶理由の理由２は解消した。 第７ 原査定について １ 原査定の拒絶の理由に引用された引用文献の記載事項 （１）引用文献Ａ 原査定の拒絶の理由に引用された引用文献Ａの段落【００２９】、【０１５０】〜【０１９１】には、次の事項が記載されている。 メッセージング・システムにおいて、送金する送信者（ドナルド）が、支払い額と支払い方法（クレデンシャル）を決めて、メッセージを受信者（ジョー）に送信する。受信者は、支払いを承認し、自己の受け取り方法（クレデンシャル）を指定すると、送信者から受信者へ資金の移動が行われる。メッセージング・システムは、リマインダ・オプションを提供し、送信者がクレデンシャルを入力していないとき、受信者の端末に、送信者に対して、支払い取引についてクレデンシャルを入力することによって支払い取引を完了させるためのリマインダ・メッセージを送信させることができる。 （２）引用文献Ｂ 原査定の拒絶の理由に引用された引用文献Ｂには、次のとおりの記載がある。 【００６５】 電子機器１１０のプロセッサ２１２は、ユーザが会話相手リスト７１０から少なくとも１人以上を選択して「送金する」ＵＩ７２０を入力した場合、図８に示すように、送金情報確認のための送金確認画面８２０を提供してよい。送金確認画面８２０は、金額や送金対象者などを確認あるいは修正するためのユーザインタフェースで構成されるものであって、お金を受け取る人として特定された送金対象者リスト８０１、送金対象者を追加するための「追加」ＵＩ８０２、送金金額を確認するか新たに入力するための金額入力ウィンドウ８０３、金額入力ウィンドウ８０３に入力された金額を送金対象者リスト８０１に含まれた人数で割って処理するための分割ＵＩ８０４などを含んでよい。 【００６７】 電子機器１１０のプロセッサ２１２は、ユーザが送金確認画面８２０で「送金する」ＵＩ８０５を入力すると、送金対象者リスト８０１に含まれた送金対象者に、金額入力ウィンドウ８０３に入力された金額に対する送金トランザクションを処理してよい。電子機器１１０のプロセッサ２１２は、お金を受け取る人に送金トランザクションによる送金メッセージを発送してよく、このとき、送金メッセージは、送金対象者それぞれの個別チャットルーム８００−１、８００−２に表示されてよい。この他にも、メッセンジャーチャットルーム７００がグループチャットルームの場合、送金メッセージはグループチャットルームに表示されてよく、グループチャットルームであったとしても、送金メッセージが電子機器１１０のユーザと送金対象者だけに伝達されて表示されるようにすることも可能である。 （３）引用文献Ｃ 原査定の拒絶の理由に引用された引用文献Ｃの段落【００９８】〜【０１０１】、【０１１２】、【０１１３】、【０１４８】〜【０１５８】には、次の事項が記載されている。 割り勘で支払いを行うとき、保証人を設定し、依頼元が支払うことができない場合にその費用を保証人が支払うこと。 （４）引用文献Ｄ 原査定の拒絶の理由に引用された引用文献Ｄには、次のとおりの記載がある。 【０１６２】 また、図４のステップＳ１６における返済期限は、所定の期間に設定されるが、入質者のインターネットを介しての申し出により、例えば、出資者の同意及び特別な金利（延長期間分の金利に加えて）の支払いを条件に延長するようにしてもよい。かかる同意（不同意）及び延長許可（延長不許可）に関する情報の送受信はインターネットを介して行うことができる。 （５）引用文献Ｅ 原査定の拒絶の理由に引用された引用文献Ｅには、次のとおりの記載がある。 【００６１】制御部３０１は、タイマー３０３から時間情報を入力し、入力した時間情報に応じて支払い催促を行うタイミングを制御する。なお、タイマー３０によって管理された時間情報には、例えば年、月、日そして時、分、秒などの情報が含まれている。制御部３０１は入力された時間情報の日が記憶部３０４に記憶されている催促通知の予備期限の日と一致したとき、インターフェース部３０５を介して、投資家に催促の通知をする。催促通知の方法は、電子メール、ウェブメッセージの他、通常の郵便送達などの方法も考えられる。なお、支払い管理サーバ装置３４は、投資家からの入金が確認された時点で、該当する件の支払い管理が完了するので、支払い完了の知らせを運営管理サーバ装置３５に送信し、上記催促通知処理を中止する。 【００６２】上述した処理によって、支払い管理サーバ装置３４は、投資家の過去の支払い状況に応じて、実際の締切り日より予備日数分早い日を予備期限として、予備期限の日に達したとき該当する投資家からの入金が確認されていない場合、その投資家に支払いの催促通知をする。催促通知が設定された回数分まで行われるが、途中で投資家からの入金が確認されたとき、催促通知を中止させ、該当する件の支払い管理が完了する。 （６）引用文献Ｆ 原査定の拒絶の理由に引用された引用文献Ｆには、次のとおりの記載がある。 【００４０】 リマインダー処理部３２は、健康状態の検診を行う時期が近づいた際に高齢者３に対してアンケートを受けるようにメールなどを通じて通知する機能を有している。リマインダー処理部３２は、検診時期が過ぎた場合も高齢者３が検診を受けるまで継続的に通知を行う。リマインダー処理部３２は、上記と同様の通知を家族６に対しても行うことが出来る。 【００４１】 アンケート送受信処理部３４は、健康状態の検診時期に高齢者３の端末３０に対して、アンケート用ウェブサイトのＵＲＬを記載したメールを送信する。高齢者３が端末３０を用いてアンケート用ウェブサイトにアクセスし、アンケートに回答するとアンケートの受信を完了したとして、リマインダー処理部３２によるリマインド機能を停止する。 ２ 原査定の理由に対する判断 令和４年３月１０日に提出された手続補正書による補正により、本願発明１〜１５は、リマインドに係る第２情報を「第１ユーザとは異なる送信元を前記端末に表示させるための」ものとすること、本願発明１６〜２６は、リマインドに係る第２表示を「前記第１ユーザとは異なる送信元の情報を含む」ものとすることを特定するものとなっており、当業者であっても、原査定の拒絶の理由に引用された引用文献Ａ〜Ｆに記載された発明に基づいて、容易に発明をすることができたものとはいえない。したがって、原査定の理由を維持することはできない。 第８ むすび 以上のとおり、本願発明１〜２６は、引用発明１及び引用発明２に基づいて当業者が容易に発明をすることができたとはいえない。 また、本願発明１〜２６は、引用文献Ａ〜Ｆに記載された発明に基づいて当業者が容易に発明をすることができたとはいえない。 また、本願の特許請求の範囲の記載は明確である。 したがって、原査定の理由及び当審拒絶理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
| 審決日 | 2022-05-24 |
| 出願番号 | P2020-104383 |
| 審決分類 |
P
1
8・
537-
WY
(G06Q)
P 1 8・ 121- WY (G06Q) |
| 最終処分 | 01 成立 |
| 特許庁審判長 |
渡邊 聡 |
| 特許庁審判官 |
高瀬 勤 関口 明紀 |
| 発明の名称 | プログラム、情報処理方法、サーバ、端末 |
| 代理人 | 加美山 豊 |
| 代理人 | 山田 勉 |
| 代理人 | 富崎 曜 |
| 代理人 | 富崎 元成 |