現在、審決メルマガは配信を一時停止させていただいております。再開まで今暫くお待ち下さい。

  • ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1326732
審判番号 不服2016-6642  
総通号数 209 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-05-26 
種別 拒絶査定不服の審決 
審判請求日 2016-05-06 
確定日 2017-03-28 
事件の表示 特願2013-537617「SMSを用いて遠隔デバイスを制御する方法及びそのための装置」拒絶査定不服審判事件〔平成24年 5月10日国際公開、WO2012/060669、平成25年11月28日国内公表、特表2013-543189〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1 手続の経緯と本願発明
本件出願は,2011年11月7日(パリ条約による優先権主張外国庁受理2010年11月5日,平成2010年11月11日 米国)を国際出願日とする出願であって,平成27年7月30日付け拒絶理由通知に対して同年11月4日に意見書及び手続補正書が提出されたが同年12月25日付けで拒絶査定がなされ,これを不服として平成28年5月6日に審判請求がなされるとともに手続補正書が提出されたものであって,本願の請求項1に係る発明(以下,「本願発明」という。)は,平成28年5月6日に提出された手続補正書の特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「SMS(Short Messaging Service)を用いて遠隔デバイスを制御する方法において,
コマンド,前記コマンドは前記遠隔デバイスによって実行される,を記述するメタデータをダウンロードするためのURLを含むテキストを複数のテキスト部分に分割する段階と,
前記テキスト部分それぞれを独立のユーザデータとする,複数のSMSメッセージを生成する段階と,
前記SMSメッセージを前記遠隔デバイスに送信する段階と,を含み,
前記SMSメッセージそれぞれは,前記遠隔デバイスが前記SMSメッセージから前記テキストを復元するために必要な情報を含む
ことを特徴とする遠隔制御方法。」

2 引用例
A.引用例1
原査定の拒絶の理由に引用された米国特許第6230004号明細書(以下,「引用例1」という。)には,(発明の名称)「Remote procedure calls using short message service(ショートメッセージサービスを用いるリモートプロシージャコール)」(括弧内は当審仮訳。以下同様。)に関し,図面とともに以下の事項が記載されている(下線は当審が付与。以下同様。)。

ア 「The present invention applies the Remote Procedure Call (RPC) technique of conventional distributed computer systems to a wireless telecommunications network. Prior art FIG. 1 illustrates a conventional distributed computer system. In FIG. 1, the main computer 11 accesses a remote server at 13 in order to invoke procedures supported by the server 13 to invoke the desired remote procedure. The main computer 11 sends an RPC command to the server 13 to invoke the desired remote procedure. The server 13 then executes the requested procedure in execution unit 37 and provides an RPC response back to the main computer.
Example FIG. 2 illustrates one example of a procedure on server 13 which might be invoked by main computer 11, namely, a procedure wherein the server 13 provides weather information relative to various geographic locations. The procedure is identified as Weather, and the desired geographic locations are set forth as operands separated by commas within parentheses. The remote server 13 executes the Weather procedure relative to the various geographic locations listed as operands.
(本発明は従来の分散型計算機システムのリモートプロシージャコール(RPC)技術を無線通信ネットワークに適用する。図1の従来例は,従来の分散型計算機システムを示す。図1で,メインコンピュータ11は遠隔サーバ13によってサポートされる手続きを起動させるためにサーバ13にアクセスし,所望の遠隔手続きを起動させる。メインコンピュータ11は所望の遠隔手続きを起動させるためにサーバ13にRPCコマンドを送信する。そしてサーバ13はその要求された手続きを実行ユニット37で実行し,メインコンピュータにRPC応答を供給する。
図2の例は,メインコンピュータ11によって起動されるサーバ13上の手続きの1例,即ち,サーバ13が色々な地理的場所の天気情報を供給する手続きである。その手続きはWeatherと識別され,所望の地理的場所が括弧内でコンマで区切られたオペランドとして表記されている。遠隔サーバ13はオペランドとしてリストされた色々な地理的場所についてWeather手続きを実行する。)」(第1欄第66行?第2欄第18行)

