• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06Q
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06Q
管理番号 1389141
総通号数 10 
発行国 JP 
公報種別 特許審決公報 
発行日 2022-10-28 
種別 拒絶査定不服の審決 
審判請求日 2021-11-17 
確定日 2022-10-11 
事件の表示 特願２０１９−１６１４１６「提供装置、提供方法および提供プログラム」拒絶査定不服審判事件〔令和 ３年 ３月１１日出願公開、特開２０２１− ３９６０２、請求項の数（１６）〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第１ 手続の経緯

本願は，令和元年９月４日の出願であって，その手続の経緯は以下のとおりである。
令和３年 ５月２６日付け：拒絶理由通知
令和３年 ７月１２日 ：意見書，手続補正書の提出
令和３年 ８月 ６日付け：拒絶査定（以下「原査定」という。）
令和３年１１月１７日 ：拒絶査定不服審判請求，手続補正書の提出
令和４年 ６月 ８日付け：拒絶理由（以下「当審拒絶理由」という。）
通知
令和４年 ７月１４日 ：意見書，手続補正書の提出

第２ 原査定の概要

原査定の概要は，次のとおりである。
この出願の請求項１〜１８に係る発明は，以下の引用文献１〜６に記載された発明に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明をすることができたものであるから，特許法第29条第2項の規定により特許を受けることができない。

引用文献１： 特開２０１７−０２７３７７号公報
引用文献２： 特開２０１７−１６７８５８号公報
引用文献３： 特開２０１０−２５２２２６号公報
引用文献４： 特開２０１５−０１８３６６号公報
引用文献５： 特開２０１３−１２２６５６号公報
引用文献６： 特開２０１５−０９０５５６号公報

第３ 本願発明

本願請求項１〜１６に係る発明（以下，それぞれ「本願発明１」〜「本願発明１６」という。）は，令和４年７月１４日に提出された手続補正書により補正された特許請求の範囲の請求項１〜１６に記載された事項により特定される，次のとおりの発明である。

「【請求項１】
電子商店街において提供される機能を示す機能情報を取得する取得部と，
前記機能情報を，当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報として，利用者に提供する提供部と
を有し，
前記提供部は，
前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供する
ことを特徴とする提供装置。
【請求項２】
前記提供部は，前記機能情報のうち，前記利用者が利用していない機能を示す機能情報を当該利用者に提供する
ことを特徴とする請求項１に記載の提供装置。
【請求項３】
前記提供部は，前記機能情報のうち，前記利用者が利用した機能を示す機能情報を，利用済みの機能を示す機能情報として提供する
ことを特徴とする請求項１または２に記載の提供装置。
【請求項４】
前記取得部は，前記電子商店街において提供される機能であって，前記利用者が利用する端末装置で実行されるアプリケーションを介して利用される機能を示す機能情報を取得する
ことを特徴とする請求項１〜３のうちいずれか１つに記載の提供装置。
【請求項５】
前記取得部は，前記アプリケーションを介した取引対象の購入に関する機能を示す機能情報を取得する
ことを特徴とする請求項４に記載の提供装置。
【請求項６】
前記取得部は，前記電子商店街において販売される取引対象の検索に関する機能を示す機能情報を取得する
ことを特徴とする請求項１〜５のうちいずれか１つに記載の提供装置。
【請求項７】
前記取得部は，前記電子商店街における利用者の認証に関する機能を示す機能情報を取得する
ことを特徴とする請求項１〜６のうちいずれか１つに記載の提供装置。
【請求項８】
前記取得部は，前記電子商店街における利用者の情報の登録に関する機能を示す機能情報を取得する
ことを特徴とする請求項１〜７のうちいずれか１つに記載の提供装置。
【請求項９】
前記提供部は，前記機能情報のうち，前記利用者の属性に応じた機能を示す機能情報を提供する
ことを特徴とする請求項１〜８のうちいずれか１つに記載の提供装置。
【請求項１０】
前記機能情報が示す機能を前記利用者が利用した場合は，当該機能に応じた内容のインセンティブを当該利用者に対して付与する付与部
を有することを特徴とする請求項１〜９のうちいずれか１つに記載の提供装置。
【請求項１１】
前記付与部は，前記利用者に対して，前記機能に応じた量のポイントを付与し，付与済みのポイントに応じたインセンティブを付与する
ことを特徴とする請求項１０に記載の提供装置。
【請求項１２】
前記付与部は，付与されたポイントが多い方から並べた場合の順位に応じたインセンティブを前記利用者に対して付与する
ことを特徴とする請求項１１に記載の提供装置。
【請求項１３】
付与されたポイントが多い方から順に前記利用者を示す情報を並べた順位情報を公開する公開部
を有することを特徴とする請求項１０または１１に記載の提供装置。
【請求項１４】
前記提供部は，前記電子商店街において取引対象を販売する販売者により設定された機能を示す機能情報を前記利用者に提供する
ことを特徴とする請求項１〜１３のうちいずれか１つに記載の提供装置。
【請求項１５】
提供装置が実行する提供方法であって，
電子商店街において提供される機能を示す機能情報を取得する取得工程と，
前記機能情報を，当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報として，利用者に提供する提供工程と
を含み，
前記提供工程は，
前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供する
ことを特徴とする提供方法。
【請求項１６】
電子商店街において提供される機能を示す機能情報を取得する取得手順と，
前記機能情報を，当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報として，利用者に提供する提供手順と
をコンピュータに実行させ，
前記提供手順は，
前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供する
ことを特徴とする提供プログラム。」

第４ 引用文献の記載，引用発明等

１ 引用文献１

（１）原査定の拒絶の理由にて引用された引用文献１には，図面とともに，次の記載がある（下線は当審による。以下同様。）。
ア 「【技術分野】
【０００１】
本発明は，情報提供システム及び情報提供方法に関する。
【背景技術】
【０００２】
従来，端末のユーザ向けの広告情報及び特典情報等の各種の情報を端末に表示することが行われている。例えば，特許文献１には，サーバに登録された特典情報を携帯端末に配信し，当該携帯端末に表示させる方法が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】 特開２００３−１４１４０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来の方法においては，端末に配信した情報が適切であったかどうかを評価することなく，予め決定した情報を配信し続けていた。その結果，ユーザのニーズに合致しない情報を配信し続けてしまう場合が生じていた。このように，ユーザのニーズに合致しない情報が配信されると，ユーザにとっては，不要な情報が表示されることにより操作性が低下するという問題が生じ，情報を配信する企業にとっては，情報配信に要する費用に見合う効果を得ることができないという問題が生じていた。
【０００５】
そこで，本発明はこれらの点に鑑みてなされたものであり，ユーザに適した情報を提供することができる情報提供システム及び情報提供方法を提供することを目的とする。
（中略）
【発明の効果】
【００１２】
本発明によれば，ユーザに適した情報を提供することができるという効果を奏する。」

イ 図２


ウ 「【００２５】
［情報提供装置１の構成］
続いて，情報提供システムＳが備える情報提供装置１及び通信端末２の構成について説明する。まず，情報提供装置１の構成を説明する。図２は，第１の実施形態に係る情報提供装置１の構成を示す図である。
【００２６】
情報提供装置１は，記憶部１１と，制御部１２とを備える。
記憶部１１は，ＲＯＭ，ＲＡＭ及びハードディスク等の記憶媒体である。記憶部１１は，制御部１２が実行するプログラムを記憶する。また，記憶部１１は，管理者端末４から受信した表示情報と，条件情報とを記憶する。
（中略）
【００３２】
制御部１２は，例えばＣＰＵである。制御部１２は，記憶部１１に記憶されている各種プログラムを実行することにより，情報提供装置１に係る機能を制御する。制御部１２は，取得部１２１と，装置送信部１２２と，装置受信部１２３と，選択部１２４とを備える。これらの機能の詳細については後述する。
（中略）
【００３９】
まず，情報提供装置１の取得部１２１は，管理者端末４から，複数の表示情報と，当該表示情報に対応する条件情報を取得する（Ｓ１）。例えば，取得部１２１は，管理者端末４から，表示情報及び条件情報の登録要求を受け付けたことに応じて，表示情報及び条件情報の登録を受け付けるための受付画面を管理者端末４に表示させ，当該受付画面を介して，表示情報及び条件情報を取得する。
（中略）
【００４２】
取得部１２１は，取得した複数の表示情報及び条件情報を記憶部１１に記憶させる。
装置送信部１２２は，複数の通信端末群のそれぞれに，記憶部１１に記憶されている複数種類の表示情報を送信する。具体的には，装置送信部１２２は，記憶部１１に記憶されている複数の表示情報のうち，第１表示情報と，当該第１表示情報に対応する条件情報とを，第１の通信端末群に属する複数の通信端末２Ａに送信する。また，装置送信部１２２は，記憶部１１に記憶されている複数の表示情報のうち，第２表示情報と，当該第２表示情報に対応する条件情報とを，第２の通信端末群に属する通信端末２Ｂに送信する。」

