拒絶査定不服の審決｜不服2017-5126 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 1項3号刊行物記載取り消して特許、登録 G06F 審判査定不服 2項進歩性取り消して特許、登録 H04W
管理番号	1334940
審判番号	不服2017-5126
総通号数	217
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2018-01-26
種別	拒絶査定不服の審決
審判請求日	2017-04-10
確定日	2017-12-22
事件の表示	特願2014-527468「拡張現実ユーザコンテキストへのアクセス方法」拒絶査定不服審判事件〔平成25年 3月 7日国際公開、WO2013/029388、平成26年11月27日国内公表、特表2014-531632、請求項の数(42)〕について、次のとおり審決する。
結論	原査定を取り消す。本願の発明は、特許すべきものとする。
理由	第1 手続の経緯本願は,2012年5月8日(パリ条約による優先権主張2011年8月27日,中国)を国際出願日とする出願であって,平成28年5月27日付けで拒絶理由が通知され,平成28年9月5日に意見書と手続補正書が提出されたが,平成28年12月5日付けで拒絶査定がなされ,これに対し,平成29年4月10日に拒絶査定不服審判の請求がされると同時に手続補正書が提出され,平成29年6月8日に前置報告がされたものである。第2 原査定の概要原査定(平成28年12月5日付け拒絶査定)の概要は次のとおりである。 1.本願請求項1-6,9,13,14,17-21に係る発明は,以下の引用文献1又は2に記載された発明であるから,特許法第29条第1項第3号に該当し,特許を受けることができない。 2.本願請求項1-42に係る発明は,下記の引用文献1-3に基づいて,その発明の属する技術の分野における通常の知識を有する者(以下,「当業者」という。)が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない。引用文献等一覧 1.Kosuke Nishihara 他,Power Saving in Mobile Devices Using Context-Aware Resource Control,2010 First International Conference on Networking and Computing,IEEE,2010年11月19日,p.220-226 2.特開2010-239568号公報 3.特開2004-159026号公報第3 審判請求時の補正について審判請求時の補正は,特許法第17条の2第3項から第6項までの要件に違反しているものとはいえない。 1.請求項1,22について審判請求時の補正によって請求項1,22の「拡張現実ユーザコンテキストへのアクセスを管理することが,適切な拡張現実端末能力にアクセスすること,又は,拡張現実端末能力へのアクセスを最適化すること,又は,取得可能なネットワーク支援能力を利用することを含む」を「拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化すること,又は,取得可能なネットワーク支援能力を利用することを含む」とする補正は,補正前の請求項1,22に記載された「拡張現実ユーザコンテキストへのアクセスを管理すること」を限定するものであって,同法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。また,特許法第17条の2第3項,第4項に違反するところはない。そして,「第4 本願発明」から「第6 対比・判断」までに示すように,補正後の請求項1-42に係る発明は,独立特許要件を満たすものである。第4 本願発明本願請求項1-42に係る発明(以下,それぞれ「本願発明1」-「本願発明42」という。)は,平成29年4月10日付けの手続補正で補正された特許請求の範囲の請求項1-42に記載された事項により特定される発明であり,本願発明1,22は以下のとおりの発明である。「【請求項1】モバイル拡張現実クライアントが,拡張現実ユーザコンテキストへのアクセスに関連する情報を収集し, 前記モバイル拡張現実クライアントが,前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し, 前記モバイル拡張現実クライアントが,前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記拡張現実ユーザコンテキストへのアクセスを管理することを含み, 拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化すること,又は,取得可能なネットワーク支援能力を利用することを含む拡張現実ユーザコンテキストへのアクセス方法。」「【請求項22】モバイル拡張現実サーバが,拡張現実ユーザコンテキストへのアクセスに関連する情報を収集し, 前記モバイル拡張現実サーバが,前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し, 前記モバイル拡張現実サーバが,前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記モバイル拡張現実クライアントに前記拡張現実ユーザコンテキストへのアクセスを管理するように通知することを含み, 拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化すること,又は,取得可能なネットワーク支援能力を利用することを含む拡張現実ユーザコンテキストへのアクセス方法。」なお,本願発明2-21,23-42の概要は以下のとおりである。本願発明2-21は,本願発明1を直接又は間接的に引用した発明である。本願発明23-42は,本願発明22を直接又は間接的に引用した発明である。第5 引用文献,引用発明等 1.引用文献1について原査定の拒絶の理由に引用された引用文献1には,図面とともに次の事項が記載されている(なお,下線は重要箇所に対して当審が付した。以下,同様。)。「 II. Context-Aware Resource Control System This system is composed of 3 modules (Figure 1): 1. A Context Recognition Module that recognizes user context using sensing data. 2. A QoS Manager that determines appropriate resource management on the basis of a Resource Control Table to be described later. 3. A Resource Control Module that actually controls resources in response to the above determination. A. Context Recognition Module The Context Recognition Module uses sensing data to recognize user contexts. These contexts include the timing, location, manner, and content of user actions, and in some cases, user interests and intents may also be considered relevant [8, 9,10]. There have been many studies about context recognition. While timing and location are fairly easy to recognize, manner and content recognition continue to pose difficulties, and one approach to this has been the use of sensors [9, 10, 11]. 」(第221ページ左欄第8-25行) (当審訳:II.コンテキストアウェア・リソース制御システムこのシステムは3つのモジュールで構成される(図1)。 1.センシングデータを用いてユーザコンテキストを認識するコンテクスト認識モジュール。 2.後述するリソース管理テーブルに基づいて,適切なリソース管理を決定するQｏSマネージャ。 3.上記決定に応じてリソースを実際に制御するリソース制御モジュール。 A.コンテキスト認識モジュールコンテキスト認識モジュールは,センシングデータを使用してユーザのコンテキストを認識する。これらのコンテキストには,ユーザの行動のタイミング,位置,方法,および内容が含まれ,場合によっては,ユーザの関心や意図もまた適切とみなされてもよい[8,9,10]。コンテキスト認識に関する多くの研究が行われてきた。タイミングと場所はかなり分かりやすいが,方法やコンテンツの認識は困難を続けており,これに対する1つのアプローチはセンサの使用である[9,10,11]。) 「B. QoS Manager The QoS Manager determines how to control resources on the basis of a matrix table, called a Resource Control Table, in which the control strategy is recorded. Controlled resources can be classified into two types. The first is a binary-type resource, which is turned on or off on the basis of whether or not the application has been designed to use the resource in the current context. The second controlled resource is an allocation-type resource, which is partially or fully allocated to applications on the basis of a scalar value, called an Application Weight, and a resource-to-usability graph, called a Quality of Experience (QoE) Graph. 1) Resource Control Table The Resource Control Table is a matrix which represents the expected behavior of applications in given contexts. Values in the Resource Control Table are based on careful estimates of device usage and user expectations for the device. We assume for the purposes of this study that the table is static and constructed before runtime, and that a device developer determines these values. We will extend the table so that end users can manually or automatically customize it to better meet expectations. The control strategy for binary-type resources, which include GPS, cameras, etc., is based on whether or not an application are expected to use a given resource in a given context. The QoS Manager will determine that a resource is to be turned off if it is not expected to be used in a context, and turned on if it is. 」(第221ページ左欄第41行-同ページ右欄第22行) (当審訳:B.QｏSマネージャ QｏSマネージャは,制御ストラテジーが記録されたリソース管理テーブルと呼ばれるマトリックステーブルに基づいてリソースを制御する方法を決定する。制御されるリソースは,2つのタイプに分類することができる。1つはバイナリタイプのリソースで,アプリケーションが現在のコンテキストでリソースを使用するように設計されているかどうかに基づいてオンまたはオフになる。第2の制御リソースは,アプリケーションの重みと呼ばれるスカラー値とQｏE(Qｕaliｔｙｏf Eｘｐeｒience)グラフと呼ばれるリソース使用率グラフに基づいてアプリケーションに部分的にまたは完全に割り当てられる割り当てタイプのリソースである。 1)リソース管理テーブルリソース管理テーブルは,特定のコンテキストでアプリケーションの予想される動作を表すマトリックスである。リソース管理テーブルの値は,デバイスの使用状況とユーザーの期待値を慎重に見積もったものである。本研究の目的上,テーブルは静的で実行前に構成され,デバイス開発者がこれらの値を決定するものと仮定している。より良い期待に応えるため,エンド・ユーザが手動又は自動でカスタマイズできるように,テーブルを拡張する。 GPS,カメラなどを含むバイナリタイプのリソースの制御ストラテジーは,アプリケーションが特定のコンテキストで特定のリソースを使用すると予想されるかどうかに基づいている。QｏSマネージャは,リソースがコンテキストで使用されることが予想されない場合はオフにし,予想される場合はオンにすることを決定する。 ) 「B. Application In this scenario, the user has 4 applications available. The first is Video application for watching news digests. The second is Face Recognition application which creates a record of the faces of all the people that the user encounters outdoors. The third is Location Information, which offers information regarding current location. The fourth is Augmented Reality (AR), which offers virtual reality superimposed on the monitor. Video and Face Recognition were specially created for this study. Existing applications on the Web were used for Location Information and AR and are examples of downloaded applications. 」(第223ページ左欄第33行-同ページ右欄第5行) (当審訳:B.アプリケーションこのシナリオでは,ユーザーは4つのアプリケーションを使用できる。1つ目は,ニュースダイジェストを見るためのビデオアプリケーションである。2つ目は,ユーザが屋外で遭遇するすべての人々の顔の記録を作成する顔認識アプリケーションである。3つ目は,現在地に関する情報を提供する位置情報である。4つ目は,モニター上に仮想現実を重ね合わせた拡張現実(AR)である。この研究のためにビデオと顔認識が特別に作成された。ウェブ上の既存のアプリケーションは,位置情報およびARに使用され,ダウンロードされたアプリケーションの例である。) 「 IV. EXPERIMENTS We have experimentally evaluated power-saving performance for the previously described scenario. Since it was our purpose to estimate power consumption in a mobile device having a multi-core processor, our experiments were conducted on a test board equipped with a multi-core processor. First, the Context Recognition Module determined user contexts: Indoor/Outdoor and Walking/ Stopping. Second, the QoS Manager determined how to control the GPS, camera, and processor. Finally, the Resource Control Module actually controlled these resources in response to the determination. 」(第224ページ左欄第1-11行) (当審訳:IV.実験前述のシナリオでは,省電力性能を実験的に評価した。マルチコアプロセッサを搭載したモバイル機器の消費電力を見積もることが目的であったため,マルチコアプロセッサ搭載のテストボードで実験を行った。最初に,コンテキスト認識モジュールは,屋内/屋外および歩行/停止というユーザコンテキストを決定した。次に,QｏSマネージャは,GPS,カメラ,プロセッサの制御方法を決定した。最後に,リソース制御モジュールは,実際にこの決定に応じてこれらのリソースを制御した。 ) 「C. Context Recognition by Context Recognition module Context Recognition Module recognizes user contexts Indoor/Outdoor and Walking/Stopped. User situations “At home”, “On subway” and “At office” are Indoor, while “To station” and “To office” are Outdoor. Each situation can be either Walking or Stopped. Indoor/Outdoor is recognized on the basis whether or not GPS signals can be received. We determined that the Context Recognition Module judges that the user is outdoors if GPS signals can be received from at least 1 GPS satellite. Preliminary experiments showed signals can be received in 7 seconds after the GPS module is turned on if signals are available. Walking/Stopped is recognized by using acceleration sensor data. Measured values for acceleration are shown in Figure 6. When the user is stopped, acceleration is always the value of gravitational acceleration 1.0G (=9.8m/s2). When walking, the value of acceleration swings around 1.0G. We determined that the Context Recognition Module judges that the user is walking if the value exceeds 1.2G three times every three seconds. This criterion was selected to distinguish the difference between walking and riding the subway. 」(第224ページ左欄第41行-同ページ右欄第17行) (当審訳:C.コンテキスト認識モジュールによるコンテキスト認識コンテキスト認識モジュールは,屋内/屋外および歩行/停止のユーザコンテキストを認識する。ユーザーの状況「自宅」,「地下鉄」および「オフィス」は屋内,「駅へ」および「オフィスへ」は屋外である。各状況は,歩行または停止のいずれかになる。屋内/屋外は,GPS信号を受信できるかどうかに基づいて認識される。少なくとも1つのGPS衛星からGPS信号を受信できれば,屋外であるとコンテキスト認識モジュールが判断すると決定した。予備実験では,信号が利用可能な場合,GPSモジュールがオンになってから7秒後に信号を受信できることが示された。歩行/停止は,加速度センサデータを使用して認識される。加速度の測定値は図6に示される。ユーザーが停止している場合,加速度は常に重力加速度1.0G(=9.8m/ｓ2)の値になる。歩行しているとき,加速度の値は1.0G近辺で振れる。コンテキスト認識モジュールは,3秒毎に値が1.2Gを3回超過する場合,ユーザーが歩行していると判断すると決定した。この基準は,歩行と地下鉄のの違いを区別するために選択された。) 上記記載及び図面並びにこの分野における技術常識を考慮すると,引用文献1には次の発明(以下,「引用発明1」という。)が記載されていると認められる。「センシングデータを用いてユーザコンテキストを認識するコンテクスト認識モジュール,リソース管理テーブルに基づいて適切なリソース管理を決定するQｏSマネージャ,上記決定に応じてリソースを実際に制御するリソース制御モジュール,の3つのモジュールで構成され(第221ページ左欄第8-25行), コンテキスト認識モジュールは,センシングデータを使用して屋内/屋外および歩行/停止のユーザコンテキストを認識し,屋内/屋外は,GPS信号を受信できるかどうかに基づいて認識され,歩行/停止は,加速度センサデータを使用して認識され(第221ページ左欄第8-25行,第224ページ左欄第41行-同ページ右欄第17行), QｏSマネージャは,制御ストラテジーが記録されたリソース管理テーブルと呼ばれるマトリックステーブルに基づいてリソースを制御する方法を決定し,GPS,カメラなどを含むバイナリタイプのリソースの制御ストラテジーは,アプリケーションが特定のコンテキストで当該リソースが使用されることが予想されない場合はオフにし,予想される場合はオンにすることを決定するものであり(第221ページ左欄第41行-同ページ右欄第22行), モニター上に仮想現実を重ね合わせた拡張現実(AR)を含むアプリケーションを使用できる(第223ページ左欄第33行-同ページ右欄第5行), システムにおいて(第221ページ左欄第8-25行), 最初に,コンテキスト認識モジュールが,屋内/屋外および歩行/停止というユーザコンテキストを決定し,次に,QｏSマネージャが,GPS,カメラ,プロセッサの制御方法を決定し,最後に,リソース制御モジュールが,実際にこの決定に応じてこれらのリソースを制御する(第224ページ左欄第1-11行), システムの制御方法。」 2.引用文献2について原査定の拒絶の理由に引用された引用文献2には,図面とともに次の事項が記載されている。「【0033】まず通信端末100および通信端末100aについて説明する。図2は本実施形態における通信端末100の機能ブロック図である。この通信端末100は,主として,端末の位置情報を取得する位置情報取得部101と,画面を表示する表示部102と,ユーザの入力を受け付ける入力部103と,端末が向いている方位を検出する方位センサ104と,通信網150と接続して通信を行う通信部105と,実空間の映像を取得するカメラ部106と,所定のプログラムおよびデータを記憶する記憶部107と,各部の動作を制御するとともに所定の情報処理を実現する制御部108とから構成されている。なお,他ユーザ端末となる通信端末100aは,通信端末100とほぼ同様の構成をとることが好ましいが,少なくとも,定期的に位置情報を取得して,その位置情報を拡張現実感サーバ300に送信する構成があればよい。【0034】位置情報取得部101は,例えば,複数のGPS(Glｏbal Pｏｓiｔiｏning Sｙｓｔem)衛星からの電波を受信して,それらの強度から現在の位置情報を取得するGPSモジュールを用いることができる。また,GPS方式に加えて通信部105を介して通信網150と通信することにより端末の近くに存在する衛星の情報をアシストデータとして取得し,位置測位を行うAGPS(Aｓｓiｓｔed Glｏbal Pｏｓiｔiｏning Sｙｓｔem)方式に対応したモジュールを利用すれば,位置情報をより高速かつ正確に取得することができるので好適である。ただし,位置情報取得システムはGPSまたはAGPSを利用するものに限られるものではなく,GPSに依存することなく位置情報を取得する構成とすることも可能である。例えば,WiFiやBlｕeｔｏｏｔh等の無線通信基地局を空間内に複数配設し,それらからの電波強度により位置情報を取得する方式を利用してもよいし,このような方式をGPSないしはAGPSに併用する方式を利用することも可能である。【0035】表示部102は,液晶表示装置または有機液晶表示装置であって,通信端末100の動作状態,通信端末100を操作するためのユーザインターフェイス等を制御部108の制御下で表示するものである。本実施形態にかかる拡張現実感システム1においては,後述する動作に従って,カメラ部106により取得した実空間の映像に拡張現実感サーバ300から取得した拡張現実感情報に基づいたオブジェクトを重畳して表示することにより拡張現実感をユーザに提供する。」「【0041】制御部108は,不図示のCPU上で記憶部107に記憶されたプログラムを実行することにより仮想的に構成される機能ブロックであって,通信端末100の位置情報取得部101,表示部102,入力部103,方位センサ104,通信部105,カメラ部106および記憶部107といった各機能ブロックとの間でデータおよび制御信号をやり取りすることにより,通信端末100の各種機能を実現するものである。ここで,制御部108は,所定のプログラムを実行することにより本実施形態にかかる拡張現実感システム1のクライアント制御部として機能し,位置情報取得部101の取得した位置情報を通信部105から後述する拡張現実感サーバへ送信して現在位置周辺における拡張現実感情報をリクエストするとともに,拡張現実感サーバから取得した拡張現実感情報をカメラ部106の取得した実空間の映像に重畳して表示部に表示する処理を行うものである。以下,これらの機能について詳細に説明する。」「【0063】以下,以上のように構成された拡張現実感システム1の動作についてフローチャートを参照しながら説明する。図6は,本実施形態にかかる拡張現実感システム1における通信端末100側の動作を示したフローチャートである。【0064】この動作では,ユーザが通信端末100の入力部103を操作して拡張現実感プログラムを起動することにより開始され,まずカメラ部106が起動されて,方位センサ104が起動されて,その検出値より通信端末100が向いている方向,ひいてはカメラ部106の向いている方向が認識可能な状態となり,ライブビュー動作が開始される。ライブビュー動作は,常法にしたがって,起動されたカメラ部106の光学系の取得した被写体像から所定露光時間で受像素子によりデータをなし,当該データを表示部102に表示する処理を所定時間間隔で繰り返すことにより行われる。(ST101)。【0065】続いて位置情報取得部101が起動されて通信端末100の現在位置にかかる位置情報が取得される(ST102)。ここで,必要に応じて,表示部102に要求する拡張現実感情報の種別を選択するためのメニュー画面が表示され,ユーザの入力により拡張現実感サーバ300に要求する情報の種別が選択されてもよい。要求する拡張現実感情報の種別としては,他ユーザ情報,地図情報,位置情報コンテンツ,経路情報などを挙げることができる。」「【0076】図7において,タイマT2が規定値n2より大きいと判断されると,通信端末100の位置情報の取得が位置情報取得部101により行われ(ST119),取得された位置情報は拡張現実感サーバ300に送信される(ST120)。拡張現実感サーバ300では,送信された位置情報に基づいて拡張現実感情報を再構成する。通信端末100では,そのリプライが通信部105により受信され(ST121),そのリプライの中に拡張現実感情報が含まれているか否かが判断される(ST122)。【0077】ここで,制御部108により含まれていると判断されると(ST122:YES),拡張現実感情報リストが更新される(ST123)。そして,カメラ部106における視界に入る拡張現実感情報の表示位置は制御部108により算出される(ST124)。表示部102において表示中の拡張現実感情報がクリアされ(ST125),算出された表示位置に拡張現実感情報によるオブジェクトが再描画される(ST126)。そして,タイマT2は,0にリセットされ,カウントが再開される(ST127)。」「【0079】つぎに,図7および図8における各更新処理における変形例について説明する。図9は,その変形例の処理を示すフローチャートである。図9においては,ST108からST116までは図7と同じ処理であり,タイマT1が規定値n1より大きい場合には,他ユーザ情報の更新処理のためのリクエスト処理を行い,新たな他ユーザ情報を取得し,他ユーザ情報によるオブジェクトを再描画する(ST108?ST116)。そして,制御部108により,視界に入っている他ユーザ端末が決定され,その他ユーザ端末は拡張現実感サーバ300に通知される(ST181)。そして,タイマT1は0にリセットされ,再度カウントが開始される(ST117)。また,ST118において,タイマT2が規定値n2より大きい場合には,図8と同様に,自装置の位置情報の更新処理が行われる(ST130)。【0080】このST130における詳細は,図10に示すとおりである。ここでは,ST119からST126までの処理は,図8と同じである。なお,この変形例においては,ST121においては,拡張現実感情報のリストを含んだもの,および他ユーザの視界に入っていることを含んだものの2回のリプライを受信する場合があり得る。【0081】 ST122において,拡張現実感情報がリプライに含まれていた場合(ST122:Nｏ),または,再描画(ST126)後には,通信端末100が他ユーザ端末の視界に入っているかが,制御部108により判断される(ST182)。そして,視界に入っていると判断されると,規定値n2は初期値により小さい値である短縮値に設定される。そして,通信端末100は,その規定値n2に基づいてタイマT2に基づいた処理を実行する。また,ST182において,他ユーザ端末の視界に入っていないと判断されると(ST182:Nｏ),規定値n2の値は標準値,すなわち初期値に戻す,または初期値のままとする(ST184)。【0082】このように,通信端末100が他ユーザ端末により見られているか否か,すなわち,カメラによる視界に入っているか否かに基づいて,自己の位置情報更新の周期を変えることができる。これにより,他ユーザ端末により見られている場合にはその位置情報更新の周期を小さくし,頻繁に更新処理を行うようにすることで,他ユーザ端末においては,通信端末100の位置をより正確に把握することができる。」上記記載及び図面並びにこの分野における技術常識を考慮すると,引用文献2には次の発明(以下,「引用発明2」という。)が記載されていると認められる。「位置情報を取得する位置情報取得部101と,画面を表示する表示部102と,ユーザの入力を受け付ける入力部103と,端末が向いている方位を検出する方位センサ104と,通信網150と接続して通信を行う通信部105と,実空間の映像を取得するカメラ部106と,所定のプログラムおよびデータを記憶する記憶部107と,各部の動作を制御するとともに所定の情報処理を実現する制御部108とから構成され(【0033】), 制御部108は,所定のプログラムを実行することによりクライアント制御部として機能し,位置情報取得部101の取得した位置情報を通信部105から後述する拡張現実感サーバへ送信して現在位置周辺における拡張現実感情報をリクエストするとともに,拡張現実感サーバから取得した拡張現実感情報をカメラ部106の取得した実空間の映像に重畳して表示部に表示する処理を行い(【0041】), 位置情報取得部101は,複数のGPS(Glｏbal Pｏｓiｔiｏning Sｙｓｔem)衛星からの電波を受信して,それらの強度から現在の位置情報を取得するGPSモジュールを用いることができ(【0034】), カメラ部106により取得した実空間の映像に拡張現実感サーバ300から取得した拡張現実感情報に基づいたオブジェクトを重畳して表示することにより拡張現実感をユーザに提供する(【0035】), 通信端末100の動作方法であって(【0063】), まずカメラ部106が起動されて,方位センサ104が起動されて,その検出値より通信端末100が向いている方向,ひいてはカメラ部106の向いている方向が認識可能な状態となり,ライブビュー動作が開始され(ST101)(【0064】), 続いて位置情報取得部101が起動されて通信端末100の現在位置にかかる位置情報が取得され(ST102)(【0065】), タイマT2が規定値n2より大きいと判断されると,通信端末100の位置情報の取得が位置情報取得部101により行われ(ST119),取得された位置情報は拡張現実感サーバ300に送信され(ST120),そのリプライが通信部105により受信され(ST121), そのリプライの中に送信された位置情報に基づいて再構成された拡張現実感情報が含まれているか否かが判断され(ST122)(【0076】), 含まれていると判断されると(ST122:YES),拡張現実実感情報リストが更新され(ST123),カメラ部106における視界に入る拡張現実感情報の表示位置は制御部108により算出され(ST124),算出された表示位置に拡張現実感情報によるオブジェクトが再描画され(ST126)(【0077】), さらに,他ユーザの視界に入っていることを含んだリプライを受信する場合があり得て(【0080】), 拡張現実感情報がリプライに含まれていた場合(ST122:Nｏ),または,再描画(ST126)後に,通信端末100が他ユーザ端末の視界に入っているかが,制御部108により判断され(ST182),視界に入っていると判断されると,規定値n2は初期値により小さい値である短縮値に設定され,通信端末100は,その規定値n2に基づいてタイマT2に基づいた処理を実行し,また,ST182において,他ユーザ端末の視界に入っていないと判断されると(ST182:Nｏ),規定値n2の値は標準値,すなわち初期値に戻す,または初期値のままとし(ST184)(【0081】), 通信端末100が他ユーザ端末により見られているか否か,すなわち,カメラによる視界に入っているか否かに基づいて,自己の位置情報更新の周期を変える(【0082】), 通信端末100の動作方法。」 3.引用文献3についてまた,原査定の拒絶の理由に引用された上記引用文献3の段落【0028】,【0044】及び【図2】の記載からみて,当該引用文献3には,目標地の緯度・経度情報と,GPSアンテナ14及びGPS部15によって測位した現在地の緯度・経度情報より現在地から目標地までの距離を算出し,この算出した現在地から目標地までの残り距離を基に次回に測位を行う時に実施する測位方法の選択を行うことにより(【0028】,【図2】),位置測位の際に,消費電力が大きくかつ測位時間のかかるGPSを使用して常時測位するのではなく,目標地からの距離に応じて,現在地の目標地からの距離に見合った測位方法を自動的に切替えるため,消費電力の削減及び測位時間の短縮を図ることができる(【0044】)という技術的事項が記載されていると認められる。第6 対比・判断 1.本願発明1について (1)引用発明1との対比・判断ア対比本願発明1と引用発明1とを対比すると,次のことがいえる。 (ア)本願明細書の「本発明の各実施例において,拡張現実ユーザコンテキストは1セットの動的情報で,当該動的情報は,拡張現実ユーザの現在状態及びその付近環境の記述に用いられる。」(段落【0032】)との記載によれば,本願発明1における「拡張現実ユーザコンテキスト」とは,拡張現実ユーザの現在状態及びその付近環境を記述する1セットの動的情報であると解される。したがって,本願発明1における「拡張現実ユーザコンテキストへのアクセスに関連する情報」とは,拡張現実ユーザの現在状態及びその付近環境を記述する1セットの動的情報である拡張現実ユーザコンテキストへのアクセスにより取得される情報を含むものといえる。一方,引用発明1では,「コンテキスト認識モジュール」が,「センシングデータを使用して屋内/屋外および歩行/停止のユーザコンテキストを認識し,屋内/屋外は,GPS信号を受信できるかどうかに基づいて認識され,歩行/停止は,加速度センサデータを使用して認識」しており,この認識に先立って,GPS信号を受信できるかどうかの情報及び加速度センサデータを収集していることは明らかである。そして,これらGPS信号を受信できるかどうかの情報及び加速度センサデータは,ユーザの現在状態及びその付近環境を示す動的情報であるといえる。さらに,引用発明1は,拡張現実(AR)を含むアプリケーションを使用できるものである。そうしてみれば,引用発明1の「GPS信号を受信できるかどうかの情報及び加速度センサデータ」は,本願発明1の「拡張現実ユーザコンテキストへのアクセスに関連する情報」に含まれる。したがって,引用発明1と本願発明1とは,「拡張現実ユーザコンテキストへのアクセスに関連する情報を収集」するという点で一致している。 (イ)引用発明1では,「コンテキスト認識モジュールは,センシングデータを使用して屋内/屋外および歩行/停止のユーザコンテキストを認識し,屋内/屋外は,GPS信号を受信できるかどうかに基づいて認識され,歩行/停止は,加速度センサデータを使用して認識され,次に,QｏSマネージャが,「GPS,カメラ」「の制御方法を決定し」ている。この決定は,「アプリケーションが特定のコンテキストで」GPS,カメラ「が使用されることが予想されない場合はオフにし,予想される場合はオンにすることを決定するもの」である。すなわち,引用発明1は,QｏSマネージャが,コンテキスト認識モジュールが収集したGPS信号を受信できるかどうかの情報及び加速度センサデータに基づいて認識した屋内/屋外および歩行/停止のユーザコンテキストでの,GPS,カメラをオン又はオフに決定するものといえる。そして,引用発明1の「GPS,カメラをオン又はオフに決定」することは,本願発明1の「前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」することに含まれるから,引用発明1と本願発明1とは,「前記収集した情報に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するという点で一致している。 (ウ)本願発明1においては,「拡張現実ユーザコンテキストへのアクセスを管理すること」に「拡張現実端末能力へのアクセスを最適化すること」が含まれる。そして,本願明細書の「拡張現実端末能力は,拡張現実端末測位能力を含むことが好ましい。」(段落【0055】),「拡張現実端末能力へのアクセスを最適化することは,拡張現実端末の測位の一時的な停止又は再起動を含むことが好ましい。」(段落【0057】)との記載によれば,本願発明1における,「拡張現実端末能力へのアクセスを最適化すること」は,拡張現実端末測位能力の測位の一時的な停止又は再起動を含むと解される。一方,引用発明1では,「QｏSマネージャが,GPS,カメラ」「の制御方法を決定」した後に,「リソース制御モジュールが,実際にこの決定に応じてこれらのリソースを制御」している。この決定は,上記(イ)で述べたとおり,GPS,カメラをオン又はオフとするものである。そうすると,引用発明1の「GPS」は,本願発明1の「拡張現実端末能力」に含まれ,また,引用発明1において「GPSをオン又はオフとする」ことは,本願発明1において,「拡張現実端末能力へのアクセスを最適化すること」に含まれる。また,上記(イ)で述べたとおり,引用発明1において,「GPS,カメラをオン又はオフに決定」することは,本願発明1の「前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」することに含まれるから,引用発明1が「この決定に応じてこれらのリソースを制御」することは,本願発明1が「前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて」,「拡張現実端末能力へのアクセス」を行うことに相当する。したがって,引用発明1と本願発明1とは,「前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記拡張現実ユーザコンテキストへのアクセスを管理することを含み, 拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化することを含む」という点で一致する。 (エ)上記(ア)で述べたとおり,本願明細書の「本発明の各実施例において,拡張現実ユーザコンテキストは1セットの動的情報で,当該動的情報は,拡張現実ユーザの現在状態及びその付近環境の記述に用いられる。」(段落【0032】)との記載によれば,本願発明1における「拡張現実ユーザコンテキスト」とは,拡張現実ユーザの現在状態及びその付近環境を記述する1セットの動的情報であると解される一方,引用発明1は,これに含まれる「GPS信号を受信できるかどうかの情報及び加速度センサデータ」を取得しており,且つ,拡張現実(AR)を含むアプリケーションを使用できるから,本願発明1と引用発明1とは,「拡張現実ユーザコンテキストのアクセス方法」という点で一致している。したがって,本願発明1と引用発明1との間には,次の一致点,相違点があるといえる。 (一致点) 「拡張現実ユーザコンテキストへのアクセスに関連する情報を収集し, 前記収集した情報に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し, 前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記拡張現実ユーザコンテキストへのアクセスを管理することを含み, 拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化することを含む拡張現実ユーザコンテキストへのアクセス方法。」 (相違点) (相違点1)本願発明1では,「拡張現実ユーザコンテキストへのアクセスに関連する情報を収集し,前記収集した情報に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記拡張現実ユーザコンテキストへのアクセスを管理する」といういずれの手順もその実行主体が「モバイル拡張現実クライアント」であるのに対して,引用発明1では,「コンテキスト認識モジュール」が屋内/屋外および歩行/停止というユーザコンテキストを決定し,「QｏSマネージャ」がGPS,カメラ,プロセッサの制御方法を決定し,「リソース制御モジュール」が実際にこの決定に応じてこれらのリソースを制御しており,各手順の実行主体がそれぞれ異なる点。 (相違点2)一致点の「前記収集した情報に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」に関して,本願発明1は,「前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するのに対して,引用発明1は,「前記収集した情報に基づいて」いるものの,「現在の拡張現実サービス環境」にも基づいて,「前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」しているものではない点。イ判断事案に鑑み,まず上記相違点2について検討する。相違点2に係る本願発明1の「前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するという構成は,上記引用文献1,3には記載されておらず,本願出願前において周知技術であるともいえない。したがって,本願発明1は,相違点1を検討するまでもなく,当業者であっても引用発明1及び引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 (2)引用発明2との対比・判断ア対比本願発明1と引用発明2とを対比すると,次のことがいえる。 (ア)引用発明2では,制御部108が「所定のプログラムを実行することによりクライアント制御部として機能し」,この制御部108を備える「通信端末100」は,「カメラ部106により取得した実空間の映像に拡張現実感サーバ300から取得した拡張現実感情報に基づいたオブジェクトを重畳して表示する」から,当該「通信端末100」は,本願発明1における「モバイル拡張現実クライアント」に相当する。 (イ)上記(1)のアの(ア)で示したとおり,本願発明1における「拡張現実ユーザコンテキスト」とは,拡張現実ユーザの現在状態及びその付近環境を記述する1セットの動的情報であると解され,本願発明1における「拡張現実ユーザコンテキストへのアクセスに関連する情報」とは,拡張現実ユーザの現在状態及びその付近環境を記述する1セットの動的情報である拡張現実ユーザコンテキストへのアクセスにより取得される情報を含むものといえる。一方,引用発明2の「通信端末100」は,「端末が向いている方位を検出する方位センサ104」と,「現在の位置情報を取得するGPSモジュールを用いることができ」る「位置情報取得部101」とを備えている。そして,これらの「端末が向いている方向」の「情報」や「現在の位置情報」は,本願発明1の「拡張現実ユーザコンテキストへのアクセスに関連する情報」に含まれるものである。そうすると,本願発明1と引用発明2とは,「モバイル拡張現実クライアントが,拡張現実ユーザコンテキストへのアクセスに関連する情報を収集し,」という点で一致している。 (ウ)引用発明2は,「タイマT2が規定値n2より大きいと判断されると,通信端末100の位置情報の取得が位置情報取得部101により行われ」,さらに,「他ユーザの視界に入っていることを含んだリプライを受信する場合があり得て」,「他ユーザ端末の視界に入っているかが,制御部108により判断され」,「視界に入っていると判断されると,規定値n2は初期値より小さい値である短縮値に設定され」,「他ユーザ端末の視界に入っていないと判断されると」,「規定値n2の値は標準値,すなわち初期値に戻す,または初期値のままと」することにより,「自己の位置情報更新の周期を変える」ものである。そして,引用発明2における,「通信端末100の位置情報」は,本願発明2の「拡張現実ユーザコンテキスト」に含まれるものであり,引用発明2の「通信端末100」が,「自身の位置情報更新の周期」を決定する「規定値n2」を「標準値」又は「短縮値」に「設定」することは,本願発明2の「拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」することに含まれる。したがって,本願発明1と引用発明2とは,「前記モバイル拡張現実クライアントが,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するという点で一致している。 (エ)本願発明1においては,「拡張現実ユーザコンテキストへのアクセスを管理すること」に「拡張現実端末能力へのアクセスを最適化すること」が含まる。そして,本願明細書の「拡張現実端末能力は,拡張現実端末測位能力を含むことが好ましい。」(段落【0055】),「拡張現実端末能力へのアクセスを最適化することは,拡張現実端末の測位精度の変更,及び/又は拡張現実端末の測位方式の変更を含むことが好ましい。」(段落【0056】)との記載によれば,本願発明1における,「拡張現実端末能力へのアクセスを最適化すること」は,拡張現実端末測位能力の測位精度の変更を含む解される。一方,引用発明2では,「規定値n2」を「標準値」又は「短縮値」に「設定」し,「タイマT2が規定値n2より大きいと判断されると,通信端末100の位置情報が位置情報取得部101により行われ」るから,この「規程値n2」を「標準値」又は「短縮値」の一方から他方に「設定」することは,「時間的な測位精度の変更」といいうるものである。そうすると,引用発明2において,「規定値n2」を「標準値」又は「短縮値」に「設定」し,「タイマT2が規定値n2より大きいと判断されると,通信端末100自身の位置情報が位置情報取得部101により行われ」ることは,本願発明2の「拡張現実端末能力へのアクセスを最適化すること」に含まれる。また,上記(ウ)で述べたとおり,引用発明2の「通信端末100」が,「自身の位置情報更新の周期」を決定する「規定値n2」を「標準値」又は「短縮値」に「設定」することは,本願発明2の「拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」することに含まれるから,引用発明2において,この「設定」に基づいて「通信端末100自身の位置情報が位置情報取得部101により行われ」ることは,本願発明1において,「前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて」,「拡張現実端末能力へのアクセス」を行うことに相当する。したがって,本願発明2と引用発明2とは,「前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記拡張現実ユーザコンテキストへのアクセスを管理することを含み, 拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化することを含む」という点で一致する。したがって,本願発明2と引用発明1との間には,次の一致点,相違点があるといえる。 (一致点) 「モバイル拡張現実クライアントが,拡張現実ユーザコンテキストへのアクセスに関連する情報を収集し, 前記モバイル拡張現実クライアントが,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し, 前記確定した拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態に基づいて,前記拡張現実ユーザコンテキストへのアクセスを管理することを含み, 拡張現実ユーザコンテキストへのアクセスを管理することが,拡張現実端末能力へのアクセスを最適化することを含む」という点で一致する。 (相違点) 一致点の「前記モバイル拡張現実クライアントが,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」に関して,本願発明1は,「前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するのに対して,引用発明1は,受信したリプライに他ユーザの視界に入っていることが含まれているか否かに応じて,自身の位置情報の更新処理を行うことを判断するためにタイマT2と比較される規定値n2を短縮値又は標準値(初期値)に設定しており,「前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するとはいえない点。イ判断上記相違点について検討すると,相違点に係る本願発明1の「前記収集した情報及び現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定」するという構成は,上記引用文献2-3には記載されておらず,本願出願前において周知技術であるともいえない。したがって,本願発明1は,当業者であっても引用発明2及び引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 2.本願発明2-21について本願発明2-21も,本願発明1の「現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」と同一の構成を有するものであるから,本願発明1と同じ理由により,当業者であっても引用発明1及び引用文献3に記載された技術的事項又は引用発明2及び引用発明3に記載された技術的事項に基づいて,当業者が容易に発明をすることができたものとはいえない。 3.本願発明22について本願発明22は,実質的に本願発明1における各手順の実行主体を「モバイル拡張現実サーバ」に置き換えた発明であり,本願発明1の「現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」と同一の構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても引用発明1及び引用文献3に記載された技術的事項又は引用発明2及び引用発明3に記載された技術的事項に基づいて,当業者が容易に発明をすることができたものとはいえない。 4.本願発明23-42について本願発明23-42も,本願発明22が備える,「現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」と同一の構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても引用発明1及び引用文献3に記載された技術的事項又は引用発明2及び引用発明3に記載された技術的事項に基づいて,当業者が容易に発明をすることができたものとはいえない。第7 原査定について 1.理由1(特許法第29条第1項第3号)について本願発明1-6,9,13,14,17-21は,「現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」という事項を有しており,拒絶査定において引用された引用文献1又は2に記載された発明ではない。したがって,原査定の理由1を維持することはできない。 2.理由2(特許法第29条第2項)について本願発明1-42は,「現在の拡張現実サービス環境に基づいて,前記拡張現実ユーザコンテキストへのアクセスの要求及び/又は状態を確定し,」という事項を有しており,当業者であっても,拒絶査定において引用された引用文献1-3に基づいて,容易に発明できたものとはいえない。したがって,原査定の理由2を維持することはできない。第8 むすび以上のとおり,原査定の理由によっては,本願を拒絶することはできない。また,他に本願を拒絶すべき理由を発見しない。よって,結論のとおり審決する。
審決日	2017-12-12
出願番号	特願2014-527468(P2014-527468)
審決分類	P 1 8・ 121- WY (H04W) P 1 8・ 113- WY (G06F)
最終処分	成立
前審関与審査官	速水雄太、森田充功
特許庁審判長	新川圭二
特許庁審判官	山田正文松田岳士
発明の名称	拡張現実ユーザコンテキストへのアクセス方法
代理人	藤本昇
代理人	中谷寛昭
代理人	日東伸二

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