イ 「Example FIG. 3 illustrates one example of how the present invention uses Short Message Service (SMS) to implement remote procedure calls in a wireless network. When the mobile user requests an operation for which the wireless mobile communication unit has inadequate data processing facilities, or for which an external database must be accessed, the I/O control section 31 of the mobile unit determines that a remote procedure call to a remote server is necessary. The I/O control section then outputs an RPC command which can, in a conventional manner, be marshalled so as to have a serialized format such as the format of the prior art RPC command in FIG. 2. This RPC command passes through an SMS-based interface 33 and ultimately arrives at the remote server 35. The desired procedure is executed by the remote server 35, and its RPC response is provided back to the SMS-based interface 33 for ultimate delivery to the I/O control section 31 of the mobile unit.
Thus, to the I/O control section 31 of the mobile unit, the operation appears identical to that seen by the main computer 11 of prior art FIG. 1, namely, the I/O control section outputs an RPC command and thereafter receives the corresponding RPC response.
(図3の例は,本発明が無線ネットワークでリモートプロシージャコールを実行するためにショートメッセージサービス(SMS)を利用するかの一例を示す。モバイルユーザが演算を要求し,それに対して無線携帯通信装置が不十分なデータ処理能力しか有しないか,または,それに対して外部のデータベースがアクセスされる必要があるとき,そのモバイル装置のI/O制御セクション31は遠隔サーバへのリモートプロシージャコールが必要であると決定する。I/O制御セクションはその後,従来のやり方で,図2の従来技術のRPCコマンドのフォーマットのように連続したフォーマットに整列されたRPCコマンドを出力する。このRPCコマンドはSMSベースのインターフェース33を通って最後に遠隔サーバ35に到着する。所望の手続きが遠隔サーバ35によって実行され,そのRPC応答がSMSベースのインターフェース33に返され,最後にモバイル装置のI/O制御セクション31に配送される。
このように,モバイル装置のI/O制御セクション31にとって,動作は,図1の従来例のメインコンピュータ11によって見られるのと全く同じように見える。即ち,I/O制御セクションはRPCコマンドを出力した後対応するRPC応答を受信する。)」(第2欄第19?41行)

ウ 「Exemplary FIG. 4 illustrates one embodiment of the SMS-based interface 33 of FIG. 3. The operation of FIG. 4 will be described with respect to the RPC command format illustrated in FIG. 2 and described above. When an RPC command such as shown in FIG. 2 is output from the I/O control section 31 of FIG. 3 and received at the splitting function 41 of the mobile unit, the splitting function splits the RPC command into as many SMS messages as are required to convey the entire command.
(図4の例は,図3のSMSベースのインターフェース33の1例を示す。図4の動作は図2に例示されて記載されたRPCコマンドフォーマットに関して記述されている。図2に示されたようなRPCコマンドが図3のI/O制御ユニット31から出力され,モバイル装置の分割機能41で受信され,分割機能がRPCコマンドを,そのコマンド全てを運ぶのに必要とされるSMSメッセージの数と同じ数に分割する。)」(第2欄第42?50行)

