【事件の表示】
　特願２０１２−１４４８８１「アプリケーション連携システム、アプリケーション連携方法及びアプリケーション連携プログラム」拒絶査定不服審判事件〔平成２６年　１月２０日出願公開，特開２０１４−　１０５１２，請求項の数（５）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，平成２４年６月２８日の出願であって，その手続の経緯は以下のとおりである。
　　平成２８年　４月２２日付け　：拒絶理由の通知
　　平成２８年　６月２７日　　　：意見書，手続補正書の提出
　　平成２８年１１月　１日付け　：拒絶査定
　　平成２９年　１月３１日　　　：審判請求書，手続補正書の提出
　　平成２９年１２月１５日付け　：拒絶理由の通知（当審）
　　平成３０年　２月１４日　　　：意見書，手続補正書の提出
第２　原査定の概要
　原査定（平成２８年１１月１日付け拒絶査定）の概要は次のとおりである。
　本願請求項１−６に係る発明は，以下の引用文献Ａ−Ｄに基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
Ａ．特開２００１−　１４４１１号公報
Ｂ．特開２００６−１９０００８号公報
Ｃ．特開平１１−　６５７９５号公報（周知技術を示す文献）
Ｄ．特開２０１１−　８１５３７号公報
第３　当審拒絶理由の概要
　当審拒絶理由の概要は次のとおりである。
　本願請求項１，４−６に係る発明は，以下の引用文献１−３に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
１．特開２０１１−　８１５３７号公報　（拒絶査定時の引用文献Ｄ）
２．特開平１１−　６５７９５号公報　（拒絶査定時の引用文献Ｃ）
３．特開２００６−１９０００８号公報　（拒絶査定時の引用文献Ｂ）
第４　本願発明
　本願請求項１−５に係る発明（以下，それぞれ「本願発明１」−「本願発明５」という。）は，平成３０年２月１４日付けの手続補正で補正された特許請求の範囲の請求項１−５に記載された事項により特定される発明であり，以下のとおりの発明である。
「　　【請求項１】
　演算装置と，記憶装置と，表示装置とを備え，複数のレコードを管理する連携元アプリケーションと，連携先アプリケーションとを連携させるためのアプリケーション連携システムにおいて，
　前記記憶装置は，連携元アプリケーション，前記連携元アプリケーションのレコード表示ウィンドウであって連携時に項目値が取得される連携時項目取得ウィンドウ，当該連携時項目取得ウィンドウ内に表示される項目であって連携時に項目値が取得される，前記連携時項目取得ウィンドウ内での前記項目値の表示位置情報を含む連携時取得項目，連携先アプリケーション，及び前記連携元アプリケーションに連携して前記連携先アプリケーションを起動させるための連携起動コマンド形式の情報を含む連携ルールを記録する連携ルール記憶部を有し，
　連携時に，前記表示装置に表示された前記連携時項目取得ウィンドウ内の前記連携時取得項目の項目値を前記表示位置情報に基づいて取得する項目値取得部と，
　連携時に，前記連携起動コマンド形式に基づき，前記項目値取得部が取得した項目値を起動パラメータとして含む連携起動コマンドを生成する連携起動コマンド生成部と，を備え，
　前記項目値取得部は，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値又はＨＴＭＬデータの前記連携時取得項目のタグの値であると共に，
　連携時に前記連携起動コマンドを実行することで，前記項目値取得部が取得した項目値を起動パラメータとしながら前記連携先アプリケーションを起動させる連携起動を実行することを特徴とするアプリケーション連携システム。
　　【請求項２】
　前記連携ルール記憶部に記録されている連携ルールは，前記連携元アプリケーションから前記連携先アプリケーションにデータを連携して受け渡しするための連携受渡プロトコル形式の情報をさらに含み，
　連携時に，前記連携受渡プロトコル形式に基づき，前記項目値取得部が取得した項目値を受渡データとして含む連携受渡プロトコルを生成する連携受渡プロトコル生成部をさらに備え，
　連携時に前記連携受渡プロトコルを実行することで，前記連携元アプリケーションから前記連携先アプリケーションに前記項目値取得部が取得した項目値を受け渡す連携受渡を実行すると共に，
　前記連携ルール記憶部に記録されている連携ルールは，複数の連携先アプリケーションについての設定情報を含んでおり，前記連携先アプリケーション毎に連携時に前記連携起動又は前記連携受渡の何れかを行うかの設定情報をさらに含んでいることを特徴とする請求項１記載のアプリケーション連携システム。
　　【請求項３】
　前記連携ルール記憶部に記録されている連携ルールは，複数の連携元アプリケーションについての設定情報を含んでおり，前記連携ルール記憶部には，前記連携元アプリケーション毎に前記連携ルールが記録されていることを特徴とする請求項１又は２記載のアプリケーション連携システム。
　　【請求項４】
　演算装置と，記憶装置と，表示装置とを備えるコンピュータに，複数のレコードを管理する連携元アプリケーションと，連携先アプリケーションとを連携させる処理を行わせるアプリケーション連携プログラムにおいて，
　連携元アプリケーション，前記連携元アプリケーションのレコード表示ウィンドウであって連携時に項目値が取得される連携時項目取得ウィンドウ，当該連携時項目取得ウィンドウ内に表示される項目であって連携時に項目値が取得される，前記連携時項目取得ウィンドウ内での前記項目値の表示位置情報を含む連携時取得項目，連携先アプリケーション，及び前記連携元アプリケーションに連携して前記連携先アプリケーションを起動させるための連携起動コマンド形式の情報を含む連携ルールを前記記憶装置に記録する連携ルール記録ステップと，
　連携時に，前記表示装置に表示された前記連携時項目取得ウィンドウ内の前記連携時取得項目の項目値を前記表示位置情報に基づいて取得する項目値取得ステップであって，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値は又はＨＴＭＬデータの前記連携時取得項目のタグの値である項目値取得ステップと，
　連携時に，前記連携起動コマンド形式に基づき，前記項目値取得ステップで取得した項目値を起動パラメータとして含む連携起動コマンドを生成する連携起動コマンド生成ステップと，
　連携時に前記連携起動コマンドを実行することで，前記項目値取得ステップで取得した項目値を起動パラメータとしながら前記連携先アプリケーションを起動させる連携起動ステップと，を前記コンピュータに実行させることを特徴とするアプリケーション連携プログラム。
　　【請求項５】
　演算装置と，記憶装置と，表示装置とを備えるコンピュータにおいて，複数のレコードを管理する連携元アプリケーションと，連携先アプリケーションとを連携させるアプリケーション連携方法において，
　連携元アプリケーション，前記連携元アプリケーションのレコード表示ウィンドウであって連携時に項目値が取得される連携時項目取得ウィンドウ，当該連携時項目取得ウィンドウ内に表示される項目であって連携時に項目値が取得される，前記連携時項目取得ウィンドウ内での前記項目値の表示位置情報を含む連携時取得項目，連携先アプリケーション，及び前記連携元アプリケーションに連携して前記連携先アプリケーションを起動させるための連携起動コマンド形式の情報を含む連携ルールを前記記憶装置に記録する連携ルール記録ステップと，
　連携時に，前記演算装置が，前記表示装置に表示された前記連携時項目取得ウィンドウ内の前記連携時取得項目の項目値を前記表示位置情報に基づいて取得する項目値取得ステップであって，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値は又はＨＴＭＬデータの前記連携時取得項目のタグの値である項目値取得ステップと，
　連携時に，前記演算装置が，前記連携起動コマンド形式に基づき，前記項目値取得ステップで取得した項目値を起動パラメータとして含む連携起動コマンドを生成する連携起動コマンド生成ステップと，
　連携時に，前記演算装置が前記連携起動コマンドを実行することで，前記項目値取得ステップで取得した項目値を起動パラメータとしながら前記連携先アプリケーションを起動させる連携起動ステップと，を備えることを特徴とするアプリケーション連携方法。」
第５　引用文献，引用発明等
１　引用文献１について
　平成２９年１２月１５日付け当審からの拒絶の理由に引用された引用文献１（特開２０１１−８１５３７号公報）には，図面とともに次のａ−ｄの事項が記載されている。
ａ　「【００１０】
　本発明は，このような課題に鑑みてなされたものであり，ソフトウェアのソースコード等を解析する必要が無く，簡単な処理で迅速にシステム間等でのデータの受け渡しが可能な汎用データ取得方法，データ連携方法及びデータ移行方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
　上記課題を解決するための本発明に係るデータ受渡方法は，演算装置と記憶装置を備えたコンピュータにおいて，受渡元データベースに格納されている受渡元レコードを変換して受渡先データベースに格納するデータ受渡方法において，前記演算装置が，受渡元レコードを表示装置に表示するレコード表示工程と，前記演算装置が，レコード表示ウィンドウにおける所定の項目値の表示領域をその項目名と関連づけて設定してあるマスクにより，前記受渡元レコードの表示ウィンドウの画像から抽出された画像データを光学文字認識することで，当該項目値のテキストデータを取得する文字認識工程と，前記演算装置が，前記テキストデータを前記マスクに設定されている当該項目値の項目名と関連づけた汎用データとして前記記憶装置に格納する汎用データ格納工程と，を備えることを特徴とする。
…（中略）…
【００１３】
　また，本発明に係るコンピュータシステムは，種々の演算を行う演算装置と，受渡元データベース及び受渡先データベースとを格納する記憶装置と，表示装置とを備えたコンピュータシステムにおいて，前記演算装置は，受渡元レコードを前記表示装置に表示するレコード表示制御と，前記レコード表示ウィンドウにおける所定の項目値の表示領域をその項目名と関連づけて設定してあるマスクにより，前記受渡元レコードの表示ウィンドウの画像から抽出された画像データを光学文字認識することで，当該項目値のテキストデータを取得する文字認識制御と，前記テキストデータを前記マスクに設定されている当該項目値の項目名と関連づけた汎用データとして前記記憶装置に格納する汎用データ格納制御と，を行うことを特徴とする。」
ｂ　「【００１７】
　図面を参照しながら本発明の実施形態について詳細に説明する。図１は，本実施形態に係るデータ移行システムの構成を概略的に示す模式図である。図１に示すように，データ移行システム１は，コンピュータ本体１０と，コンピュータ本体１０からの出力情報を表示する表示装置であるディスプレイ２０と，コンピュータ本体１０に情報入力するためのキーボードやマウス等の入力装置２２とを備える。
【００１８】
　コンピュータ本体１０は，各種演算を行うＣＰＵ（Central
Processing Unit）等の演算装置１１と，各種情報を記憶しておくＨＤＤ（Hard DiscDrive）や演算処理のワークエリアとして使用されるＲＡＭ（Random Access Memory）等からなる記憶装置１２とを備えている。
【００１９】
　記憶装置１２は，コンピュータ本体１０において後述するアプリケーションや所定の処理を実行するための各種プログラムを格納するプログラムＤＢ（データベース）１２１と，アプリケーションＡのレコードを格納するアプリＡ−ＤＢ１２２と，後述するようにアプリケーションＡのレコードから取得される汎用データを格納する汎用データＤＢ１２３と，アプリケーションＢのレコードを格納するアプリＢ−ＤＢ１２４と，汎用データを取得するためのマスクを格納するマスクＤＢ１２５とを備えている。
【００２０】
　なお，本実施形態では，一台のコンピュータにおいて，異なるアプリケーション（アプリケーションＡとアプリケーションＢ）の間でデータの受け渡しを行う，すなわち，アプリケーションＡのデータベースＡ（ＤＢ−Ａ）１２２に格納されているレコードを，アプリケーションＢのデータベース（ＤＢ−Ｂ）１２４に移行させる場合を例に挙げて説明する。アプリケーションＡ及びＢは，ともに住所録データベースを管理するためのアプリケーションである。
【００２１】
　本実施形態は，アプリケーションＡのレコードの所望の項目値を，表示画面の中のレコード表示ウィンドウの画像データから光学文字認識（ＯＣＲ：Optical Character Recognition）によりテキスト化することで，アプリＢ−ＤＢ１２４に移行するための汎用データを取得することを特徴としている。このとき，レコード表示ウィンドウの画像から所望の項目値の表示領域を抽出するためにマスクを用いている。
【００２２】
　そこで，このマスクを作成する手順について，図面を参照しながら説明する。図２は，本実施形態に係るマスクの作成手順を示すフローチャートであり，図３は，本実施形態に係るアプリＡ−ＤＢ１２２に格納されている一レコードの表示ウィンドウを示す図である。図４は，マスクＤＢ１２５に格納されるマスクＸの設定内容を示す図である。なお，本実施形態では，マスクＸを用いて，図３の「氏名」，「氏名読み」，「社名」，「電子メール」の４つの項目について，汎用データを取得する場合を例に挙げて説明する。
【００２３】
　まず，データ移行を行うユーザは，移行元のデータベースを管理するアプリケーションＡと，移行のための処理を行う移行アプリケーションを起動させた状態で，マスク作成を開始する。アプリケーションＡ及び移行アプリケーションを実行するためのプログラムは，プログラムＤＢ１２１内に格納されており，演算装置１１がこれらのプログラムを実行することで，アプリケーションＡ及び移行アプリケーションが実行される。
【００２４】
　開始後，Ｓ１０では，ユーザは，入力装置２２を操作して，図３に示すように，移行元のアプリＡ−ＤＢ１２２の所望の移行元レコードを表示するようデータ移行システム１に指示する。指示を受けたコンピュータ本体１０は，演算装置１１がアプリケーションＡのプラグラムを実行することで，上記移行元レコードをディスプレイ２０に表示する。
【００２５】
　この状態で，ユーザが，移行アプリケーションのマスク設定機能を起動させ，マスク設定処理が開始される（Ｓ１１）。なお，本実施形態では，レコードの表示ウィンドウがディスプレイ２０の全体にわたって最大化されて表示されている場合を例に挙げて説明する。
【００２６】
　Ｓ１２では，移行アプリケーションが，表示されているアプリケーションＡのレコードに含まれる複数の項目の中から，アプリケーションＢのＤＢ１２４に移行させたい項目の項目名を入力するように，ユーザに促す。この案内は，例えば，音声やディスプレイ２０上への表示によって呈示される。最初に設定される項目名として，ユーザが「氏名」を入力すると，マスクＸの設定として，マスクＤＢ１２５に記録される。
【００２７】
　続いて，Ｓ１３に進み，移行アプリケーションからユーザに対して，項目「氏名」の項目値が表示されている領域を指定するように案内がなされる。ユーザが入力装置２２であるマウスを操作して，図３の項目「氏名」の項目値が表示されている領域５１（図中，点線で囲んである領域）を指定すると，指定された領域の座標値が項目名「氏名」と関連づけられ，マスクＸの設定としてマスクＤＢ１２５に記録される。
【００２８】
　続いて，Ｓ１４では，移行アプリケーションが，全ての項目について設定が終了したか否かについて，ユーザに問い合わせる。このような問い合わせは，例えば，画面上に，問い合わせの文章と共に，「ＹＥＳ」及び「ＮＯ」の回答ボタン表示させることで行われる。まだ，終了していないとユーザが回答した場合には，Ｓ１２に戻り，次の項目について，上述したＳ１２及びＳ１３が再度実施される。
【００２９】
　全ての項目について設定が終了，すなわち，本実施形態では，「氏名」，「氏名読み」，「社名」及び「電子メール」の項目についてのマスク設定（項目名及び項目値の領域座標）が終了，すなわち，残りの項目名「氏名読み」に対して領域５２が指定され，項目名「社名」に対して領域５３が指定され，項目名「電子メール」に対して領域５４が指定され，Ｓ１４においてユーザが終了と回答すると，Ｓ１５へと進む。
【００３０】
　Ｓ１５へ進むときには，マスクＤＢ１２５には，図４（ａ）に示すようなマスクＸの設定が格納されている。このように，マスクＸの項目情報としては，項目番号毎に，項目名及び領域座標が関連づけて記録されている。」
ｃ　「【００３５】
　続いて，図５を参照しながら，データベースＡのレコードからデータベースＢに移行可能な中間的な汎用データを取得する汎用データ取得処理の流れを説明する。図５は，汎用データ取得処理の流れを示すフローチャートである。
【００３６】
　まず，ユーザは，アプリケーションＡと移行アプリケーションを起動したうえで，汎用データの取得を開始する。開始後，Ｓ２０では，ユーザの指令に従って，アプリケーションＡが実行され，ユーザが汎用データの取得を望む移行元レコードがディスプレイ２０に表示される。この状態で，ユーザが移行アプリケーションの汎用データ取得機能を起動させ，汎用データ取得処理が開始される（Ｓ２１）。
【００３７】
　Ｓ２２では，ディスプレイ画面上のレコード表示ウィンドウがキャプチャされ，画像データとして記憶装置１２に一時的に記録される。続いて，Ｓ２３では，マスクＸに設定されている特徴画像を用いて，キャプチャ画像（移行元レコード表示ウィンドウ）を確認し，マスクＸ設定時のレコード表示ウィンドウと比較してウィンドウが縮小されるなどして，特徴画像の一部が表示されていない場合には，ユーザに警告アナウンス「ウィンドウサイズを大きくしてください」を発し，ウィンドウの拡大等の補正を求める。なお，全ての特徴画像が表示されるように，演算装置１２が自動でレコード表示ウィンドウを拡大するように構成しても良い。
【００３８】
　続いて，Ｓ２４では，マスクＸに設定されている各項目について，キャプチャ画像から各項目値の領域座標の画像を抜き出して，ＯＣＲ（光学文字認識）処理によりテキストデータに変換する。変換された項目値のテキストデータは，対応する項目名と関連づけられた汎用データとして，記憶装置１２の汎用データＤＢ１２３に格納される（Ｓ２５）。」
ｄ　「【００４５】
　続いて，アプリＡ−ＤＢ１２２のレコードから取得した汎用データをアプリケーションＢのフォーマットに合わせたレコードに変換して，移行先レコードとしてアプリＢ−ＤＢ１２４に格納する処理について説明する。汎用データは，図６に示したように，項目名と項目値とを一対一で関連づけて列記したデータ構造であるため，アプリケーションＢがこのような標準データのインポートに対応している場合には，汎用データをアプリケーションＢにインポートするだけで，汎用データがアプリＢ−ＤＢ１２４用のレコードに変換されてデータベースに記録され，データの移行が完了する。
【００４６】
　また，アプリケーションＢのレコード構造が分かっていれば，汎用データをアプリケーションＢのレコード構造のデータに直接変換し，アプリＢ−ＤＢ１２４に格納するようにしても良い。このような汎用データのアプリケーションＢへの受け渡しは，ユーザの指示によって行うだけなく，移行アプリケーションの機能として組み込むようにしても良い。このとき，移行したい全てのレコードの汎用データを取得してからまとめてアプリケーションＢに渡すようにしても良いし，一つのレコードの汎用データを取得するたびにアプリケーションＢに渡すように構成しても良い。
【００４７】
　なお，汎用データを一つずつアプリケーションＢに受け渡すといったデータ連携の場合には，アプリケーションＢを起動してレコード入力画面を表示すると共に，このレコード入力画面の対応する項目値の入力欄に汎用データの各項目値を入力するようなプログラムを作成すれば良い。この場合には，汎用データに含まれていない項目値であって，アプリケーションＢのレコードとして必要な項目値を，そのままその入力画面において補充入力することも可能である。」
２　したがって，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
「種々の演算を行う演算装置と，記憶装置と，表示装置とを備えたコンピュータシステムにおいて，
　前記記憶装置は，
　受渡元アプリケーション，受渡先アプリケーション，および移行アプリケーションなど所定の処理を実行するための各種プログラムを格納するプログラムＤＢと，受渡元アプリケーションのレコードを格納する受渡元アプリＤＢと，受渡元アプリケーションのレコードから取得される汎用データを格納する汎用データＤＢと，受渡先アプリケーションのレコードを格納する受渡先アプリＤＢと，汎用データを取得するためのマスクを格納するマスクＤＢとを有し，
　前記演算装置は，
　受渡元アプリケーションのレコードを前記表示装置に表示するレコード表示制御部と，
　レコード表示ウィンドウにおける所定の項目値の表示領域を，その項目名及び，ユーザが入力装置を操作して指定した領域座標と関連づけて設定してあるマスクにより，前記受渡元アプリケーションのレコードの表示ウィンドウの画像から抽出された画像データを光学文字認識することで，当該項目値のテキストデータを取得する文字認識制御部と，
　前記テキストデータを前記マスクに設定されている当該項目値の項目名と関連づけた汎用データとして前記記憶装置に格納する汎用データ格納制御部と
　前記汎用データを前記受渡先アプリＤＢのフォーマットのレコードに変換し，受渡先レコードとして前記受渡先アプリＤＢに格納する受渡先レコード格納制御部と，
　を備えたコンピュータシステム。」
３　引用文献２について
　平成２９年１２月１５日付け当審からの拒絶の理由に引用された引用文献２（特開平１１−６５７９５号公報）には，図面とともに次のｅの事項が記載されている。
ｅ　「【００３０】４３はプログラム検索・起動手段，４４はプログラム管理テーブルである。このプログラム管理テーブル４４は後述のような情報を保持し，プログラム検索・起動手段４３は，実行中のプログラム４１より図示しないＯＳの通信手段を介して要求のあった場合，その要求からプログラム管理テーブル４４を検索し，起動すべき適切なプログラムを決定し，領域選択手段４２から獲得したデータを適切な方法でこのプログラムに受け渡して起動する。４５はこのようにして起動されたプログラムのプロセスを示す。４６はプログラム選択ウインドウで，プログラム検索・起動手段４３がプログラムの一覧を表示し，ユーザに選択させるためのプログラム選択ウインドウである。これは基本的に従来例の図１のウインドウ１と同様なウインドウであるが，本実施の形態では通常は表示されていない。
【００３１】次に図５を参照して，本発明の実施の形態に係わるプログラム管理テーブル４４のデータ構成を説明する。
【００３２】図５において，データ種類の欄５０１は，前述した領域選択手段４２でユーザが選択しているデータの種類であり，ここでは単なる文字列（text）とビットマップイメージ（image）の２つに分類している。なお図中『＊』はデータ種類がいずれでもよいことを示している。
【００３３】機能欄５０２は，選択されているデータに対して行う処理の名称を示し，ここでは「印刷（print）」，「編集（edit）」，「mail（電子メールで送信）」，「save（ファイルに保存）」の４つに分類されている。
【００３４】プログラムパス名の欄５０３には，そのデータを処理するプログラムのパス名が記述され，起動方法の欄５０４には，そのプログラムの起動方法およびデータの受渡し方法が記述される。
【００３５】起動方法の欄５０４の例で，「$exec」はそのパス名のプログラムを起動することを示し，「$1」は領域選択手段４２から獲得されるデータを示す。「saveToFile($1)」，「send($1)」等は，このデータに対する１種の関数であり，
・saveToTemp($1)は一時ファイルを生成して，このデータをセーブし，その一時ファイル名を返す関数である。
・send($1)は，起動済のプログラムプロセスに対して，所定の通信手段を使用してデータを送信する関数である。
・saveFile($1)は，保存するファイル名をユーザに問い合わせて，データをファイルに保存し，そのファイル名を返す関数である。」
　したがって，上記引用文献２には，
「プログラム１のウィンドウ上の所定領域から獲得したデータを受け渡してプログラム２を起動するために，当該プログラム２のパス名及び起動方法を含む起動コマンド形式の情報を少なくともプログラム管理テーブルに登録しておく」
旨の技術（以下，「引用文献２記載技術」という。）が記載されていると認められる。
４　引用文献３について
　平成２９年１２月１５日付け当審からの拒絶の理由に引用された引用文献３（特開２００６−１９０００８号公報）には，図面とともに次のｆ−ｇの事項が記載されている。
ｆ　「【００６３】
　連携手段３３はこの段階で，この連携の組み合わせをシステムに登録するか，利用者に尋ねる。利用者が「登録する」というのを選んだ場合，本組み合わせがアプリケーション管理手段３１のプロセス管理テーブル３１ｂから参照される連係情報テーブルに連携の組み合わせとして，送信元のアプリケーションＩＤ，送信元のアプリケーション画面名，データ名，型名，受信元のアプリケーションＩＤ，受信アプリケーション画面名，データ名，型名が登録される。
【００６４】
　連携手段は，アプリケーション画面の変化を検知すると，該アプリケーションのＩＤ，アプリケーションの変化後の画面名をキーとして，本連携情報テーブルを検索する。該エントリが見つかった場合，受信アプリケーションがすでに起動されていれば，該受信アプリケーションにデータを通知し，受信アプリケーションが起動されていなければ，起動し，が受信アプリケーションにデータを通知する。本処理により，一旦登録した連携方法は，次回は明示的に指定せずとも有効となり，送信側アプリケーションの画面変化により，連携データが自動的に受信アプリケーションに反映するようになる。」
ｇ　「【００７３】
　ここでゴルフ検索アプリケーション画面上の「所在地」の横に表示されている「共鳴アイコン］を利用者がクリックすると，「所在地」に記載されている値「東京都武蔵野市○○−△−□−×」が，地図アプリケーション上の住所入力フォームに転送される。」
　したがって，上記引用文献３には，
「連携情報テーブルに，受信側アプリケーションの画面名，その画面上のデータ名，及び，送信側及び受信側の両者のデータの型名も登録しておき，共鳴アイコンをクリックすることによって連携データが転送されて受信側アプリケーションに自動的に反映される」
旨の技術（以下，「引用文献３記載技術」という。）が記載されていると認められる。
第４　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると，次のことがいえる。
ア　引用発明では，「演算装置」，「記憶装置」，「表示装置」を備えた「コンピュータシステム」において，「受渡元アプリＤＢ」に「レコード」を格納する「受渡元アプリケーション」から取得した「汎用データ」を「受渡先アプリケーション」に受け渡すことから，「受渡元アプリケーション」と「受渡先アプリケーション」とを連携させるといえる。
　そうすると，引用発明の「コンピュータシステム」は本願発明１の「アプリケーション連携システム」に対応し，引用発明の「演算装置」，「記憶装置」，「表示装置」，「受渡元アプリケーション」，「受渡先アプリケーション」はそれぞれ，本願発明１の「演算装置」，「記憶装置」，「表示装置」，「連携元アプリケーション」，「連携先アプリケーション」に相当するといえる。
　よって，引用発明と本願発明１とは，“演算装置と，記憶装置と，表示装置とを備え，複数のレコードを管理する連携元アプリケーションと，連携先アプリケーションとを連携させるためのアプリケーション連携システム”である点で一致するといえる。
イ　引用発明では，「記憶装置」は，「受渡元アプリケーションのレコードから取得される汎用データを格納する汎用データＤＢ」と，「汎用データを取得するためのマスクを格納するマスクＤＢとを有」し，「マスク」について，「演算装置」は，「受渡元アプリケーションのレコードを前記表示装置に表示」し，「レコード表示ウィンドウにおける所定の項目値の表示領域を，その項目名及び領域座標と関連づけて設定してあるマスクにより，前記受渡元アプリケーションのレコードの表示ウィンドウの画像から抽出された画像データを光学文字認識することで，当該項目値のテキストデータを取得」し，「テキストデータを前記マスクに設定されている当該項目値の項目名と関連づけた汎用データとして前記記憶装置に格納」し，「前記汎用データを前記受渡先アプリＤＢのフォーマットのレコードに変換し，受渡先レコードとして前記受渡先アプリＤＢに格納する」ところ，「記憶装置」は，連携時に「項目値」が取得される「受渡元アプリケーション」の「レコード表示ウィンドウ」，前記「レコード表示ウィンドウ」内に表示される「項目」であって連携時に「項目値」が取得される，前記「レコード表示ウィンドウ」内での前記「項目値」の「領域座標」を含む「項目」，を含む「マスク」を記録する「マスクＤＢ」を有するといえる。
　また，引用発明の「マスク」は，上位概念では「受渡元アプリケーション」と「受渡先アプリケーション」の“連携事項”とみることができ，本願発明１の「連携ルール」も“連携事項”の態様であり，上位概念では“連携事項”とみることができる。
　そうすると，引用発明の「マスク」，「マスクＤＢ」と本願発明１の「連携ルール」，「連携ルール記憶部」とは，連携時の“連携事項”，“連携事項記憶部”である点で共通し，引用発明の「レコード表示ウィンドウ」，「項目」，「項目値」，「領域座標」はそれぞれ，本願発明１の「連携時項目取得ウィンドウ」，「連携時取得項目」，「項目値」，「表示位置情報」に相当するといえる。
　したがって，引用発明と本願発明１とは，
　“前記記憶装置は，連携元アプリケーションのレコード表示ウィンドウであって連携時に項目値が取得される連携時項目取得ウィンドウ，当該連携時項目取得ウィンドウ内に表示される項目であって連携時に項目値が取得される，前記連携時項目取得ウィンドウ内での前記項目値の表示位置情報を含む連携時取得項目，を含む連携事項を記録する連携事項記憶部を有”する点で共通するといえる。
ウ　引用発明では，「レコード表示ウィンドウにおける所定の項目値の表示領域を，その項目名及び，ユーザが入力装置を操作して指定した領域座標と関連づけて設定してあるマスクにより，前記受渡元アプリケーションのレコードの表示ウィンドウの画像から抽出された画像データを光学文字認識することで，当該項目値のテキストデータを取得する」ところ，上記イでの検討から，引用発明の「レコード表示ウィンドウ」，「項目」，「項目値」，「領域座標」はそれぞれ，本願発明１の「連携時項目取得ウィンドウ」，「連携時取得項目」，「項目値」，「表示位置情報」に相当するといえ，引用発明は，「受渡元アプリケーション」と「受渡先アプリケーション」の連携時に，「表示装置」に表示された「レコード表示ウィンドウ」内の「項目」の「項目値」を「領域座標」に基づいて取得する手段を実質的に備え，「項目値」は当該「項目」のユーザが指定した「領域座標」の画像データを光学文字認識することにより取得するといえる。
　そうすると，引用発明と本願発明１とは，
　“連携時に，前記表示装置に表示された前記連携時項目取得ウィンドウ内の前記連携時取得項目の項目値を前記表示位置情報に基づいて取得する項目値取得部”を備える点で共通するといえる。
エ　上記ウでの検討から，引用発明では，連携時に，“項目値取得部”が取得した「項目値」を“パラメータ”としながら，「受渡先アプリケーション」に対して連携を実行するといえる。
　一方，本願発明１では，「連携時に前記連携起動コマンドを実行することで，前記項目値取得部が取得した項目値を起動パラメータとしながら前記連携先アプリケーションを起動させる連携起動を実行する」ところ，「連携起動を実行する」ことは“連携を実行する”ことに他ならず，「起動パラメータ」は“パラメータ”の一態様であることから，連携時に，「項目値取得部」が取得した「項目値」を“パラメータ”としながら「連携先アプリケーション」に対して連携を実行するとみることができる。
　そうすると，引用発明と本願発明１とは，
　“連携時に，前記項目値取得部が取得した項目値をパラメータとしながら前記連携先アプリケーションに対して連携を実行する”点で共通するといえる。
　したがって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。
（一致点）
「演算装置と，記憶装置と，表示装置とを備え，複数のレコードを管理する連携元アプリケーションと，連携先アプリケーションとを連携させるためのアプリケーション連携システムにおいて，
　前記記憶装置は，連携元アプリケーションのレコード表示ウィンドウであって連携時に項目値が取得される連携時項目取得ウィンドウ，当該連携時項目取得ウィンドウ内に表示される項目であって連携時に項目値が取得される，前記連携時項目取得ウィンドウ内での前記項目値の表示位置情報を含む連携時取得項目，を含む連携事項を記録する連携事項記憶部を有し，
　連携時に，前記表示装置に表示された前記連携時項目取得ウィンドウ内の前記連携時取得項目の項目値を前記表示位置情報に基づいて取得する項目値取得部と，
を備え，
　連携時に，前記項目値取得部が取得した項目値をパラメータとしながら前記連携先アプリケーションに対して連携を実行することを特徴とするアプリケーション連携システム。」
（相違点）
（相違点１）
　連携事項に関し，本願発明１では，「連携ルール記憶部」が「連携元アプリケーション，前記連携元アプリケーションのレコード表示ウィンドウであって連携時に項目値が取得される連携時項目取得ウィンドウ，当該連携時項目取得ウィンドウ内に表示される項目であって連携時に項目値が取得される，前記連携時項目取得ウィンドウ内での前記項目値の表示位置情報を含む連携時取得項目，連携先アプリケーション，及び前記連携元アプリケーションに連携して前記連携先アプリケーションを起動させるための連携起動コマンド形式の情報を含む連携ルールを記録する」のに対して，
　引用発明では，「マスクＤＢ」が，連携時に「項目値」が取得される「受渡元アプリケーション」の「レコード表示ウィンドウ」，前記「レコード表示ウィンドウ」内に表示される「項目」であって連携時に「項目値」が取得される，前記「レコード表示ウィンドウ」内での前記「項目値」の「領域座標」を含む「項目」，を含む「マスク」を記録するものの，「受渡元アプリケーション」，「受渡先アプリケーション」，「連携起動コマンド形式の情報」を含むことについて言及されていない点。
（相違点２）
　連携時の項目取得に関し，本願発明１では，「連携時に，前記表示装置に表示された前記連携時項目取得ウィンドウ内の前記連携時取得項目の項目値を前記表示位置情報に基づいて取得する項目値取得部」を備え，「前記項目値取得部は，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値又はＨＴＭＬデータの前記連携時取得項目のタグの値である」のに対して，
　引用発明では，「受渡元アプリケーション」と「受渡先アプリケーション」の連携時に，「表示装置」に表示された「レコード表示ウィンドウ」内の「項目」の「項目値」を「領域座標」に基づいて取得する手段を備えるものの，「項目値」は当該「項目」の，ユーザが指定した「領域座標」の画像データを光学文字認識することにより取得し，ウィンドウハンドル又はＨＴＭＬデータを用いることについて言及されていない点。
（相違点３）
　連携起動に関し，本願発明１では，「連携時に，前記連携起動コマンド形式に基づき，前記項目値取得部が取得した項目値を起動パラメータとして含む連携起動コマンドを生成する連携起動コマンド生成部」を備え，「連携時に前記連携起動コマンドを実行することで，前記項目値取得部が取得した項目値を起動パラメータとしながら前記連携先アプリケーションを起動させる連携起動を実行する」のに対して，
　引用発明では，連携時に取得した「項目値」をパラメータとしながら，「受渡先アプリケーション」に対して連携を実行するものの，「連携起動コマンド」を使用して連携起動を実行することについて言及されていない点。
（２）相違点についての判断
　事案に鑑みて，上記相違点２について先に検討すると，
　引用発明では，「受渡元アプリケーション」と「受渡先アプリケーション」の連携時に，「レコード表示ウィンドウにおける所定の項目値の表示領域を，その項目名及び，ユーザが入力装置を操作して指定した領域座標と関連づけて設定してあるマスクにより，前記受渡元アプリケーションのレコードの表示ウィンドウの画像から抽出された画像データを光学文字認識することで，当該項目値のテキストデータを取得する」ところ，「項目値」は当該「項目」の，ユーザが指定した「領域座標」の画像データを光学文字認識することにより取得しており，受渡元アプリケーションのレコードの表示ウィンドウを画像データとして文字認識処理するために，項目それぞれの領域座標はユーザが指定する必要があるといえる。
　また，引用発明において，「受渡元アプリケーション」の「レコード表示ウィンドウ」において，取得する「項目」の「領域座標」を，ウィンドウハンドルの値又はＨＴＭＬデータの連携時取得項目のタグの値から取得すること，あるいは，ユーザの介在無しに取得することについて動機があるとはいえない。
　そして，連携時に，受渡元アプリケーションのレコード表示ウィンドウにおいて，取得する項目の領域座標を，ウィンドウハンドルの値又はＨＴＭＬデータの連携時取得項目のタグの値から取得することは，本願出願前に当該技術分野の周知技術とはいえず，さらに，引用文献２−３にも記載も示唆もされていない。
　そうすると，引用発明において，受渡元アプリケーションのレコード表示ウィンドウにおいて，項目のユーザが指定した領域座標の画像データを光学文字認識して項目値を取得することに代えて，受渡元アプリケーションのレコード表示ウィンドウのウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得し，表示位置情報は，ウィンドウハンドルの値又はＨＴＭＬデータの連携時取得項目のタグの値から取得すること，すなわち，上記相違点２に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
　したがって，上記相違点１，３について判断するまでもなく，本願発明１は，当業者であっても，引用発明及び引用文献２−３に記載された技術に基づいて容易に発明できたものとはいえない。
２　本願発明２−３について
　本願発明２−３は，本願発明１を減縮した発明であり，本願発明１の「前記項目値取得部は，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値又はＨＴＭＬデータの前記連携時取得項目のタグの値である」とすること，と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明及び引用文献２−３に記載された技術に基づいて容易に発明できたものとはいえない。
３　本願発明４，５について
　本願発明４，５は，本願発明１とカテゴリのみが異なり，本願発明１の「前記項目値取得部は，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値又はＨＴＭＬデータの前記連携時取得項目のタグの値である」とすること，と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明及び引用文献２−３に記載された技術に基づいて容易に発明できたものとはいえない。
第７　原査定についての判断
　平成３０年２月１４日付け手続補正により補正された請求項１，４，５は，それぞれ「前記項目値取得部は，ウィンドウハンドル又はＨＴＭＬデータを用いて項目値を取得しており，前記表示位置情報は，ウィンドウハンドルの値又はＨＴＭＬデータの前記連携時取得項目のタグの値である」とするという事項，前記事項と実質的に同一の構成を有するものとなっており，上記のとおり，本願発明１−５は，上記引用文献Ａ−Ｄに記載された発明に基づいて，当業者が容易に発明できたものではない。
　したがって，原査定を維持することはできない。
第８　むすび
　以上のとおり，本願発明１−５は，当業者が引用発明及び引用文献２−３に記載された技術に基づいて容易に発明をすることができたものではない。したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。