エ 図９


オ 「【００６７】
＜第２の実施形態＞
［アプリケーションの利用実態に応じて表示情報を選択する］
続いて，第２の実施形態に係る情報提供システムＳについて説明する。第２の実施形態に係る情報提供システムＳは，情報提供装置１が，ユーザのアプリケーションの利用実態に応じて，複数種類の表示情報から表示情報を選択する点で第１の実施形態に係る情報提供システムＳと異なる。以下，第１の実施形態と異なる部分について説明を行う。第１の実施形態と同じ部分については適宜説明を省略する。
【００６８】
図９は，第２の実施形態に係る情報提供システムＳの概要を示す図である。
第２の実施形態に係る情報提供システムＳにおいて，情報提供装置１は，管理者端末４から，複数の表示情報と，条件情報とを受信する（図９の（１））。
複数の通信端末２のそれぞれは，表示装置３に表示されている画面の遷移が発生したことを特定し，当該画面の遷移を示す画面遷移情報を情報提供装置１に送信する（図９の（２））。
【００６９】
情報提供装置１は，複数の通信端末２のそれぞれから画面遷移情報を受信すると，受信した複数の画面遷移情報に基づいて，複数の通信端末２におけるアプリケーションの利用実態を特定し，当該利用実態に基づいて，それぞれの通信端末２に送信する表示情報を選択する（図９の（３））。
【００７０】
その後，情報提供装置１は，選択された表示情報を複数の通信端末２に送信する（図９の（４））。複数の通信端末２のそれぞれは，選択された表示情報を受信すると，当該表示情報を表示装置３に表示させる。
【００７１】
続いて，第２の実施形態における情報提供装置１の制御部１２及び通信端末２の制御部２３の具体的な機能について説明する。
第２の実施形態において，選択部１２４は，装置受信部１２３が受信した複数の画面遷移情報に基づいて，複数の通信端末２におけるアプリケーションの使用傾向を特定し，当該使用傾向に基づいて表示情報を選択する。
【００７２】
具体的には，選択部１２４は，複数の通信端末２から受信した複数の画面遷移情報の統計情報と，一の通信端末から受信した画面遷移情報とに基づいて，当該一の通信端末２におけるアプリケーションの使用頻度が高いか否かを判定し，使用頻度が高いと判定した場合に，当該一の通信端末２に送信する表示情報を選択する。
【００７３】
以下に，一の通信端末２における動画アプリケーションの使用頻度に基づいて，当該一の通信端末２に送信する表示情報を選択する例について説明する。
まず，通信端末２の特定部２３３は，動画アプリケーションによって表示される動画の再生時間を特定し，当該再生時間を含む画面遷移情報を生成する。そして，通信端末２の端末送信部２３４は，当該画面遷移情報を情報提供装置１に送信する。
【００７４】
続いて，選択部１２４は，複数の通信端末２から受信した複数の画面遷移情報の統計情報として，単位時間（例えば，１週間）あたりの動画の再生時間を特定する。すなわち，選択部１２４は，複数の端末ＩＤのそれぞれについて，画面遷移情報に含まれる動画の再生時間に基づいて，動画アプリケーションの平均利用時間を算出する。
【００７５】
そして，選択部１２４は，一の通信端末２における，動画アプリケーションの単位時間当たりの動画の利用時間が，算出した平均利用時間よりも所定割合以上長いか否かを判定することにより，動画アプリケーションの利用頻度が高いか否かを判定する。選択部１２４は，動画アプリケーションの利用頻度が高いと判定すると，当該ユーザの通信端末２に表示させる表示情報として，複数の表示情報の中から，動画アプリケーションに関する特典情報が含まれている表示情報を選択する。
【００７６】
例えば，選択部１２４は，動画アプリケーションの有料サービスを無料で利用することが可能な特典情報を含む表示情報を選択する。また，選択部１２４は，動画アプリケーションの利用頻度が高いと判定されなかったユーザの通信端末２に表示させる表示情報として，複数の表示情報の中から，動画アプリケーションの利用を促すメッセージを含む表示情報を選択する。
【００７７】
なお，選択部１２４は，画面遷移情報に含まれるパッケージ名，及び切替時刻に基づいて，一の通信端末２において起動された複数のアプリケーションのそれぞれの表示画面，起動回数，起動を継続した時間，起動開始時刻及び起動日時の少なくともいずれかを特定し，特定した表示画面，起動回数，起動を継続した時間，起動開始時刻及び起動日時の少なくともいずれかに基づいて，当該一の通信端末２に送信する表示情報を選択してもよい。このようにすることで，情報提供装置１は，アプリケーションの表示画面，起動回数，起動を継続した時間，起動開始時刻及び起動日時等の組み合わせに基づいてユーザを分類し，分類されたユーザのそれぞれに適した表示情報を選択することができる。
【００７８】
［第２の実施形態における効果］
以上の通り，第２の実施形態に係る情報提供装置１は，複数の通信端末２におけるアプリケーションの使用傾向を特定し，当該使用傾向に基づいて表示情報を選択する。このようにすることで，情報提供装置１は，ユーザのアプリケーションの利用状況に適した表示情報を選択することができる。」

（２）上記（１）から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されていると認められる。

「ユーザに適した情報を提供することができる情報提供システム情報提供システムＳが備える情報提供装置１であって，
情報提供装置１は，記憶部１１と，制御部１２とを備え，
記憶部１１は，ＲＯＭ，ＲＡＭ及びハードディスク等の記憶媒体であり，記憶部１１は，制御部１２が実行するプログラムを記憶しており，また，記憶部１１は，管理者端末４から受信した表示情報と，条件情報とを記憶しており，
制御部１２は，記憶部１１に記憶されている各種プログラムを実行することにより，情報提供装置１に係る機能を制御し，制御部１２は，取得部１２１と，装置送信部１２２と，装置受信部１２３と，選択部１２４とを備えており，
取得部１２１は，管理者端末４から，複数の表示情報と，当該表示情報に対応する条件情報を取得し，取得した複数の表示情報及び条件情報を記憶部１１に記憶させ，
装置送信部１２２は，複数の通信端末群のそれぞれに，記憶部１１に記憶されている複数種類の表示情報を送信しており，
選択部１２４は，装置受信部１２３が受信した複数の画面遷移情報に基づいて，複数の通信端末２におけるアプリケーションの使用傾向を特定し，当該使用傾向に基づいて表示情報を選択するものであり，
具体的には，選択部１２４は，複数の通信端末２から受信した複数の画面遷移情報の統計情報と，一の通信端末から受信した画面遷移情報とに基づいて，当該一の通信端末２におけるアプリケーションの使用頻度が高いか否かを判定し，使用頻度が高いと判定した場合に，当該一の通信端末２に送信する表示情報を選択しており，
動画アプリケーションの利用頻度が高いと判定すると，当該ユーザの通信端末２に表示させる表示情報として，複数の表示情報の中から，動画アプリケーションに関する特典情報が含まれている表示情報を選択し，
動画アプリケーションの利用頻度が高いと判定されなかったユーザの通信端末２に表示させる表示情報として，複数の表示情報の中から，動画アプリケーションの利用を促すメッセージを含む表示情報を選択する
情報提供装置１。」

２ 引用文献２

原査定の拒絶の理由にて引用された引用文献２には，図面とともに，次の記載がある。

ア 「【技術分野】
【０００１】
本発明は，課金サーバ，課金システム及び課金方法に関する。
【背景技術】
【０００２】
データ通信サービスの需要は，時間帯や場所によって増加する場合がある。例えば，通勤時間帯における電車内，イベント会場におけるイベント開催時，災害時，および夜間の住宅街などにおいて，データ通信サービスの需要が増加する。データ通信サービスの需要が増加すると，輻輳が発生して通信が途切れがちになったり，通信データが途中で失われたり，一時的に通信不能になったりすることがある。
特許文献１に記載の帯域予約装置は，ユーザによって操作された通信端末から送信される予約情報に応じて，移動体通信システムにおける通信帯域の使用の予約を事前に受け付けることにより，予約に応じたデータ通信サービスを提供することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】 特開２０１５−１５６５６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら，特許文献１に記載されるような，特定の通信端末に対して優先的に通信を行うサービス（以下，優先通信ともいう）を提供したとしても，通信の途切れや通信データの喪失，一時的な通信不能などを，必ずしも回避できるとは限らない。このような通信の途切れや通信データの喪失，一時的な通信不能などの通信品質の低下は，発生しないことが好ましい。例えば，コンテンツプロバイダが通信を介してユーザにサービスを提供する場合に，コンテンツプロバイダとの通信を行う動機をユーザに対して与える観点から，ユーザとコンテンツプロバイダとの間の通信については通信品質の低下が発生しないことが好ましい。
一方で，仮に通信品質の低下等が発生したとしても，コンテンツプロバイダとの通信を行うユーザに対して何らかの特典があれば，コンテンツプロバイダとの通信を行う動機をユーザに対して与えることができる場合がある。
【０００５】
本発明は，上記の点に鑑みてなされたものであり，ユーザに対して，コンテンツプロバイダとの通信を行う動機を与えることができる課金サーバ，課金システム及び課金方法を提供することを目的とする。」