エ 「Example FIG. 5 illustrates the output of the splitting function 41. The informational portion of a conventional SMS message is limited to 160 characters and, in this example, 10 of those characters are reserved for an RPC header as shown at 51 and 53. Accordingly, if the RPC command is longer than 150 characters, then more than one SMS message will be required in FIG. 5. The splitting function provides the 10 characters for the RPC header, and allocates the next 150 characters to the first 150 characters of the RPC command of FIG. 2. The remaining characters of the RPC command must be handled in additional SMS messages as shown in FIG. 5. In the example of FIG. 5, two 160-character SMS messages are adequate to accommodate the entire RPC command. The X characters are "don't care" characters.
As shown in FIG. 5, each SMS message provided by the splitting function 41 includes a ten character RPC header. The example header 51 of FIG. 5 is illustrated in more detail in FIG. 6, and the example header 53 of FIG. 5 is illustrated in more detail in FIG. 7. The header 51 includes three characters that identify the SMS message as an RPC command. The fourth character of the header is a comma, and the fifth character is an identification (ID) number which identifies the message in which the header 51 appears as the first (ID=1) message of the RPC command. The sixth character of the header 51 is another comma, and the seventh character identifies the number of SMS messages in this RPC command, in this example, 2.
The header 53 of FIG. 7 is similar to the header 51 of FIG. 6, but the ID=2 (see the fifth character) in this instance because the header 53 is associated with the second message of the RPC command. The header 53 also indicates that there are a total of two SMS messages in this RPC command (seventh character=2). In the examples of FIGS. 5-7, the final three characters of the RPC headers 51 and 53 are shown as "don't care" characters (X). It should be clear, however, that the size and informational content of the RPC headers can vary as required by the particular application.
In the example of FIGS. 5-7, the two SMS messages have ID=1 and ID=2, respectively. However, any desired identification scheme for ordering the SMS messages properly can be used. For example, if the first message has an ID=c, wherein c is a rational number, then the second message could have an ID=s(c), the third message could have an ID =s(s(c)), and so on, where s is a successor function that provides the respective ID numbers for the messages. In the example of FIGS. 5-7, c=1, and s(c)=c+1. As mentioned above, any type of identification scheme can be used to identify and order the SMS messages to insure that the RPC command is received and interpreted properly at the remote server. This will be discussed in more detail below.
The SMS control adding function 43 of the mobile unit in FIG. 4 receives as input the 160-character SMS messages (see FIG. 5) from the splitting function 41, and adds to these 160 informational characters the conventional SMS control characters which insure that the 160-character informational content of each message will traverse the conventional SMS data communication path properly. An example SMS message output from the function 43 is shown in example FIG. 8. The SMS control information is added by the function 43 to each of the SMS messages (FIG. 5) provided from the splitting function 41. Thus, the function 43 outputs a complete SMS message having the format of a conventional SMS message, including both SMS informational content and SMS control content as shown in FIG. 8. Each message output from the splitting function 41 (see FIG. 5) occupies the SMS informational field, and the SMS control adding function 43 adds the SMS control content. FIG. 8 illustrates the SMS format, produced by the function 43, which results when the function 43 receives the message having ID=1 in FIG. 5. Each message received by function 43 is put into conventional SMS format in similar fashion to that shown in FIG. 8. The SMS Send function 45 of the mobile unit in FIG. 4 receives the complete SMS messages from the function 43, and sends the SMS messages out in the conventional manner over a conventional SMS data communication path through the wireless network. The ordinary SMS message input 40 is held inactive by mobile I/O control 31 (FIG. 3) during processing of RPC commands through the SMS Send function, and the RPC command input is held inactive by mobile I/O control 31 (FIG. 3) during processing of an ordinary SMS message through the SMS Send function.
At the remote server, the SMS message is received and analyzed by the SMS Receive and Analyze function 47. This section can detect the presence or absence of the RPC header and thus identify whether the SMS messages constitute a remote procedure call. If no remote procedure call is detected, then the SMS message(s) is routed to the ordinary SMS channel 42. If a remote procedure call is identified, then the receive and analyze section 47 forwards the received SMS messages to the SMS control stripping function 49. The function 49 strips the SMS control portion (see FIG. 8) from the messages, and then forwards the remaining 160 characters to the joining function at 44. The joining function stores all of the messages of the RPC command in a memory, and then strips off the RPC header and sends the 150-character messages of FIG. 5 in the correct order to the remote procedure in the server.
The joining function applies the successor function s(c) to the ID in the RPC header of the first message received, and determines the proper ordering of the messages by subsequent application of s(c) as described above. The joining function can thus organize the 150-character messages into the appropriate order to reconstruct the RPC command that was originally received at the input of the splitting function 41 in the mobile unit. As mentioned above, both the splitting function 41 and the joining function 49 must utilize the same successor function so that the message can be split up and re-joined accurately. One or more successor functions can be stored in both the splitting function and the joining function. If more than one successor function is available, then the splitting function can insert into the RPC header a code which identifies which successor function is to be used in conjunction with the current RPC command. The joining function determines the proper successor function by inspecting the code in the RPC header.
The remote procedure in the server receives the RPC command in exactly the same format (see FIG. 2) as it would receive the RPC command in the conventional distributed computer system of FIG. 1. After the remote server has executed the desired procedure, it provides the RPC response, again in the same format as would be provided in the conventional system of FIG. 1.
(図5の例は,分割機能41の出力を示す。標準のSMSメッセージの情報部分は160文字に制限されており,本例ではそのうちの10文字が,51と53として示されるRPCヘッダのためにに予約されている。したがって,もしもRPCコマンドが150文字よりも長ければ,図5のように1つより多いSMSメッセージが必要とされる。分割機能はRPCヘッダ用の10文字分を提供し,次の150文字分を図2のRPCコマンドの最初の150文字のために提供する。RPCコマンドの残りの文字は図5に示されるように追加のSMSメッセージで扱われる必要がある。図5の例では,RPCコマンドの全てを収容するのに2つの160文字SMSメッセージで十分である。Xの文字は任意("don't care")の文字である。
図5に示されるように,分割機能41によって提供される各SMSメッセージは10文字のRPCヘッダを含む。図5に例示のヘッダ51が図6により詳しく示され,図5に例示のヘッダ53が図7により詳しく示されている。ヘッダ51はSMSメッセージがRPCコマンドであることを識別する3文字を含む。ヘッダの4番目の文字はコンマで,5番目の文字はID番号であってそのヘッダ51が現れるメッセージがRPCコマンドの最初の(ID=1)メッセージであることが識別できる。ヘッダ51の6番目の文字はまたコンマであり,7番目の文字はRPCコマンドのSMSメッセージ数を示し,この例の場合2である。
図7のヘッダ53は図6のヘッダ51と類似するが,この例ではヘッダ53はRPCコマンドの2番目のメッセージに関連するので,ID=2(5番目の文字参照)である。ヘッダ53はまたRPCコマンドにトータルで2つのSMSメッセージがあることを示す(7番目の文字=2)。図5-7の例では,RPCヘッダ51,53の最後の3文字は任意("don't care")の文字(X)である。しかしながら,特定の応用のために必要とされるRPCヘッダのサイズと情報内容が変わることは明らかである。
図5-7の例では,2つのSMSメッセージがそれぞれID=1とID=2である。しかしながら,SMSメッセージを適切に順番付けるために必要とされる任意の順番付けスキームが使用されうる。例えば,最初のメッセージがID=c,ここでcは有理数,であれば,2番目のメッセージはID=s(c),3番目のメッセージはID=s(s(c)),等々,ここでsはメッセージの各IDを供給する後者関数(successor function)である。図5-7の例では,c=1であり,s(c)=c+1である。上述したように,RPCコマンドが遠隔サーバで受信され,正しく解釈されることを確実にするために,SMSメッセージを識別して順番付けるどのようなタイプの順番付けスキームが用いられてもよい。
図4のモバイル装置のSMS制御付加機能43は,分割機能41から160文字のSMSメッセージ(図5参照)を入力として受信し,この160の情報文字に標準のSMS制御文字を加え,各メッセージの160文字の情報内容が標準のSMSデータ通信路を正しく通過することを確実にする。機能43からのSMSメッセージの例が図8に例示される。分割機能41から供給されるSMSメッセージ(図5)の各々に対して機能43によりSMS制御情報が付加される。このようにして,機能43は,図8に示すようにSMSの情報部分とSMS制御部分をともに備えた完全なSMSメッセージを出力する。分割機能41からの各メッセージ出力(図5参照)はSMS情報フィールドを占め,SMS制御付加機能43はSMS制御部分を付加する。図8は,機能43によって作られるSMSフォーマットを示し,機能43が図5のID=1のメッセージを受信した結果である。機能43で受信された各メッセージは,図8に示されたのと同様の標準のSMSメッセージフォーマットに入れられる。図4のモバイル装置のSMS送信機能45は機能43から完全なSMSメッセージを受信し,有線ネットワークを通る標準のSMSデータ通信路上を標準の方法で送信する。SMS送信機能によるRPCコマンドの処理中は,通常のSMSメッセージ入力40はモバイル装置のI/O制御装置(図3)により運用中止とされ,また,SMS送信機能による通常のSMSメッセージの処理中は,RPCコマンド入力はモバイル装置のI/O制御装置(図3)により運用中止とされる。
遠隔サーバにおいて,SMSメッセージが受信されSMS受信解析機能47で解析される。このセクションはRPCヘッダの有無を検出し,これによりSMSメッセージがリモートプロシージャコールであるかどうかを識別する。リモートプロシージャコールが検出されなければ,SMSメッセージは通常のSMSチャネル42へ送付される。リモートプロシージャコールが確認されれば,受信解析機能47は受信したSMSメッセージをSMS制御分離機能49へ転送する。機能49はSMS制御部分(図8参照)をメッセージからはぎ取り,残りの160文字を統合機能44へ転送する。統合機能はそのRPCコマンドのメッセージを全てメモリに蓄え,その後RPCヘッダをはぎ取り,図5の150文字のメッセージをサーバの遠隔手続きに正しい順序で送る。
統合機能は受信した最初のメッセージのRPCヘッダ中のIDに後者関数を適用し,上述した後者関数の連続的な適用によりメッセージの正しい順序を決定する。このようにして統合機能は,モバイル装置の分割機能41の入力で最初に受信されたRPCコマンドを再構成するために,150文字のメッセージを正しい順序に編成することができる。上述したように,分割機能41と統合機能49の双方は,メッセージが正確に分割,統合されるように同じ後者関数を利用しなければならない。1以上の後者関数が分割機能と統合機能に蓄えられる。1以上の後者関数が使用可能な場合,分割機能は現在のRPCコマンドに使用されるでき後者関数を識別するコードをRPCヘッダに挿入しうる。統合機能はRPCヘッダのコードを検査して正しい後者関数を決定する。
サーバの遠隔手続きは,図1の従来の分散型計算機システムにおいてRPCコマンドを受信するのと全く同じフォーマット(図2参照)でRPCコマンドを受信する。遠隔サーバが,要求される処理を実行した後,再び図1の従来のシステムで提供されるのと同じフォーマットでRPC応答を供給する。)」(第2欄第51行?第4欄第39行)

