• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 発明同一 特許、登録しない。 A63F
管理番号 1361839
審判番号 不服2018-17266  
総通号数 246 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-06-26 
種別 拒絶査定不服の審決 
審判請求日 2018-12-26 
確定日 2020-04-23 
事件の表示 特願2017- 95702「通知方法,ユーザ端末,及び通知プログラム」拒絶査定不服審判事件〔平成29年 9月28日出願公開,特開2017-170164〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯
本願は,平成25年9月30日(以下,「原々々々出願日」という。)に出願された特願2013-204206号(以下,「原々々々出願」という。)の一部を,平成27年6月25日に新たな特許出願とした特願2015-127545号の一部を,平成27年12月25日に新たな特許出願とした特願2015-253120号の一部を,平成29年3月14日に新たな特許出願とした特願2017-48551号の一部を,平成29年5月12日に新たな特許出願とした出願であって,平成30年3月13日付けで拒絶理由が通知され,同年5月18日に意見書及び手続補正書が提出され,同年10月2日付けで拒絶査定(以下,「原査定」という。)がされ,それに対して,同年12月26日に拒絶査定不服審判が請求されるのと同時に手続補正書(以下,当該本件補正書による手続補正を「本件補正」という。)が提出されたものである。

第2 本願発明
本願の請求項1ないし8に係る発明は,本件補正後の特許請求の範囲の請求項1ないし8に記載された事項によって特定されるものであり,そのうち請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。

「【請求項1】
複数のゲームに関する通知を行う方法であって,
ユーザ端末の表示部に接続された制御部が,
前記ユーザ端末におけるゲームの使用状況を取得し,
前記ユーザ端末で使用中のゲームを継続可能な状態で,前記ゲームとは別のゲームであって使用中ではないゲームの体力情報をネットワークを介して取得し,
前記体力情報に基づき,継続可能な前記ゲームのゲーム画面内で,前記別のゲームにおける体力の回復状況に応じた体力情報を前記表示部に出力する
ことを特徴とする通知方法。」

第3 原査定の理由の概要
原査定の拒絶の理由は,平成30年5月18日に提出された手続補正書により補正された本願の請求項1に係る発明は,その出願(特許法44条2項の規定により,原々々々出願の出願の時に出願されたものとみなす。)の日(原々々々出願日)より前の特許出願であって,本願の出願後に特許掲載公報の発行又は出願公開がされた特許出願である下記の先願の願書に最初に添付された明細書,特許請求の範囲又は図面(以下,「先願明細書等」という。)に記載された発明と同一であり,しかも,本願の発明者が先願に係る上記発明をした者と同一ではなく,また本願の出願の時において,本願の出願人が上記先願の出願人と同一でもないから,特許法29条の2の規定により,特許を受けることができない,というものを含むものである。



先願:特願2012-131431号(特開2013-255526号)

第4 先願及び引用発明
1 先願明細書等の記載事項
先願は,本願の出願日より前の平成24年6月8日に出願され,本願の出願後である平成25年12月26日に特開2013-255526号として出願公開がされたものであるところ,先願明細書等には,次の事項が記載されている。なお,下線は引用発明の認定に用いた箇所を強調するために,当審において付加したものである。