イ 図３


ウ 「【００２６】
［課金サーバの構成］
次に，課金サーバ９０の機能構成について，図面を参照しながら説明する。
図３は，本実施形態に係る通信システム１の課金サーバ９０の機能構成を示すブロック図である。
課金サーバ９０は，通信情報取得部９００と，課金部９１と，特典付与部９２と，を含んで構成される。課金部９１は，課金データ生成部９１１と，課金情報記憶部９１２と，課金実行部９１３と，を含んで構成される。特典付与部９２は，特典付与条件取得部９２１と，特典付与条件記憶部９２２と，特典処理部９２３と，を含んで構成される。」

エ 図４


オ 「【００３６】
次に，特典処理部９２３が行う判定の一例について，図４を参照して説明する。
図４は，本実施形態に係る課金サーバ９０による特典付与条件の一例を示す図である。
【００３７】
［特典パターン１：特定のアプリケーションが使用されたことによる特典の付与］
特典処理部９２３は，通信が特定のアプリケーションによって行われたか否かを判定する。具体的には，特典付与条件記憶部９２２には，特典対象アプリケーション情報が記憶されている。この特典対象アプリケーション情報とは，端末で動作する様々なアプリケーションのうち，特典の対象であるアプリケーションを示す情報である。この場合，ユーザＵＲが，特典対象のアプリケーションを利用してコンテンツプロバイダＣＰと通信をした場合に，ユーザＵＲに対して特典が付与される。ここで，特典対象のアプリケーションには，コンテンツプロバイダＣＰが提供するアプリケーションが含まれる。例えば，コンテンツプロバイダＣＰが動画配信事業者である場合には，特典対象のアプリケーションには，動画視聴アプリケーションが含まれる。また，例えば，コンテンツプロバイダＣＰが通信販売事業者である場合には，特典対象のアプリケーションには，商品選択アプリケーションが含まれる。
課金サーバ９０は，コンテンツプロバイダＣＰが推奨するアプリケーションの利用に対して特典を付与することにより，ユーザＵＲに対して，コンテンツプロバイダＣＰとの通信を行う動機を与えることができる。
なお，課金サーバ９０は，コンテンツプロバイダＣＰが推奨するアプリケーションを利用し，更にコンテンツプロバイダＣＰとの間において有料の取引を行ったことに対して特典を付与してもよい。このように構成しても，課金サーバ９０は，ユーザＵＲに対して，コンテンツプロバイダＣＰとの通信を行う動機を与えることができる。
【００３８】
［特典パターン２：特定ＵＲＬに対して通信が行われたことによる特典の付与］
特典処理部９２３は，通信が特定のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に対して行われたか否かを判定する。具体的には，特典付与条件記憶部９２２には，特典対象アクセス先情報が記憶されている。この特典対象アクセス先情報とは，様々なアクセス先のうち，特典の対象であるアクセス先を示す情報である。この場合，コンテンツプロバイダＣＰが提供するＵＲＬに対してユーザＵＲがアクセスした場合に，ユーザＵＲに対して特典が付与される。ここで，コンテンツプロバイダＣＰが提供するＵＲＬには，コンテンツプロバイダＣＰのホームページやポータルサイトのＵＲＬが含まれる。また，コンテンツプロバイダＣＰが提供するＵＲＬには，コンテンツプロバイダＣＰが提供するキャンペーン，バナー広告，コンテンツのお試し利用などのＵＲＬが含まれる。
課金サーバ９０は，コンテンツプロバイダＣＰが推奨するＵＲＬへのアクセスに対して特典を付与することにより，ユーザＵＲに対して，コンテンツプロバイダＣＰとの通信を行う動機を与えることができる。
【００３９】
［特典パターン３：取引状況に応じた特典の付与］
特典処理部９２３は，ユーザＵＲとコンテンツプロバイダＣＰとの取引状況を判定する。具体的には，特典付与条件記憶部９２２には，特典対象取引情報が記憶されている。この特典対象取引情報とは，ユーザＵＲとコンテンツプロバイダＣＰとの取引状況のうち，特典が付与される取引状況を示す情報である。この取引状況には，ユーザＵＲを識別するユーザＩＤ，ユーザＵＲとコンテンツプロバイダＣＰとの間の取引有無，取引回数，取引頻度，日時，商品名等，などが含まれる。例えば，特典処理部９２３は，コンテンツプロバイダＣＰへのアクセスが所定回数以上ある場合に特典を付与するとしてもよい。また，特典処理部９２３は，通信が行われた月内に過去１回でも取引があれば特典を付与するとしてもよい。取引有無が特典の付与条件である場合，特典処理部９２３は，ユーザＵＲとコンテンツプロバイダＣＰとの取引の有無を判定する。特典処理部９２３は，ユーザＵＲとコンテンツプロバイダＣＰとの取引が有る場合，又は無い場合に，ユーザＵＲに対して特典を付与する。取引が有る場合に特典を付与する場合の一例に「リピーター特典」がある。また，取引が無い場合に特典を付与する場合の一例に「新規顧客特典」がある。
また，ユーザＵＲとコンテンツプロバイダＣＰとの取引状況には，ユーザＵＲのコンテンツプロバイダＣＰへの会員登録処理の状況や，商品等の購入処理の状況が含まれる。特典処理部９２３は，例えば，ユーザＵＲがコンテンツプロバイダＣＰへの新規会員登録を行った場合に，特典を付与するとしてもよい。
また，課金サーバ９０は，ユーザＵＲとコンテンツプロバイダＣＰとの間においてやり取りされる通信内容を受信することにより，ユーザＵＲとコンテンツプロバイダＣＰとの取引状況を取得するとして説明するが，これに限られない。例えば，コンテンツプロバイダＣＰが，ユーザＵＲとコンテンツプロバイダＣＰとの取引状況を記憶するデータベース（不図示）を備えている場合がある。この場合には，課金サーバ９０は，ユーザＵＲとコンテンツプロバイダＣＰとの取引状況を，コンテンツプロバイダＣＰのデータベースから取得してもよい。」

３ 引用文献３

原査定の拒絶の理由にて引用された引用文献３には，図面とともに，次の記載がある。

ア 「【技術分野】
【０００１】
本発明は，携帯端末および取扱説明書表示方法に関する。
【背景技術】
【０００２】
携帯電話機，ＰＨＳ（Personal Handyphone System），ＰＤＡ（Personal Data Assistance，Personal Digital Assistants：個人向け携帯型情報通信機器）等の携帯端末では，多機能化が進んでいる。例えば，電話機能の他に，カメラ機能，音楽再生機能等々，様々な便利な機能が実装されている携帯電話機が知られている。
【０００３】
携帯端末が多機能化するにつれて，携帯端末のユーザ（以下，単に「ユーザ」と称する）は，携帯端末が有するすべての機能の操作方法を覚えることが困難になってくる。また，多くのユーザは，携帯端末の取扱説明書を携帯端末と共に持ち歩かない。このため，ユーザは，携帯端末が有する多くの機能のうち，日頃使い慣れた機能のみを使用することが多い。
【０００４】
特許文献１には，携帯端末が有する多くの機能のうち，使用されていない機能の名称を，便利機能として，表示部に表示する携帯端末が記載されている。
【０００５】
特許文献２には，ある機能に対するユーザの操作履歴に基づいて，その機能についての操作ガイドのうち，ユーザに必要と思われる操作ガイド部分を特定して表示する操作ガイド表示装置が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】 特開２００１−３５８８１８号公報
【特許文献２】 特開２００８−２８８６５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
取扱説明書に記載された説明のうち，ユーザが希望する説明部分を表示することが，携帯端末に求められている。しかしながら，ユーザが希望する説明部分は，個々のユーザによって異なると考えられる。例えば，携帯端末の操作に詳しいユーザは，特定の機能のみの操作ガイド（説明）を希望する可能性が高いが，携帯端末の操作に詳しくないユーザは，すべての機能についての説明を希望する可能性がある。
【０００８】
特許文献１に記載の携帯端末は，使用されていない機能の名称を表示するため，携帯端末の操作に詳しいユーザにとっては，ユーザが希望する説明部分を表示する携帯端末となる可能性が高い。しかしながら，この携帯端末は，すべての機能についての説明を希望するユーザにとっては，ユーザが希望する説明部分を表示しない携帯端末となる可能性が高い。
【０００９】
また，特許文献２に記載の操作ガイド表示装置は，ユーザの操作履歴に基づいて操作ガイド部分を特定して表示する。このため，この操作ガイド表示装置は，ユーザが操作した履歴がない機能については，予め定められた操作ガイドを表示する。よって，この予め定められた操作ガイドが，互いに異なる説明内容を希望する複数のユーザ（例えば，装置の操作に詳しいユーザと，装置の操作に詳しくないユーザ）のそれぞれが希望する説明部分となる可能性は低い。
【００１０】
つまり，特許文献１に記載の携帯端末および特許文献２に記載の操作ガイド表示装置は，取扱説明の表示に関するユーザの多様な要求に応えることができないという課題があった。
【００１１】
本発明の目的は，上述した課題を解決可能な携帯端末および取扱説明書表示方法を提供することである。」