上記引用例1の記載(特に,下線部)及び図面ならびにこの分野における技術常識を考慮すると,上記引用例1には,以下の発明(以下,「引用発明」という。)が開示されていると認める。

「SMSを用いて遠隔サーバに手続きを実行させる方法において,
前記遠隔サーバに前記手続きを実行させるための150文字を超えるRPC(Remote Procedure Call)コマンドを2つの部分に分割し,前記2つの部分それぞれと10文字のRPCヘッダをその情報部分とする2つのSMSメッセージを生成して前記遠隔サーバに送信し,各SMSメッセージのRPCヘッダはそのメッセージが前記RPCコマンドのための何番目のメッセージであるかを示すID番号を備え,前記遠隔サーバは前記ID番号を用いて分割前のRPCコマンドを再構成する,方法。」

B 引用例2
同じく原査定の拒絶の理由に引用された特開2005-181196号公報(以下,「引用例2」という。)には,「車載装置及びデータ作成装置」(発明の名称)に関し,図面とともに以下の事項が記載されている。

オ 「【発明を実施するための最良の形態】
【0009】
以下,本発明の車載装置の好適な実施形態であるエージェント装置,シナリオが記憶されるサーバ,及びデータ作成装置の好適な実施形態であるシナリオエディタについて,図1から図21を参照して詳細に説明する。
【0010】
(1)実施形態の概要
本実施形態のエージェント装置では,所定の容姿からなるエージェント(キャラクタ)の画像(平面的画像,ホログラフィ等の立体的画像等)を車両内に表示する。そして,エージェント装置の機能である,センサ等の検出結果から周囲の状態(人の動きや音声を含む)を認識,判断し,その結果に応じた動作や音声を出力するという機能を,このエージェントの容姿の動きや音声と連動して実行する。例えば,「どのジャンルの食事がすきですか」等の回答(和食,洋食等)を要求する問かけを行い,この問いかけに対するユーザの回答内容を判別(回答音声の認識や,回答選択ボタンの選択から判別)して,次のシーンに応じた処理を実行する。このように,装置からの回答を要求する問いかけと,その回答に応じて,所定の操作の実行を開始するので,ユーザは,あたかも擬似人格を備えたエージェントが車両内に存在しているような体感をするようになる。以下の説明では,このようなエージェント装置の一連の機能の実行を,エージェントの行為や動作として説明する。
本実施形態のエージェント装置では,このエージェントに運転者との各種コミュニケーションや,操作の代行を行わせる。そしてエージェントが自律的に行う様々な行為(各行為)を複数のシナリオ(画面要素推移体)で構成する。
そして,エージェントによる一連の連続した行為の内容を規定した複数のシナリオデータと,各シナリオの展開を自律的に開始(起動)するための自律起動条件(起動条件)とにより規格化された形式で作成される。
【0011】
シナリオデータは,シーン(画面要素)を最小単位として,1又は連続する複数のシーンで構成される。自律的に行う処理内容とエージェントの画像及び音声の少なくとも1つから構成される場面が1シーンである。
シナリオデータは,所定のシーンから次のシーンに移行するための1の移行条件(推移条件)又は複数の移行条件(分岐条件(複数の状態が発生する場合の各状態毎へのシーンの移行するための条件))と,各移行条件に対応して移行先のシーンを特定する移行先データとから,各シーンの展開構成が規定されている。
【0012】
このように構成された各シナリオは,自律起動条件とは分離されてネット接続された1又は複数のサーバや,ホームページ等の所定のアドレスに保存される。
各シナリオの保存先を示す保存先指定情報としては,URL(Uniform Resource Locator)により,インターネット上のリソースが指示される。
なお,シナリオ作成装置は,シナリオデータの保存先URLの指定及び,起動条件の年月日と位置情報による分類を,シナリオとその起動条件の作成が完了し,エージェント装置で実行可能な形式に変換する際に行う。
【0013】
各シナリオを自動的に実行するための自律起動条件は,年月日,時間,位置,道路種別,車両状態,ナビゲーション装置の稼動状態,使用者データによる個別条件の論理積(論理和を含まない個別条件の組)に展開されている。そして,論理積から成る自律起動条件は,所定の個別条件である年月日と位置でソートすることでグループ化(分類)されている。位置については,一定サイズに区分した領域(メッシュ)単位で分類されている。本実施形態では,年,月,日,一次メッシュ,二次メッシュの順に下位となるように分類されている。
すなわち,最初に,年による条件の中から自動で開始する条件(個別条件)が同じ年のものがグループ化され,次に日付(月日)による条件の中から自動で開始する条件が同じ日付(月日)のものがグループ化され,次に位置に関する自動で開始する条件で大きい領域(1次メッシュ)に入るものがまとめてグループ化され,最後に1次メッシュの中でさらに切り分けた小領域(2次メッシュ)に入るものがまとめてグループ化されている。
なお,年,日付,位置の条件を含まないものも,該当条件がないものに分類されている。例えば,年月日の条件がなく位置の条件がある自律起動条件の場合,年条件無しという分類内の,日付条件無しという分類内に,その位置に応じた1次メッシュ,2次メッシュに分類されている。
【0014】
各シナリオデータについての分類された自律起動条件には,シナリオデータの保存先を示すURL(保存先指定情報)と関連付けて設定される。
そして,各シナリオの自律起動条件は,シナリオから分離され,起動条件とシナリオが保存されたURLとが,インターネットやメール,所定の記憶媒体等を介してエージェント装置で取得され,記憶されることになる(起動条件記憶手段)。
【0015】
一方,エージェント装置のユーザ等は,規定された規格に従った独自のシナリオデータを,シナリオ作成装置を使用して作成する。シナリオ作成装置は,シナリオ編集プログラムやデータをパーソナルコンピュータにインストールすることで構成することができる。
作成したシナリオデータは,インターネット等のネットワークを介してエージェント装置に送信し,又はダウンロードしてもらうことにより,また,所定の半導体メモリを介してエージェント装置に格納することで,自己(第三者)の希望通りの行為(コミュニケーションや処理)をエージェントに行わせることが可能になる。
作成するシナリオの最初のシーンに,例えば,人間に対する回答を要求する問いかけのシーンのシナリオとすることができる。
【0016】
そして,独自に作成したシナリオデータを,インターネット等の通信によりサーバ等にURLを指定して保存することが可能である。
一方,作成したシナリオデータに対応する起動条件とシナリオデータの保存先URLは,外部の装置から入力装置を介して入力することが可能である。この場合の入力装置は,半導体メモリに追加する起動条件とURLが格納されている場合には,半導体メモリの内容を読みとる記憶媒体駆動装置が該当し,インターネット等のネットワークを介して特定のサーバ等からダウンロードする場合には通信制御装置が該当する。
【0017】
エージェント装置は,メール,ブラウザソフトを備えることにより,ブラウザソフト等を使ってシナリオの起動条件とURLをダウンロードし,そのダウンロードしたファイルがエージェントを機能させるシナリオデータの起動条件とURLであるか否かを判断し,起動条件とURLであれば所定の場所に組み込んで使用できるようにする。
また,メールに添付されている場合も同様に,添付のファイルが起動条件とURLであるか否か判断し,そうであればエージェントシステムに組み込んで使用できるようにする。
これにより従来の手法以外にも,既存の通信インフラであるメール,ネットワーク等を使った通信とを使用することにより,また,半導体メモリ等を介することで,パーソナルコンピュータ等を使用して作成した独自のシナリオの起動条件とURLを追加することができるようになる。
このように,ユーザは自分の思い通りにエージェントを機能させるシナリオを独自にまた,容易に作成ことが可能になるので,エージェント装置の自律的な動作に対する抵抗がなくなる。
【0018】
さらに,エージェント装置では,シナリオ作成装置で作成されたシナリオデータに基づいてエージェントを自律的に起動させる(自動で登場させる)条件を満たしたかを判断する処理を定期的にもしくは特定の状態を満たしたときに実行し,条件を満たした場合にエージェントを自動で登場させることができるシステムを少ない記憶容量で実現する。
【0019】
すなわち,シナリオをエージェント装置で実行可能にする場合,シナリオを実行するための自律起動条件とURLを含む集録シナリオ管理データのみをダウンロード等により取得して存する。
そして,エージェント装置では,自律起動条件を満たしたか否かを監視し,自律起動条件を満たした場合,その自律起動条件に対応するシナリオデータ(シナリオ本体)を,自律起動条件に関連付けられたURLで指定される保存先からダウンロードして一時記憶し(画面要素推移体取得手段),取得したシナリオを実行する。
シナリオの自律起動条件は,条件部分の現在位置と日付から必要な部分を高速アクセスが可能な記憶媒体(例えば,RAM)に読み込み,実行判定を行なう。
実行判定の結果,シナリオ実行要求を発行された場合,シナリオデータが存在するサーバのURLを使ってサーバからシナリオデータをダウンロードする処理を行ない,ダウンロードが完了したら実行する。
【0020】
このように,ナビゲーション装置では,自律起動条件とURLを含む集録シナリオ管理データを記憶し,シナリオデータ(シナリオ本体)は実行する際に保存先のURLからダウンロードして実行するので,同等の実行可能なシナリオ数(機能)であっても,車載装置に搭載する記憶媒体の容量を少なくすることができる。」