(1) 「【背景技術】
【0002】
近年,特定のサービス提供者によるソーシャルネットワーキングサービス(SNS)においてウェブブラウザ上で動作するAPI(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される,いわゆるソーシャルゲーム(Social Game)が普及している。ソーシャルゲームは,不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは,インターネットに接続可能であって,かつウェブブラウザが搭載された通信端末を備えていれば,時間と場所を問わずソーシャルゲームを楽しむことができる。
【0003】
ソーシャルゲームの一例として,下記の非特許文献1に記載されたデジタルカードゲーム(ドラゴンコレクション(登録商標))が知られている。ソーシャルゲームには,例えばユーザの体力ポイントが設定され,ゲームの進行に応じてポイント(例えば,体力ポイント)が消費されていき,ポイントが消費できなくなると,ユーザによるゲームの進行ができなくなるものがある。このポイントは,例えば一定時間に所定量だけ増加(回復)するため,時間が経過するとユーザは再度ゲームを進行することができる仕組みとなっている。」

(2) 「【発明が解決しようとする課題】
【0005】
ところで,ユーザは,複数のソーシャルゲームに登録していることがある。このとき,ユーザは従来,登録済みのいずれかのゲームを実行した結果,そのゲームの進行ができなくなった場合には,登録済みのゲームの中から実行可能な他のゲームを選択して,選択したゲームを実行していた。ここで,例えば,ゲームを十分に進行させることができる程度にポイントが回復しているかについての情報は,そのゲームにアクセスするまで分からないため,ユーザは,登録済みのゲームを手当たり次第アクセスしてゲームを十分に実行可能かどうか確認する必要があり,面倒であった。
【0006】
本発明は上述した観点に鑑みてなされたもので,あるゲームを実行中,あるいは実行しようとするユーザが別のゲームについての自らの情報を知ることができるようにしたゲーム制御装置,ゲーム制御方法,プログラム,ゲームシステムを提供することを目的とする。」

(3) 「【0040】
<第1の実施形態>
(1)ゲームシステムの構成
図1は,本実施形態のゲームシステムのシステム構成例を示している。図1に示すように,このゲームシステムは,例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と,通信網NWに接続されているゲームサーバ20a,20b,20c,…と,データベースサーバ30a,30b,30c,…とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ,個々のユーザによって操作される端末であり,例えば,携帯端末,スマートフォン,PDA(Personal Digital Assistant),パーソナルコンピュータ,双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)などの通信端末である。なお,以下の説明において,各通信端末10a,10b,10c,…に共通して言及するときには,通信端末10と表記する。同様に,各ゲームサーバ20a,20b,20c,…に共通して言及するときには,ゲームサーバ20と表記する。各データベースサーバ30a,30b,30c,…に共通して言及するときには,データベースサーバ30と表記する。
【0041】
このゲームシステムにおいて,ゲームサーバ20aは,クライアントである通信端末10と通信可能に構成され,ゲームサーバ20aとデータベースサーバ30aは,通信端末10に対してゲームAについてのサービスを提供する。ゲームサーバ20bは,クライアントである通信端末10と通信可能に構成され,ゲームサーバ20bとデータベースサーバ30bは,通信端末10に対してゲームBについてのサービスを提供する。ゲームサーバ20cは,クライアントである通信端末10と通信可能に構成され,ゲームサーバ20cとデータベースサーバ30cは,通信端末10に対してゲームCについてのサービスを提供する。つまり,各ゲームサーバは,それぞれ異なるゲームについてのサービスを提供するように構成されている。
ゲームサーバ20には,ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ30は,ゲームを実行する上での後述する様々な情報を格納しており,それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
通信端末10は,ゲームサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており,ユーザは,通信端末10に表示されるウェブページ上のメニュー等を選択する操作を行うことでゲームを実行する。
【0042】
図1には図示していないが,ゲームサーバ20とは別に各通信端末10のユーザを認証するための認証サーバを設けてもよい。また,多くの通信端末10からのアクセスを受け
入れるために複数のゲームサーバ20を設ける場合は,その複数のゲームサーバ20間の負荷を調整するためのロードバランサを設けてもよい。また,ゲームサーバ20は単一のサーバ装置として構成してもよいが,機能を分散させた複数のサーバ装置として構成してもよい。
【0043】
(2)通信端末の構成
図2及び図3を参照して通信端末10について説明する。
図2は,通信端末10の外観の例を示す図であって,(a)は,例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり,(b)は,例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3は,通信端末10の内部構成を示すブロック図である。
図3に示すように,通信端末10は,CPU(Central Processing Unit)11,ROM(Read Only Memory)12,RAM(Random Access Memory)13,画像処理部14,指示入力部15,表示部16,及び,信号送受信部としての通信インタフェース部17を備えており,各部間の制御信号あるいはデータ信号を伝送するためのバス18が設けられている。
【0044】
CPU11は,ROM12内のウェブブラウザをRAM13にロードして実行する。そして,CPU11は,指示入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の適切な指定に基づき,通信インタフェース部17を介して,ゲームサーバ20からウェブページを表示するためのデータ,すなわち,HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下,総称して適宜「HTMLデータ」と表記する。)を通信インタフェース部17を介して取得し,そのHTMLデータを解釈する。なお,通信端末10には,ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてもよい。そのようなプラグインの一例は,アドビシステムズ社(米国)によるフラッシュプレイヤである。
なお,HTMLデータの取得に当たって,CPU11は,予め登録されたユーザID(ユーザ識別情報),あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを,通信インタフェース部17を介してゲームサーバ20へ通知する。
【0045】
ウェブブラウザは,ゲームサーバ20とHTTP(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは,ゲームサーバ20から取得したHTMLデータを解釈して,画像処理部14を介してウェブページを表示部16に表示する。また,ウェブブラウザは,ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると,ウェブページの更新のために,その選択結果を含むHTTPリクエストをゲームサーバ20に送信する。
【0046】
画像処理部14は,HTMLデータの解析結果としてCPU11から与えられる表示用画像データに基づいて,表示部16にウェブページを表示する。表示部16は,例えば,マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタであり,表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面16aに表示する。」

(4) 「【0054】
(4)データベースサーバの構成
データベースサーバ30(記憶装置)は,大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の装置等,汎用ストレージで実現できる。データベースサーバ30内の各データベースは,ゲームサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。
データベースサーバ30の構成は,処理対象となるゲームによって異なるが,ここでは説明の簡略化のために,いずれのデータベースサーバ30についても図6に示した共通の構成を備えているものとする。図5に示すように,データベースサーバ30は,ユーザデータベース31と,ゲームデータベース32とを備える。
【0055】
本実施形態のゲームサーバ20によって実現されるゲームのタイプは特に限定されるものではないが,以下では,実施形態の説明の便宜上,ゲームサーバ20によって実現されるゲームの一例として,ゲームキャラクタの画像が表示されるカードを使用するデジタルカードゲームを採り上げる。つまり,ゲームサーバ20a,20b,…はそれぞれ,デジタルカードゲームであるゲームA,ゲームB,…をそれぞれ実行するものとする。
【0056】
図6に,本実施形態のデジタルカードゲーム(以下適宜,単に「ゲーム」あるいは「本実施形態のゲーム」という。)において適用されるユーザデータベース31の一例を示す。この例では,ユーザデータベース31は,ユーザID(ユーザ識別情報)ごとに,ユーザ名,進行レベル,体力ポイント,経験値,仲間のユーザID,保有カード,保有アイテムの各項目についての情報を含む。ユーザデータベース31に含まれる情報は,ゲームサーバ20によって逐次更新されうる。
【0057】
以下の説明では,ユーザデータベース31に含まれるユーザID,あるいはユーザを特定するユーザ名ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは,以下のとおりである。
本実施形態のゲームシステムでは,複数のゲームサーバ20a,20b,20c,…が共通のプラットフォーム上に実装されており,複数のゲームA,B,C,…において同一のユーザは同一のユーザIDによって管理される。
・ユーザ名
ゲームの実行時に通信端末10のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は,ユーザIDと同様に,複数のゲームA,B,C,…において同一のユーザは同一のユーザ名によって管理されてもよいし,ゲーム毎に異なるユーザ名が設定できるようにしてもよい。
・進行レベル
各ゲーム上のユーザの進行レベル示すデータである。例えばLv1(レベル1)からLv100(レベル100)までの範囲のレベル値である。経験値が所定値に達すると進行レベルが1つ上昇する。
・体力ポイント
本実施形態のゲームにおいて,後述するクエストを行う上で必要となるポイントである。体力ポイントは,クエストを行う度に低減し,所定の時間が経過する毎に回復(増加)する値である。
・経験値
本実施形態のゲームにおいて,後述するクエストを行う上で増加する値である。経験値が所定の値(例えば,100)に達すると,進行レベルが1増加して経験値はリセットされる(つまりゼロになる)。
・仲間のユーザID
ユーザがゲーム上で仲間(後述する)の関係にあるユーザIDである。
・保有カード
保有カードは,ゲーム上でユーザが保有しているカードのデータ(例えばC1等のカードの種類を示す識別子など)である。各カードは,例えばゲーム内のバトル等で参照されるパラメータ(つまり,攻撃力と防御力等の能力値)が対応付けられてもよい。
・保有アイテム
保有アイテムは,ゲーム上でユーザが保有しているアイテムのデータ(例えばIm1等のアイテムの種類を示す識別子など)である。」

(5) 「【0107】
<第4の実施形態>
次に,本発明の第4の実施形態について説明する。本実施形態のゲームシステムを構成する各要素(通信端末10,ゲームサーバ20及びデータベースサーバ30)のハードウエア構成は,第1の実施形態と同じでよい。
【0108】
(1)ゲーム制御装置が備える機能の概要
本実施形態のゲーム制御装置の機能ブロック図を,図16に示す。図16に示すように,本実施形態は,第1の実施形態(図9)と比較して,第2判定手段58が追加された点で異なる。第2判定手段58は,情報取得手段55により取得された,ユーザのアクセス対象のゲームとは別のゲーム(第2ゲーム)のユーザの体力ポイント(ユーザ情報)が第2条件を満たすか否かを判定する機能を備える。
【0109】
第2判定手段58の機能を実現するために,ゲームサーバ20aのCPU21は,ユーザのアクセス対象のゲームとは別のゲームのユーザの体力ポイント(ユーザ情報)を取得すると,その体力ポイントが第2条件を満たすか否かを判定する。例えば,別のゲームにおいて,1回のクエストの実行に「8」の体力ポイントを要し,かつ別のゲームにおけるユーザの体力ポイントが「8」以上である場合には,体力ポイントを消費して少なくとも1回のクエストを実行できるため,第2条件を満たしたことになる。
なお,ここでは,ユーザのアクセス対象のゲーム(第1ゲーム)と別のゲーム(第2ゲーム)とがそれぞれクエストの処理を行うように構成されている場合を例示したが,この例に限られない。それぞれ別々のゲームであり,そのゲームに設けられる機能は異なってもよいため,第1判定手段54における第1条件と,第2判定手段58における第2条件の判定の基礎となるデータはそれぞれ異なっていてよい。
【0110】
本実施形態において,通知手段56は,第2判定手段58により第2条件を満たすと判定された場合に,ユーザのアクセス対象のゲームとは別のゲーム(第2ゲーム)のユーザの体力ポイント(ユーザ情報)をユーザに通知してもよい。
【0111】
(2)本実施形態のゲーム制御装置の主要な処理のフロー
次に,本実施形態のゲームシステムにより行われる主要な処理のフローの一例について,図17を参照して説明する。図17は,本実施形態のゲーム制御装置において,実行中のゲームとは異なるゲームの情報をユーザに提示する処理の一例を示すシーケンスチャートである。
なお,図17のシーケンスチャートは,図11と同様に,ユーザがゲームAを実行中である場合の例である。
特定のユーザU1の通信端末10からのHTTPリクエスト(ステップS100)に応じて,ゲームAを実行するゲームサーバ20aのCPU21は,ステップS110で第1条件を満たした(つまり,体力ポイントを低下させることができずクエストを実行できない)と判定した場合には,別のゲームB,C,D,…を実行するゲームサーバ20b,20c,20d,…のAPIサーバ26に対して,処理対象となるユーザU1のゲームB,C,D,…における体力ポイント(ユーザ情報の例)を取得するためのリクエストを生成するように,ゲームサーバ20aのAPIサーバ26を制御する(ステップS120)。これにより,ゲームサーバ20aのAPIサーバ26からゲームサーバ20b,20c,20d,…のAPIサーバ26に対して上記リクエストが送られる(ステップS130)。このリクエストには,処理対象となるユーザU1のユーザIDが含まれる。リクエストを受けたゲームサーバ20b,20c,20d,…の各々のCPU21は,そのリクエストの対象となるユーザIDをキーとしてユーザデータから,ユーザ情報として体力ポイントを抽出する(ステップS140)。ゲームサーバ20b,20c,20d,…の各々のAPIサーバ26は,処理対象となるユーザU1のゲームB,C,D,…おける体力ポイントの値を含むレスポンスを,ゲームサーバ20aのAPIサーバ26に返す(ステップS150)。
【0112】
ゲームサーバ20aのCPU21は,ゲームサーバ20bから,処理対象となるユーザU1のゲームB,C,D,…における体力ポイントを取得すると,第2条件を満たすか否かを判定する(ステップS155)。例えば,ゲームB,C,D,…におけるユーザU1の体力ポイントが,各ゲームの1回のクエストの実行に要する体力ポイント以上である場合に,第2条件を満たしたと判定する。第2条件を満たすゲームが存在する場合(ステップS155:YES),ゲームサーバ20aのCPU21は,例えば,第2の実施形態で例示した選択方法で,第2条件を満たすゲームの中から,いずれかのゲーム,又は所定数のゲームを選択してもよい(ステップS157)。次いでゲームサーバ20aのCPU21は,ステップS100のHTTPリクエストに応じた,ステップS157で選択されたゲーム(ゲームB,C,D,…のうち1又は複数のゲーム)における体力ポイントを含むHTMLデータを生成して(ステップS160),ユーザU1の通信端末10宛に送信する(ステップS170)。これによって,ユーザの通信端末10には,ゲームAのウェブページが更新される(ステップS180)。更新されたゲームAのウェブページには,ステップS157で選択されたゲームにおける体力ポイントが含まれることになる。なお,ステップS150のレスポンスを受信した場合,ステップS160で生成されるHTMLデータには,ステップS157で選択されたゲームの実行を開始するためのバナー(操作対象)を含むことが好ましい。
なお,ステップS157でゲームを選択することは必ずしも必要ではなく,第2条件を満たすすべてのゲームにおける体力ポイントと,そのすべてのゲームにおけるバナーをHTMLデータに含めてもよい。
【0113】
上述したように本実施形態では,アクセス対象のゲームA(第1ゲーム)とは別のゲームB,C,D,…(第2ユーザ)の体力ポイント(ユーザ情報)を闇雲にユーザに通知するのではなく,第2条件を満たす場合にその体力ポイントを通知することで,適切な第2ゲームについての体力ポイントをユーザに通知することができるようになる。これにより,クエストを実行可能な第2ゲームの体力ポイントを通知するようにすることができ,ゲームAを進行させることができなくなった時点で,別のゲームを進行させることができることをユーザが認識することができる。」

(6) 「【0117】
上述した各実施形態では,ユーザ情報のユーザへの通知の態様として,ウェブページ等のゲーム画像にユーザ情報(例えば,体力ポイント)が表示される場合について説明したが,ユーザ情報の通知の態様は表示に限られない。ユーザへのユーザ情報の通知方法は,ユーザ情報を音声によって出力する方法などでもよい。その場合,各ゲームサーバ20から通信装置10宛に,ユーザ情報の圧縮音声信号を含むHTMLデータを送信し,通信装置10において圧縮音声信号を伸長・増幅して音声出力するようにしてもよい。なお,通知の態様としては,上述した各実施形態で示したように,ユーザ情報を表示させることが好ましい。ユーザ情報をゲーム画像に表示する方法を採ることで,例えば音声の出力が制限される環境(例えば,公共交通機関内)においてもユーザがゲーム画像を認識することができる。さらに,音声でユーザ情報を出力する場合はユーザが聞き逃す場合等が生じうるが,ユーザ情報の表示することで情報伝達の不確実性を抑制することもできる。
【0118】
上述した各実施形態について,ユーザ情報の一例としてゲームを進行させる上での体力ポイントを挙げたが,取得対象となるユーザ情報は,ゲームの性質や第1判定手段における第1条件の内容に応じて適宜設定されてよい。
例えば,ゲームキャラクタの攻撃力及び防御力がゲームの進行に応じて変動するバトルゲームの場合,ユーザ情報は,その攻撃力及び防御力を示すゲームキャラクタのパラメータの値であってもよい。
また,上述した実施形態では,第1条件として,クエストを実行できないためにゲームを進行させることができないことを条件とした場合を例示したが,このような条件に限られない。例えばユーザがアクセス中のゲームAを進行させることができる場合(例えば,クエストを実行できる場合)であっても,ゲームAの区切りのタイミング(例えば,クエストの特定のエリアの探索が終了するタイミング)や,ゲームAにアクセスしてから定期的なタイミング(例えば,10分間隔のタイミング)毎に,ゲームA以外の他のゲームのユーザ情報を取得し,そのユーザ情報をユーザに通知するようにしてもよい。つまり,第1条件は,所定時間が経過したことや,ユーザによるゲームの進行によってゲームAの区切りの位置に達したことであってよい。
例えば,ゲームA以外の他のゲームにおいて,ゲームAにアクセスしているユーザ宛の仲間申請を受けている場合や,そのユーザ宛のトレードの申請・返答がある場合,プレゼントが届いている場合など,ゲームA以外のゲームにおいてユーザ向けのイベントが生じている場合には,そのイベントの内容をユーザ情報として通知してもよい。このような通知によって,ゲームAにアクセスしているユーザが適時に他のゲームにアクセスして所要の操作を行うことができる。」


(7) 「【図17



(8) 図17からは,ゲームサーバ20aへのレスポンスであるユーザ情報は,ゲームサーバ20b,20c,20d,…からのものであることが看取できる。

(9) 段落【0107】の「次に,本発明の第4の実施形態について説明する。本実施形態のゲームシステムを構成する各要素(通信端末10,ゲームサーバ20及びデータベースサーバ30)のハードウエア構成は,第1の実施形態と同じでよい。」という記載に照らせば,上記(3)及び(4)で摘記した,通信端末10,ゲームサーバ20に関する記載は,上記(5)で摘記した,通信端末10,ゲームサーバ20a,20b,20c,20d,…に対しても妥当する記載であることは明らかである。

(10) 段落【0057】の記載において,「体力ポイント」についての説明は,ゲームA,B,C,D,…毎に区別されているものではないことから,ゲームB,C,D,…の「体力ポイント」は,クエストを行う度に低減し,所定の時間が経過する毎に回復する値であることは明らかである。

(11) 段落【0112】には,「ゲームサーバ20aのCPU21は,ゲームサーバ20bから,処理対象となるユーザU1のゲームB,C,D,…における体力ポイントを取得する」という記載があるが,上記(8)で説示した図17の図示を踏まえれば,当該記載は,「ゲームサーバ20aのCPU21は,ゲームサーバ20b,20c,20d,…から,処理対象となるユーザU1のゲームB,C,D,…における体力ポイントを取得する」の誤記であることは明らかである。

(12) 段落【0112】の「第2条件を満たすゲームが存在する場合(ステップS155:YES),ゲームサーバ20aのCPU21は,例えば,第2の実施形態で例示した選択方法で,第2条件を満たすゲームの中から,いずれかのゲーム,又は所定数のゲームを選択してもよい(ステップS157)。次いでゲームサーバ20aのCPU21は,ステップS100のHTTPリクエストに応じた,ステップS157で選択されたゲーム(ゲームB,C,D,…のうち1又は複数のゲーム)における体力ポイントを含むHTMLデータを生成して(ステップS160),ユーザU1の通信端末10宛に送信する(ステップS170)。」という記載と,「更新されたゲームAのウェブページには,ステップS157で選択されたゲームにおける体力ポイントが含まれることになる。」という記載と,「なお,ステップS157でゲームを選択することは必ずしも必要ではなく,第2条件を満たすすべてのゲームにおける体力ポイントと,そのすべてのゲームにおけるバナーをHTMLデータに含めてもよい。」という記載に照らせば,先願明細書等には,第2条件を満たすゲームが存在する場合,ゲームサーバ20aのCPU21は,HTTPリクエストに応じた,第2条件を満たすすべてのゲームにおける体力ポイントを含むHTMLデータを生成して,ユーザU1の通信端末10宛に送信すること,及び更新されたゲームAのウェブページには,第2条件を満たすすべてのゲームにおける体力ポイントが含まれることが,開示されているものと認められる。

(13) 段落【0118】の「また,上述した実施形態では,第1条件として,クエストを実行できないためにゲームを進行させることができないことを条件とした場合を例示したが,このような条件に限られない。例えばユーザがアクセス中のゲームAを進行させることができる場合(例えば,クエストを実行できる場合)であっても,ゲームAの区切りのタイミング(例えば,クエストの特定のエリアの探索が終了するタイミング)や,ゲームAにアクセスしてから定期的なタイミング(例えば,10分間隔のタイミング)毎に,ゲームA以外の他のゲームのユーザ情報を取得し,そのユーザ情報をユーザに通知するようにしてもよい。つまり,第1条件は,所定時間が経過したことや,ユーザによるゲームの進行によってゲームAの区切りの位置に達したことであってよい。」という記載に照らせば,先願明細書等には,段落【0111】の「第1条件を満たした(つまり,体力ポイントを低下させることができずクエストを実行できない)と判定した場合には,別のゲームB,C,D,…を実行するゲームサーバ20b,20c,20d,…のAPIサーバ26に対して,処理対象となるユーザU1のゲームB,C,D,…における体力ポイント(ユーザ情報の例)を取得するためのリクエストを生成するように,ゲームサーバ20aのAPIサーバ26を制御する」という記載における「第1条件」として,「ユーザがアクセス中のゲームAを進行させることができる場合であっても,ユーザによるゲームの進行によってゲームAの区切りの位置に達したこと」とすることができることが,開示されているものと認められる。

2 引用発明
上記1の事項から,先願明細書等には,ユーザに,実行中のゲームとは異なる他のゲームにおける体力ポイントを通知する通知方法として,以下の発明(以下,「引用発明」という。)が記載されているものと認められる。

「通信網NWに接続可能な通信端末10a,10b,10c,…と,通信網NWに接続されているゲームサーバ20a,20b,20c,…と,データベースサーバ30a,30b,30c,…とによって構成されているゲームシステムにおいて,ユーザに,実行中のゲームとは異なるゲームにおける体力ポイントを通知する通知方法であって,
ゲームサーバ20aは,クライアントである通信端末10と通信可能に構成され,ゲームサーバ20aとデータベースサーバ30aは,通信端末10に対してゲームAについてのサービスを提供しており,ゲームサーバ20aのCPU21は,通信インタフェース部25を介して通信端末10からHTTPリクエストを受信し,そのHTTPリクエストによって要求される処理を実行し,その実行結果であるHTMLデータを含むHTTPレスポンスを通信端末10宛に返すものであり,
ゲームAを実行するゲームサーバ20aのCPU21は,特定のユーザU1の通信端末10からのHTTPリクエストに応じて,ユーザがアクセス中のゲームAを進行させることができる場合であっても,ユーザによるゲームの進行によってゲームAの区切りの位置に達したという第1条件を満たしたと判定した場合には,別のゲームB,C,D,…を実行するゲームサーバ20b,20c,20d,…のAPIサーバ26に対して,処理対象となるユーザU1のゲームB,C,D,…における,クエストを行う度に低減し,所定の時間が経過する毎に回復する値である体力ポイントを取得するための,処理対象となるユーザU1のユーザIDが含まれるリクエストを生成するように,ゲームサーバ20aのAPIサーバ26を制御し,これにより,ゲームサーバ20aのAPIサーバ26からゲームサーバ20b,20c,20d,…のAPIサーバ26に対して上記リクエストが送られ,リクエストを受けたゲームサーバ20b,20c,20d,…の各々のCPU21は,そのリクエストの対象となるユーザIDをキーとしてユーザデータから,ユーザ情報として体力ポイントを抽出し,ゲームサーバ20b,20c,20d,…の各々のAPIサーバ26は,処理対象となるユーザU1のゲームB,C,D,…における体力ポイントの値を含むレスポンスを,ゲームサーバ20aのAPIサーバ26に返し,
ゲームサーバ20aのCPU21は,ゲームサーバ20b,20c,20d,…から,処理対象となるユーザU1のゲームB,C,D,…における体力ポイントを取得すると,ゲームB,C,D,…におけるユーザU1の体力ポイントが,各ゲームの1回のクエストの実行に要する体力ポイント以上である場合に満たしたと判定される第2条件を満たすか否かを判定し,第2条件を満たすゲームが存在する場合,ゲームサーバ20aのCPU21は,HTTPリクエストに応じた,第2条件を満たすすべてのゲームにおける体力ポイントを含むHTMLデータを生成して,ユーザU1の通信端末10宛に送信し,これによって,ユーザの通信端末10では,ゲームAのウェブページが更新され,更新されたゲームAのウェブページには,第2条件を満たすすべてのゲームにおける体力ポイントが含まれ,ウェブページは通信端末10の表示部16に表示される,
通知方法。」

3 引用発明の発明者及び先願の出願人
引用発明の発明者は戸田貴弘,遠藤卓であり,先願の出願人は株式会社コナミデジタルエンタテインメントであるから,いずれも本願の発明者である村田慶介,出願人であるグリー株式会社とは同一の者ではない。

第5 当審における判断
1 対比
本願発明と引用発明とを対比すると,以下のことがいえる。

(1) 引用発明の「通信端末10」は,ユーザU1が持つものであることは明らかであるから,本願発明の「ユーザ端末」に相当する。

(2) 引用発明の「表示部16」は,本願発明の「表示部」に相当する。

(3) 引用発明の「ゲームAのウェブページ」は,本願発明の「ゲーム画面」に相当する。

(4) 引用発明においては,「ユーザがアクセス中のゲームA」とは「別のゲームB,C,D,…」のうち,「第2条件を満たすすべてのゲームにおける体力ポイントを含むHTMLデータを生成して,ユーザU1の通信端末10宛に送信し」ており,複数のゲームが第2条件を満たす場合には,複数のゲームの体力ポイントを含むHTMLデータが生成されて,ユーザU1の通信端末10宛に送信されることは,明らかであるから,引用発明は,複数のゲームに関する通知を行っているといえる。
したがって,本願発明と引用発明とは,「複数のゲームに関する通知を行う」点において一致する。

(5) 本願発明の「ユーザ端末の表示部に接続された制御部」の対比にあたり,本願明細書の記載を参酌する。
ア 本願明細書には,以下の記載がある。
(ア) 「【0018】
(第1の実施形態)
以下,通知方法の一実施形態を図1?図3に従って説明する。本実施形態は,複数のアプリケーション(例えば,ゲーム)を利用するユーザに対して,各種通知を行なう場合を想定する。
【0019】
図1に示すように,本実施形態では,インターネット等のネットワークを介して接続されたユーザ端末10,管理サーバ20,複数のゲームサーバ30を用いる。
ユーザ端末10は,ユーザ登録されたユーザのコンピュータ端末(スマートフォン等の情報処理端末)である。このユーザ端末10は,ゲームサーバ30から提供されるゲームに参加する場合に用いられる。また,ユーザ端末10においてローカルカレンダを管理したり,各種SNS(ソーシャルネットワークサービス)に参加したりする場合にも用いられる。
【0020】
ゲームサーバ30は,インターネットにおいて,各種ゲームを提供しているサーバコンピュータである。本実施形態では,ゲームサーバ30は,ユーザ端末10に対してゲームサービスを提供する。更に,ゲームサーバ30は,例えば,対戦ゲーム等において,ゲームにおけるキャラクタの体力が回復した場合や,仲間と協力して敵と戦う場面において他のユーザに協力要請を行なう場合等に,管理サーバ20に対して通知(体力情報や協力要請)を送信する。
【0021】
管理サーバ20は,ユーザ端末10に対して,複数のアプリケーションを利用するユーザを管理するコンピュータシステムである。具体的には,管理サーバ20は,ユーザを取りまとめ,各種ゲームサーバ30から提供されるゲームサービスを管理する基盤システム(プラットフォーム)として機能する。この管理サーバ20は,CPU,RAM及びROM等からなる制御部21,ユーザ情報記憶部22,通知情報記憶部23を備える。
【0022】
この制御部21は,管理プログラムを実行することにより,ユーザ管理部211,通知取得部212,ユーザ状況判定部213,通知転送部214として機能する。
ユーザ管理部211は,各種アプリケーションを利用するユーザを管理する処理を実行する。」
(イ) 「【0036】
次に,管理サーバ20の制御部21は,ゲームログイン通知処理を実行する(ステップS1-4)。具体的には,制御部21のユーザ管理部211は,選択されたアプリケーションAのゲームサーバ30に対して,ログインを通知する。この場合,ユーザ管理部211は,ユーザ情報記憶部22のユーザ管理情報に,ステータスとして,ログイン「ゲームA」を記録する。
【0037】
(通知転送処理)
次に,図2(b)を用いて,通知転送処理を説明する。
ここでは,まず,管理サーバ20の制御部21は,通知の受信処理を実行する(ステップS2-1)。具体的には,制御部21の通知取得部212は,ゲームサーバ30から,各ユーザ宛の通知を取得する。ここでは,ユーザがログインしていないアプリケーションのゲームサーバ30から,通知を取得する。この場合,通知取得部212は,取得した通知の通知種別を特定する。そして,通知取得部212は,ユーザID,ゲームID,取得時刻,通知種別,通知内容を記録した通知管理情報を生成し,通知情報記憶部23に登録する。」
(ウ)「【0041】
一方,オンラインと判定した場合(ステップS2-3において「YES」の場合),管理サーバ20の制御部21は,ゲーム内表示処理を実行する(ステップS2-5)。具体的には,制御部21の通知転送部214は,ユーザ管理情報におけるステータスに基づいて,ログインしているゲームを特定する。そして,通知転送部214は,ゲーム画面にオンライン通知を出力する。
【0042】
この場合,図3に示すように,ユーザ端末10のディスプレイには,ゲーム画面500が出力される。このゲーム画面500には,新規通知リンク501が出力される。この新規通知リンク501には,新たな通知を受けたことを示すメッセージが含まれる。
【0043】
新規通知リンク501が選択された場合,管理サーバ20の制御部21は,このログインユーザのユーザIDに関連付けられた通知管理情報を,通知情報記憶部23において検索する。この場合,通知転送部214は,抽出した通知管理情報を,通知種別毎に,受信時刻が新しい順番に並べ替える。そして,通知転送部214は,通知情報記憶部23から抽出した通知管理情報をユーザ端末10のディスプレイに出力する。
【0044】
この場合,図3に示すように,ユーザ端末10のディスプレイには,詳細表示画面510が出力される。この詳細表示画面510には,他のアプリケーションB,C,Dの各ゲームサーバ30から取得した通知の通知種別に対応して,「体力ゲージ」タブ,「協力要請」タブが含まれる。「体力ゲージ」タブが選択された場合,このユーザのキャラクタについて,各ゲームサーバ30から取得した体力ゲージ画面511が表示される。また,「協力要請」タブが選択された場合には,ゲームサーバ30から取得した他のユーザの協力要請画面512が表示される。」

イ 上記アで摘記した事項から,本願発明の
「前記ユーザ端末におけるゲームの使用状況を取得し,
前記ユーザ端末で使用中のゲームを継続可能な状態で,前記ゲームとは別のゲームであって使用中ではないゲームの体力情報をネットワークを介して取得し,
前記体力情報に基づき,継続可能な前記ゲームのゲーム画面内で,前記別のゲームにおける体力の回復状況に応じた体力情報を前記表示部に出力する」
という動作の主体である「制御部」は,本願明細書の「管理サーバ20(の制御部21)」に相当するものであると認められ,「管理サーバ20」は,「ディスプレイ」を備える「ユーザ端末10」とネットワークを介して接続されていることを踏まえると,本願発明において,「制御部」が,「ユーザ端末の表示部に接続され」ていることは,ユーザ端末とネットワークを介して接続されることを包含するものと認められる。

ウ そして,引用発明の「ゲームサーバ20a」は,その「CPU21が,通信端末10からのHTTPリクエストに応じてHTMLデータを生成して,ユーザU1の通信端末10に送信し,これによって,ユーザU1の通信端末10では,ゲームAのウェブページが更新され,ウェブページは通信端末10の表示部16に表示される」のであるから,「ゲームサーバ20a」は,ユーザU1の通信端末10の表示部16と,ネットワークを介して接続されているといえる。
したがって,引用発明の「ゲームサーバ20a」は,本願発明の「ユーザ端末の表示部に接続された制御部」に相当する。

(6) 引用発明において,「ゲームサーバ20aは,クライアントである通信端末10と通信可能に構成され,ゲームサーバ20aとデータベースサーバ30aは,通信端末10に対してゲームAについてのサービスを提供して」いるから,「ゲームサーバ20a」は,「通信端末10」がゲームAを使用しているという状況を取得しているものといえる。
したがって,本願発明の「ユーザ端末の表示部に接続された制御部」と,引用発明の「ゲームサーバ20a」とは,「前記ユーザ端末におけるゲームの使用状況を取得」する点においても一致する。

(7) 引用発明においては,「ゲームAを実行するゲームサーバ20aのCPU21は,特定のユーザU1の通信端末10からのHTTPリクエストに応じて,ユーザがアクセス中のゲームAを進行させることができる場合であっても,ユーザによるゲームの進行によってゲームAの区切りの位置に達したという第1条件を満たしたと判定した場合には」,「別のゲームB,C,D,…を実行するゲームサーバ20b,20c,20d,…」から,「処理対象となるユーザU1のゲームB,C,D,…における体力ポイントを取得」している。
そうすると,本願発明の「ユーザ端末の表示部に接続された制御部」と,引用発明の「ゲームサーバ20a」とは,「前記ユーザ端末で使用中のゲームを継続可能な状態で,前記ゲームとは別のゲームであって使用中ではないゲームの体力情報をネットワークを介して取得」する点においても一致する。

(8) 引用発明においては,「ゲームサーバ20aのCPU21」は,「ゲームサーバ20b,20c,20d,…」から,「処理対象となるユーザU1のゲームB,C,D,…における,クエストを行う度に低減し,所定の時間が経過する毎に回復する値である体力ポイントを取得する」と,「第2条件を満たすか否かを判定し,第2条件を満たすゲームが存在する場合,HTTPリクエストに応じた,第2条件を満たすすべてのゲームにおける体力ポイントを含むHTMLデータを生成して,ユーザU1の通信端末10宛に送信し,これによって,ユーザの通信端末10では,ゲームAのウェブページが更新され,更新されたゲームAのウェブページには,第2条件を満たすすべてのゲームにおける体力ポイントが含まれ,ウェブページは通信端末10の表示部16に表示され」ている。
上記(7)で説示したとおり,「ゲームA」は「進行させることができる」状態であり,また,「ゲームB,C,D,…」の「体力ポイント」は,「所定の時間が経過する毎に回復する値である」ことを踏まえると,「更新されたゲームAのウェブページ」に表示される,「第2条件を満たすすべてのゲームにおける体力ポイント」は,回復状況に応じているものであると認められる。
そうすると,本願発明の「ユーザ端末の表示部に接続された制御部」と,引用発明の「ゲームサーバ20a」とは,「前記体力情報に基づき,継続可能な前記ゲームのゲーム画面内で,前記別のゲームにおける体力の回復状況に応じた体力情報を前記表示部に出力する」点においても一致する。

(9) 引用発明の「通知方法」は,本願発明の「通知方法」に相当する。

(10) 上記(1)ないし(9)から,本願発明と引用発明との間で,発明特定事項に差異はない。

2 請求人の主張の検討
審判請求人は,審判請求書において,本願発明は,ゲームを継続可能な状態で,別のゲームの体力情報を取得しているのに対して,引用発明は,ゲームの進行が妨げられたタイミングで別のゲームの体力情報を取得する点で相違する旨主張するが,上記第4の1(13)や,上記1(7)で検討したとおり,引用発明は,ゲームの進行が可能な状況であっても,別のゲームの体力情報を取得するものであって,ゲームの進行が妨げられたタイミングで別のゲームの体力情報を取得するものではないから,請求人の主張を採用することはできない。
また,審判請求人は,審判請求書において,先願明細書等が,ゲームAを継続可能な状態でゲームBの体力ポイントを表示することを開示するものだとしても,ゲームAのゲーム画面においてどのようにゲームBの体力ポイントを表示するのかまでは開示も示唆もされておらず,体力ポイントがゲームAを継続可能な所定値(例えば,ゲームの進行が妨げられる値に近い値)に到達した場合に,ゲームBの体力ポイントによらず,何らかの表示方法によってゲームBの体力ポイントが表示される場合には,その度に別のゲームの通知が表示されてしまうため,ユーザはかえって煩わしさを感じる可能性があるから,本出願に係る発明と,引用文献1に記載された発明とは同一ではない旨を主張する。
しかし,引用発明は,ゲームB,C,D…の体力ポイントについて,第2条件を満たすか否かを判定しているから,審判請求人が主張するような,体力ポイントによらず,表示するものではないし,そもそも,本願発明も,別のゲームの体力情報が表示されてしまうことを排除するものでもない。
そうすると,出願人の主張は特許請求の範囲の記載に基づいているとはいえないから,採用することはできない。

第6 むすび
以上のとおりであるから,本願発明は,引用発明,すなわち,先願明細書等に記載された発明と同一である。
そして,引用発明の発明者が本願発明の発明者と同一の者ではなく,また,本願の出願の時に本願の出願人と先願の出願人とが同一の者でもない。
したがって,本願発明は,特許法第29条の2の規定により,特許を受けることができない。
よって,結論のとおり審決する。

 
審理終結日 2020-02-18 
結審通知日 2020-02-25 
審決日 2020-03-09 
出願番号 特願2017-95702(P2017-95702)
審決分類 P 1 8・ 161- Z (A63F)
最終処分 不成立  
前審関与審査官 田辺 正樹目黒 大地  
特許庁審判長 藤本 義仁
特許庁審判官 清水 康司
塚本 丈二
発明の名称 通知方法、ユーザ端末、及び通知プログラム  
代理人 恩田 博宣  
代理人 恩田 誠  
  • この表をプリントする

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