イ 図５（ａ）


ウ 「【００９８】
図５（ａ）に示した画面２ｄでは，未操作フラグ“１”が付与されていない「外観図」２ｄ１および「キー操作」２ｄ２は，グレーアウトされている。このため，カテゴリ名がグレーアウトされているか否かにより，未使用機能（未使用項目）を有するカテゴリを見分けることが可能になる。」

４ 引用文献４

原査定の拒絶の理由にて引用された引用文献４には，図面とともに，次の記載がある。

ア 「【技術分野】
【０００１】
本発明は，登録されている端末機器にユーザに推奨するコンテンツの情報を提供する情報提供プログラム，情報提供サーバ装置及び端末機器に関するものである。
【背景技術】
【０００２】
スマートフォンやタブレットＰＣのような多くの携帯情報端末は，アプリケーション，動画，電子書籍等のコンテンツを，コンテンツ提供サービス（サーバ）を介して取得するようになっている。このようなコンテンツ提供サービスは，ユーザの要求によりコンテンツを送信する以外にも，ユーザに対し，おすすめ情報を提供するサービスを行っている場合が多い。このようなおすすめ情報の提供サービスは，たとえば，特許文献１に示すような配信サービスがある。
【０００３】
特許文献１の新着コンテンツ配信方法は，予めユーザによって登録されている検索キーを用いてコンテンツ収集ロボットが，ウェブ上のコンテンツを検索する。そして，前記コンテンツ収集ロボットが収集したコンテンツを，データベースに保存し，最新のコンテンツの情報を登録ユーザに送信する。このとき，コンテンツ解析部が，データベースに保存したコンテンツ情報に，ユーザが登録している検索キーに基づいてユーザの嗜好に類似したコンテンツが含まれているか解析する。そして，データベースにユーザの嗜好に類似したコンテンツが含まれている場合，ユーザの嗜好に類似したコンテンツの情報も一緒にユーザに送信するようにしている。
【０００４】
これにより，ユーザの嗜好にマッチしたコンテンツの情報を送信することで，ユーザは詳細に検索キーを登録しなくても，嗜好にマッチしたコンテンツの情報を取得することができる。また，ユーザが以前にダウンロードしたコンテンツに類似したコンテンツのうち，ダウンロード数の多いコンテンツを，推奨情報として送信するものもある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】 特開２００２−２９７６５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら，上記特許文献１の構成では，ユーザが予め登録している検索キーに基づき，ユーザの嗜好にマッチしたコンテンツの情報を提示しているが，ユーザが登録した検索キーによっては，類似するコンテンツの量が膨大になり，利便性が悪い場合がある。また，検索キーの登録から長い時間がたっている場合，現在のユーザの嗜好とは異なるコンテンツの情報が送信され，ユーザの利便性が悪い場合がある。
【０００７】
さらに，ユーザがダウンロードしたコンテンツと類似のコンテンツでダウンロード数の多いコンテンツの情報を推奨情報とするものの場合，すでに所有しているコンテンツと類似したコンテンツであるため，有益ではないコンテンツである場合が多い。例えば，コンテンツがアプリケーションの場合，ダウンロードしているアプリケーションと同種のアプリケーションの情報を提供されても，ユーザにとって有益な情報にならない場合がある。
【０００８】
この発明は，上記のような課題を解決するためになされたものであり，この発明の１つの目的は，ユーザにとって有益なコンテンツの情報を提供する情報提供サーバ装置，情報提供サーバ装置から情報を取得する端末機器及び情報提供プログラムを提供することである。」

イ 図８


ウ 「【００７１】
次に，サーバ装置１による推奨アプリの情報の送信手順について図面を参照して説明する。図８は本発明にかかる情報提供サーバ装置による推奨アプリの情報の提供手順を示すフローチャートであり，図９は利用情報データベースの他の例を示す図である。図８に示すように，サーバ装置１は，登録されているスマートフォン２に対してアプリの利用情報の要求を発信する（ステップＳ２１）。なお，図示はしていないが，利用情報要求の送信は定期的に行われる。また，図８に示す推奨アプリの情報の提供手順は，任意のアカウントに対し，推奨アプリを選出し，その推奨アプリの情報を提供するものである。そして，任意のアカウントを入れ替えることで，登録されている全て又は略全てのアカウントに対して推奨する推奨アプリを選出できる。
【００７２】
サーバ装置１の中央処理部３は，登録されているアカウントのスマートフォン２からのアプリの利用情報を取得したかどうか確認する（ステップＳ２２）。利用情報を取得していない場合（ステップＳ２２でＮｏの場合），スマートフォン２がネットワーク１００に接続されていない可能性もあるので，アプリの利用情報の要求を行う（ステップＳ２１）。
【００７３】
スマートフォン２からの利用情報を取得した場合（ステップＳ２２でＹｅｓの場合），情報管理部３２が利用情報データベースＤｐ１に利用情報を追加記録する（ステップＳ２３）。なお，スマートフォン２からの利用情報は，一定以上の利用度のアプリの情報が送信されるため，利用情報データベースＤｐ１は，一定の利用度以上のアプリが登録されていることになる。
【００７４】
そして，コンテンツ選出部３３は，利用情報データベースＤｐ１を参照し，複数のアカウントで利用されているアプリを特定する（ステップＳ２４）。例えば，図４に示す利用情報データベースＤｐ１を参照すると，アカウントＡｃｃ１のスマートフォン２では，アプリＡｐ１，アプリＡｐ２，アプリＡｐ３が多く利用されていることがわかる。また，同様に図９に示す利用情報データベースＤｐ１を参照するとアカウントＡｃｃ２のスマートフォン２では，アプリＡｐ２，Ａｐ４，Ａｐ５が多く利用されていることがわかる。つまり，アプリＡｐ２は，アカウントＡｃｃ１とアカウントＡｃｃ２の複数のアカウントで利用されていることがわかり，アプリＡｐ２を複数のアカウントで利用されているアプリとして特定する。
【００７５】
このようにして，複数のアカウントが利用しているアプリが特定されると，コンテンツ情報抽出部３４がその特定されたアプリの情報（ジャンル，作者，容量）をコンテンツ保持部４１に保持されているアプリより抽出する（ステップＳ２５）。図５に示すように，アプリＡｐ１，アプリＡｐ２，アプリＡｐ４，アプリＡｐ５が複数のアカウントで利用されているアプリであり，このアプリの情報（ジャンル，作者，容量）を抽出する。そして，これらの情報を，コンテンツデータベースＤｃ１の各データフィールドに記録する（ステップＳ２６）。
【００７６】
そして，コンテンツ選出部３３は，コンテンツデータベースＤｃ１を参照し，任意のアカウントが利用しているアプリを利用している他のアカウントを抽出する（ステップＳ２７）。そして，コンテンツ選出部３３は，他のアカウントが利用しているアプリで任意のアカウントが利用していないアプリを選出する（ステップＳ２８）。
【００７７】
例えば，任意のアカウントをアカウントＡｃｃ１とすると，図５に示すように，任意のアカウントＡｃｃ１が利用しているコンテンツＡｐ２を利用しているアカウントはＡｃｃ２，Ａｃｃ６がいることがわかる。このアカウントＡｃｃ２，Ａｃｃ６が他のアカウントである。そして，コンテンツ選出部３３が，この他のアカウントＡｃｃ２，Ａｃｃ６が利用していて，アカウントＡｃｃ１が利用していないコンテンツ，すなわち，コンテンツＡｐ４，Ａｐ５を選出する。
【００７８】
そして，コンテンツ情報送信部３５は，コンテンツデータベースＤｃ１を参照し，選出したアプリの情報を対応するアカウントのスマートフォン２に対して送信する（ステップＳ２９）。例えば，任意のアカウントであるアカウントＡｃｃ１のスマートフォン２に，アプリＡｐ４，Ａｐ５の情報を送信する。
【００７９】
このように，サーバ装置１が一定以上の利用度（例えば，利用頻度，時間で表される）アプリを取得し，任意のアカウントの使用者と同じアプリを利用している他のアカウントの使用者は，アプリに対する嗜好，要求が似ているものと考えることができる。そして，同じアプリを利用している他のアカウントが利用しているアプリで任意のアカウントが利用していないアプリの情報をそのアカウントに提供することで，使用者の嗜好，ニーズに高度に合致した推奨アプリの情報を提供することができる。
【００８０】
（第２実施形態）
図８に示す推奨アプリの提供手順では，同じアプリを利用している他のアカウントが利用しているアプリで，未使用のアプリの情報を送信する構成となっていた。この構成でも，使用者の嗜好や要求に合致するアプリの情報を提供することが可能である。」