上記引用例2の記載(特に,下線部)及び図面ならびにこの分野における技術常識を考慮すると,引用例2には以下の技術事項(以下,「引用例2技術事項」という。)が開示されていると認める。

「エージェント装置による一連の連続した行為の内容を規定し複数のシーン及びシーン間の移行条件を含んでなるシナリオデータの保存先を示すURLと該シナリオデータの起動条件(自律起動条件)とを含む集録シナリオ管理データを,メールにより前記エージェント装置に送信すること。」

3 対比
本願発明と引用発明1とを対比するに,

a 引用発明の「遠隔サーバに手続きを実行させる」とは「遠隔サーバ」を「制御する」ことに他ならないから,引用発明の「遠隔サーバ」は本願発明の「遠隔デバイス」に相当し,また,引用発明の「SMSを用いて遠隔サーバに手続きを実行させる方法」は,後述する相違点は別として,本願発明の「SMS(Short Messaging Service)を用いて遠隔デバイスを制御する方法」に相当する。

b 引用発明の「150文字を超えるRPC(Remote Procedure Call)コマンド」を構成する文字は明らかに「テキスト」であって「コマンドに関するテキスト」といえる。
一方,本願発明の「コマンド,前記コマンドは前記遠隔デバイスによって実行される,を記述するメタデータをダウンロードするためのURLを含むテキスト」も「コマンドに関するテキスト」といいうるものである。
そうすると,引用発明の「前記遠隔サーバに前記手続きを実行させるための150文字を超えるRPC(Remote Procedure Call)コマンドを2つの部分に分割」することと,
本願発明の「コマンド,前記コマンドは前記遠隔デバイスによって実行される,を記述するメタデータをダウンロードするためのURLを含むテキストを複数のテキスト部分に分割する」こととは,
「コマンド,前記コマンドは前記遠隔デバイスによって実行される,に関するテキストを複数のテキスト部分に分割する」ことである点で共通する。

