【事件の表示】
　特願２０１７−　９５７０２「通知方法，ユーザ端末，及び通知プログラム」拒絶査定不服審判事件〔平成２９年　９月２８日出願公開，特開２０１７−１７０１６４〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成２５年９月３０日（以下，「原々々々出願日」という。）に出願された特願２０１３−２０４２０６号（以下，「原々々々出願」という。）の一部を，平成２７年６月２５日に新たな特許出願とした特願２０１５−１２７５４５号の一部を，平成２７年１２月２５日に新たな特許出願とした特願２０１５−２５３１２０号の一部を，平成２９年３月１４日に新たな特許出願とした特願２０１７−４８５５１号の一部を，平成２９年５月１２日に新たな特許出願とした出願であって，平成３０年３月１３日付けで拒絶理由が通知され，同年５月１８日に意見書及び手続補正書が提出され，同年１０月２日付けで拒絶査定（以下，「原査定」という。）がされ，それに対して，同年１２月２６日に拒絶査定不服審判が請求されるのと同時に手続補正書（以下，当該本件補正書による手続補正を「本件補正」という。）が提出されたものである。
第２　本願発明
　本願の請求項１ないし８に係る発明は，本件補正後の特許請求の範囲の請求項１ないし８に記載された事項によって特定されるものであり，そのうち請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
　
　「【請求項１】
　複数のゲームに関する通知を行う方法であって，
　ユーザ端末の表示部に接続された制御部が，
　前記ユーザ端末におけるゲームの使用状況を取得し，
　前記ユーザ端末で使用中のゲームを継続可能な状態で，前記ゲームとは別のゲームであって使用中ではないゲームの体力情報をネットワークを介して取得し，
　前記体力情報に基づき，継続可能な前記ゲームのゲーム画面内で，前記別のゲームにおける体力の回復状況に応じた体力情報を前記表示部に出力する
　ことを特徴とする通知方法。」
第３　原査定の理由の概要
　原査定の拒絶の理由は，平成３０年５月１８日に提出された手続補正書により補正された本願の請求項１に係る発明は，その出願（特許法４４条２項の規定により，原々々々出願の出願の時に出願されたものとみなす。）の日（原々々々出願日）より前の特許出願であって，本願の出願後に特許掲載公報の発行又は出願公開がされた特許出願である下記の先願の願書に最初に添付された明細書，特許請求の範囲又は図面（以下，「先願明細書等」という。）に記載された発明と同一であり，しかも，本願の発明者が先願に係る上記発明をした者と同一ではなく，また本願の出願の時において，本願の出願人が上記先願の出願人と同一でもないから，特許法２９条の２の規定により，特許を受けることができない，というものを含むものである。
　　　　　　　　　　　　　　　記
先願：特願２０１２−１３１４３１号（特開２０１３−２５５５２６号）
第４　先願及び引用発明
　１　先願明細書等の記載事項
　先願は，本願の出願日より前の平成２４年６月８日に出願され，本願の出願後である平成２５年１２月２６日に特開２０１３−２５５５２６号として出願公開がされたものであるところ，先願明細書等には，次の事項が記載されている。なお，下線は引用発明の認定に用いた箇所を強調するために，当審において付加したものである。
（１）　「【背景技術】
【０００２】
　近年，特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される，いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは，不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは，インターネットに接続可能であって，かつウェブブラウザが搭載された通信端末を備えていれば，時間と場所を問わずソーシャルゲームを楽しむことができる。
【０００３】
　ソーシャルゲームの一例として，下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。ソーシャルゲームには，例えばユーザの体力ポイントが設定され，ゲームの進行に応じてポイント（例えば，体力ポイント）が消費されていき，ポイントが消費できなくなると，ユーザによるゲームの進行ができなくなるものがある。このポイントは，例えば一定時間に所定量だけ増加（回復）するため，時間が経過するとユーザは再度ゲームを進行することができる仕組みとなっている。」
（２）　「【発明が解決しようとする課題】
【０００５】
　ところで，ユーザは，複数のソーシャルゲームに登録していることがある。このとき，ユーザは従来，登録済みのいずれかのゲームを実行した結果，そのゲームの進行ができなくなった場合には，登録済みのゲームの中から実行可能な他のゲームを選択して，選択したゲームを実行していた。ここで，例えば，ゲームを十分に進行させることができる程度にポイントが回復しているかについての情報は，そのゲームにアクセスするまで分からないため，ユーザは，登録済みのゲームを手当たり次第アクセスしてゲームを十分に実行可能かどうか確認する必要があり，面倒であった。
【０００６】
　本発明は上述した観点に鑑みてなされたもので，あるゲームを実行中，あるいは実行しようとするユーザが別のゲームについての自らの情報を知ることができるようにしたゲーム制御装置，ゲーム制御方法，プログラム，ゲームシステムを提供することを目的とする。」
（３）　「【００４０】
　＜第１の実施形態＞
　（１）ゲームシステムの構成
　図１は，本実施形態のゲームシステムのシステム構成例を示している。図１に示すように，この
ゲームシステムは
通信網ＮＷ
に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と，通信網ＮＷに接続されているゲームサーバ２０ａ，２０ｂ，２０ｃ，…と，データベースサーバ３０ａ，３０ｂ，３０ｃ，…とによって構成されている。
【００４１】
　このゲームシステムにおいて，
ゲームサーバ２０ａは，クライアントである通信端末１０と通信可能に構成され，ゲームサーバ２０ａとデータベースサーバ３０ａは，通信端末１０に対してゲームＡについてのサービスを提供する。
　ゲームサーバ２０には，ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は，ゲームを実行する上での後述する様々な情報を格納しており，それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
　通信端末１０は，ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており，ユーザは，通信端末１０に表示されるウェブページ上のメニュー等を選択する操作を行うことでゲームを実行する。
【００４２】
　図１には図示していないが，ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また，多くの通信端末１０からのアクセスを受け
入れるために複数のゲームサーバ２０を設ける場合は，その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また，ゲームサーバ２０は単一のサーバ装置として構成してもよいが，機能を分散させた複数のサーバ装置として構成してもよい。
【００４３】
　（２）通信端末の構成
　図２及び図３を参照して通信端末１０について説明する。
　図２は，通信端末１０の外観の例を示す図であって，（ａ）は，例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり，（ｂ）は，例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は，通信端末１０の内部構成を示すブロック図である。
　図３に示すように，
通信端末１０は，
表示部１６，
が設けられている。
【００４４】
　ＣＰＵ１１は，ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして，ＣＰＵ１１は，指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき，通信インタフェース部１７を介して，ゲームサーバ２０からウェブページを表示するためのデータ，すなわち，ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下，総称して適宜「ＨＴＭＬデータ」と表記する。）を通信インタフェース部１７を介して取得し，そのＨＴＭＬデータを解釈する。なお，通信端末１０には，ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてもよい。そのようなプラグインの一例は，アドビシステムズ社（米国）によるフラッシュプレイヤである。
　なお，ＨＴＭＬデータの取得に当たって，ＣＰＵ１１は，予め登録されたユーザＩＤ（ユーザ識別情報），あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを，通信インタフェース部１７を介してゲームサーバ２０へ通知する。
【００４５】
　ウェブブラウザは，ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは，ゲームサーバ２０から取得したＨＴＭＬデータを解釈して，画像処理部１４を介して
ウェブページを表示部１６に表示する。
【００４６】
　画像処理部１４は，ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて，表示部１６にウェブページを表示する。表示部１６は，例えば，マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり，表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。」
（４）　「【００５４】
　（４）データベースサーバの構成
　データベースサーバ３０（記憶装置）は，大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等，汎用ストレージで実現できる。データベースサーバ３０内の各データベースは，ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
　データベースサーバ３０の構成は，処理対象となるゲームによって異なるが，ここでは説明の簡略化のために，いずれのデータベースサーバ３０についても図６に示した共通の構成を備えているものとする。図５に示すように，データベースサーバ３０は，ユーザデータベース３１と，ゲームデータベース３２とを備える。
【００５５】
　本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが，以下では，実施形態の説明の便宜上，ゲームサーバ２０によって実現されるゲームの一例として，ゲームキャラクタの画像が表示されるカードを使用するデジタルカードゲームを採り上げる。つまり，ゲームサーバ２０ａ，２０ｂ，…はそれぞれ，デジタルカードゲームであるゲームＡ，ゲームＢ，…をそれぞれ実行するものとする。
【００５６】
　図６に，本実施形態のデジタルカードゲーム（以下適宜，単に「ゲーム」あるいは「本実施形態のゲーム」という。）において適用されるユーザデータベース３１の一例を示す。この例では，ユーザデータベース３１は，ユーザＩＤ（ユーザ識別情報）ごとに，ユーザ名，進行レベル，体力ポイント，経験値，仲間のユーザＩＤ，保有カード，保有アイテムの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は，ゲームサーバ２０によって逐次更新されうる。
【００５７】
　以下の説明では，ユーザデータベース３１に含まれるユーザＩＤ，あるいはユーザを特定するユーザ名ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは，以下のとおりである。
　本実施形態のゲームシステムでは，複数のゲームサーバ２０ａ，２０ｂ，２０ｃ，…が共通のプラットフォーム上に実装されており，複数のゲームＡ，Ｂ，Ｃ，…において同一のユーザは同一のユーザＩＤによって管理される。
・ユーザ名
　ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は，ユーザＩＤと同様に，複数のゲームＡ，Ｂ，Ｃ，…において同一のユーザは同一のユーザ名によって管理されてもよいし，ゲーム毎に異なるユーザ名が設定できるようにしてもよい。
・進行レベル
　各ゲーム上のユーザの進行レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。経験値が所定値に達すると進行レベルが１つ上昇する。
・体力ポイント
　
本実施形態のゲームにおいて，後述するクエストを行う上で必要となるポイントである。体力ポイントは，クエストを行う度に低減し，所定の時間が経過する毎に回復（増加）する値である。
・経験値
　本実施形態のゲームにおいて，後述するクエストを行う上で増加する値である。経験値が所定の値（例えば，１００）に達すると，進行レベルが１増加して経験値はリセットされる（つまりゼロになる）。
・仲間のユーザＩＤ
　ユーザがゲーム上で仲間（後述する）の関係にあるユーザＩＤである。
・保有カード
　保有カードは，ゲーム上でユーザが保有しているカードのデータ（例えばＣ１等のカードの種類を示す識別子など）である。各カードは，例えばゲーム内のバトル等で参照されるパラメータ（つまり，攻撃力と防御力等の能力値）が対応付けられてもよい。
・保有アイテム
　保有アイテムは，ゲーム上でユーザが保有しているアイテムのデータ（例えばＩｍ１等のアイテムの種類を示す識別子など）である。」
（５）　「【０１０７】
　＜第４の実施形態＞
　次に，本発明の第４の実施形態について説明する。本実施形態のゲームシステムを構成する各要素（通信端末１０，ゲームサーバ２０及びデータベースサーバ３０）のハードウエア構成は，第１の実施形態と同じでよい。
【０１０８】
　（１）ゲーム制御装置が備える機能の概要
　本実施形態のゲーム制御装置の機能ブロック図を，図１６に示す。図１６に示すように，本実施形態は，第１の実施形態（図９）と比較して，第２判定手段５８が追加された点で異なる。第２判定手段５８は，情報取得手段５５により取得された，ユーザのアクセス対象のゲームとは別のゲーム（第２ゲーム）のユーザの体力ポイント（ユーザ情報）が第２条件を満たすか否かを判定する機能を備える。
【０１０９】
　第２判定手段５８の機能を実現するために，ゲームサーバ２０ａのＣＰＵ２１は，ユーザのアクセス対象のゲームとは別のゲームのユーザの体力ポイント（ユーザ情報）を取得すると，その体力ポイントが第２条件を満たすか否かを判定する。例えば，別のゲームにおいて，１回のクエストの実行に「８」の体力ポイントを要し，かつ別のゲームにおけるユーザの体力ポイントが「８」以上である場合には，体力ポイントを消費して少なくとも１回のクエストを実行できるため，第２条件を満たしたことになる。
　なお，ここでは，ユーザのアクセス対象のゲーム（第１ゲーム）と別のゲーム（第２ゲーム）とがそれぞれクエストの処理を行うように構成されている場合を例示したが，この例に限られない。それぞれ別々のゲームであり，そのゲームに設けられる機能は異なってもよいため，第１判定手段５４における第１条件と，第２判定手段５８における第２条件の判定の基礎となるデータはそれぞれ異なっていてよい。
【０１１０】
　本実施形態において，通知手段５６は，第２判定手段５８により第２条件を満たすと判定された場合に，ユーザのアクセス対象のゲームとは別のゲーム（第２ゲーム）のユーザの体力ポイント（ユーザ情報）をユーザに通知してもよい。
【０１１１】
　（２）本実施形態のゲーム制御装置の主要な処理のフロー
　次に，本実施形態のゲームシステムにより行われる主要な処理のフローの一例について，図１７を参照して説明する。図１７は，本実施形態のゲーム制御装置において，
実行中のゲームとは異なるゲームの情報をユーザに提示する
　なお，図１７のシーケンスチャートは，図１１と同様に，ユーザがゲームＡを実行中である場合の例である。
　
特定のユーザＵ１の通信端末１０からのＨＴＴＰリクエスト
に応じて，ゲームＡを実行するゲームサーバ２０ａのＣＰＵ２１は，
第１条件を満たした
と判定した場合には，別のゲームＢ，Ｃ，Ｄ，…を実行するゲームサーバ２０ｂ，２０ｃ，２０ｄ，…のＡＰＩサーバ２６に対して，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイント（ユーザ情報の例）を取得するためのリクエストを生成するように，ゲームサーバ２０ａのＡＰＩサーバ２６を制御する
これにより，ゲームサーバ２０ａのＡＰＩサーバ２６からゲームサーバ２０ｂ，２０ｃ，２０ｄ，…のＡＰＩサーバ２６に対して上記リクエストが送られる
このリクエストには，処理対象となるユーザＵ１のユーザＩＤが含まれる。リクエストを受けたゲームサーバ２０ｂ，２０ｃ，２０ｄ，…の各々のＣＰＵ２１は，そのリクエストの対象となるユーザＩＤをキーとしてユーザデータから，ユーザ情報として体力ポイントを抽出する
ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…の各々のＡＰＩサーバ２６は，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…おける体力ポイントの値を含むレスポンスを，ゲームサーバ２０ａのＡＰＩサーバ２６に返す
【０１１２】
　
ゲームサーバ２０ａのＣＰＵ２１は，ゲームサーバ２０ｂから，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントを取得すると，第２条件を満たすか否かを判定する
ゲームＢ，Ｃ，Ｄ，…におけるユーザＵ１の体力ポイントが，各ゲームの１回のクエストの実行に要する体力ポイント以上である場合に，第２条件を満たしたと判定する。第２条件を満たすゲームが存在する場合
，ゲームサーバ２０ａのＣＰＵ２１は，
これによって，ユーザの通信端末１０には，ゲームＡのウェブページが更新される
更新されたゲームＡのウェブページには，
体力ポイントが含まれることになる。
　なお，
ステップＳ１５７でゲームを選択することは必ずしも必要ではなく，第２条件を満たすすべてのゲームにおける体力ポイントと，そのすべてのゲームにおけるバナーをＨＴＭＬデータに含めてもよい。
【０１１３】
　上述したように本実施形態では，アクセス対象のゲームＡ（第１ゲーム）とは別のゲームＢ，Ｃ，Ｄ，…（第２ユーザ）の体力ポイント（ユーザ情報）を闇雲にユーザに通知するのではなく，第２条件を満たす場合にその体力ポイントを通知することで，適切な第２ゲームについての体力ポイントをユーザに通知することができるようになる。これにより，クエストを実行可能な第２ゲームの体力ポイントを通知するようにすることができ，ゲームＡを進行させることができなくなった時点で，別のゲームを進行させることができることをユーザが認識することができる。」
（６）　「【０１１７】
　上述した各実施形態では，ユーザ情報のユーザへの通知の態様として，ウェブページ等のゲーム画像にユーザ情報（例えば，体力ポイント）が表示される場合について説明したが，ユーザ情報の通知の態様は表示に限られない。ユーザへのユーザ情報の
通知方法
【０１１８】
　上述した各実施形態について，ユーザ情報の一例としてゲームを進行させる上での体力ポイントを挙げたが，取得対象となるユーザ情報は，ゲームの性質や第１判定手段における第１条件の内容に応じて適宜設定されてよい。
　例えば，ゲームキャラクタの攻撃力及び防御力がゲームの進行に応じて変動するバトルゲームの場合，ユーザ情報は，その攻撃力及び防御力を示すゲームキャラクタのパラメータの値であってもよい。
　また，上述した実施形態では，第１条件として，クエストを実行できないためにゲームを進行させることができないことを条件とした場合を例示したが，このような条件に限られない。例えば
ユーザがアクセス中のゲームＡを進行させることができる場合
であっても，ゲームＡの区切りのタイミング
に，ゲームＡ以外の他のゲームのユーザ情報を取得し，そのユーザ情報をユーザに通知するようにしてもよい。
第１条件は，
ユーザによるゲームの進行によってゲームＡの区切りの位置に達したことであってよい。
　例えば，ゲームＡ以外の他のゲームにおいて，ゲームＡにアクセスしているユーザ宛の仲間申請を受けている場合や，そのユーザ宛のトレードの申請・返答がある場合，プレゼントが届いている場合など，ゲームＡ以外のゲームにおいてユーザ向けのイベントが生じている場合には，そのイベントの内容をユーザ情報として通知してもよい。このような通知によって，ゲームＡにアクセスしているユーザが適時に他のゲームにアクセスして所要の操作を行うことができる。」
（７）　「【図１７
」
（８）　図１７からは，ゲームサーバ２０ａへのレスポンスであるユーザ情報は，ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…からのものであることが看取できる。
（９）　段落【０１０７】の「次に，本発明の第４の実施形態について説明する。本実施形態のゲームシステムを構成する各要素（通信端末１０，ゲームサーバ２０及びデータベースサーバ３０）のハードウエア構成は，第１の実施形態と同じでよい。」という記載に照らせば，上記（３）及び（４）で摘記した，通信端末１０，ゲームサーバ２０に関する記載は，上記（５）で摘記した，通信端末１０，ゲームサーバ２０ａ，２０ｂ，２０ｃ，２０ｄ，…に対しても妥当する記載であることは明らかである。
（１０）　段落【００５７】の記載において，「体力ポイント」についての説明は，ゲームＡ，Ｂ，Ｃ，Ｄ，…毎に区別されているものではないことから，
ゲームＢ，Ｃ，Ｄ，…の「体力ポイント」は，クエストを行う度に低減し，所定の時間が経過する毎に回復する値である
（１１）　段落【０１１２】には，「ゲームサーバ２０ａのＣＰＵ２１は，ゲームサーバ２０ｂから，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントを取得する」という記載があるが，上記（８）で説示した図１７の図示を踏まえれば，当該記載は，「
ゲームサーバ２０ａのＣＰＵ２１は，ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…から，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントを取得する
（１２）　段落【０１１２】の「第２条件を満たすゲームが存在する場合（ステップＳ１５５：ＹＥＳ），ゲームサーバ２０ａのＣＰＵ２１は，例えば，第２の実施形態で例示した選択方法で，第２条件を満たすゲームの中から，いずれかのゲーム，又は所定数のゲームを選択してもよい（ステップＳ１５７）。次いでゲームサーバ２０ａのＣＰＵ２１は，ステップＳ１００のＨＴＴＰリクエストに応じた，ステップＳ１５７で選択されたゲーム（ゲームＢ，Ｃ，Ｄ，…のうち１又は複数のゲーム）における体力ポイントを含むＨＴＭＬデータを生成して（ステップＳ１６０），ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。」という記載と，「更新されたゲームＡのウェブページには，ステップＳ１５７で選択されたゲームにおける体力ポイントが含まれることになる。」という記載と，「なお，ステップＳ１５７でゲームを選択することは必ずしも必要ではなく，第２条件を満たすすべてのゲームにおける体力ポイントと，そのすべてのゲームにおけるバナーをＨＴＭＬデータに含めてもよい。」という記載に照らせば，先願明細書等には，
第２条件を満たすゲームが存在する場合，ゲームサーバ２０ａのＣＰＵ２１は，ＨＴＴＰリクエストに応じた，第２条件を満たすすべてのゲームにおける体力ポイントを含むＨＴＭＬデータを生成して，ユーザＵ１の通信端末１０宛に送信する
更新されたゲームＡのウェブページには，第２条件を満たすすべてのゲームにおける体力ポイントが含まれる
（１３）　段落【０１１８】の「また，上述した実施形態では，第１条件として，クエストを実行できないためにゲームを進行させることができないことを条件とした場合を例示したが，このような条件に限られない。例えば
ユーザがアクセス中のゲームＡを進行させることができる場合
であっても，ゲームＡの区切りのタイミング
に，ゲームＡ以外の他のゲームのユーザ情報を取得し，そのユーザ情報をユーザに通知するようにしてもよい。
第１条件は，
ユーザによるゲームの進行によってゲームＡの区切りの位置に達したことであってよい。
　２　引用発明
　上記１の事項から，先願明細書等には，ユーザに，実行中のゲームとは異なる他のゲームにおける体力ポイントを通知する通知方法として，以下の発明（以下，「引用発明」という。）が記載されているものと認められる。
　「通信網ＮＷに接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と，通信網ＮＷに接続されているゲームサーバ２０ａ，２０ｂ，２０ｃ，…と，データベースサーバ３０ａ，３０ｂ，３０ｃ，…とによって構成されているゲームシステムにおいて，ユーザに，実行中のゲームとは異なるゲームにおける体力ポイントを通知する通知方法であって，
　ゲームサーバ２０ａは，クライアントである通信端末１０と通信可能に構成され，ゲームサーバ２０ａとデータベースサーバ３０ａは，通信端末１０に対してゲームＡについてのサービスを提供しており，ゲームサーバ２０ａのＣＰＵ２１は，通信インタフェース部２５を介して通信端末１０からＨＴＴＰリクエストを受信し，そのＨＴＴＰリクエストによって要求される処理を実行し，その実行結果であるＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に返すものであり，
　ゲームＡを実行するゲームサーバ２０ａのＣＰＵ２１は，特定のユーザＵ１の通信端末１０からのＨＴＴＰリクエストに応じて，ユーザがアクセス中のゲームＡを進行させることができる場合であっても，ユーザによるゲームの進行によってゲームＡの区切りの位置に達したという第１条件を満たしたと判定した場合には，別のゲームＢ，Ｃ，Ｄ，…を実行するゲームサーバ２０ｂ，２０ｃ，２０ｄ，…のＡＰＩサーバ２６に対して，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における，クエストを行う度に低減し，所定の時間が経過する毎に回復する値である体力ポイントを取得するための，処理対象となるユーザＵ１のユーザＩＤが含まれるリクエストを生成するように，ゲームサーバ２０ａのＡＰＩサーバ２６を制御し，これにより，ゲームサーバ２０ａのＡＰＩサーバ２６からゲームサーバ２０ｂ，２０ｃ，２０ｄ，…のＡＰＩサーバ２６に対して上記リクエストが送られ，リクエストを受けたゲームサーバ２０ｂ，２０ｃ，２０ｄ，…の各々のＣＰＵ２１は，そのリクエストの対象となるユーザＩＤをキーとしてユーザデータから，ユーザ情報として体力ポイントを抽出し，ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…の各々のＡＰＩサーバ２６は，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントの値を含むレスポンスを，ゲームサーバ２０ａのＡＰＩサーバ２６に返し，
　ゲームサーバ２０ａのＣＰＵ２１は，ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…から，処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントを取得すると，ゲームＢ，Ｃ，Ｄ，…におけるユーザＵ１の体力ポイントが，各ゲームの１回のクエストの実行に要する体力ポイント以上である場合に満たしたと判定される第２条件を満たすか否かを判定し，第２条件を満たすゲームが存在する場合，ゲームサーバ２０ａのＣＰＵ２１は，ＨＴＴＰリクエストに応じた，第２条件を満たすすべてのゲームにおける体力ポイントを含むＨＴＭＬデータを生成して，ユーザＵ１の通信端末１０宛に送信し，これによって，ユーザの通信端末１０では，ゲームＡのウェブページが更新され，更新されたゲームＡのウェブページには，第２条件を満たすすべてのゲームにおける体力ポイントが含まれ，ウェブページは通信端末１０の表示部１６に表示される，
　通知方法。」
　３　引用発明の発明者及び先願の出願人
　引用発明の発明者は戸田貴弘，遠藤卓であり，先願の出願人は株式会社コナミデジタルエンタテインメントであるから，いずれも本願の発明者である村田慶介，出願人であるグリー株式会社とは同一の者ではない。
第５　当審における判断
　１　対比
　本願発明と引用発明とを対比すると，以下のことがいえる。
（１）　引用発明の「通信端末１０」は，ユーザＵ１が持つものであることは明らかであるから，本願発明の「ユーザ端末」に相当する。
（２）　引用発明の「表示部１６」は，本願発明の「表示部」に相当する。
（３）　引用発明の「ゲームＡのウェブページ」は，本願発明の「ゲーム画面」に相当する。
（４）　引用発明においては，「ユーザがアクセス中のゲームＡ」とは「別のゲームＢ，Ｃ，Ｄ，…」のうち，「第２条件を満たすすべてのゲームにおける体力ポイントを含むＨＴＭＬデータを生成して，ユーザＵ１の通信端末１０宛に送信し」ており，複数のゲームが第２条件を満たす場合には，複数のゲームの体力ポイントを含むＨＴＭＬデータが生成されて，ユーザＵ１の通信端末１０宛に送信されることは，明らかであるから，引用発明は，複数のゲームに関する通知を行っているといえる。
　したがって，本願発明と引用発明とは，「複数のゲームに関する通知を行う」点において一致する。
（５）　本願発明の「ユーザ端末の表示部に接続された制御部」の対比にあたり，本願明細書の記載を参酌する。 
　ア　本願明細書には，以下の記載がある。 
（ア）　「【００１８】 
　（第１の実施形態） 
　以下，通知方法の一実施形態を図１〜図３に従って説明する。本実施形態は，複数のアプリケーション（例えば，ゲーム）を利用するユーザに対して，各種通知を行なう場合を想定する。
【００１９】 
　図１に示すように，本実施形態では，インターネット等のネットワークを介して接続されたユーザ端末１０，管理サーバ２０，複数のゲームサーバ３０を用いる。
　ユーザ端末１０は，ユーザ登録されたユーザのコンピュータ端末（スマートフォン等の情報処理端末）である。このユーザ端末１０は，ゲームサーバ３０から提供されるゲームに参加する場合に用いられる。また，ユーザ端末１０においてローカルカレンダを管理したり，各種ＳＮＳ（ソーシャルネットワークサービス）に参加したりする場合にも用いられる。
【００２０】 
　ゲームサーバ３０は，インターネットにおいて，各種ゲームを提供しているサーバコンピュータである。本実施形態では，ゲームサーバ３０は，ユーザ端末１０に対してゲームサービスを提供する。更に，ゲームサーバ３０は，例えば，対戦ゲーム等において，ゲームにおけるキャラクタの体力が回復した場合や，仲間と協力して敵と戦う場面において他のユーザに協力要請を行なう場合等に，管理サーバ２０に対して通知（体力情報や協力要請）を送信する。
【００２１】 
　管理サーバ２０は，ユーザ端末１０に対して，複数のアプリケーションを利用するユーザを管理するコンピュータシステムである。具体的には，管理サーバ２０は，ユーザを取りまとめ，各種ゲームサーバ３０から提供されるゲームサービスを管理する基盤システム（プラットフォーム）として機能する。この管理サーバ２０は，ＣＰＵ，ＲＡＭ及びＲＯＭ等からなる制御部２１，ユーザ情報記憶部２２，通知情報記憶部２３を備える。
【００２２】 
　この制御部２１は，管理プログラムを実行することにより，ユーザ管理部２１１，通知取得部２１２，ユーザ状況判定部２１３，通知転送部２１４として機能する。
　ユーザ管理部２１１は，各種アプリケーションを利用するユーザを管理する処理を実行する。」 
（イ）　「【００３６】 
　次に，
管理サーバ２０の制御部２１は，ゲームログイン通知処理を実行する
具体的には，制御部２１のユーザ管理部２１１は，選択されたアプリケーションＡのゲームサーバ３０に対して，ログインを通知する。この場合，ユーザ管理部２１１は，ユーザ情報記憶部２２のユーザ管理情報に，ステータスとして，ログイン「ゲームＡ」を記録する。
【００３７】 
　（通知転送処理） 
　次に，図２（ｂ）を用いて，通知転送処理を説明する。 
　ここでは，まず，
管理サーバ２０の制御部２１は，通知の受信処理を実行する
具体的には，制御部２１の通知取得部２１２は，ゲームサーバ３０から，各ユーザ宛の通知を取得する。ここでは，ユーザがログインしていないアプリケーションのゲームサーバ３０から，通知を取得する。
（ウ）「【００４１】 
　一方，オンラインと判定した場合（ステップＳ２−３において「ＹＥＳ」の場合），
管理サーバ２０の制御部２１は，ゲーム内表示処理を実行する
具体的には，制御部２１の通知転送部２１４は，ユーザ管理情報におけるステータスに基づいて，ログインしているゲームを特定する。そして，通知転送部２１４は，ゲーム画面にオンライン通知を出力する。
【００４２】 
　
この場合，
ユーザ端末１０のディスプレイには，ゲーム画面５００が出力される。
【００４３】 
　新規通知リンク５０１が選択された場合，管理サーバ２０の制御部２１は，このログインユーザのユーザＩＤに関連付けられた通知管理情報を，通知情報記憶部２３において検索する。この場合，通知転送部２１４は，抽出した通知管理情報を，通知種別毎に，受信時刻が新しい順番に並べ替える。そして，通知転送部２１４は，通知情報記憶部２３から抽出した通知管理情報をユーザ端末１０のディスプレイに出力する。
【００４４】 
　この場合，図３に示すように，
ユーザ端末１０のディスプレイには，詳細表示画面５１０が出力される。この詳細表示画面５１０には，他のアプリケーションＢ，Ｃ，Ｄの各ゲームサーバ３０から取得した通知の通知種別に対応して，「体力ゲージ」タブ，
が含まれる。「体力ゲージ」タブが選択された場合，このユーザのキャラクタについて，各ゲームサーバ３０から取得した体力ゲージ画面５１１が表示される。
　イ　上記アで摘記した事項から，本願発明の 
　「前記ユーザ端末におけるゲームの使用状況を取得し， 
　前記ユーザ端末で使用中のゲームを継続可能な状態で，前記ゲームとは別のゲームであって使用中ではないゲームの体力情報をネットワークを介して取得し，
　前記体力情報に基づき，継続可能な前記ゲームのゲーム画面内で，前記別のゲームにおける体力の回復状況に応じた体力情報を前記表示部に出力する」
　という動作の主体である「制御部」は，本願明細書の「管理サーバ２０（の制御部２１）」に相当するものであると認められ，「管理サーバ２０」は，「ディスプレイ」を備える「ユーザ端末１０」とネットワークを介して接続されていることを踏まえると，本願発明において，「制御部」が，「ユーザ端末の表示部に接続され」ていることは，ユーザ端末とネットワークを介して接続されることを包含するものと認められる。
　ウ　そして，引用発明の「ゲームサーバ２０ａ」は，その「ＣＰＵ２１が，通信端末１０からのＨＴＴＰリクエストに応じてＨＴＭＬデータを生成して，ユーザＵ１の通信端末１０に送信し，これによって，ユーザＵ１の通信端末１０では，ゲームＡのウェブページが更新され，ウェブページは通信端末１０の表示部１６に表示される」のであるから，「ゲームサーバ２０ａ」は，ユーザＵ１の通信端末１０の表示部１６と，ネットワークを介して接続されているといえる。
　したがって，引用発明の「ゲームサーバ２０ａ」は，本願発明の「ユーザ端末の表示部に接続された制御部」に相当する。 
（６）　引用発明において，「ゲームサーバ２０ａは，クライアントである通信端末１０と通信可能に構成され，ゲームサーバ２０ａとデータベースサーバ３０ａは，通信端末１０に対してゲームＡについてのサービスを提供して」いるから，「ゲームサーバ２０ａ」は，「通信端末１０」がゲームＡを使用しているという状況を取得しているものといえる。
　したがって，本願発明の「ユーザ端末の表示部に接続された制御部」と，引用発明の「ゲームサーバ２０ａ」とは，「前記ユーザ端末におけるゲームの使用状況を取得」する点においても一致する。
（７）　引用発明においては，「ゲームＡを実行するゲームサーバ２０ａのＣＰＵ２１は，特定のユーザＵ１の通信端末１０からのＨＴＴＰリクエストに応じて，ユーザがアクセス中のゲームＡを進行させることができる場合であっても，ユーザによるゲームの進行によってゲームＡの区切りの位置に達したという第１条件を満たしたと判定した場合には」，「別のゲームＢ，Ｃ，Ｄ，…を実行するゲームサーバ２０ｂ，２０ｃ，２０ｄ，…」から，「処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントを取得」している。
　そうすると，本願発明の「ユーザ端末の表示部に接続された制御部」と，引用発明の「ゲームサーバ２０ａ」とは，「前記ユーザ端末で使用中のゲームを継続可能な状態で，前記ゲームとは別のゲームであって使用中ではないゲームの体力情報をネットワークを介して取得」する点においても一致する。
（８）　引用発明においては，「ゲームサーバ２０ａのＣＰＵ２１」は，「ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…」から，「処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における，クエストを行う度に低減し，所定の時間が経過する毎に回復する値である体力ポイントを取得する」と，「第２条件を満たすか否かを判定し，第２条件を満たすゲームが存在する場合，ＨＴＴＰリクエストに応じた，第２条件を満たすすべてのゲームにおける体力ポイントを含むＨＴＭＬデータを生成して，ユーザＵ１の通信端末１０宛に送信し，これによって，ユーザの通信端末１０では，ゲームＡのウェブページが更新され，更新されたゲームＡのウェブページには，第２条件を満たすすべてのゲームにおける体力ポイントが含まれ，ウェブページは通信端末１０の表示部１６に表示され」ている。
　上記（７）で説示したとおり，「ゲームＡ」は「進行させることができる」状態であり，また，「ゲームＢ，Ｃ，Ｄ，…」の「体力ポイント」は，「所定の時間が経過する毎に回復する値である」ことを踏まえると，「更新されたゲームＡのウェブページ」に表示される，「第２条件を満たすすべてのゲームにおける体力ポイント」は，回復状況に応じているものであると認められる。
　そうすると，本願発明の「ユーザ端末の表示部に接続された制御部」と，引用発明の「ゲームサーバ２０ａ」とは，「前記体力情報に基づき，継続可能な前記ゲームのゲーム画面内で，前記別のゲームにおける体力の回復状況に応じた体力情報を前記表示部に出力する」点においても一致する。
（９）　引用発明の「通知方法」は，本願発明の「通知方法」に相当する。
（１０）　上記（１）ないし（９）から，本願発明と引用発明との間で，発明特定事項に差異はない。
　２　請求人の主張の検討
　審判請求人は，審判請求書において，本願発明は，ゲームを継続可能な状態で，別のゲームの体力情報を取得しているのに対して，引用発明は，ゲームの進行が妨げられたタイミングで別のゲームの体力情報を取得する点で相違する旨主張するが，上記第４の１（１３）や，上記１（７）で検討したとおり，引用発明は，ゲームの進行が可能な状況であっても，別のゲームの体力情報を取得するものであって，ゲームの進行が妨げられたタイミングで別のゲームの体力情報を取得するものではないから，請求人の主張を採用することはできない。
　また，審判請求人は，審判請求書において，先願明細書等が，ゲームＡを継続可能な状態でゲームＢの体力ポイントを表示することを開示するものだとしても，ゲームＡのゲーム画面においてどのようにゲームＢの体力ポイントを表示するのかまでは開示も示唆もされておらず，体力ポイントがゲームＡを継続可能な所定値（例えば，ゲームの進行が妨げられる値に近い値）に到達した場合に，ゲームＢの体力ポイントによらず，何らかの表示方法によってゲームＢの体力ポイントが表示される場合には，その度に別のゲームの通知が表示されてしまうため，ユーザはかえって煩わしさを感じる可能性があるから，本出願に係る発明と，引用文献１に記載された発明とは同一ではない旨を主張する。
　しかし，引用発明は，ゲームＢ，Ｃ，Ｄ…の体力ポイントについて，第２条件を満たすか否かを判定しているから，審判請求人が主張するような，体力ポイントによらず，表示するものではないし，そもそも，本願発明も，別のゲームの体力情報が表示されてしまうことを排除するものでもない。
　そうすると，出願人の主張は特許請求の範囲の記載に基づいているとはいえないから，採用することはできない。
第６　むすび
　以上のとおりであるから，本願発明は，引用発明，すなわち，先願明細書等に記載された発明と同一である。
　そして，引用発明の発明者が本願発明の発明者と同一の者ではなく，また，本願の出願の時に本願の出願人と先願の出願人とが同一の者でもない。
　したがって，本願発明は，特許法第２９条の２の規定により，特許を受けることができない。
　よって，結論のとおり審決する。