５ 引用文献５

原査定の拒絶の理由にて引用された引用文献５には，図面とともに，次の記載がある。

ア 「【技術分野】
【０００１】
本発明は，ユーザに操作を習得させるための操作ガイドを実行する技術に関する。
【背景技術】
【０００２】
携帯電話機やスマートフォンなどの情報処理装置では，例えばインストールされたアプリケーションプログラムの数が増加すると，それに伴い，ユーザの操作に応じて実現可能な機能の数も増加する。また，情報処理装置において各機能を実現する操作の操作方法も様々である。例えばタッチパネルディスプレイを有している情報処理装置では，いわゆるピンチイン操作（２本の指を画面上に載せてその間隔を縮める動作による操作）やピンチアウト操作（２本の指を画面上に載せて指と指の間を広げる動作による操作），フリック操作（画面上で指を滑らせる操作）などと呼ばれる操作に対応しており，実現される機能が操作に応じて異なることもある。このような理由により，情報処理装置を利用するユーザにとっては，情報処理装置でどのような機能を実現可能であり，また，各機能を実現させるためにどのような操作を行うべきか，ということを正確に理解するのが難しいことがある。汎用の情報処理装置は，不特定多数のユーザに利用されることを想定して設計されているため，個々のユーザにしてみれば，自身にとって必要な機能とそうではない機能とが混在して情報処理装置に実装されていることも少なくない。よって，ユーザは，説明書を見たりヘルプ機能を利用したりして機能と操作との関係を理解し，自身が利用したい機能を選んで必要な操作を習得する。情報処理装置の操作の習得に関するユーザの負担を軽減できるように，ユーザの操作の習熟度や情報処理装置の利用意図を基に支援を行う技術が，例えば特許文献１から特許文献３に開示されている。
【０００３】
特許文献１は，多様な機能の存在の教示による機能活用率を向上させるべく，起動回数がより少ない機能を優先させて，機能に関してユーザに教示することを開示している。特許文献２は，ユーザの一連の操作履歴を基に，ユーザによる装置の利用目的を推定し，更に操作方法や操作内容を推定して，適切な操作ガイドをユーザに対して行うことを開示している。特許文献３は，画面に表示される個々の機能の説明文に含まれる文字と，個々の機能に対し付与された機能表現名とを比較することにより，ユーザの操作意図を推定し，適切なガイドをユーザに提示することを開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】 特開２００４−２８９２１０号公報
【特許文献２】再表２００８−２６５６６号公報
【特許文献３】再表２００８−５６５４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところでタッチパネルディスプレイを採用した情報処理装置には，アイコンやウィジェット等の選択対象のオブジェクトに入力フォーカスが与えられた状態にはならないものがある。この種の情報処理装置では，入力フォーカスが与えられたオブジェクトを基にユーザの操作意図を推定することができない。このように，操作意図の推定精度が情報処理装置の操作手段に大きく依存する場合がある。このような場合であっても，情報処理装置が積極的に機能を提示すれば，操作手段（操作意図の推定精度）によらないで，いずれはユーザが望む機能を提示できるようになる。しかしながら，ユーザが操作の習得を望んでいないような場面で操作ガイドに関する表示があると，ユーザがその表示を煩わしく感じてしまい，情報処理装置がユーザにとって使いづらいものとなるおそれがある。
そこで，本発明は，機能を実現させる操作のユーザの習得意欲に配慮して操作ガイドを実行することを目的とする。」

イ 図３


ウ 「【００２０】
＜機能ＤＢ１５１の構成＞
図３は，機能ＤＢ１５１の構成を示す図である。図３に示すように，機能ＤＢ１５１は，機能ＩＤと，機能名称と，推奨情報と，操作ガイド情報と，実現アプリＩＤと，実現画面ＩＤと，機能特徴量と，低利用機能フラグと，推奨情報提示フラグと，操作ガイド実行フラグと，実行フラグ変更時刻と，操作ガイド即時実行フラグという各情報を対応付けて格納したデータベースである。機能ＩＤは，情報処理装置１０で実現可能な機能を識別する識別情報である。機能ＤＢ１５１には，機能ＩＤが示す各機能に対応して前掲の各情報が格納される。
（中略）
【００２２】
図３の説明に戻る。
低利用機能フラグは，情報処理装置１０において機能が実現された（つまり，ユーザに機能が利用された）頻度が低いか否かを示す情報である。本実施形態の低利用機能は，機能ＤＢ１５１において低利用機能フラグが「Ｔｒｕｅ」とされた機能であり，例えば予め決められた期間（例えば，３ヶ月）継続して情報処理装置１０で実現されていない機能である。低利用機能は，ユーザがその存在を知らなかったり，実現させる操作をユーザが知らなかったりする可能性が，他の機能よりも高いと考えられる。それ以外の機能は低利用機能ではないから，低利用機能フラグが「Ｆａｌｓｅ」とされる。推奨情報提示フラグは，推奨情報が示す内容が提示対象（つまり，推奨機能としての提示対象）となっているか否かを示す情報である。推奨情報が示す内容が提示対象となっている機能については，推奨情報提示フラグが「Ｔｒｕｅ」とされ，推奨情報が示す内容が提示対象となっていない機能については，推奨情報提示フラグが「Ｆａｌｓｅ」とされる。操作ガイド実行フラグは，操作ガイドが実行対象となっているか否かを示す情報である。操作ガイドが実行対象となっている機能については，操作ガイド実行フラグが「Ｔｒｕｅ」とされ，操作ガイドが実行対象となっていない機能については，操作ガイド実行フラグが「Ｆａｌｓｅ」とされる。実行フラグ変更日時は，操作ガイド実行フラグが「Ｆａｌｓｅ」から「Ｔｒｕｅ」に変更させられた日時を示す情報である。操作ガイド即時実行フラグは，操作ガイドを即時（すぐに）実行する対象となっているか否かを示す情報である。操作ガイドが即時の実行対象になっている機能ついては，操作ガイド即時実行フラグが「Ｔｒｕｅ」とされ，操作ガイドが即時の実行対象になっていない機能については，操作ガイド即時実行フラグが「Ｆａｌｓｅ」とされる。
図３に示すように機能ＤＢ１５１において，低利用機能フラグの初期値は「Ｔｒｕｅ」であり，推奨情報提示フラグ，操作ガイド実行フラグ及び操作ガイド即時実行フラグの初期値はいずれも「Ｆａｌｓｅ」である。また，操作ガイド実行フラグが「Ｆａｌｓｅ」のときには，実行フラグ変更日時はブランクである。」