c 引用発明の「情報部分」がSMSメッセージのユーザデータであることは明らかであるから,
引用発明の「前記2つの部分それぞれと10文字のRPCヘッダをその情報部分とする2つのSMSメッセージを生成して前記遠隔サーバに送信」することは,
本願発明の「前記テキスト部分それぞれを独立のユーザデータとする,複数のSMSメッセージを生成する段階と,前記SMSメッセージを前記遠隔デバイスに送信する段階と」に相当する。

d 引用発明の「各SMSメッセージのRPCヘッダ」はそれぞれ「ID番号」を備え,該「ID番号」により「分割前のRPCコマンドを再構成」できるから,
引用発明の「各SMSメッセージのRPCヘッダはそのメッセージが前記RPCコマンドのための何番目のメッセージであるかを示すID番号を備え,前記遠隔サーバは前記ID番号を用いて分割前のRPCコマンドを再構成する」ことは,
本願発明「前記SMSメッセージそれぞれは,前記遠隔デバイスが前記SMSメッセージから前記テキストを復元するために必要な情報を含む」ことに相当する。

以上をまとめると,両者は以下の点で一致ないし相違している。

(一致点)
「SMS(Short Messaging Service)を用いて遠隔デバイスを制御する方法において,
コマンド,前記コマンドは前記遠隔デバイスによって実行される,に関するテキストを複数のテキスト部分に分割する段階と,
前記テキスト部分それぞれを独立のユーザデータとする,複数のSMSメッセージを生成する段階と,
前記SMSメッセージを前記遠隔デバイスに送信する段階と,を含み,
前記SMSメッセージそれぞれは,前記遠隔デバイスが前記SMSメッセージから前記テキストを復元するために必要な情報を含む遠隔制御方法。」

(相違点)
「コマンド,前記コマンドは前記遠隔デバイスによって実行される,に関するテキスト」が,
本願発明では「コマンド,前記コマンドは前記遠隔デバイスによって実行される,を記述するメタデータをダウンロードするためのURLを含むテキスト」であるのに対し,
引用発明では「前記遠隔サーバに前記手続きを実行させるための150文字を超えるRPC(Remote Procedure Call)コマンド」即ち「コマンド」自体である点。

4 検討
上記(相違点)につき検討する。

まず,「2 引用例」の項中の「B.引用例2」の項に記した引用例2技術事項を再掲する。
「エージェント装置による一連の連続した行為の内容を規定し複数のシーン及びシーン間の移行条件を含んでなるシナリオデータの保存先を示すURLと該シナリオデータの起動条件(自律起動条件)とを含む集録シナリオ管理データを,メールにより前記エージェント装置に送信すること。」
ここで,「シナリオデータ」は「エージェント装置による一連の連続した行為の内容を規定し複数のシーン及びシーン間の移行条件を含んでなる」ものであって「エージェント装置」の動作を制御する「コマンド」を記述する「メタデータ」といえ,また,「エージェント装置」は「メール」により制御される「遠隔デバイス」といえるから,上記引用例2技術事項は「遠隔デバイスを制御するコマンドを記述するメタデータの保存先を示すURLを含むデータをメールにより遠隔デバイスに送信すること。」ということができる。