エ 「【００３４】
＜１．新たな推奨機能の提示＞
まず，情報処理装置１０が新たな推奨機能を提示する際の動作を説明する。ここでは，情報処理装置１０の制御部１１はホームアプリケーションを予め実行していて，図２に示すホーム画面ＳＣをＵＩ部１４に表示させているものとする。
【００３５】
制御部１１は，推奨機能を提示するか否かを判断する（図７のステップＳａ１）。制御部１１は，図２に示すホーム画面ＳＣにおいて別の情報（例えば，交通情報等の情報を記したポップアップ画面など）を表示させていない場合に，例えば所定周期毎に又は所定期間継続してユーザの操作を受け付けなかったときには，推奨機能を提示すると判断する。これ以外にも，制御部１１は，操作ガイドを契機に推奨機能を実現する操作を受け付けた場合にも，推奨機能を提示すると判断するが，この内容については後で説明する。
なお，制御部１１が推奨機能を提示しないと判断した場合は（ステップＳａ１；ＮＯ），ステップＳａ１７の処理に進み，操作ガイドに関する操作ガイド制御を実行するが，この内容についても後で説明する。
【００３６】
制御部１１は，ステップＳａ１の処理で「ＹＥＳ」と判断すると，要求元アプリＩＤ及び要求元画面ＩＤを，実行状態管理テーブル１５２から取得する（ステップＳａ２）。ここにおいて，制御部１１は，図４に示す実行状態管理テーブル１５２から，要求元アプリＩＤ「com.XXX.homeApp」と要求元画面ＩＤ「.launcher」とを取得する。これにより，制御部１１は，推奨機能の提示の要求元がホームアプリケーションで，かつ，推奨機能の提示の要求元の表示画面がホーム画面ＳＣと特定する。
【００３７】
次に，制御部１１は，ＵＩ部１４に表示させている画面がホーム画面であるか否かを判断する（ステップＳａ３）。制御部１１は，実行状態管理テーブル１５２における実行中アプリＩＤ及び表示中画面ＩＤにより，ホーム画面を表示させているか否かを判断する。ここでは，実行中アプリＩＤが「com.XXX.homeApp」で，表示中画面ＩＤが「.launcher」であるから，制御部１１はステップＳａ３の処理で「ＹＥＳ」と判断して，ステップＳａ４の処理に進む。
なお，仮に，制御部１１がホームアプリケーションとともに別のアプリケーションプログラムを実行していて，ホーム画面と異なる画面をＵＩ部１４に表示させている場合には，ステップＳａ３の処理では「ＮＯ」と判断することとなる。
【００３８】
次に，制御部１１は，リマインド提示するか否かを判断する（ステップＳａ４）。リマインド提示は，既に提示した推奨機能についてユーザが操作ガイドの実行を指示したものの，操作ガイドの実行が所定期間経過してもなかった場合に，再び同じ推奨機能を提示する処理である。リマインド提示は，ユーザに推奨機能を思い出させる（いわゆるリマインドする）ことを目的とした処理であるが，その処理の詳細については後述する。制御部１１は，機能ＤＢ１５１において，ガイド実行フラグが「Ｔｒｕｅ」で，かつ，実行フラグ変更時刻から所定期間が経過した推奨機能が１つでも存在する場合には，ステップＳａ５の処理でリマインド提示を行うと判断する。この所定期間は予め決められた長さの期間であればよい。
【００３９】
ここではリマインド提示の対象となる推奨機能がないから，制御部１１はステップＳａ４の処理で「ＮＯ」と判断して，ステップＳａ８の処理に進む。次に，制御部１１は，ＵＩ部１４において提示中の推奨機能を所定期間継続して提示したか否かを判断する（ステップＳａ８）。制御部１１は，未だ推奨機能を提示していないから，ステップＳａ８の処理で「ＮＯ」と判断し，ステップＳａ１０の処理に進む。
【００４０】
次に，制御部１１は，新たな推奨機能を提示するか否かを判断する（ステップＳａ１０）。制御部１１は，リマインド提示せず，かつ，提示中の推奨機能がない場合には，低利用機能のいずれかを推奨機能として提示するとし，ステップＳａ１０の処理で「ＹＥＳ」と判断する。次に，制御部１１は，機能ＤＢ１５１から低利用機能を特定する（ステップＳａ９）。ここでは，制御部１１は，機能ＤＢ１５１に機能ＩＤが格納されたすべての機能を対象として，低利用フラグが「Ｔｒｕｅ」となっている低利用機能を特定する。
次に，制御部１１は，第１機能決定処理を実行する（ステップＳａ６）。第１機能決定処理は，ホーム画面において提示する推奨機能を決定する処理である。
【００４１】
図９は，第１機能決定処理の手順を示すフローチャートである。
制御部１１は，ステップＳａ９の処理で低利用機能を１以上特定したか否かを判断する（ステップＳａ６１）。ここでは，制御部１１はステップＳａ６１の処理で「ＹＥＳ」と判断し，ステップＳａ６２の処理に進む。
【００４２】
次に，制御部１１は，ステップＳａ９の処理で特定した低利用機能の推奨度をそれぞれ算出する（ステップＳａ６２）。ここでは，制御部１１は，低利用機能の推奨度を，機能特徴量と嗜好特徴量とにより以下の手順で算出する。ここで，ｉ番目に特定したアプリケーションプログラムにより実現されるｊ番目の機能における推奨度をＳｉｊとした場合，推奨度Ｓｉｊは下記式（１）の関係を満たす。
Ｓｉｊ＝ｗｉｐ・ｆｉｊ ・・・（１）
【００４３】
ここで，ｗｉはｉ番目に特定したアプリケーションプログラムに対する重み付け係数である。ｐは嗜好特徴量を表す特徴ベクトルである。ｆｉｊはｉ番目に特定したアプリケーションプログラムにより実現されるｊ番目の機能の機能特徴量を表す特徴ベクトルである。「・」は内積を意味する。重み付け係数ｗｉは下記式（２）の関係を満たす。
ｗｉ＝αｌｏｇ（１＋ｉｎｖｉ）＋βｌｏｇ（１＋ｔｉｍｅ＿ｕｓｅｄｉ／（ｔｉｍｅ＿ｉｎｓｔａｌｌｅｄｉ）＋θ ・・・（２）
【００４４】
ここで，ｉｎｖｉは，ｉ番目に特定したアプリケーションプログラムの起動回数（回）である。ｔｉｍｅ＿ｕｓｅｄｉは，ｉ番目に特定したアプリケーションプログラムの実行時間（秒）である。ｔｉｍｅ＿ｉｎｓｔａｌｌｅｄｉは，ｉ番目に特定したアプリケーションプログラムがインストールされてからの経過時間（秒）である。経過時間は，現在日時とインストール日時との差分に相当する時間である。α，βは，それぞれ定数である。θは，ｉ番目に特定したアプリケーションプログラムが情報処理装置１０において直前に実行されたアプリケーションプログラムである場合には０よりも大きい定数となり，直前に実行されたアプリケーションプログラムでない場合には０となる。制御部１１は，嗜好特徴量を表す特徴ベクトルｐを実行状態管理テーブル１５２から取得し，機能特徴量を表す特徴ベクトルｆｉｊを機能ＤＢ１５１から取得する。制御部１１は，ｉｎｖｉやｔｉｍｅ＿ｉｎｓｔａｌｌｅｄｉを利用実績ＤＢ］１５３から取得する。また，制御部１１は，実行状態管理テーブル１５２の直前実行アプリＩＤを参照して，直前に実行したアプリケーションプログラムを特定する。
【００４５】
これにより，重み付け係数ｗｉは，実行頻度が高いアプリケーションプログラムや直前に実行されたアプリケーションプログラムによって実現される機能ほど大きな値を採ることとなる。そして，重み付け係数ｗｉが大きいほど推奨度は高くなる。このようにしているのは，実行頻度が高いアプリケーションプログラムで実現される機能が推奨機能として提示される方が，それ以外のアプリケーションプログラムで実現される機能が推奨される場合に比べて，ユーザにとって有益な操作ガイドを実行できる可能性が高まるからである。
【００４６】
制御部１１は，ステップＳａ６２の処理で算出した推奨度に基づき，最大の推奨度が推奨閾値を上回るか否かを判断する（ステップＳａ６３）。制御部１１は，ステップＳａ６３の処理で「ＹＥＳ」と判断すると，推奨度が最大であった機能を提示対象の推奨機能に決定する（ステップＳａ６４）。すなわち，制御部１１は，推奨度が推奨閾値を上回った機能を推奨機能の候補とする。
なお，制御部１１は，ステップＳａ６１の処理で機能を１つも特定しなかったと判断した場合（ステップＳａ６１；ＮＯ），又はステップＳａ６３の処理で最大の推奨度が推奨閾値を上回らなかった場合には（ステップＳａ６３；ＮＯ），提示対象の推奨機能を決定しないで，第１機能決定処理を終了する。
以上が第１機能決定処理の説明である。
【００４７】
図７の説明に戻る。
制御部１１は，ステップＳａ６４の処理で提示対象として決定した推奨機能を，ＵＩ部１４のホーム画面において提示する（ステップＳａ７）。ステップＳａ６４の処理で，「ショートカット作成機能」を決定していた場合，制御部１１は，図１３に示すホーム画面ＳＣ１をＵＩ部１４に表示させる。具体的には，制御部１１は，機能名称に基づく「ショートカット作成機能を試してみませんか？」というメッセージと，推奨情報に基づく「アプリケーションの・・・好きな場所にアイコンを置くことができます。」というメッセージとを配置したウィンドウＷ１をホーム画面ＳＣ１において表示させる。さらに，制御部１１は，ウィンドウＷ１において，「すぐ試す」と記したソフトボタンＳＢ１と，「後で」と記したソフトボタンＳＢ２と，「不要」と記したソフトボタンＳＢ３とを表示させる。
このようにして，制御部１１は，ＵＩ部１４により推奨機能を提示する。」

６ 引用文献６