そして,引用例2に「シナリオデータ(シナリオ本体)は実行する際に保存先のURLからダウンロードして実行するので,同等の実行可能なシナリオ数(機能)であっても,車載装置に搭載する記憶媒体の容量を少なくすることができる」(【0020】)として,「コマンドを記述するメタデータの保存先を示すURL」を送信することによりコマンドを記憶する記憶媒体の容量を少なくできる効果が記載されているが,引用発明についても,引用例1に「図5-7の例では,2つのSMSメッセージがそれぞれID=1とID=2である。しかしながら,SMSメッセージを適切に順番付けるために必要とされる任意の順番付けスキームが使用されうる。例えば,最初のメッセージがID=c,ここでcは有理数,であれば,2番目のメッセージはID=s(c),3番目のメッセージはID=s(s(c)),等々,ここでsはメッセージの各IDを供給する後者関数(successor function)である。」(摘記事項エ)として,RPCコマンド長が2よりも多くのSMSメッセージの送信を必要とする程大きくなることが示唆されているが,このような場合に上記引用例2の【0020】に記載された効果を得るために,引用発明1に引用例2技術事項を用いることは,当業者であれば容易に想到しうるものである。

そうすると,引用発明において,「遠隔サーバに手続きを実行させるRPC(Remote Procedure Call)コマンド」即ち「コマンド」自体をSMSメッセージで送信することに代えて,本願発明のように「コマンド,前記コマンドは前記遠隔デバイスによって実行される,を記述するメタデータをダウンロードするためのURLを含むテキスト」をSMSメッセージで送信するようにすることは,上記引用例2技術事項に基づいて当業者が容易になし得たものである。

そして,本願発明が奏する効果も引用発明および引用例2技術事項から容易に予測出来る範囲内のものである。

5 むすび
以上のとおり,本願発明は,引用発明および引用例2技術事項に基づいて,当業者が容易に発明をすることができたものと認められるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,他の請求項に係る発明について審理するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2016-10-24 
結審通知日 2016-10-31 
審決日 2016-11-11 
出願番号 特願2013-537617(P2013-537617)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 寺谷 大亮  
特許庁審判長 高瀬 勤
特許庁審判官 新川 圭二
山澤 宏
発明の名称 SMSを用いて遠隔デバイスを制御する方法及びそのための装置  
代理人 崔 允辰  
代理人 木内 敬二  
代理人 阿部 達彦  
代理人 実広 信哉  
  • この表をプリントする

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