原査定の拒絶の理由にて引用された引用文献６には，図面とともに，次の記載がある。

ア 「【技術分野】
【０００１】
本発明は，情報処理システム，および情報処理方法に関する。
【背景技術】
【０００２】
今日において，位置情報サービスとＳＮＳ（ソーシャルネットワークサービス）とを組み合わせたサービスを提供する「フォースクエア（foursquare（登録商標））」と呼ばれるアプリケーションプログラムが知られている。
【０００３】
このフォースクエアのアプリケーションプログラム（以下，ＦＳＡＰという）を利用する場合，利用者は，自分の携帯端末装置にＦＳＡＰをインストールし，インターネット上のフォースクエアのサーバ装置に対して利用者登録を行う。
【０００４】
次に，利用者は，所望の場所でＦＳＡＰを起動する。携帯端末装置の制御部（ＣＰＵ）は，起動したＦＳＡＰに従って，インターネット上のフォースクエアのサーバ装置と通信を行い，利用者の現在位置に対応して予め登録されている「ベニュー」と呼ばれる場所情報を取得し，表示部に一覧表示する。このベニューは，多くの場合，現在位置から所定の地理的範囲内に存在する店舗，観光地等の情報となる。
【０００５】
利用者により，ベニューの一覧の中から所望のベニューが選択操作されると，携帯端末装置の制御部（ＣＰＵ）は，選択されたベニューの住所，電話番号，地図等の詳細情報をフォースクエアのサーバ装置から取得し，表示部に表示する。利用者は，このような詳細情報の表示等を行いながら，選択中のベニューが所望のベニューであるか否かを確認する。そして，利用者は，選択中のベニューが，自分が希望するベニューである場合に，表示画面上のチェックインボタンを操作する。
【０００６】
チェックインボタンが操作されると，携帯端末装置のＣＰＵは，利用者により選択されたベニューを示す情報を，利用者登録情報と共に，フォースクエアのサーバ装置に送信する。フォースクエアのサーバ装置は，利用者により選択されたベニューの情報を，利用者登録情報に関連付けてデータベースに記憶する。
【０００７】
フォースクエアのサーバ装置は，各ベニューに対するチェックイン回数を利用者毎にカウントしており，例えば各ベニューに対するチェックイン回数に応じて，利用者に対してバッジを付与する。このバッジは，金属等で形成されたバッジを模した画像であり，付与された利用者の携帯端末装置の表示部に表示される。
【０００８】
また，フォースクエアのサーバ装置は，ベニュー毎に，チェックイン回数が最も多い利用者を，そのベニューのメイヤー（市長）として認定する。フォースクエアのサーバ装置は，メイヤーに認定した利用者の情報を，上述の詳細情報に含めて送信することで，他の利用者に紹介する。
【０００９】
また，フォースクエアは，他の利用者のチェックイン状況を確認することができる。そして，チェックイン中の他の利用者に対して，メール等でコミュニケーションを図ることともできる。
【００１０】
このようなフォースクエアの場合，利用者は，ベニューに対するチェックイン回数を多くすることで，バッジまたはメイヤーの称号等の名誉的な利益を得ることができる。また，ベニューの店舗等は，バッジまたはメイヤーの称号等を目的とする利用者およびメール等のコミュニケーションによる紹介で訪れた利用者が店舗を利用することで，金銭的利益を得ることができる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかし，ベニューを訪れる利用者は，そのベニューの店舗の利用を目的としているわけではなく，そのベニューに対するチェックイン回数を増やすことを目的としている。このため，ベニューを訪れた利用者が，必ずしも店舗の売り上げに貢献するとは限らない。
【００１２】
すなわち，チェックイン回数を増やすことのみが目的である利用者は，ベニューを訪れて，店舗を利用することなくチェックインすることも可能である。この場合でも，フォースクエアのサーバ装置でチェックイン回数がインクリメントされるため，利用者にとって利益はあるが，店舗にとっては，利用者に利用されないことで金銭的利益が得られない。
【００１３】
これは，フォースクエアのシステムが，サーバ装置で利用者のチェックイン回数をカウントするシステムだからである。ベニューを訪れた利用者が，店舗を利用しないのであれば，店舗側は利益を得ることは困難となる。このようなことから，フォースクエアのシステムは，店舗側にとって導入しづらいシステムとなっていた。
【００１４】
本発明は，上述の課題に鑑みてなされたものであり，利用者および利用者が訪れる各場所の店舗等の双方のシステム導入を促進可能な情報処理システム，および情報処理方法の提供を目的とする。」

イ 図１４


ウ 「【００６０】
表示モードは，店舗の利用者の携帯端末装置２に表示される店舗情報の表示形態を示す。データベースには，店舗情報の表示形態が，表示モード番号で登録されている。図１４は，店舗情報の表示形態を示すモード番号表である。店舗側の担当者は，店舗情報の編集時等に，自店舗が希望する表示形態に対応する表示モード番号を，図１４に示すモード番号表を参照して指定する。例えば，自店舗の全ての利用者を取得ポイントが多い順に全員表示する場合，「１」の表示モード番号を指定する。また，自店舗の利用回数が多い５人の利用者と共に，本人を表示する場合，「２」の表示モード番号を指定する。また，自店舗の利用回数が多い全ての利用者を順に表示する場合，「３」の表示モード番号を指定する。また，自店舗の取得ポイントが多い５人の利用者と共に，本人を表示する場合，「４」の表示モード番号を指定する。
【００６１】
平均予算（ポイント）は，店舗側がレジスタ装置３で「平均予算＝総売り上げ÷利用者数」，または，「平均付与ポイント＝総発行ポイント数÷利用者数」の演算を行い，この演算結果をサーバ装置１に登録したものである。
【００６２】
このような第１の実施の形態のコミュニケーションシステムは，以下の効果を得ることができる。
【００６３】
取得ポイントに応じてメイヤー等の名誉的な利益を与えることで，各利用者は，ポイントの取得を目的として店舗に来店する。店舗では，実際に商品を購入，またはサービスの提供を受けた利用者に対してのみ，ポイントを付与する。このため，利用者は，必ず店舗で商品等を購入することとなり，確実に売り上げを上げることができる。従って，利用者は上述の名誉的な利益を得ることができ，店舗側は確実に売り上げを上げることができ，利用者および店舗の双方のシステム導入を促進可能なコミュニケーションシステムを提供することができる。
【００６４】
また，図１４を用いて説明したように，取得ポイント数の多い他の利用者と共に，本人の取得ポイント数を表示することで，本人である利用者は，自分が常連客ランキングのどの位置にいるのか認識することができる。なお，常連客ランキングの位置に応じて，ボーナス等の名目で利用者にポイントを付与してもよい。また，利用者は，所望の店舗に来店して商品を購入し，レシートに印刷された二次元コードを撮像して，サーバ装置１に送信するだけで一連の動作は完結する。また，実名やプロフィール写真は不要である。このため，簡単かつ安全なコミュニケーションシステムを提供できる。」

第５ 対比・判断

１ 本願発明１について

（１）対比

本願発明１と引用発明とを対比すると，以下のとおりとなる。

引用発明は，「ユーザに適した情報を提供することができる情報提供システム情報提供システムＳが備える情報提供装置１であって，」「取得部１２１は，管理者端末４から，複数の表示情報と，当該表示情報に対応する条件情報を取得し，取得した複数の表示情報及び条件情報を記憶部１１に記憶させ，装置送信部１２２は，複数の通信端末群のそれぞれに，記憶部１１に記憶されている複数種類の表示情報を送信しており，」「選択部１２４は，装置受信部１２３が受信した複数の画面遷移情報に基づいて，複数の通信端末２におけるアプリケーションの使用傾向を特定し，当該使用傾向に基づいて表示情報を選択するものであり，具体的には，選択部１２４は，複数の通信端末２から受信した複数の画面遷移情報の統計情報と，一の通信端末から受信した画面遷移情報とに基づいて，当該一の通信端末２におけるアプリケーションの使用頻度が高いか否かを判定し，使用頻度が高いと判定した場合に，当該一の通信端末２に送信する表示情報を選択しており，動画アプリケーションの利用頻度が高いと判定すると，当該ユーザの通信端末２に表示させる表示情報として，複数の表示情報の中から，動画アプリケーションに関する特典情報が含まれている表示情報を選択」しているとされている。

ここで，引用発明の「取得部１２１は，管理者端末４から，」「通信端末２に送信する表示情報を」「取得し」ているから，本願発明１と同様に，（通信端末２に）「提供される」「情報を取得」しているといえる。

また，引用発明の「装置送信部１２２は，複数の通信端末群のそれぞれに，」「ユーザの通信端末２に表示させる表示情報として」「送信して」いるから，本願発明１と同様に，「前記」「情報を，」「利用者に提供」しているといえる。

したがって，本願発明１と引用発明とは，「提供される」「情報を取得する取得部と，」「前記」「情報を，」「利用者に提供する提供部とを有し」ている「提供装置」である点で共通しているといえる。

しかし，本願発明１では，「提供装置」が取得する情報が「電子商店街において提供される機能を示す機能情報」であり，「当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報」であるのに対して，引用発明では，「電子商店街において提供される機能を示す機能情報」でなく，「当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報」でもない点で相違している。

また，本願発明１では，「提供部」が「前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供」しているのに対して，引用発明では，そのように提供していない点で相違している。

（２）一致点・相違点

本願発明１と，引用発明とは，以下アの点で一致し，以下イの点で相違する。

ア 一致点

「提供される情報を取得する取得部と，
前記情報を，利用者に提供する提供部と
を有する提供装置。」

イ 相違点

（ア） 相違点１

本願発明１では，「提供装置」が取得する情報が「電子商店街において提供される機能を示す機能情報」であり，「当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報」であるのに対して，引用発明では，「電子商店街において提供される機能を示す機能情報」でなく，「当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報」でもない点。

（イ） 相違点２

本願発明１では，「提供部」が「前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供」しているのに対して，引用発明では，そのように提供していない点。

（３）相違点についての判断

事案に鑑みて，まず，相違点２について検討する。

本願発明１の相違点２に係る構成の，特に，「前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を」提供するという構成について，引用文献１ないし６には，記載も示唆も無く，当該構成が周知であったとも認められない。

特に，原査定の引用文献３には，未使用機能を判別可能に表示することが開示されており，引用文献４には，他の利用者（先行利用者）が利用しているアプリであって，利用者が使用していないアプリの情報を提供することが開示されているものの，いずれにも，「先行利用者が利用していたタイミングに基づく所定の条件を満たす」ように提供する構成は開示されていない。

したがって，引用発明に基づいて，当業者は本願発明１の相違点２に係る構成を容易に想到することができない。

エ 小括

したがって，上記相違点１について判断するまでもなく，本願発明１は，引用発明および引用文献２ないし６に基づいて，当業者が容易に発明できたものであるとはいえない。

２ 本願発明２ないし本願発明１４について

本願発明２ないし本願発明１４は，いずれも，本願発明１を減縮したものであって，本願発明１と同一の構成を備えるものであるから，本願発明１と同じ理由により，引用発明および引用文献２ないし６に基づいて，当業者が容易に発明できたものであるとはいえない。

３ 本願発明１５について

本願発明１５は，概ね，本願発明１の発明のカテゴリを，単に，装置の発明から方法の発明へと変更したものであり，上記相違点２に係る構成と同様の以下の構成を備えているから，本願発明１と同様に，引用発明および引用文献２ないし６に基づいて，当業者が容易に発明できたものであるとはいえない。

「前記提供工程は，
前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供する」

４ 本願発明１６について

本願発明１６は，概ね，本願発明１の発明のカテゴリを，単に，装置の発明からプログラムの発明へと変更したものであり，上記相違点２に係る構成と同様の以下の構成を備えているから，本願発明１と同様に，引用発明および引用文献２ないし６に基づいて，当業者が容易に発明できたものであるとはいえない。

「前記提供手順は，
前記機能情報のうち，前記利用者が利用済みの機能を，当該利用者とは異なる利用者であって，前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に，前記利用者が利用済みの機能を含まない当該先行利用者が利用した機能を示す機能情報であって，当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を，インセンティブが提供される対象となる機能を示す前記機能情報として，当該利用者に対して提供する」

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

令和４年７月１４日提出の手続補正書による補正の結果，本願発明１〜１６はそれぞれ，相違点１および２に係る発明特定事項又はそれらに対応する発明特定事項を有するものとなっており，上記第５のとおり，引用発明および引用文献２ないし６に基づいて，当業者が容易に発明できたものであるとはいえない。

したがって，原査定を維持することはできない。

第７ 当審拒絶理由について

１ 当審拒絶理由の概要

当審が令和４年４月１９日付けで通知した当審拒絶理由の概要は次のとおりである。

（１）理由１（明確性）

この出願は，特許請求の範囲の記載が下記アおよびイの点で，特許法第36条第6項第2号に規定する要件を満たしていない。

ア 請求項１には「前記機能情報のうち、前記利用者が利用済みの機能を、当該利用者とは異なる利用者であって、前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に、当該先行利用者が利用した機能を示す機能情報であって、当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を、当該利用者に対して提供する」と記載され、「前記利用者が利用済みの機能」と「当該先行利用者が利用した機能」が規定されているところ、これらの関係は規定されていない。これらは、同じ機能であるのか、異なる機能であるのか、同じ機能と異なる機能を含む機能であるのか、特定できない。
したがって、請求項１に記載された「提供部」により提供する「機能情報」が不明りょうである。

請求項１を引用する請求項２−１４についても同じことが指摘される。
発明のカテゴリーが異なる請求項１５−１６についても同様の記載があり、同じことが指摘される。

イ 請求項１には「前記機能情報を、当該機能情報が示す機能を前記電子商店街において利用した場合にインセンティブが提供される対象となる機能を示す機能情報として、利用者に提供する提供部」と記載されているところ、該提供部に関して、「前記機能情報のうち、前記利用者が利用済みの機能を、当該利用者とは異なる利用者であって、前記電子商店街における利用態様が所定の条件を満たす利用者である先行利用者が利用していた場合に、当該先行利用者が利用した機能を示す機能情報であって、当該利用者が利用済みの機能を当該先行利用者が利用していたタイミングに基づく所定の条件を満たす機能情報を、当該利用者に対して提供する」と規定されているものの、提供部が提供する、該「機能情報」が「インセンティブが提供される対象となる機能」であるのか否か特定できない。 したがって、請求項１に記載された「提供部」が提供する「機能情報」が不明りょうである。

請求項１を引用する請求項２−１４についても同じことが指摘される。
発明のカテゴリーが異なる請求項１５−１６についても同様の記載があり、同じことが指摘される。

ウ よって、請求項１−１６に係る発明は明確でない。

（２）理由２（サポート要件）

この出願は，特許請求の範囲の記載が，特許法第36条第6項第1号に規定する要件を満たしていない。

本願明細書の段落【０００４】に記載の「近年、電子商店街に関するサービスの多様化に伴い、様々な内容のサービスが利用者に対して提供されている。しかしながら、上述した技術では、単に購買に応じた特典を提供しているに過ぎないため、サービスの存在を利用者に報知することができず、サービスを介した販売機会の損失を招く恐れがある。従って、電子商店街の利用をさらに促進させる余地がある。」との発明が解決しようとする課題によれば、本願発明の課題は、機能の存在を知らない利用者に報知することと認められる。すなわち、本願発明は、利用者が知らない（利用済みではない）機能を報知することで、電子商店街の利用をさらに促進させるものと認められる。

一方、提供する機能情報に関し、請求項１には「当該先行利用者が利用した機能を示す機能情報であって」と記載されているところ、上記（１）のとおり「利用者が利用済みの機能」との関係が規定されていないから、該「当該先行利用者が利用した機能」には「利用者が利用済みの機能」が含まれ得ると解される。
そうすると、請求項１に係る発明は、利用者が利用済みの機能、つまり、利用者がその存在を知っている機能、を提示するものを包含し、この場合、「利用者が知らない（利用済みではない）機能を報知することには、ならない。
したがって、請求項１には、発明の詳細な説明に記載された、発明の課題を解決するための手段が反映されておらず、請求項１に係る発明は、発明の詳細な説明に記載した範囲を超えることとなる。

請求項２−１４は、少なくとも請求項１を引用するから同じことが指摘される。
発明のカテゴリーが異なる請求項１５−１６についても同じ記載があり、同じことが指摘される。

よって、請求項１−１６に係る発明は、発明の詳細な説明に記載したものでない。

２ 検討

これに対し，令和４年７月１４日に提出された手続補正書により補正された特許請求の範囲では，請求項１，１５，１６について，それぞれ，「当該先行利用者が利用した機能を示す機能情報」が，「利用者が利用済みの機能を含まない」ことが明らかとなったから，当審拒絶理由の理由１および２はいずれも解消した。

第８ むすび

以上のとおり，原査定の理由によって，本願を拒絶することはできない。
また，他に本願を拒絶すべき理由を発見しない。
よって，結論のとおり審決する。

 
審決日 2022-09-27 
出願番号 P2019-161416
審決分類 P 1 8・ 121- WY (G06Q)
P 1 8・ 537- WY (G06Q)
最終処分 01   成立
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 石井 則之
野崎 大進
発明の名称 提供装置、提供方法および提供プログラム  
代理人 弁理士法人酒井国際特許事務所  

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