2024-700774

特許第７４４５２４６号発明「データ処理システム、データ処理方法、及びデータ処理プログラム」の特許異議申立事件について、次のとおり決定する。

結 論 特許第７４４５２４６号の特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔１～６〕、７、８について訂正することを認める。 特許第７４４５２４６号の請求項１～３、５～８に係る特許を維持する。 特許第７４４５２４６号の請求項４に係る特許についての特許異議の申立てを却下する。

理 由 第１ 手続の経緯 特許第７４４５２４６号の請求項１～８に係る特許についての出願は、令和５年７月２４日に出願され、令和６年２月２８日にその特許権の設定登録がされ、同年３月７日に特許掲載公報が発行された。本件特許異議の申立ての経緯は、次のとおりである。 令和 ６年 ８月１４日 ：特許異議申立人 大津理津子（以下、「申立人１」という。）による請求項１～８に係る特許に対する特許異議の申立て（以下、「異議申立て１」という。） 令和 ６年 ８月２６日 ：特許異議申立人 影山剛士（以下、「申立人２」という。）による請求項１～８に係る特許に対する特許異議の申立て（以下、「異議申立て２」という。） 令和 ６年 ９月 ４日 ：特許異議申立人 寺尾康典（以下、「申立人３」という。）による請求項１～８に係る特許に対する特許異議の申立て（以下、「異議申立て３」という。） 令和 ６年１２月１２日付け：取消理由通知書 令和 ７年 ２月１４日 ：特許権者による意見書の提出 令和 ７年 ４月 ３日付け：取消理由通知書（決定の予告） 令和 ７年 ４月 ７日 ：申立人３による上申書の提出 令和 ７年 ４月１０日 ：申立人３による上申書の提出 令和 ７年 ４月１１日 ：申立人２による上申書の提出 令和 ７年 ６月 ２日 ：特許権者による意見書及び訂正請求書の提出 令和 ７年 ７月 ４日 ：申立人２による意見書の提出 令和 ７年 ７月 ９日 ：申立人３による意見書の提出 なお、申立人１からは、期間を指定して意見書を提出する機会を与えたが、何らの応答もない。 第２ 訂正の適否 １ 訂正の内容 令和７年６月２日に特許権者が行った訂正請求は、本件特許の特許請求の範囲を、訂正請求書に添付した訂正特許請求の範囲のとおり、訂正後の請求項１～８について訂正することを求めるものであり（以下、本訂正請求書でする訂正を「本件訂正」という。）、その訂正の内容は、次のとおりである（下線は訂正箇所を示す。）。 （１）訂正事項１ 特許請求の範囲の請求項１を、以下のとおり訂正する。 「 複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定する権限設定部と、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する要求受信部と、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部と、 を備え、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、 ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり、 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、 前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 データ処理システム。」 （２）訂正事項２ 特許請求の範囲の請求項４を削除する。 （３）訂正事項３ 特許請求の範囲の請求項５を、以下のとおり訂正する。 「 前記管理用データベースは、現時点の情報として登録されているデータのデータベースを含む現在データベースと、現時点以降に更新される予定のデータのデータベースを含む予定データベースとを含み、 前記データ処理部は、前記予定データベースに、更新される予定の少なくとも１つのデータを登録し、前記更新時期データが示す前記更新する時期に、前記予定データベースに登録されている前記更新される予定の少なくとも１つのデータに基づいて、前記現在データベースを更新する、 請求項１又は２に記載のデータ処理システム。」 （４）訂正事項４ 特許請求の範囲の請求項７を、以下のとおり訂正する。 「 コンピュータが、 複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定し、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信し、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をし、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり、 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理し、 前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 データ処理方法。」 （５）訂正事項５ 特許請求の範囲の請求項８を、以下のとおり訂正する。 「 コンピュータに、 複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定する権限設定部と、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する要求受信部と、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部と、 を実現させ、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり、 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、 前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 データ処理プログラム。」 なお、訂正前の請求項２～６は、訂正事項１による訂正の対象である請求項１の記載を直接又は間接的に引用する関係にあるから、訂正事項１～訂正事項３に係る訂正は、一群の請求項１～６について請求されたものである。 訂正事項４に係る訂正前の請求項７、訂正事項５に係る訂正前の請求項８は、他の請求項と引用関係を有しない請求項である。 ２ 訂正の目的の適否、新規事項の有無、特許請求の範囲の拡張・変更の存否 （１）訂正事項１ 訂正事項１に係る請求項１についての訂正は、訂正前の「データ処理システム」について、「前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え」る旨を追加することにより、「データ処理システム」を限定し、さらに、訂正前の「データ処理システム」における「データ処理部」について、「前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする」との特定を追加することにより、「データ処理部」を具体的に特定するものであるから、特許法第１２０条の５第２項ただし書第１号に掲げる「特許請求の範囲の減縮」を目的とする訂正である。 そして、当該事項は本件明細書等に、 「【請求項４】 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、 前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 請求項１又は２に記載のデータ処理システム。」 「【００２７】 続いて、データ処理システム１００の詳細について説明する。データ処理システム１００は、記憶部１１０、権限設定部１２０、要求受信部１３０、更新管理部１４０、データ処理部１５０、通知設定部１６０、通知部１７０を備える。図２に示す各部は、例えば、記憶領域を用いたり、記憶領域に格納されたプログラムをプロセッサが実行したりすることにより実現することができる。」 「【００４６】 更新管理部１４０は、管理用データベース１０１に記憶される複数のデータに含まれる少なくとも１つのデータを更新する時期を示す更新時期データを管理する。」 「【００５７】 また、データ処理部１５０は、例えば、まず、予定データベースに更新内容データを登録し、所定のタイミング（例えば、更新時期データが示す更新時期）で、予定データベースに登録された更新内容データに基づいて、現在データベースに含まれるデータを更新してもよい。これにより、データ処理システム１００は、任意の更新時期で、データを更新することができる。」 という記載があるから、訂正事項１は、特許明細書等に記載した事項の範囲内でされた訂正である。 また、訂正事項１に係る請求項１についての訂正により、訂正後の請求項１に係る発明は、訂正前の請求項４に係る発明と同一となったから、カテゴリーや対象、目的を変更するものではなく、実質上特許請求の範囲を拡張し、又は変更するものでもない。 （２）訂正事項２ 訂正事項２は、訂正前の請求項４を削除する訂正であるから、特許法第１２０条の５第２項ただし書第１号に掲げる「特許請求の範囲の減縮」を目的とする訂正である。 また、訂正事項２は、特許明細書等に記載した事項の範囲内でされた訂正であり、かつ、カテゴリーや対象、目的を変更するものではなく、実質上特許請求の範囲を拡張し、又は変更するものでもない。 （３）訂正事項３ 訂正事項３は、訂正事項１及び訂正事項２による訂正に伴って、請求項５の引用請求項の引用形式の表現を訂正前の「請求項４」から「請求項１又は２」とすることで、請求項５が訂正により実質的に変更されない旨を明確に表現するための訂正である。このことから、訂正事項３は、訂正事項１及び訂正事項２に伴う訂正であり、特許法第１２０条の５第２項ただし書第１号に掲げる「特許請求の範囲の減縮」を目的とする訂正、又は、同条同項第３号に掲げる明瞭でない記載の釈明を目的とする訂正に該当するといえる。 また、訂正前の請求項４は「請求項１又は２」を引用する形式で記載されていたものであるところ、上記１（１）の訂正事項１により、訂正後の請求項１は訂正前の請求項４に相当するものとなったため、訂正事項１～３を併せて考慮すると、請求項５は訂正前後で実質的に変更されていない。 したがって、訂正事項３は、特許明細書等に記載した事項の範囲内でされた訂正であり、かつ、カテゴリーや対象、目的を変更するものではなく、実質上特許請求の範囲を拡張し、又は変更するものでもない。 （４）訂正事項４、５ 訂正事項４に係る請求項７についての訂正、及び訂正事項５に係る請求項８についての訂正は、特許請求の範囲の請求項７及び８について、上記１（１）で示した訂正事項１に係る請求項１についての訂正と同様の訂正を行うものであり、上記（１）で示したのと同様に、特許請求の範囲の減縮を目的とするものである。 また、訂正事項４に係る請求項７についての訂正、及び訂正事項５に係る請求項８についての訂正により、特許請求の範囲の請求項７及び８について追加した事項は、本件明細書の段落【００４６】、【００５７】に記載されているから、特許明細書等に記載した事項の範囲内でされた訂正であり、かつ、カテゴリーや対象、目的を変更するものではなく、実質上特許請求の範囲を拡張し、又は変更するものでもない。 ３ 独立特許要件について 本件においては、全ての請求項１～８について特許異議の申立てがなされているので、訂正事項１～５に関して、特許法第１２０条の５第９項で読み替えて準用する同法第１２６条第７項の独立特許要件は課されない。 ４ 小括 上記のとおり、本件訂正は、特許法第１２０条の５第２項ただし書第１号から第３号に掲げる事項を目的とするものであり、かつ、同条第９項で準用する同法第１２６条第５項及び第６項の規定に適合する。 したがって、特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔１～６〕、７、８について訂正することを認める。 第３ 訂正後の本件発明 上記第２のとおり、本件訂正は認められることから、本件特許の特許請求の範囲の記載は、令和７年６月２日に提出された訂正請求書に添付した訂正特許請求の範囲に記載された、次のとおりのものである。以下、本件特許の請求項１～８に係る発明（訂正後の特許請求の範囲の請求項１～８に記載された発明）を、それぞれ「本件発明１」～「本件発明８」という。 「【請求項１】 複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定する権限設定部と、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する要求受信部と、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部と、 を備え、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、 ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり、 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、 前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 データ処理システム。 【請求項２】 前記権限設定部は、前記ユーザの前記ユーザ端末を通じた操作に基づいて、前記複数の情報処理サービスシステムごとに異なる、前記権限データを設定する、請求項１に記載のデータ処理システム。 【請求項３】 前記要求受信部による前記データ処理要求の受信及び前記データ処理部による前記データ処理要求に基づく処理の少なくともいずれかを含む要通知処理に応じて、前記第１情報処理サービスシステムとは異なる第２情報処理サービスシステムに対し、前記要通知処理があった旨を通知する通知データを出力する通知部をさらに実現させる、請求項１又は２に記載のデータ処理システム。 【請求項４】（削除） 【請求項５】 前記管理用データベースは、現時点の情報として登録されているデータのデータベースを含む現在データベースと、現時点以降に更新される予定のデータのデータベースを含む予定データベースとを含み、 前記データ処理部は、前記予定データベースに、更新される予定の少なくとも１つのデータを登録し、前記更新時期データが示す前記更新する時期に、前記予定データベースに登録されている前記更新される予定の少なくとも１つのデータに基づいて、前記現在データベースを更新する、 請求項１又は２に記載のデータ処理システム。 【請求項６】 前記複数のデータは、複数の人事データを含み、 前記複数の情報処理サービスシステムのそれぞれは、前記ユーザ端末に、人事関連業務に関する情報処理サービスを提供する、 請求項１又は２に記載のデータ処理システム。 【請求項７】 コンピュータが、 複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定し、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信し、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をし、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり、 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理し、 前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 データ処理方法。 【請求項８】 コンピュータに、 複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定する権限設定部と、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する要求受信部と、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部と、 を実現させ、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり、 前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、 前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする、 データ処理プログラム。」 第４ 取消理由（決定の予告）の概要 当審が令和７年４月３日付けで特許権者に通知した取消理由（決定の予告）の要旨は、次のとおりである。 １ 取消理由１（新規性欠如） 請求項１、２、７、８に係る発明は、本件特許出願前に日本国内又は外国において、頒布された引用文献１に記載された発明であって、特許法第２９条第１項第３号の規定に違反してされたものであり、取り消されるべきものである。 ２ 取消理由２（進歩性欠如） 請求項１～３、６～８に係る発明は、本件特許出願前に日本国内又は外国において、頒布された引用文献１に記載された発明及び引用文献２に記載の技術的事項に基づいて、本件特許出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定に違反してされたものであり、取り消されるべきものである。なお、より具体的には以下のとおりである。 （１）請求項１～３、７、８に係る発明は、引用文献１に記載された発明に基づき、当業者が容易に発明をすることができたものである。 （２）本件発明６に係る発明は、引用文献１に記載された発明に基づき、または、引用文献１に記載された発明及び引用文献２に記載された技術的事項に基づき、当業者が容易に発明をすることができたものである。 引用文献１：米国特許公開公報第２０１２／０２３９６９９号明細書（異議申立て２の甲第１号証） 引用文献２：車井登、猪股順二，SaaSアプリケーションプラットフォームから見たアイデンテイティ管理，人工知能学会誌，２００９年７月１日，第２４巻，第４号，ｐ．５５２～５５８（異議申立て３の甲第４号証） 第５ 引用文献の記載、引用発明 １ 引用文献１（米国特許公開公報第２０１２／０２３９６９９号明細書、申立人２により提出された甲第１号証） （１）引用文献１に記載された事項 取消理由及び取消理由（決定の予告）で通知した引用文献１には、以下の事項が記載されている（下線は当審で付した。以下、同様。）。 「Abstract Shared data management in software-as-a-service platform may provide a common object data schema for one or more data objects and one or more data attributes associated with said one or more data objects stored in a master database. A plurality of applications may be enabled to be deployed dynamically on a platform and interoperate by sharing said data values stored in the master database. Data trading is enabled in which applications request permissions to read from or write to, or both, the master database, and in which the requests are mediated by granting or denying permissions.」 （当審訳： 要約 software-as-a-serviceプラットフォームにおける共有データ管理は、マスタデータベースに格納された1つ以上のデータオブジェクトおよび前記1つ以上のデータオブジェクトに関連付けられた1つ以上のデータ属性に対して、共通オブジェクトデータスキーマを提供し得る。複数のアプリケーションを、プラットフォーム上に動的に展開し、マスタデータベースに格納されたデータバリューを共有することによって相互運用できるようにしてもよい。データの取引は、アプリケーションがマスタデータベースに対して読み取りまたは書き込みを行う権限を要求し、権限の付与または拒否を行うことによって行われる。） 「[0022] Shared data management (SDM) is disclosed in one embodiment that enables platform-mediated data sharing among applications, for example, in Software-as-a-Service platform. Software-as-a-Service or SaaS refers to providing the use of software or application as a service on demand, for instance, by subscription, e.g., in a “pay-as-you-go” model. A customer or a user subscribes for the use of a software application, for instance, as needed by the customer. Typically, an application being provided as a service is resident in a remote platform which a customer may access via a network (e.g., the Internet via a browser or the like interface). The remote platform may include a number of different applications. For instance, a provider of SaaS provides a computing platform and resources for running applications. The applications need not have been developed by the provider, but may have been deployed and set up on the platform by independent software vendors. SDM of the present disclosure provides a common database system, a common data object schema or model, and logic or algorithms for enabling those applications to share data. [0023] FIG.1 is a block diagram showing system architecture in one embodiment of the present disclosure. SDM 102 may include common object model or schema that defines the format for different data attributes 106 for use and sharing among a plurality of applications on a SaaS platform 104. The SaaS platform 104 hosts applications (or services). Take, for example, a SaaS platform 104 that hosts applications used by a municipal government entity. A municipal government entity may employ multiple applications or software as part of its information technology (IT) system, for instance, a tax department application 108, a building department application 110, financials application 112. Each of the application may have and use a separate database (114, 116, 118, respectively) to write and read data needed for the workings of the application. SDM 102 of the present disclosure allows for those applications (e.g., 108, 110, 112) to share the data that may be common to two or more of the applications (e.g., 108, 110, 112).」 （当審訳： [0022] 共有データ管理(SDM)は、例えば、Software-as-a-Serviceプラットフォームにおいて、アプリケーション間でのプラットフォームを介したデータ共有を可能にする一実施形態において開示される。Software-as-a-Service(SaaS)とは、ソフトウェアやアプリケーションをオンデマンドで、例えば「従量課金制」モデルなどのサブスクリプション方式で提供することを指す。顧客またはユーザは、たとえば、顧客の必要に応じて、ソフトウェアアプリケーションの使用をサブスクライブする。典型的には、サービスとして提供されるアプリケーションは、顧客がネットワーク(例えば、ブラウザまたは類似のインタフェースを介したインターネット)を介してアクセスすることができる遠隔プラットフォーム上で実行される。リモートプラットフォームには、さまざまなアプリケーションが含まれ得る。たとえば、SaaSのプロバイダは、アプリケーションを実行するためのコンピューティングプラットフォームとリソースを提供する。アプリケーションは、プロバイダによって開発されたものでなくてもよく、独立系ソフトウェアベンダによってプラットフォームに展開およびセットアップされているものであってもよい。本開示のSDMは、共通データベースシステム、共通データオブジェクトスキーマまたはモデル、およびそれらのアプリケーションがデータを共有できるようにするためのロジックまたはアルゴリズムを提供する。 [0023] 図1は、本開示の一実施形態におけるシステムアーキテクチャを示すブロック図である。SDM102は、SaaSプラットフォーム104上の複数のアプリケーション間で使用および共有するための異なるデータ属性106のフォーマットを定義する共通のオブジェクトモデルまたはスキーマを含んでもよい。SaaSプラットフォーム104は、アプリケーション(またはサービス)をホストする。例えば、地方自治体のエンティティによって使用されるアプリケーションをホストするSaaS プラットフォーム104を例にとってみる。地方自治体は、その情報技術(IT)システムの一部として、例えば、税務部門アプリケーション108、建築部門アプリケーション110、財務アプリケーション112など、複数のアプリケーションまたはソフトウェアを採用することができる。各アプリケーションは、アプリケーションの動作に必要なデータの書き込みおよび読出しを行うために、別個のデータベース(それぞれ114、116、118)を有し、使用してもよい。本開示のSDM102は、これらのアプリケーション(例えば、108、110、112)が、2つ以上のアプリケーション(例えば、108、110、112)に共通し得るデータを共有することを可能にする。） 「[0027] A user (e.g., an administrator of municipal government) may subscribe to a set of applications hosted on SaaS platform 104. A set of applications that a user subscribes to may be referred to as the “subscription set.” The SDM 102 of the present disclosure in one embodiment allows the applications in a subscription set to work cooperatively without being directly aware of each other's presence. For instance, the applications need not directly communicate with each other, hence, the application need not be tightly-coupled. Communications and interactions among applications in a subscription set are mediated by SDM 102, and therefore, the applications are loosely-coupled. [0028] Data Sharing in SDM 102 may be accomplished, for example, by analyzing the data used in the SaaS platform 104 and identifying the data objects commonly used by the applications hosted on the platform 104. For instance, in a municipal government information technology (IT) system, government data systems may be analyzed and data objects common to the government applications may be identified. The identified common data objects used by the applications may be stored and maintained by SDM 102 in a database system, using a generated object schema or model for those objects. In an IT environment (e.g., of one or more municipal governments), it is possible that there may be multiple copies of the same object from one or more applications. Also, there may be conflicting information about the object from different applications that read and/or write values to the object. SDM 102 may store the master copy of the objects (also referred to as authoritative information or data). Thus, SDM 102 may take responsibility for common data, making it easier to create new applications that can use the data and making the platform more sticky, that is, making it easier to keep the applications and their users on the platform. [0029] Common data objects managed by the SDM may be viewed as “Master Data”. The data is to be authoritative, e.g., there are no duplicates and/or full auditable history may be made available. Common data objects may be high value information that an organization uses repeatedly across many business processes. The database system used in the SDM to store the common data objects may offer data sharing functionality for SaaS with features such as data stewardship which prevents inadvertent creation of duplicate parties and products, and eliminates any duplicates by using sophisticated matching techniques, point-in-time history which includes a full audit database that contains the full modification histories of all business objects so that rich set of query options are available for the audit database, track source of data which keeps track of the source of all data and when it was added, and rules of visibility which allows administrators to define what elements and sub-elements users and user groups can see based on defined constraints.」 （当審訳： [0027] ユーザ(例えば、地方自治体の管理者)は、SaaSプラットフォーム104 上でホストされるアプリケーションのセットをサブスクライブすることができる。ユーザがサブスクライブするアプリケーションのセットは、「サブスクリプションセット」と呼ばれてもよい。本開示のSDM102 は、一実施形態において、サブスクリプションセット内のアプリケーションが、互いの存在を直接認識することなく、協調的に動作することを可能にしている。たとえば、アプリケーションは互いに直接通信する必要がないため、アプリケーションを緊密に結合する必要はない。サブスクリプションセット内のアプリケーション間の通信および相互作用は、SDM102によって媒介されるため、アプリケーションは疎結合である。 [0028] SDM102におけるデータ共有は、例えば、SaaSプラットフォーム104において使用されるデータを分析し、プラットフォーム104上でホストされるアプリケーションによって共通に使用されるデータオブジェクトを識別することによって達成され得る。たとえば、地方自治体の情報技術(IT)システムでは、政府のデータシステムを分析し、政府のアプリケーションに共通するデータオブジェクトを特定できる。アプリケーションによって使用される識別された共通データオブジェクトは、それらのオブジェクトに対して生成されたオブジェクトスキーマまたはモデルを使用して、SDM102によってデータベースシステム内に格納され、維持され得る。IT環境(たとえば、1つ以上の地方自治体)では、複数のアプリケーションにおいて同じオブジェクトの複数のコピーが存在する可能性があり得る。また、オブジェクトに対して値を読み書きする異なるアプリケーションから、オブジェクトに関する矛盾した情報が提供されることがあり得る。SDM102は、オブジェクトのマスターコピー(権威ある信頼し得る情報またはデータとも呼ばれる)を格納しうる。従って、SDM102は、共通データに責任を負い、データを使用することができる新しいアプリケーションを作成することを容易にし、プラットフォームをより柔軟かつ強固なものにする、すなわち、アプリケーション及びそのユーザをプラットフォーム上に維持しやすくすることができる。 [0029] SDMが管理する共通のデータオブジェクトは、「マスタデータ」と見なすことができる。このデータは信頼できるものでなければならず、たとえば、重複がないこと、および／または検証可能な完全な履歴が利用可能であることが求められる。共通データオブジェクトは、組織が多くのビジネスプロセスにわたって繰り返し使用する、価値の高い情報である。共通データオブジェクトを格納するためにSDMで使用されるデータベースシステムは、SaaS向けのデータ共有機能を提供することができ、この機能には、データスチュワードシップなどの機能があり、不注意による当事者や製品の重複作成を防止し、高度なマッチング技術を使用して重複を排除すること、ポイントインタイム履歴（すべてのビジネスオブジェクトの完全な変更履歴を含む完全な監査データベースを含み、監査データベースで豊富なクエリオプションを利用できる）、データソースの追跡（すべてのデータのソースとそれがいつ追加されたかを追跡）、可視性のルール（管理者が、定義された制約に基づいて、ユーザやユーザグループがどの要素やサブ要素を見ることができるかを定義できる）などが含まれる。） 「[0031] An example of a database system may be master data management (MDM) system from International Business Machines Corporation (IBM), Armonk, N.Y. SDM 102 in one embodiment may be implemented with one or more MDM systems. [0032] An MDM system manages master data, for example, manages objects and attributes; defines data governance procedures such as conflict resolution, data import and data integration; defines transactions over the mater data; and defines access control to objects and attributes. An MDM server may ensure consistent master information across transactional and analytical systems; address issues such as data quality and consistency proactively rather than “after the fact” in the data warehouse; decouple master information from individual applications; become a central, application independent resource; and simplify ongoing integration tasks and new application development. An MDM system may be implemented in “consolidation” style in which data is periodically replicated to the MDM server; “registry” style in which the MDM server know where to find the data, e.g., by reference; “transactional hub” style in which MDM server becomes the system of record for master data, for example, for appropriately architected applications.」 （当審訳： [0031] データベースシステムの例は、ニューヨーク州アーモンクのインターナショナルビジネスマシンズコーポレーション(IBM)のマスタデータ管理(MDM)システムであり得る。一実施形態におけるSDM102は、1つ以上のMDMシステムを用いて実装され得る。 [0032] MDMシステムは、マスタデータを管理し、例えば、オブジェクトおよび属性を管理し、具体的には、競合解決、データインポート、データ統合などのデータガバナンス手順を定義すること、マテリアルデータに対するトランザクションを定義すること、オブジェクトと属性へのアクセスコントロールを定義することが含まれる。MDMサーバは、トランザクションシステムと分析システムにわたって一貫したマスタ情報を確保し、データウェアハウスで「事後的」にではなく、データ品質や一貫性などの問題に先取りして対処し、個々のアプリケーションからマスタ情報を切り離し、アプリケーションに依存しない中央リソースとなり、継続的な統合タスクと新しいアプリケーション開発を簡素化することができる。MDMシステムは、データが定期的にMDMサーバに複製される「コンソリデーション」スタイル、MDMサーバが参照などによってデータを見つける場所を知っている「レジストリ」スタイル、MDMサーバが例えば適切に設計されたアプリケーションのマスタデータの記録システムになる「トランザクションハブ」スタイルで実装されることがある。） 「[0037] FIG.2 is a flow diagram illustrating a method of shared data management in one embodiment of the present disclosure. At 202, SDM data model (e.g., FIG. 1 106) may be published on a SaaS platform. For instance, a platform administrator may publish the data model for applications to view. For example, an interface or API may be made available to display data model and schema, e.g., data structure of data object and attributes. In another aspect, publishing may include sending notifications to the applications. A data model, as described above, refers to data object schema (or data structure format) for managing, storing and maintaining data. At 204, application developers may deploy one or more applications on the SaaS platform, with offers and requests on the published SDM data model. An offer refers to asking for permission to write selected data associated with one or more attributes of the data model to a shared database. A request refers to asking to be able to read or access selected data associated with one or more attributes of the data model from the shared database. For examples, application developer or vendor may study the data object schema (model) and application programming interface (API) published by SDM, then decide which shared objects and attributes will be accessed by the application. Data object schema (model) and application programming interface (API) may be made available through ISV toolkit package. ISV may define the trade for the application. Trade refers to offers and requests. For instance, each object or attribute may be defined with constraints of read or update access. ISV may register the list of trades for the application. In the applications, an action handling mechanism may be provided to enable or disable functions in the application based on the attribute permissions granted.」 （当審訳： [0037] 図2 は、本開示の一実施形態における共有データ管理方法を示すフロー図である。202 において、SDMデータモデル（例えば、図1の106）は、SaaSプラットフォーム上で公開されてもよい。たとえば、プラットフォーム管理者は、アプリケーションが表示できるようにデータモデルを公開してもよい。たとえば、データモデルとスキーマ（たとえば、データオブジェクトと属性のデータ構造）を表示するためのインタフェースまたはAPIを利用できるようにしてもよい。別の態様では、公開は、アプリケーションに通知を送信することを含む場合がある。データモデルとは、上述したように、データを管理、保存、維持するためのデータオブジェクトスキーマ（またはデータ構造フォーマット）を指す。ステップ204において、アプリケーション開発者は、SaaSプラットフォーム上に1つまたは複数のアプリケーションを展開することができ、公開されたSDMデータモデルにオファーとリクエストを行うことができる。オファーとは、データモデルの1つ以上の属性に関連付けられた選択されたデータを共有データベースに書き込む許可を求めることを指す。リクエストとは、データモデルの1つ以上の属性に関連付けられた選択されたデータを共有データベースから読み取るかアクセスできるようにすることを求めることを指す。たとえば、アプリケーション開発者やベンダーは、SDM が公開しているデータオブジェクトスキーマ（モデル）とアプリケーションプログラミングインタフェース（API）を調べ、アプリケーションでアクセスする共有オブジェクトと属性を決定することができる。データオブジェクトスキーマ（モデル）とアプリケーションプログラミングインタフェース（API）は、ISVツールキットパッケージを通じて使用できるようにすることができる。ISVはアプリケーションの取引を定義することができる。取引とは、オファーとリクエストを指す。例えば、各オブジェクトや属性は、読み取りや更新アクセスの制約を定義することができる。ISVは、アプリケーションのために取引のリストを登録することができる。アプリケーションでは、付与された属性権限に基づいてアプリケーションの機能を有効または無効にするアクション処理メカニズムが提供されてもよい。） 「[0040] At 208, a user or customer of the applications (e.g., an IT administrator on the user side or customer side) may subscribe to the use of the applications on the SaaS platform, for example, from a list contained in the offering catalog. A subscribing user may grant permissions to the offers and/or requests. Thus, a user may select applications, decide which application features to use, and define a shared data access policy. A policy may be a high level statement regarding which departments will control the shared objects. Other policies may be specified. The user (e.g., software customer's IT administrator) may designate who will access the application. For instance, if the user is an IT administrator of a municipal government, that IT administrator may designate what users or user groups in the municipal government may access the application. The user (e.g., an IT administrator) may use a tool such as shared data editor to specify shared object permissions. The statuses of permissions (granted or denied) associated with the shared data objects are stored, for example, in an operational database. SDM also may send event notifications (e.g., broadcast) about the new permissions to all trading applications.」 （当審訳： [0040] ステップ208では、アプリケーションのユーザまたは顧客(ユーザ側または顧客側のIT管理者など)は、たとえば、オファリングカタログに含まれるリストから、SaaSプラットフォーム上のアプリケーションの使用をサブスクライブできる。サブスクライブするユーザは、アプリケーションに対し、オファーおよび/またはリクエストの権限を付与できる。したがって、ユーザはアプリケーションを選択し、使用するアプリケーション機能を決定し、共有データへのアクセスポリシーを定義できる。ポリシーは、共有オブジェクトを制御する部門に関する高レベルのステートメントである。他のポリシーを指定することもできる。ユーザ(ソフトウェアカスタマーのIT管理者など)は、アプリケーションにアクセスできるユーザを指定できる。たとえば、ユーザが市役所のIT管理者である場合、そのIT管理者は、市役所内のどのユーザまたはユーザグループがアプリケーションにアクセスできるかを指定できる。ユーザ(例えばIT管理者など)は、共有データエディタなどのツールを使用して、共有オブジェクトに対する権限を指定できる。共有データオブジェクトに関連付けられた権限のステータス(付与または拒否)は、たとえば運用データベースに保存される。SDMは、新たに設定された権限に関するイベント通知(例:ブロードキャスト)をすべての取引アプリケーションに送信することもできる。） 「[0041] Thus, the customer (user of the applications) may add an application to a subscription set. In addition, the customer may remove an application from the subscription set, or modify permissions for applications in the subscription set. Permissions may be granted/denied as follows: accept an attribute update offer; decline an attribute update offer; grant an attribute access request; deny an attribute access request. After permissions are determined by the customer, applications are notified of the permissions. This may occur at any time, for instance, during configuration or deployment of the application, and/or during operation of the application (e.g., when the application is running on the platform to provide its services). During operation of an application, it may update the attribute corresponding to an accepted offer in the SDM. The application may read the attribute value from SDM. If an attribute update offer is declined, the application may not update or write to SDM. In this case, the application's functionality may be modified so that updating or writing of the data associated with the update offer is disabled. Once attribute access (read) request is granted, an application may read from SDM. Once attribute access (read) request is denied, an application may not read that data in SDM associated with the denied request. In one embodiment, the read requests may be either a mandatory read or optional read. That is, if an application needs to read the data associated with the read request in order to perform its functions, the request for that data is considered as mandatory. If an application can function without the data, the read request for that data is considered as optional. In the event that a mandatory request is denied, and for instance, the denied application could not obtain the data other than through the SDM, the application may be in disabled state, since it cannot obtain the data needed to function. Alternatively, the application may run in a different mode without the data. In the event an optional request is denied, the application may still provide its functionalities.」 （当審訳： [0041] したがって、顧客(アプリケーションのユーザ)は、サブスクリプションセットにアプリケーションを追加することができる。さらに、顧客はサブスクリプションセット（SaaSプラットフォーム上で展開されたSaaSアプリケーションのまとまり）からアプリケーションを削除したり、サブスクリプションセット内のアプリケーションの権限を変更したりすることができる。権限は次のように付与/拒否できる。アプリケーションからのデータ属性の更新オファーを受け入れる。アプリケーションからのデータ属性の更新オファーを拒否する。データ属性の読み取りリクエストを許可する。データ属性の読み取りリクエストを拒否する。顧客が権限を決定すると、アプリケーションにその権限が通知される。これは、例えば、アプリケーションの構成中または配置中、および/またはアプリケーションの操作中(例えば、アプリケーションがそのサービスを提供するためにプラットフォーム上で実行されている場合)に、いつでも起こり得る。アプリケーションの操作中に、SDMで受け入れられたオファーに対応する属性が更新される場合がある。アプリケーションは、SDMから属性値を読み取ることができる。属性更新オファーが拒否された場合、アプリケーションはSDMに更新または書き込みをしない可能性があり得る。この場合、更新オファーに関連付けられているデータの更新または書き込みを無効にするように、アプリケーションの機能が変更され得る。属性アクセス(読み取り)要求が許可されると、アプリケーションはSDMから読み取ることができるようになる。属性アクセス(読み取り)要求が拒否されると、アプリケーションは拒否された要求に関連付けられているSDM内のデータを読み取ることができなくなる。一実施形態では、読取り要求は、必須読取りまたは任意読取りのいずれかであり得る。つまり、アプリケーションがその機能を実行するために読み取り要求に関連付けられたデータを読み取る必要がある場合、そのデータに対する要求は必須と見なされる。アプリケーションがデータなしで機能できる場合、そのデータの読み取り要求は任意と見なされる。必須の要求が拒否された場合、たとえば、拒否されたアプリケーションがSDM以外でデータを取得できなかった場合、アプリケーションは機能するために必要なデータを取得できないため、無効状態になる可能性があり得る。または、データを使わずに別のモードでアプリケーションを実行することもできる。任意のリクエストが拒否された場合においては、アプリケーションはその機能を提供できる。） 「[0045] Applications (e.g., 408, 410, 412) send trade requests (i.e., data offers and requests) to SDM 402. The trade requests may be stored in an SDM operational database 406. A user of the applications or the like or an SDM administrator may use a tool, for example, Shared Data Editor 420 to view or otherwise identify trades from selected applications dynamically, and also grant permissions to the applications dynamically. Permissions may be granted to applications, for example, to read, to write, or to both read and write the data specified in the trade. Providing permissions may be automated. In one embodiment, the granted trade requests are stored in SDM operational database 406. SDM 402 notifies applications (e.g., 408, 410, 412) about the permissions set. In response, applications (e.g., 408, 410, 412) may adapt their functionality to match the granted permissions. For example, one or more functions may be disabled if the application is not given access to requested data. SDM 402 notifies applications when requests are no longer viable, e.g., because associated offers are removed or disabled.」 （当審訳： [0045]アプリケーション(例えば、408、410、412)は、取引要求(すなわち、オファーおよびリクエスト)をSDM402に送る。取引要求は、SDM運用データベース406に格納され得る。アプリケーションのユーザ又はSDM管理者は、ツール、例えば、共有データエディタ420を使用して、選択されたアプリケーションからの取引を動的に表示又は識別し、また、アプリケーションに動的に権限を付与することができる。たとえば、取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可をアプリケーションに付与できる。権限の付与は自動化できる。一実施形態では、付与された取引要求は、SDM運用データベース406に格納される。SDM402は、設定された権限をアプリケーション(408、410、412など)に通知する。これに応答して、アプリケーション(例:408、410、412)は、付与された権限に一致するように機能を適合させることができる。たとえば、アプリケーションからリクエストを受けたデータへのアクセス権が付与されていない場合、1つ以上の機能を無効にすることができる。SDM402は、関連するオファーが削除または無効化されるなど、取引要求が実行可能でなくなった場合、アプリケーションに通知する。） 「[0046] FIG.5 is a diagram showing an example of shared data editor interface in one embodiment of the present disclosure. Shared data editor 506 may include a user interface, for instance, for requesting data reads 510 and for offering data writes 508. In the example shown in FIG.5, a subscription set may include applications for parking lot monitor 512, parking 514 and tax 516. A municipal government, for instance, may subscribe to those applications installed or deployed on a SaaS platform. A subscription set may include other applications. The applications 512, 514, 516 (or developers or administrators of those applications) may make requests to read data defined in a data object model 518 using the interface 510. Similar, the applications 512, 514, 516 (or developers or administrators of those applications) may make offers to write to the data defined in the data object model 520 using the interface 508. For instance, a parking lot monitor application developer or administrator or the like may select the “parking lot monitor” application button and then select one or more data objects in the data object model. The editor 506 shows the requests and offers by dotted lines. A subscriber (e.g., a municipal government IT administrator) may view or otherwise identify the data requests and offers by the applications on the editor 506 (e.g., the dotted lines on the interfaces 508, 510 show which applications have made requests and/or offers). The subscriber then may grant or deny those request and/or offers, for example, by clicking on those links. The editor 506 may show the granted permissions by solid lines (e.g., once granted, the dotted lines change to solid lines). The editor 506 communicates the granted permissions to SDM 502, and SDM 502 stores the granted/denied permissions in a database or storage 504.」 （当審訳： [0046] 図5は、本開示における共有データエディタインタフェースの一実施形態を示す図である。共有データエディタ506は、例えば、データ読出し510またはデータ書き込み508をリクエストするためのユーザインタフェースを含んでもよい。図5に示す例では、サブスクリプションセットは、駐車場モニタ512、駐車場514 および税金516のアプリケーションを含み得る。たとえば、地方自治体は、SaaSプラットフォームにインストールまたは展開されたアプリケーションをサブスクライブできる。サブスクリプションセットには、他のアプリケーションが含まれる場合がある。アプリケーション512、514、516(またはこれらのアプリケーションの開発者または管理者)は、インタフェース510を使用して、データオブジェクトモデル518で定義されたデータを読み取るリクエストを行うことができる。同様に、アプリケーション512、514、516(またはそれらのアプリケーションの開発者もしくは管理者)は、インタフェース508を使用して、データオブジェクトモデル520で定義されたデータへの書き込みをオファーすることができる。たとえば、駐車場モニタプリケーションの開発者や管理者などは、「駐車場モニタ」アプリケーションボタンを選択してから、データオブジェクトモデル内の1つ以上のデータオブジェクトを選択できる。エディタ506は、リクエストおよびオファーを点線で表示する。サブスクライバ(例えば、地方自治体のIT管理者)は、エディタ506上のアプリケーションによるデータリクエストおよびオファーを表示または識別することができる(例えば、インタフェース508、510上の点線は、どのアプリケーションがリクエストおよび/またはオファーを行ったかを示す)。サブスクライバは、例えば、これらのリンクをクリックすることにより、これらのリクエストおよび/またはオファーを許可または拒否することができます。エディタ506は、付与された権限を実線で表示しうる(例えば、一旦付与されると、点線は実線に変わる)。エディタ506は、付与された権限をSDM502に伝達し、SDM502は、付与された/拒否された権限をデータベースまたはストレージ504に格納する。） 「[0047] FIG.6 shows examples of data objects in shared data management (SDM) in one embodiment of the present disclosure. Examples of data objects may include data associated with land parcel that describe basic unit of land and accompanying structures managed by municipal government. Such data may be used by various applications, for example, employed by municipal governments. Land parcel shared objects 602 may include data such as parcel identifier (ID) such section-block-lot (SBL) number, owner name, owner address, tax status such as whether current or delinquent, registered vehicles such as a list of vehicles associated with this parcel, and others. The data may be used by one or more applications, for example, tax application 604 and parking lot management application 606. [0048] A tax application 604, for example, may keep track of tax bills and payments and needs mandatory read access to ID, Owner Name, and Owner address. All read requests may be mandatory and if denied, application may not be able to function. A tax application 604 may send an offer to update Tax Status object in the land parcel shared objects 602. In one embodiment, all update offers may be optional. In one aspect, even if offer is not accepted, application may be able to function since for instance, each application has its own database. [0049] A parking lot management application 606 may be used to manage parking permits for town-owned parking lots. This application 606 may require optional read access to Tax Status and mandatory read access to parcel ID, Owner Name and Owner Address. If the read request is granted, Tax Status may be used to deny parking permits to delinquent residents. If not granted, the application still may operate without the data. This application may also offer to update Registered Vehicles object in the land parcel shared objects 602. The value of this attribute may be useful for other applications as well.」 （当審訳： [0047] 図6は、本開示の一実施形態における共有データ管理(SDM)におけるデータオブジェクトの例を示す。データオブジェクトの例としては、地方自治体が管理する土地の基本単位と付随する構造物を記述する土地区画に関連付けられたデータが含まれる。このようなデータは、例えば、地方自治体によって採用されている様々なアプリケーションによって使用され得る。土地区画共有オブジェクト602は、区画識別子(ID)、区画ブロックロット(SBL)番号、所有者名、所有者の住所、現在か滞納中かのような納税状態、この区画に関連する車両のリストのような登録車両などのデータを含み得る。それらのデータは、1つ以上のアプリケーション、例えば、税務アプリケーション604および駐車場管理アプリケーション606によって使用され得る。 [0048] 例えば、税務アプリケーション604は、税金の請求書および支払いを追跡することができ、ID、所有者名、および所有者の住所への強制的な読み取りアクセスを必要とする。すべての読み取りリクエストは必須であり、拒否された場合、アプリケーションが機能しなくなる可能性がある。税務アプリケーション604は、土地区画共有オブジェクト602内の税務ステータスオブジェクトを更新するためのオファーを送信し得る。一実施形態では、すべての更新オファーを任意とすることができる。ある態様では、たとえオファーが受け入れられなかったとしても、例えば、各アプリケーションがそれ自身のデータベースを持っているので、そのアプリケーションは機能し得る。 [0049] 駐車場管理アプリケーション606を使用して、町有駐車場の駐車許可証を管理することができる。このアプリケーション606は、納税ステータスへの任意の読み取りアクセスと、区画ID、所有者名、および所有者の住所への必須の読み取りアクセスを必要とする場合がある。読み取りリクエストが許可された場合、納税ステータスを使用して、滞納している居住者への駐車許可を拒否することができる。許可されない場合でも、アプリケーションは当該データなしで動作し得る。このアプリケーションは、土地区画共有オブジェクト602内の登録車両オブジェクトを更新することも提案してもよい。この属性の値は、他のアプリケーションにも役立つ場合があり得る。） 「[0050] FIG.7 is a flow diagram illustrating a method of dynamic data trading among applications in one embodiment vie the SDM of the present disclosure. At 702, one or more applications send trade requests to SDM, trade requests may be offers (offer to update specified data), requests (requests to read specified data) and/or withdrawals (request to withdraw from offer or request). Such trade requests may be made by the applications using a shared data editor and its interface (e.g., shown in FIG.5). The requests may be made graphically by selecting the data objects. At 704, SDM receives the trade requests and dynamically may grant or deny permissions to data trade requests, for instance, also via the shared editor. An SDM administrator may view the trade requests via the shared data editor and grant/deny permissions via the shared data editor. In another embodiment, this step may be fully automated. At 706, SDM records the granted trade requests in SDM operational database. At 708, SDM notifies the application of the updated permissions. At 710, applications run their functions according to the granted permission. [0051] In one embodiment, there may be a plurality of user groups using the SDM of the present disclosure. For example, a platform administrator may design and publish shared object schema of SDM on SaaS, and maintain the application catalog. An independent software vendor (ISV) may create applications that access SDM and deploy on the SaaS. A customer (user) may subscribe to those applications. [0052] The SDM on SaaS may also include a plurality of user interfaces. For example, a platform administrator user interfaces may be provided to manage the application catalog, for example, add, update and remove ISV applications in an integrated catalog. ISV user interfaces may be provided for submitting application to the catalog, providing application user interface and taking input from user and storing data in private databases. Customer business manager user interfaces may be provided to allow users to search for list of applications deployed on SaaS, e.g., with description of those applications. Customer IT administrator user interfaces may be provided for a user to configure application permissions to shared data, and to manage users, groups and roles. In addition, each application deployed on SaaS may include its own user interface. [0053] An ISV thus may develop and register applications on SaaS. A platform administrator may add new application to a catalog and remove applications from the catalog. A customer IT administrator may add an application to a subscription set, remove an application from the subscription set, modify permissions for applications in the subscription set. The applications in the subscription set may interact by sharing the data in SDM according to the permissions.」 （当審訳： [0050] 図7は、本開示のSDMを経由した一実施形態におけるアプリケーション間の動的なデータ取引の方法を示すフロー図である。ステップ702では、1つ以上のアプリケーションがSDMに取引要求を送信し、取引要求は、オファー(特定のデータの更新のオファー)、リクエスト(特定のデータを読み取るリクエスト)、および/または撤回(オファーまたはリクエストの撤回)であり得る。このような取引要求は、共有データエディタとそのインタフェース(例えば、図5に示す)を使用しアプリケーションによって行うことができる。取引要求は、データオブジェクトを選択することによってグラフィカルに行うことができる。ステップ704では、SDMは取引要求を受信し、たとえば共有エディタを介して、データ取引要求への権限を動的に付与または拒否できる。SDM管理者は、共有データエディタを介して取引要求を表示し、共有データエディタを介して権限を付与/拒否することができる。別の実施形態では、このステップは完全に自動化されてもよい。ステップ706では、SDMは付与された取引要求をSDM運用データベースに記録する。ステップ708で、SDMは更新されたアクセス許可をアプリケーションに通知する。ステップ710では、アプリケーションは付与された権限に従って機能を実行する。 [0051] 一実施形態では、本開示のSDMを使用する複数のユーザグループが存在することができる。たとえば、プラットフォーム管理者は、SaaS上のSDMの共有オブジェクトスキーマを設計および公開し、アプリケーションカタログを保守できる。独立系ソフトウェアベンダ(ISV)は、SDMにアクセスしてSaaSに展開するアプリケーションを作成できる。顧客(ユーザ)は、これらのアプリケーションをサブスクライブできる。 [0052] SaaS上のSDMは、複数のユーザインタフェースを含んでもよい。たとえば、統合カタログ内のISVアプリケーションの追加、更新、削除など、アプリケーションカタログを管理するために、プラットフォーム管理者のユーザインタフェースが提供される場合があり得る。ISVユーザインタフェースは、アプリケーションをカタログに送信し、アプリケーションユーザインタフェースを提供し、ユーザから入力を取得し、プライベートデータベースにデータを格納するために提供できる。顧客業務管理のユーザインタフェースは、ユーザがSaaS に展開されたアプリケーションのリストを、例えば、それらのアプリケーションの説明とともに検索できるようにするために提供されてもよい。顧客のIT管理者のユーザインタフェースは、ユーザが共有データに対するアプリケーションのアクセス許可を構成し、ユーザグループ、およびロールを管理するために提供される場合があり得る。さらに、SaaSに展開された各アプリケーションには、独自のユーザインタフェースが含まれている場合があり得る。 [0053] このように、ISV（independent software vendors（SaaSアプリケーションの開発者））はSaaS上でアプリケーションを開発し、登録することができる。プラットフォーム管理者は、カタログ（サブスクリプションセットに追加可能なSaaSアプリケーションの一覧）に新しいアプリケーションを追加したり、カタログからアプリケーションを削除したりできる。顧客のIT管理者は、サブスクリプションセットにアプリケーションを追加したり、サブスクリプションセットからアプリケーションを削除したり、サブスクリプションセット内のアプリケーションの権限を変更したりできる。サブスクリプションセット内のアプリケーションは、権限に従ってSDM内のデータを共有することで相互作用することができる。） 「[0054] FIG.8 is a diagram illustrating shared data management in one embodiment of the present disclosure. In one embodiment, all possible shared object attributes that an application may request are specified when the application is developed. The application vendors 806 may specify all commonly used attributes and all attributes that could be consumed from the SDM 802 by their applications 804, respectively. New applications 804 are then added to the subscription set. The applications 804 send to SDM 802 offers and request. A platform administrator 808 reviews the offers and requests, and updates configuration in SDM 802. SDM 802 allows those applications whose offers have been accepted to publish or update data, and allows applications whose requests have been accepted to read SDM data.」 （当審訳： [0054] 図8は、本開示の一実施形態における共有データ管理を示す図である。一実施形態では、アプリケーションがリクエストし得るすべての可能な共有オブジェクト属性は、アプリケーションが開発されるときに指定される。アプリケーションベンダー806は、一般的に使用されるすべての属性、及び、そのアプリケーション804がSDM802から受け取って使用する可能性のあるすべての属性をそれぞれ指定することができる。新しいアプリケーション804がサブスクリプションセットに追加されると、アプリケーション804は、SDM802にオファーおよびリクエストを送る。プラットフォーム管理者808は、オファーおよびリクエストを検討し、SDM802の構成を更新する。SDM802は、オファーが許可されたアプリケーションに対し、データの書き込みまたは更新の権限を付与し、リクエストが許可されたアプリケーションに対しデータの読み取りの権限を付与する。） 「[0058] FIG.10 is a diagram illustrating data permission architecture in one embodiment of the present disclosure. For example, shared objects may include parcel object 1002, citizen object 1004 and building object 1006. The parcel object 1002 may have attributes such as SBL 1008, acreage 1010, and school district 1012. The citizen object 1004 may include attributes such as address 1014, name 1016, and age 1018. The building object 1006 may include attributes such as address 1020 and name 1022. A subscription set may include applications, for example, tax application 1024, assessor application 1026, and parking application 1028. Each application may have its permissions as established according to the method and/or system of the present disclosure. For example, applications 1024, 1026, 1028 may have sent to SDM, requests (for read) and offers (to write or update data) for specific data objects or attributes of data objects, shown as R and U, respectively. The applications 1024, 1026, 1028 may have been granted or denied those requests and offers, for instance as shown as solid circle or dotted circle.」 （当審訳： [0058] 図10は、本開示の1つの実施形態におけるデータ許可アーキテクチャを示す図である。たとえば、共有オブジェクトには、区画オブジェクト1002、市民オブジェクト1004、および建物オブジェクト1006が含まれる。区画オブジェクト1002には、SBL1008、面積1010、学区1012などの属性が含まれる。市民オブジェクト1004には、住所1014、名前1016、年齢1018などの属性が含まれる。建物オブジェクト1006 には、住所1020、名前1022 などの属性が含まれる。サブスクリプションセットには、たとえば、税金アプリケーション1024、査定者アプリケーション1026、駐車場アプリケーション1028などのアプリケーションが含まれる。各アプリケーションには、本開示の方法および/またはシステムによってなされた権限に関する設定がされている。たとえば、アプリケーション1024、1026、1028は、それぞれRとUで示される特定のデータオブジェクトまたはデータオブジェクトの属性に対するリクエスト(読み取り)とオファー(データの書き込みまたは更新)をSDMに送信し得る。アプリケーション1024、1026、1028 は、実線の円または点線の円で示されるように、これらのリクエストとオファーを許可または拒否した状態にある。） 「 ［図：0001429000000001.jpg］ 」 「 ［図：0001429000000002.jpg］ 」 「 ［図：0001429000000003.jpg］ 」 「 ［図：0001429000000004.jpg］ 」 「 ［図：0001429000000005.jpg］ 」 「 ［図：0001429000000006.jpg］ 」 「 ［図：0001429000000007.jpg］ 」 （２）引用文献１に記載された事項 上記（１）の摘記事項によると、引用文献１には、以下の事項が記載されている。 ア 段落[0022]、[0031]の記載によれば、引用文献１には、Software-as-a-Serviceプラットフォームにおいて、アプリケーション間でのプラットフォームを介したデータ共有を可能にする共有データ管理(SDM)を実装した、データベースシステムが記載されている。 イ 段落[0023]、[0028]、図１の記載によれば、SDMは、SaaSプラットフォーム上の複数のアプリケーション間で使用および共有するための異なるデータ属性のフォーマットを定義する共通のオブジェクトモデルまたはスキーマを含み、例えば、地方自治体のエンティティによって使用されるアプリケーションをホストするSaaSプラットフォームでは、地方自治体が税務部門アプリケーション、建築部門アプリケーション、財務アプリケーションなどの複数のアプリケーションまたはソフトウェアを採用する場合、SDMは、これらのアプリケーションが、2つ以上のアプリケーションに共通し得るデータを共有することを可能にし、アプリケーションによって使用される識別された共通データオブジェクトは、SDM102によってデータベースシステム内に格納され、維持され、SDM102は、オブジェクトのマスターコピー(権威ある信頼し得る情報またはデータとも呼ばれる)を格納しうるものである。 ウ 段落[0037]、図２の記載によれば、アプリケーション開発者は、SaaSプラットフォーム上に1つまたは複数のアプリケーションを展開し、公開されたSDMデータモデルに対し、データモデルの1つ以上の属性に関連付けられた選択されたデータについて、共有データベースに書き込む許可を求めるオファーと、共有データベースから読み取るかアクセスできるようにすることを求めるリクエストを行い、アプリケーションでアクセスする共有オブジェクトと属性を決定することができる。 エ 段落[0040]、[0046]、[0052]、図２、図５の記載によれば、SaaSプラットフォーム上のアプリケーションの使用をサブスクライブするユーザまたは顧客(ユーザ側または顧客側のIT管理者など)は、アプリケーションに対し、オファーおよび/またはリクエストの権限を付与でき、ユーザ(例えばIT管理者など)は、共有データエディタなどのツールを使用して、共有オブジェクトに対する権限を指定でき、データオブジェクトモデルで定義されたデータを読み取るリクエスト、及びデータオブジェクトモデルで定義されたデータへの書き込みをオファーすることができ、顧客のIT管理者のユーザインタフェースは、ユーザが共有データに対するアプリケーションのアクセス許可を構成し、共有データオブジェクトに関連付けられた権限のステータス(付与または拒否)は、運用データベースに保存される。 オ 段落[0045]、[0050]、図７の記載によれば、SDMを経由したアプリケーション間の動的なデータ取引において、1つ以上のアプリケーションがSDMに特定のデータの更新のオファー、特定のデータを読み取るリクエスト、および/または、オファーまたはリクエストの撤回であり得る取引要求を送信すると、SDMは取引要求を受信し、取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可をアプリケーションに付与することで、データ取引要求への権限を動的に付与または拒否でき、付与された取引要求をSDM運用データベースに記録し、設定された権限をアプリケーションに通知すると、アプリケーションは付与された権限に従って機能を実行するものである。 カ 段落[0047]、[0058]、図６の記載によれば、土地区画共有オブジェクトは、地方自治体が管理する土地の基本単位と付随する構造物を記述する土地区画に関連付けられたデータとして、区画識別子(ID)、区画ブロックロット(SBL)番号、所有者名、所有者の住所、現在か滞納中かのような納税状態、この区画に関連する車両のリストのような登録車両などのデータを含み、それらのデータは、1つ以上のアプリケーション、例えば、税務アプリケーションおよび駐車場管理アプリケーションによって使用され得るものであり、共有オブジェクトには、区画オブジェクト、市民オブジェクト、および建物オブジェクトが含まれ、区画オブジェクトには、SBL、面積、学区などの属性が、市民オブジェクトには、住所、名前、年齢などの属性が、建物オブジェクトには、住所、名前などの属性が、それぞれ含まれ、サブスクリプションセットに含まれる、税金アプリケーション、査定者アプリケーション、駐車場アプリケーションの各アプリケーションには、システムによってなされた権限に関する設定がされており、各アプリケーションは、特定のデータオブジェクトまたはデータオブジェクトの属性に対するリクエスト(読み取り)とオファー(データの書き込みまたは更新)をSDMに送信し得る。 （３）引用文献１に記載された発明 上記（２）の事項から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されている。 「Software-as-a-Serviceプラットフォームにおいて、アプリケーション間でのプラットフォームを介したデータ共有を可能にする共有データ管理(SDM)を実装した、データベースシステムであって、 SDMは、SaaSプラットフォーム上の複数のアプリケーション間で使用および共有するための異なるデータ属性のフォーマットを定義する共通のオブジェクトモデルまたはスキーマを含み、例えば、地方自治体のエンティティによって使用されるアプリケーションをホストするSaaSプラットフォームでは、地方自治体が税務部門アプリケーション、建築部門アプリケーション、財務アプリケーションなどの複数のアプリケーションまたはソフトウェアを採用する場合、SDMは、これらのアプリケーションが、2つ以上のアプリケーションに共通し得るデータを共有することを可能にするものであり、アプリケーションによって使用される識別された共通データオブジェクトは、SDM102によってデータベースシステム内に格納され、維持され、SDM102は、オブジェクトのマスターコピー(権威ある信頼し得る情報またはデータとも呼ばれる)を格納しうるものであり、 アプリケーション開発者は、SaaSプラットフォーム上に1つまたは複数のアプリケーションを展開し、公開されたSDMデータモデルに対し、データモデルの1つ以上の属性に関連付けられた選択されたデータについて、共有データベースに書き込む許可を求めるオファーと、共有データベースから読み取るかアクセスできるようにすることを求めるリクエストを行い、アプリケーションでアクセスする共有オブジェクトと属性を決定することができ、 SaaSプラットフォーム上のアプリケーションの使用をサブスクライブするユーザまたは顧客(ユーザ側または顧客側のIT管理者など)は、アプリケーションに対し、オファーおよび/またはリクエストの権限を付与でき、ユーザ(例えばIT管理者など)は、共有データエディタなどのツールを使用して、共有オブジェクトに対する権限を指定でき、データオブジェクトモデルで定義されたデータを読み取るリクエスト、及びデータオブジェクトモデルで定義されたデータへの書き込みをオファーすることができ、顧客のIT管理者のユーザインタフェースは、ユーザが共有データに対するアプリケーションのアクセス許可を構成し、共有データオブジェクトに関連付けられた権限のステータス(付与または拒否)は、運用データベースに保存され、 SDMを経由したアプリケーション間の動的なデータ取引において、1つ以上のアプリケーションがSDMに特定のデータの更新のオファー、特定のデータを読み取るリクエスト、および/または、オファーまたはリクエストの撤回であり得る取引要求を送信すると、SDMは取引要求を受信し、取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可をアプリケーションに付与することで、データ取引要求への権限を動的に付与または拒否でき、付与された取引要求をSDM運用データベースに記録し、設定された権限をアプリケーションに通知すると、アプリケーションは付与された権限に従って機能を実行し、 土地区画共有オブジェクトは、地方自治体が管理する土地の基本単位と付随する構造物を記述する土地区画に関連付けられたデータとして、区画識別子(ID)、区画ブロックロット(SBL)番号、所有者名、所有者の住所、現在か滞納中かのような納税状態、この区画に関連する車両のリストのような登録車両などのデータを含み、それらのデータは、1つ以上のアプリケーション、例えば、税務アプリケーションおよび駐車場管理アプリケーションによって使用され得るものであり、共有オブジェクトには、区画オブジェクト、市民オブジェクト、および建物オブジェクトが含まれ、区画オブジェクトには、SBL、面積、学区などの属性が、市民オブジェクトには、住所、名前、年齢などの属性が、建物オブジェクトには、住所、名前などの属性が、それぞれ含まれ、サブスクリプションセットに含まれる、税金アプリケーション、査定者アプリケーション、駐車場アプリケーションの各アプリケーションには、システムによってなされた権限に関する設定がされており、各アプリケーションは、特定のデータオブジェクトまたはデータオブジェクトの属性に対するリクエスト(読み取り)とオファー(データの書き込みまたは更新)をSDMに送信し得る、 データベースシステム。」 ２ 引用文献２（車井登、猪股順二，SaaSアプリケーションプラットフォームから見たアイデンテイティ管理，人工知能学会誌，２００９年７月１日，第２４巻，第４号，ｐ．５５２～５５８、申立人３により提出された甲第４号証） （１）引用文献２に記載された事項 取消理由で通知した引用文献２には、以下の事項が記載されている。 「さらに，昨今ではSaaS事業者が提供するアプリケーション（以降SaaSアプリケーションと呼ぶ）を運用・監視・保守するための環境をサービスとして提供する動きが活発化している．この環境はSaaSアプリケーションプラットフォーム，もしくはPaaS (Platform as a Service) と呼ばれているもので，ネットワーク，ハードウェア，OS，ミドルウェアまでを提供している．」（第５５３頁左欄） 「3. マルチテナント SaaSに必要な権限モデルを考えるにあたって，まずはマルチテナントの考え方を整理する．マルチテナントとは，一つのシステムで複数のユーザ企業に対応したものを指し，少ない資源（ハードウェア，ネットワークなど）を効率良く利用することが可能である． まず，一つのSaaSアプリケーションに対して複数のテナントが存在する例を図2に示す． 図2で，ユーザ情報（ログインIDや，属性情報）はユーザそのものに付随する情報であり，一方，企業名や代表者名，SaaSアプリケーションの利用権限，利用期間などの属性はテナントに付随する情報である． SaaSアプリケーションから見たテナントはエンドユーザが所属する企業そのものである． ID管理の観点では，SaaSアプリケーションはユーザ企業ごとにIDを管理すればよい． 次に，PaaSの上に複数のSaaSアプリケーションが搭載されている例を図3に示す． この場合， PaaSから見るとSaaSアプリケーションがマルチテナントで搭載されており，またSaaSアプリケーションから見るとユーザ企業がマルチテナントで搭載されているため，マルチテナントが2段階で存在している． 図2と同様に，SaaSアプリケーションから見たテナントはエンドユーザが所属する企業そのものである．しかしながら，PaaSからは，テナント2がSaaSアプリケーションAを利用しているのか，SaaSアプリケーションBを利用しているのか区別がつかない． これは，PaaSがマルチテナントをサポートする機能を提供する場合に間題となる．すなわち，SaaSアプリケーションにログインしたユーザがどのテナントに所属するかをSaaSアプリケーションに通知する際に，テナントに付随する属性情報のうち，当該SaaSアプリケーションが参照してよいのかがわからないのである． 例えば，テナント2がSaaSアプリケーションAを利用する期間と，SaaSアプリケーションBを利用する期間が異なる場合，この利用期間情報をテナントに保持していると，PaaSからはログインIDだけでアプリケーション側に通知できないなどの問題がある．」（第５５４頁右欄～第５５５頁左欄） 「3・1 PaaSにおけるモデル 前章で述べたとおり，PaaSからテナントを見た場合，それぞれのSaaSアプリケーションごとにユーザ属性を参照するための権限情報を管理しなくてはならない．」（第５５５頁左欄） 「さて，ここまではPaaSにおけるID管理のモデルについて見てきたが，SaaSアプリケーションでID管理が不要になったわけではない．あくまでプラットフォームが制御するのは，IDの認証とサービス利用に関する認可までであり，サービス固有の属性情報や権限管理までは行うことができない．サービス固有の属性情報とは，例えばショッピングサイトにおける購入履歴や，出退勤管理システムにおける出退勤情報であり，サービス固有の権限管理とは，例えば購入申請における承認のワークフローである． これらの情報はSaaSアプリケーション固有の情報であり，アプリケーションによって管理対象が異なるため，PaaSによって認証されたIDにひも付ける形で，独自のデータ管理領域に保持する必要がある．」 「 ［図：0001429000000008.jpg］ 」 「 ［図：0001429000000009.jpg］ 」 イ 引用文献２に記載された技術的事項 上記アの摘記事項から、引用文献２には、次の技術的事項が記載されている。 「SaaS事業者が提供するアプリケーション（SaaSアプリケーション）を運用・監視・保守するための環境である、SaaSアプリケーションプラットフォーム、もしくはPaaS (Platform as a Service)において、PaaSの上に複数のSaaSアプリケーションが搭載され、SaaSアプリケーション固有の情報であり、アプリケーションによって管理対象が異なる、サービス固有の属性情報として、出退勤管理システムにおける出退勤情報を含む。」 第６ 取消理由についての当審の判断 １ 本件発明１について （１）対比 本件発明１と引用発明とを対比する。 ア 引用発明の「共有データ管理(SDM)」は、「Software-as-a-Serviceプラットフォームにおいて、アプリケーション間でのプラットフォームを介したデータ共有」を可能にするものであり、「SDMを経由したアプリケーション間の動的なデータ取引」が行われる際に、「1つ以上のアプリケーション」から下記で詳述する「取引要求」を受信すると、「取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可をアプリケーションに付与することで、データ取引要求への権限を動的に付与または拒否でき、付与された取引要求をSDM運用データベースに記録し、設定された権限をアプリケーションに通知する」というデータ処理を実行するものであるから、引用発明の「共有データ管理(SDM)」を実装した「データベースシステム」は、本件発明１の「データ処理システム」に相当する。 イ 引用発明における「SaaSプラットフォーム上の複数のアプリケーション」には、「地方自治体のエンティティによって使用される」場合は、「税務部門アプリケーション」、「建築部門アプリケーション」、「財務アプリケーション」などが採用され、より具体的には、「税金アプリケーション」、「査定者アプリケーション」、「駐車場アプリケーション」などが採用されるところ、これらのアプリケーションを使用することにより、ユーザまたは顧客に対し、各アプリケーションに対応した情報処理サービスを提供するものであることは自明であるから、引用発明の「（SaaSプラットフォーム上の）複数のアプリケーション」は、本件発明１の「複数の情報処理サービスシステム」に相当する。 ウ 引用発明の「SDM」は、「アプリケーションによって使用される識別された共通データオブジェクト」をデータベースシステム内に格納、維持し、「オブジェクトのマスターコピー(権威ある信頼し得る情報またはデータとも呼ばれる)を格納しうるもの」であり、引用発明の「データベースシステム」が、このような「オブジェクト」を格納する「データベース」を備えていることは明らかである。 また、引用発明では、「共有オブジェクト」に「区画オブジェクト」、「市民オブジェクト」、「建物オブジェクト」が含まれる例が示されているところ、「区画オブジェクト」に「SBL、面積、学区などの属性」が含まれているように、いずれの「オブジェクト」にも複数の「属性」が含まれているから、引用発明の「オブジェクト」に含まれる、SBL、面積、学区などの「複数の属性」は、本件発明１の「複数の項目」に相当する。 そして、引用発明の「SDM」は、アプリケーション開発者が、公開されたSDMデータモデルの1つ以上の「属性」に関連付けられた選択された「データ」について、「共有データベースに書き込む許可を求めるオファー」と「共有データベースから読み取るかアクセスできるようにすることを求めるリクエスト」を行い、「アプリケーションでアクセスする共有オブジェクトと属性を決定する」ことができるものであるから、1つ以上の「属性」に関連付けられた選択された「データ」は、「共有データベース」に格納されるものである。 してみると、引用発明の「共有データベース」は、本件発明１の「管理用データベース」に相当し、引用発明の1つ以上の「属性」に関連付けられた選択された「データ」は、本件発明１の「管理用データベースに含まれる複数の項目に関する複数のデータ」に相当する。また、引用発明における「（共有データベースに書き込む許可を求める）オファー」と「（共有データベースから読み取るかアクセスできるようにすることを求める）リクエスト」は、それぞれ本件発明１の「更新」と「参照」に相当する。 エ 引用発明の「SDM」は、「SaaSプラットフォーム上のアプリケーションの使用をサブスクライブするユーザまたは顧客(ユーザ側または顧客側のIT管理者など)」が、「共有データエディタなどのツールを使用して、共有オブジェクトに対する権限を指定でき、データオブジェクトモデルで定義されたデータを読み取るリクエスト、及びデータオブジェクトモデルで定義されたデータへの書き込みをオファーすることができ」るものであって、「顧客のIT管理者のユーザインタフェースは、ユーザが共有データに対するアプリケーションのアクセス許可を構成し」、「共有データオブジェクトに関連付けられた権限のステータス(付与または拒否)は、運用データベースに保存され」、「各アプリケーションは、特定のデータオブジェクトまたはデータオブジェクトの属性に対するリクエスト(読み取り)とオファー(データの書き込みまたは更新)をSDMに送信し得る」ものである。 してみると、引用発明において、そのような「ユーザまたは顧客(ユーザ側または顧客側のIT管理者など)」は、「共有データエディタ」のような「ユーザインタフェース」を介して、各アプリケーションに関し、「データオブジェクトの属性」に対する「オファー」と「リクエスト」の「権限を指定でき」、これにより「権限のステータス(付与または拒否)」が「運用データベースに保存され」るといえるから、引用発明の運用データベースに保存される「権限のステータス(付与または拒否)」は、本件発明１の「権限データ」に相当する。 したがって、上記イ、ウを踏まえると、引用発明の「データベースシステム」に実装された「SDM」において、「ユーザまたは顧客(ユーザ側または顧客側のIT管理者など)」によって指定された、各アプリケーションにおける「データオブジェクトの属性」に対する「オファー」と「リクエスト」の権限に関し、「権限のステータス(付与または拒否)」を運用データベースに保存する機能を実現する手段は、本件発明１の「複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定する権限設定部」に相当する。 オ 引用発明の「SDM」は、「SDMを経由したアプリケーション間の動的なデータ取引」において、「1つ以上のアプリケーション」から「特定のデータの更新のオファー、特定のデータを読み取るリクエスト」であり得る「取引要求」を「受信」するものであり、引用発明の当該「取引要求」は、本件発明１の「前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求」に相当し、また、引用発明において、当該「取引要求」を送信する「1つ以上のアプリケーション」は、本件発明１の「第１情報処理サービスシステム」に相当する。 したがって、引用発明の「データベースシステム」に実装された「SDM」において、「1つ以上のアプリケーション」から送信される「取引要求」を「受信」する機能を実現する手段は、本件発明１の「前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する要求受信部」に相当する。 カ 引用発明の「SDM」は、上記オに示した「取引要求」を「受信」すると、「取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可をアプリケーションに付与することで、データ取引要求への権限を動的に付与または拒否でき、付与された取引要求をSDM運用データベースに記録し、設定された権限をアプリケーションに通知する」ことによって、「アプリケーションは付与された権限に従って機能を実行」するものであり、ここで「付与された権限」とは、「取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可」のことである。 そして、上記エ、オを踏まえると、引用発明の「SDM」は、「運用データベース」に保存された「権限のステータス(付与または拒否)」によって「付与された権限」の内容を把握し得るものであり、これと「取引要求」に基づいて、当該「取引要求」で要求され、権限が付与された（すなわちアクセス許可された）「特定のデータの更新のオファー」及び「特定のデータを読み取るリクエスト」の少なくともいずれかの処理を実行するものである。ここで、引用発明において、「付与された権限に従って機能を実行」するのは、「SDM」から「設定された権限」の通知を受ける「アプリケーション」であるものの、引用発明の「SDM」においても、当該「アプリケーション」が「付与された権限」に従って「取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス」を行うことができるようにするための、制御を行う機能を有しているといえる。 したがって、引用発明の「データベースシステム」に実装された「SDM」において、「取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス許可をアプリケーションに付与することで、データ取引要求への権限を動的に付与または拒否でき、付与された取引要求をSDM運用データベースに記録し、設定された権限をアプリケーションに通知する」ことにより、「アプリケーション」が「付与された権限」に従って「取引で指定されたデータの読み取り、書き込み、または読み取りと書き込みの両方に対するアクセス」を行うことができるようにするための機能を実現する手段は、本件発明１の「前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部」に相当する。 キ 引用発明における「複数のアプリケーション」は、上記イで示したように、「SaaSプラットフォーム上」で動作し、「税金アプリケーション」、「査定者アプリケーション」、「駐車場アプリケーション」のように、それぞれ異なる所定の「情報処理サービス」を提供するものである。 また、引用発明の「SDM」は、2つ以上のアプリケーションに共通し得るデータを共有することを可能にするものであって、上記ウを踏まえると、このようなデータは「共有データベース」に格納されるものであるといえる。 そして、引用発明の「SDM」は、「1つ以上のアプリケーション」から「特定のデータを読み取るリクエスト」の「取引要求」を受信すると、権限が付与された当該特定のデータを「共有データベース」から読み取ることができるように処理するものであるところ、当該「取引要求」の送信元が、当該アプリケーションの使用をサブスクライブするユーザまたは顧客(ユーザ側または顧客側のIT管理者など)が使用する端末であることは明らかであって、「リクエスト」の対象である「特定のデータ」を、「取引要求」の送信元である当該端末に提供することも、当業者において自明の事項である。 してみると、引用発明において、「アプリケーションの使用をサブスクライブするユーザまたは顧客(ユーザ側または顧客側のIT管理者など)」は、本件発明１の「ユーザ」に相当し、引用発明において、そのような「ユーザまたは顧客(ユーザ側または顧客側のIT管理者など)」が使用する端末は、本件発明１の「ユーザが利用するユーザ端末」に相当する。 したがって、引用発明の「共有データベース」に格納されたデータを「ユーザまたは顧客(ユーザ側または顧客側のIT管理者など)」が使用する端末に提供する、「SaaSプラットフォーム上」で動作する「複数のアプリケーション」は、本件発明１の「前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システム」であることに相当する。 ク 引用発明においては、「土地区画共有オブジェクト」に含まれる「区画識別子(ID)、区画ブロックロット(SBL)番号、所有者名、所有者の住所、現在か滞納中かのような納税状態、この区画に関連する車両のリストのような登録車両などのデータ」が、例えば、「税務アプリケーション」および「駐車場管理アプリケーション」によって使用されるものであり、上記ウを踏まえると、このようなデータは「共有データベース」に格納されるものであるといえるから、引用発明の「共有データベース」に格納される「区画識別子(ID)、区画ブロックロット(SBL)番号、所有者名、所有者の住所、現在か滞納中かのような納税状態、この区画に関連する車両のリストのような登録車両などのデータ」が、「税務アプリケーション」および「駐車場管理アプリケーション」のような複数のアプリケーションによってそれぞれ使用されることは、本件発明１の「前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースである」ことに相当する。 ケ 上記ア～クによれば、本件発明１と引用発明との間には、次の一致点、相違点があるといえる。 ［一致点］ 「複数の情報処理サービスシステムのそれぞれにおける、管理用データベースに含まれる複数の項目に関する複数のデータのそれぞれの、参照及び更新の少なくともいずれかの権限に関する権限データを設定する権限設定部と、 前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する要求受信部と、 前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部と、 を備え、 前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、 ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを、ユーザが利用するユーザ端末に提供する情報処理システムであり、 前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースである、 データ処理システム。」 ［相違点］ 本件発明１は、「前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする」ものであるのに対し、引用発明は、そのような特定がない点。 （２）相違点についての判断 ア 相違点について 本件発明１の「更新管理部」において、「更新時期データ」を管理する対象である「前記少なくとも１つのデータ」は、「管理用データベースに含まれる複数の項目に関する複数のデータ」のうち、「前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステム」からの「データ処理要求」に基づいて「提供及び更新の少なくともいずれかの処理」が行われるデータであるところ、「管理用データベース」は、「複数の情報処理サービスシステム」の「それぞれ」が「相互に利用する」ものであり、また、「複数の情報処理サービスシステム」は、その「それぞれ」が管理用データベースに基づいて「ＳａａＳを含むそれぞれ異なる所定の情報処理サービス」をユーザが利用するユーザ端末に提供する情報処理システムであるから、本件発明１の「前記少なくとも１つのデータ」は、「それぞれ」が「それぞれ異なる所定の情報処理サービス」をユーザ端末に提供する「情報処理サービスシステム」である「複数の情報処理サービスシステム」の「それぞれ」が「相互に利用する」、「管理用データベース」に含まれる複数の項目に関する複数のデータの部分（一部又は全部）のデータである。 これに対し、引用文献２に記載された技術的事項は、引用発明と同様の、複数のSaaSアプリケーションが搭載されるプラットフォーム（PaaS）に関するものであり、「前記少なくとも１つのデータ」を、「それぞれ異なる所定の情報処理サービス」である「複数のSaaSアプリケーション」を提供する「複数の情報処理サービスシステム」の「それぞれが相互に利用する」データ処理システムであるとはいえるものの、複数の情報処理サービスシステムのそれぞれが相互に利用する管理用データベースに含まれる、複数の項目に関する複数のデータの部分（一部又は全部）のデータを更新する時期を管理するものとはいえず、引用文献２に記載された技術的事項は、本件発明１の上記［相違点］に係る構成を備えるものではない。 また、第７において後述するとおり、本件発明１の上記［相違点］に係る構成は、申立人が証拠として用いたいずれの甲号証にも記載されていない。 イ 本件発明１の作用効果について 本件明細書には、「また、データ処理部１５０は、例えば、まず、予定データベースに更新内容データを登録し、所定のタイミング（例えば、更新時期データが示す更新時期）で、予定データベースに登録された更新内容データに基づいて、現在データベースに含まれるデータを更新してもよい。これにより、データ処理システム１００は、任意の更新時期で、データを更新することができる。」（【００５７】）と記載されていることから、本件発明１は、上記［相違点］に係る構成を採用することにより、「任意の更新時期で、データを更新することができる」という、格別顕著な作用効果を奏するものである。 ウ 申立人の主張に対する検討 （ア）申立人２の主張について ａ 申立人２は、令和７年７月４日提出の意見書（以下、「申立人２意見書」という。）において、概略、次のように主張している。 （ａ）本件発明１、７、８は、引用文献１に開示された発明と同一であって、特許法第２９条第１項第３号に違反するから、特許法第１１３条第２号により取り消されるべきものである。（申立人２意見書第２～４頁） （ｂ）本件発明１、７、８は、引用文献１の発明から当業者が容易に想到できた発明であって、特許法第２９条第２項に違反するから、特許法第１１３条第２号により取り消されるべきものである。（申立人２意見書第５～８頁） （ｃ）本件発明１、７、８は、引用文献１及び（申立人２が追加で提出した）甲第１８号証から当業者が容易に想到できた発明であって、特許法第２９条第２項に違反するから、特許法第１１３条第２号により取り消されるべきものである。（申立人２意見書第８～１７頁） （ｄ）本件発明５は、引用文献１に開示された発明及び（申立人２が追加で提出した）MDMシステムの具体的な実施方法を解説した甲第１６号証に基づいて当業者が容易に想到できた発明であって、特許法第２９条第２項に違反するから、特許法第１１３条第２号により取り消されるべきものである。（申立人２意見書第１７～１９頁） しかしながら、上記第２の２（１）に示したとおり、本件訂正後の請求項１に係る発明である本件発明１は、本件訂正前の請求項４に係る発明と同一であり、他方、引用文献１は申立人２により提出された甲第１号証であるところ、申立人２は異議申立て２の申立て理由において、（本件訂正前の）請求項４に係る発明が、甲第１号証に開示された発明と同一であるとも、甲第１号証に開示された発明に基づいて、当業者が容易に発明することができたものであるとも主張していないから、上記（ａ）、（ｂ）の主張は、特許異議の申立ての理由に実質的に新たな内容を付加するものであり、審理の対象にならない。 また、本件訂正は、新たな技術的事項を付加しておらず、本訂正請求に付随して新たな技術的事項について追加で証拠を提出する必要性は生じていないものであるから、主張を行うために新たな証拠を追加する上記（ｃ）、（ｄ）の主張も、特許異議の申立ての理由に実質的に新たな内容を付加するものであり、審理の対象にならない。 ｂ したがって、申立人２による上記ａ（ａ）～（ｄ）の主張はいずれも採用できないが、上記ａ（ａ）の主張において、申立人２が引用文献１に開示された事項に関する主張について、以下に補足的に検討する。 申立人２は、引用文献１の段落[0031]、[0032]の記載によれば、SDMは、IBMが提供するMDMシステムであってもよく、MDMシステムでは、データを「周期的に」MDMサーバ（すなわちSDM）に複製する「統合」スタイルを採用できることが開示されており、周期的にデータを統合するためには、その「周期」が具体的にどのような頻度、日時、イベント等によって特定されるものであるかを示すデータが何らかの形で保持されている必要があり、また、更新の周期が到来したか否かの判定を行うためには、当該データを参照する必要があるから、引用文献１は、「少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、（前記データ処理部は、）前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする」という、本件訂正によって本件発明１、７、８に追加された構成要件についても開示している旨を主張する。 しかしながら、以下のとおり、この主張を採用することはできない。 上記アのとおり、本件発明１の「前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする」における「前記少なくとも１つのデータ」は、「それぞれ」が「それぞれ異なる所定の情報処理サービス」をユーザ端末に提供する「情報処理サービスシステム」である「複数の情報処理サービスシステム」の「それぞれ」が「相互に利用する」、「管理用データベース」に含まれる複数の項目に関する複数のデータの部分（一部又は全部）のデータである。 （このことは、特許請求の範囲の文言上明示されているし、本件特許の明細書の「更新管理部」及び「更新時期データ」に基づく「データ処理部」に関する次の記載とも整合している。 「【００２５】 管理用データベース１０１は、現在データベース及び予定データベースを含んでもよい。現在データベースは、現時点の情報として登録されているデータのデータベースである。予定データベースは、現時点以降に更新される予定のデータのデータベースである。予定データベースでは、更新予定のデータと、更新時期を示す更新時期データとが対応付けられていてもよい。管理用データベース１０１が、現在データベース及び予定データベースを含むことにより、後述するデータ処理部１５０は、更新管理部１４０と連携して、所定の更新時期にデータを更新することができる。」 「【００４６】 更新管理部１４０は、管理用データベース１０１に記憶される複数のデータに含まれる少なくとも１つのデータを更新する時期を示す更新時期データを管理する。」 「【００５７】 また、データ処理部１５０は、例えば、まず、予定データベースに更新内容データを登録し、所定のタイミング（例えば、更新時期データが示す更新時期）で、予定データベースに登録された更新内容データに基づいて、現在データベースに含まれるデータを更新してもよい。これにより、データ処理システム１００は、任意の更新時期で、データを更新することができる。 【００５８】 また、データ処理部１５０は、更新時期データに基づいて、当該更新時期データが示す時期に、データの更新の処理を行ってもよい。」 「【００７２】 データ処理部１５０が、データ処理要求に応じて、管理用データベース１０１に記憶されるデータの提供又は更新の処理を行う（Ｓ６０３）。このとき、データ処理部１５０は、更新管理部１４０によって管理される更新時期データが示す更新時期に、管理用データベース１０１に記憶されるデータの更新の処理を行ってもよい。」） これに対し、引用文献１に記載の「SDM」は、「共有データベース」に記憶されたデータを周期的に更新するものであるとしても、周期的な更新の対象となるデータが部分的なデータを想定しているか定かではなく、まして部分的なデータの「更新時期データ」を管理するものではないから、引用発明は、複数の情報処理サービスシステムのそれぞれが相互に利用する管理用データベースに含まれる、複数の項目に関する複数のデータの部分（一部又は全部）のデータを更新する時期を管理する技術を示すものではない。 また、引用文献１に記載の「共有データベース」において、記憶されたデータ全体を周期的な更新の対象とする場合、例えば、毎週日曜日の深夜に更新を行う、毎月の最終日に更新を行う等のように、予めデータベース内の全データに対してデータの更新を行うタイミングを決めておけば足りることであり、このことを踏まえれば、引用発明において、複数の情報処理サービスシステムのそれぞれが相互に利用する管理用データベースに含まれる、複数の項目に関する複数のデータの部分（一部又は全部）のデータを更新する時期を管理する技術を組み合わせる動機付けがあるともいえない。 ｃ よって、申立人２による申立人２意見書の主張は、いずれも採用できない。 （イ）申立人３の主張について ａ 申立人３は、令和７年７月９日提出の意見書（以下、「申立人３意見書」という。）において、概略、次のように主張している。 （ａ）本件発明１は、引用文献１に開示された発明と同一であって、仮に、本件発明１が引用文献１の発明に対して相違点を有していたとしても、そのような相違点は技術的微差であるから、本件発明１は新規性、進歩性を有しない。（申立人３意見書第３～６頁） （ｂ）本件発明１は、引用文献１に開示された発明及び異議申立て３における甲第９～１２号証に開示されている技術に基づいて、当業者が容易に想到できた発明であるから、本件発明１は進歩性欠如の取消理由を有する。（申立人３意見書第６～１２頁） （ｃ）本件発明１は、引用文献１に開示された発明、及び異議申立て３における甲第９～１２号証、異議申立て１における甲第９～１２号証、異議申立て２における甲第３～１０号証、（申立人３が追加で提出した）甲第２０～２２号証のそれぞれに開示された周知技術に基づいて、当業者が容易に想到できた発明であるから、本件発明１は進歩性欠如の取消理由を有する。（申立人３意見書第１２～１５頁） （ｄ）本件発明１は、引用文献１に開示された発明及び（申立人３が追加で提出した）甲第１８号証に開示されている技術に基づいて、当業者が容易に想到できた発明であるから、本件発明１は進歩性欠如の取消理由を有する。（申立人３意見書第１５～２７頁） しかしながら、そもそも申立人３は異議申立て３において、申立人２により提出された甲第１号証に基づく理由を主張しておらず、上記主張（ａ）～（ｄ）は、異議申立て３の申立ての理由に実質的に新たな内容を付加するものであるから、審理の対象にならない。 ｂ したがって、申立人３による上記ａ（ａ）～（ｄ）の主張はいずれも採用できないが、上記ａ（ａ）、（ｂ）の主張において、申立人３が引用文献１に開示された事項、及び本件発明１の解釈に関する主張について、以下に補足的に検討する。 （ａ）申立人３は、引用文献１の段落[0031]、[0032]の記載によれば、引用文献１には、MDMシステムで実装されるSDMのデータベースが、更新する時期を示す周期を管理する構成が「MDMシステムにより周期的にMDMサーバに複製する構成として」実質的に開示されており、さらに、その周期に基づいて、この周期により特定される時期にデータの複製（更新に相当する）を処理する構成が開示されているから、本件訂正により本件発明１に追加された構成に関しても、引用文献１に開示されている旨を主張する。（申立人３意見書第４～６頁） しかしながら、当該主張に関しても、上記（ア）ｂで検討したとおりであって、申立人３の引用文献１に開示された事項に関する上記主張は採用できない。 （ｂ）申立人３は、本件発明１に関し、(1)本件発明１は、「データ処理部」についての「前記少なくとも１つのデータの・・・更新・・・の処理をする、」にかかる「前記」が単に「（前記複数のデータに含まれる）少なくとも１つのデータ」に係り受けするのか、それとも「（権限データ及びデータ処理要求に基づいたデータの）更新の処理」に係り受けするのか明確に特定されておらず、ＳａａＳを提供する情報処理サービスシステムのデータ処理要求とは別個に、ＳａａＳに依拠しないプロセスに基づいて、管理された更新時期にデータの更新の処理をする態様を包含している点、(2)本件発明１はデータ処理要求がデータの参照の要求のみであり、データの更新の要求を含まない態様を選択肢として包含している点、(3)本件発明１には、更新時期データを、ＳａａＳを提供する情報処理サービスシステムから受信したことは特定されていない点、の３点を挙げ、本件発明１の範囲を必要以上に狭く解釈すべきではない旨を主張する。（申立人３意見書第９～１１頁） 本件発明１の「前記少なくとも１つのデータを更新する時期を示す更新時期データを管理する更新管理部をさらに備え、前記データ処理部は、前記更新時期データにさらに基づいて、前記更新時期データが示す時期に前記少なくとも１つのデータの更新の処理をする」における「前記少なくとも１つのデータ」は、「それぞれ」が「それぞれ異なる所定の情報処理サービス」をユーザ端末に提供する「情報処理サービスシステム」である「複数の情報処理サービスシステム」の「それぞれ」が「相互に利用する」、「管理用データベース」に含まれる複数の項目に関する複数のデータの部分（一部又は全部）のデータであり、引用文献１には、複数の情報処理サービスシステムのそれぞれが相互に利用する管理用データベースに含まれる複数の項目に関する複数のデータの部分（一部又は全部）のデータを更新する時期を管理することは開示されていないから、本件発明１と引用発明とは［相違点］において相違するものであり、「データ処理要求」が「データの参照の要求のみ」を選択肢として含むか否かや「更新時期データ」が「ＳａａＳを提供する情報処理サービスシステム」から受信しないものを含むか否かに関わらず、この点は相違点となる。（「データ処理部」についての「前記少なくとも１つのデータの・・・更新・・・の処理をする、」の「前記」は、「更新」の「処理」ではなく、「少なくとも１つのデータ」に係ることは、文言上明らかである。） ｃ よって、申立人３による申立人３意見書の主張は、いずれも採用できない。 エ 小括 したがって、本件発明１は、引用発明と同一であるとはいえず、また引用発明及び引用文献２に記載された技術的事項に基いて、当業者が容易に発明をすることができたものではない。 （２）本件発明２、３、５、６について 本件発明２、３、５、６は、本件発明１の構成に限定を加えて減縮したものであり、これらの請求項に係る発明は、いずれも、上記１（１）ケに示した上記［相違点］に係る構成を有しているから、上記（１）に示した理由と同様の理由により、本件発明２、３、５、６は、引用発明と同一であるとはいえず、また引用発明及び引用文献２に記載された技術的事項に基づいて当業者が容易に発明をすることができたものではない。 （３）本件発明７、８について 本件発明７は、本件発明１の「データ処理システム」の発明を「データ処理方法」として記載した発明であって、本件発明８は、本件発明１の「データ処理システム」の発明を「データ処理プログラム」として記載した発明であって、いずれも上記［相違点］に係る構成を有しているから、上記（１）に示した理由と同様の理由により、引用文献１に記載された発明と同一であるとはいえず、また引用文献１に記載された発明及び引用文献２に記載された技術的事項に基づいて当業者が容易に発明をすることができたものではない。 第７ 取消理由（決定の予告）において採用しなかった特許異議申立て理由について １ 特許異議申立て理由の概要 申立人１は甲第１号証～甲第１３号証を、申立人２は甲第１号証～甲第１５号証を、申立人３は甲第１号証～甲第１７号証を、それぞれ証拠として用い、概略、以下のとおり主張している。 なお、下記「（２）申立て理由の概要」においては、申立人１～申立人３による異議申立て１～異議申立て３に関し、申立て理由の条文ごとにまとめて申立て理由を記す。 （１）証拠方法 申立人１～３によって提出された甲号証は以下のとおりである。なお、以下、申立人Ｘによる甲第Ｙ号証を、「甲Ｘ－Ｙ」などという。 甲１－１ ：特開２０１６－２１８６４４号公報 甲１－２ ：特開２０２１－５６８０７号公報 甲１－３ ：特表２０１５－５２８１６８号公報 甲１－４ ：特開２０１１－１２８９９４号公報 甲１－５ ：特開２０１５－３５０９６号公報 甲１－６ ：特開２００２－１１６９４４号公報 甲１－７ ：特開２００４－１９９３６７号公報 甲１－８ ：特開２０２１－１７４０６８号公報 甲１－９ ：特開２０００－８２０８１号公報 甲１－１０：特開２０００－９９３７７号公報 甲１－１１：特開平８－１２９５０１号公報 甲１－１２：特開平９－４４３８４号公報 甲１－１３：特開２００７－６６１５５号公報 甲２－１ ：米国特許公開公報第２０１２／０２３９６９９号明細書（上記第５の１の引用文献１） 甲２－２ ：米国特許公開公報第２０１７／０３３７２５４号明細書 甲２－３ ：特許第３９２６６７４号公報 甲２－４ ：特開第２０１９－２００７６７号公報 甲２－５ ：特開第２００１－１１７９４５号公報 甲２－６ ：特開平８－１２９５０１号公報（甲１－１１と同じ） 甲２－７ ：特開平２－２５３３５２号公報 甲２－８ ：特開２００７－２１９８４４号公報 甲２－９ ：特開２０００－３０５８２７号公報 甲２－１０：特開２０００－１４８５７０号公報 甲２－１１：特開２０２２－１６０３０４号公報 甲２－１２：特開２０１８－１８４３３号公報 甲２－１３：特開２００９－２２３８３３号公報 甲２－１４：特開２００２－２３０２４１号公報 甲２－１５：特開２００６－２４４４８８号公報 甲３－１ ：米国特許第１０４６７４２６号明細書 甲３－２ ：米国特許公開公報第２０１２／０３２４５３９号明細書 甲３－３ ：Haitham Yaish, Madhu Goyal and George Feuerlicht、「A NOVEL MULTI-TENANT ARCHITECTURE DESIGN FOR SOFTWARE AS A SERVICE APPLICATIONS」、平成２４年（２０１２年）、p．８２－８８ 甲３－４ ：車井登、猪股順二、「SaaSアプリケーションプラットフォームから見たアイデンテイティ管理」、人工知能学会誌、２００９年７月、第２４巻、第４号、p．５５２－５５８（上記第５の２の引用文献２） 甲３－５ ：特開２００４－１７８２８７号公報 甲３－６ ：特開２００３－２０２９９６号公報 甲３－７ ：特開２０１９－１６０３３６号公報 甲３－８ ：特開２０１９－１６８７７８号公報 甲３－９ ：特開２０１３－２１８５７５号公報 甲３－１０：特開２０１０－１１７８９９号公報 甲３－１１：特開２００７－２４９５４０号公報 甲３－１２：特開２００４－２９５８４７号公報 甲３－１３：Webページ、「SaaS」、https://jinjibu.jp/keyword/detl/803/ 甲３－１４：Webページ、「複数の人事SaaSシステム運用で生じる重複登録を回避する方法」、https://www.comit-hr.jp/blog-list/b210718/ 甲３－１５：Webページ、「基幹系SaaSがイノベーションの起点に─Workdayに見る人材管理／財務管理の世界トレンド」、https://it.impress.co.jp/articles/-/19060 甲３－１６：Webページ、「Workday」、https://ja.wikipedia.org/wiki/Workday 甲３－１７：Webページ、「Zoho、SaaSスイートにSMB向け人事アプリ追加」、https://www.itmedia.co.jp/im/articles/0803/11/news137.html （２）申立て理由の概要 ア 特許法第２９条第１項第３号 （ア）申立人１は、本件発明１、７、８は、甲１－１に記載された発明である旨主張する。（異議申立て１の理由１に相当） （イ）申立人２は、本件発明１～３、６～８は、甲２－１に記載された発明である旨主張する。なお、当該申立て理由については、取消理由通知で採用した。（異議申立て２の「３ 申立ての理由」（１）ア（ア）に相当） （ウ）申立人２は、本件発明１、２、４～８は、甲２－２に記載された発明である旨主張する。（異議申立て２の「３ 申立ての理由」（１）ア（イ）に相当） （エ）申立人３は、本件発明１～３、６～８は、甲３－１に記載された発明である旨主張する。（異議申立て３の異議理由１に相当） （オ）申立人３は、本件発明１、２、７、８は、甲３－２に記載された発明である旨主張する。（異議申立て３の異議理由２に相当） （カ）申立人３は、本件発明１、２、６～８は、甲３－３に記載された発明である旨主張する。（異議申立て３の異議理由３に相当） （キ）申立人３は、本件発明１～３、６～８は、甲３－４に記載された発明である旨主張する。なお、甲３－４については、引用文献２として取消理由通知で採用した。（異議申立て３の異議理由４に相当） イ 特許法第２９条第２項 （ア）甲１－１を主たる発明とした進歩性の申立て理由（異議申立て１の理由２に相当） ａ 申立人１は、本件発明１、７、８は、甲１－１に記載された発明に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人１は、本件発明２は、甲１－１に記載された発明、及び甲１－４に記載された技術事項に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人１は、本件発明３は、甲１－１に記載された発明、及び甲１－４に記載された技術事項、並びに甲１－５～甲１－８に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｄ 申立人１は、本件発明４、５は、甲１－１に記載された発明、及び甲１－４に記載された技術事項、並びに甲１－９～甲１－１２に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｅ 申立人１は、本件発明６は、甲１－１に記載された発明、及び甲１－４、甲１－１３に記載された技術事項に基づいて、当業者が容易に発明をすることができたものである旨主張する。 （イ）甲１－２を主たる発明とした進歩性の申立て理由（異議申立て１の理由３に相当） ａ 申立人１は、本件発明１、２、６～８は、甲１－２に記載された発明、及び甲１－３に記載された技術事項に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人１は、本件発明３は、甲１－２に記載された発明、及び甲１－３に記載された技術事項、並びに甲１－５～甲１－８に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人１は、本件発明４、５は、甲１－２に記載された発明、及び甲１－３に記載された技術事項、並びに甲１－９～甲１－１２に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 （ウ）甲２－１を主たる発明とした進歩性の申立て理由（異議申立て２の「３ 申立ての理由」（１）ア（ア）に相当） ａ 申立人２は、本件発明４は、甲２－１に記載された発明、及び甲２－３に記載された技術事項に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人２は、本件発明５は、甲２－１に記載された発明、及び甲２－３に記載された技術事項、並びに甲２－４～甲２－１０に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人２は、本件発明６は、甲２－１に記載された発明、及び甲２－３に記載された技術事項、並びに甲２－１１～甲２－１４に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。なお、当該申立て理由については、取消理由通知で採用した。 （エ）甲２－２を主たる発明とした進歩性の申立て理由（異議申立て２の「３ 申立ての理由」（１）ア（イ）に相当） ａ 申立人２は、本件発明３は、甲２－２に記載された発明、及び甲２－１５に記載された技術事項に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人２は、本件発明５は、甲２－２に記載された発明、及び甲２－３に記載された技術事項、並びに甲２－４～甲２－１０に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 （オ）甲３－１を主たる発明とした進歩性の申立て理由（異議申立て３の異議理由１に相当） ａ 申立人３は、本件発明１、２、７、８は、甲３－１に記載された発明に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人３は、本件発明３は、甲３－１に記載された発明、及び甲３－５～甲３－８に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人３は、本件発明４、５は、甲３－１に記載された発明、及び甲３－９～甲３－１２に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｄ 申立人３は、本件発明６は、甲３－１に記載された発明、及び甲３－１３～甲３－１７に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 （カ）甲３－２を主たる発明とした進歩性の申立て理由（異議申立て３の異議理由２に相当） ａ 申立人３は、本件発明１、２、７、８は、甲３－２に記載された発明に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人３は、本件発明３は、甲３－２に記載された発明、及び甲３－５～甲３－８に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人３は、本件発明４、５は、甲３－２に記載された発明、及び甲３－９～甲３－１２に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｄ 申立人３は、本件発明６は、甲３－２に記載された発明、及び甲３－１に記載された技術事項又は甲３－１３～甲３－１７に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 （キ）甲３－３を主たる発明とした進歩性の申立て理由（異議申立て３の異議理由３に相当） ａ 申立人３は、本件発明１、２、７、８は、甲３－３に記載された発明に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｂ 申立人３は、本件発明３は、甲３－３に記載された発明、及び甲３－５～甲３－８に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人３は、本件発明４、５は、甲３－３に記載された発明、及び甲３－９～甲３－１２に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｄ 申立人３は、本件発明６は、甲３－３に記載された発明、及び甲３－１３～甲３－１７に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 （ク）甲３－４を主たる発明とした進歩性の申立て理由（異議申立て３の異議理由４に相当） ａ 申立人３は、本件発明１～３、７、８は、甲３－４に記載された発明に基づいて、当業者が容易に発明をすることができたものである旨主張する。なお、甲３－４については、引用文献２として取消理由通知で採用した。 ｂ 申立人３は、本件発明４、５は、甲３－４に記載された発明、及び甲３－９～甲３－１２に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。 ｃ 申立人３は、本件発明６は、甲３－４に記載された発明、及び甲３－１３～甲３－１７に示される周知技術に基づいて、当業者が容易に発明をすることができたものである旨主張する。なお、甲３－４については、引用文献２として取消理由通知で採用した。 ウ 特許法第３６条第６項第２号 申立人１は、本件発明６は、発明が明確に記載されていないから、特許法第３６条第６項第２号に規定する要件を満たしておらず、請求項６に係る特許を取り消すべきものである旨主張する。（異議申立て１の理由４に相当） エ 特許法第３６条第６項第１号 申立人３は、本件発明１～８は、発明の詳細な説明に記載されていないから、特許法第３６条第６項第１号に規定する要件を満たしておらず、請求項１～８に係る特許を取り消すべきものである旨主張する。（異議申立て３の異議理由５に相当） オ 特許法第３６条第４項第１号 申立人３は、本件特許明細書の発明の詳細な説明の記載には不備があり、請求項１～８の特許に係る発明は、特許法第３６条第４項第１号に規定する要件を満たしていない特許出願に対してされたものである旨主張する。（異議申立て３の異議理由６に相当） ２ 特許法第２９条第１項第３号、特許法第２９条第２項の申立て理由についての判断 （１）甲号証の記載 ア 甲１－１（特開２０１６－２１８６４４号公報） 甲１－１には、以下のとおりの記載がある。 「【要約】 【課題】患者が病院、介護施設、在宅と移動しても、これらの多施設間で一貫した記録文書や作業指示文書の作成、参照を可能とし、スムーズな医療、介護、福祉連携活動を実現する多施設統合電子カルテシステムを提供する。 【解決手段】複数の施設で用いられる文書カテゴリーを管理する施設毎文書カテゴリー管理手段、施設毎文書カテゴリー毎に文書データを記録する施設毎文書カテゴリー毎文書記録手段、施設毎文書カテゴリー毎にスタッフのアクセス権限を管理する施設毎文書カテゴリー毎アクセス権限管理手段を備える。施設毎文書カテゴリー毎アクセス権限管理手段は、施設毎文書カテゴリー毎にスタッフの認証を得るスタッフログイン認証手段を備える。指定された利用者に関して、スタッフがアクセス権限を有する文書を、施設毎、文書カテゴリー毎に参照するアクセス可能文書参照手段と、参照された複数施設にわたる文書を表示する複数施設文書表示手段を備える。」 「【０００１】 本発明は医療や介護、福祉機関で、患者や入所者などの記録文書や作業指示文書の作成、参照をコンピュータネットワークで効率的に行う電子カルテシステムに関し、施設毎に各々文書カテゴリーの構成が異なっていても、また、従事する多数の職種のスタッフが施設間で複雑に入り組んだ状況であっても、さらに、患者が病院、介護施設、在宅と移動したとしても、これらの多施設間で一貫した記録文書や作業指示文書の作成、参照を可能とし、スムーズな医療、介護、福祉連携活動を実現する多施設統合電子カルテシステムに関する。」 「【００２４】 図４は、本発明の多施設統合電子カルテシステムの全体構成の内、一施設内の構成を示す。施設毎に、その施設を利用している利用者のＩＤを管理する施設毎利用者ＩＤ管理手段がある。病院であれば、入院患者リストや外来患者リストであり、施設では、入所者リスト、訪問系サービスでは、訪問先リストなどである。各リストは、利用しやすいように、部屋番号順、五十音順、ＩＤ番号順等々がある。」 「【００２６】 また、各施設には、個々の施設で提供されているサービスに応じて、施設毎の文書カテゴリーと、文書カテゴリー毎の項目建て(書式定義)がある。この文書カテゴリー名のリストと、文書カテゴリー毎の項目建ての情報を、施設毎文書カテゴリー管理手段で記録し管理している。指定された文書カテゴリーの文書は、前記文書カテゴリー毎の項目建ての情報に基づいて作成、編集される。作成、編集された文書は、当該文書カテゴリーの施設毎文書カテゴリー毎記録手段によって記録される。 【００２７】 各施設において、スタッフの所属や職種によって、作成、編集できる文書カテゴリー、参照のみできる文書カテゴリー、参照も許さない文書カテゴリーなど、文書カテゴリー毎のアクセス権限の組合せが異なっている。施設毎文書カテゴリー毎アクセス権限管理手段において、図５に示すような管理テーブルを作成し、スタッフ毎、文書カテゴリー毎に、アクセス権限を管理している。ここでは、作成、編集、参照もできる○、参照のみ可能な△、一切参照できない×、で表示している。例えば当該施設に勤務している医師は、医師関連記事文書、医療上の作業指示文書や処方箋（オーダー文書）の作成、編集、参照が可能であるが、他職種である看護師や介護士の記事は参照しかできない。なお、たとえ医師であっても、勤務していない施設の医師記事やオーダー文書に関しては、当該施設の許可（アクセス権限付与）があれば、許可された範囲の文書カテゴリーに関して参照は可能であるが、文書の作成や編集は不可である。 【００２８】 端末からスタッフＩＤとパスワードあるいは生体認証等を入力することにより、スタッフの認証が得られる(スタッフログイン認証手段)。スタッフの認証が得られれば、前記施設毎文書カテゴリー毎アクセス権限管理手段によって、当該スタッフの文書カテゴリー毎のアクセス権限が明確になる。当該スタッフが指定した文書カテゴリーの作成、編集、或は参照のアクセス要求に対して、権限があれば当該アクセスを許可し、無ければ拒絶する。 【００２９】 図６は、本発明の多施設統合電子カルテシステムの全体構成を示す。ある利用者が複数施設でサービスを受けている場合、各施設に対して参照要求を送信する。この参照要求に対し、施設間利用者ＩＤ紐づけ手段を用いて、それぞれの施設における当該利用者ＩＤを得る。また、スタッフログイン認証手段で認証の済んでいるスタッフＩＤに対して、それぞれの施設の施設毎文書カテゴリー毎アクセス権限管理手段を用いて、どの文書カテゴリーにどのようなアクセス権限が与えられているかが特定できる。その施設で、当該利用者に関し、当該スタッフにアクセス権限のある文書カテゴリーが存在すれば、その参照文書データを参照要求元に送信する（アクセス可能文書参照手段）。参照文書データを受信した端末では、複数施設文書表示手段を用いて表示する。 【００３０】 ここでは説明の便宜上、施設毎利用者ＩＤ管理手段、施設間利用者ＩＤ紐づけ手段、施設毎文書カテゴリー管理手段、施設毎文書カテゴリー毎記録手段、施設毎文書カテゴリー毎アクセス権限管理手段、スタッフログイン認証手段は、施設内にあるサーバーなどに実装されているとしているが、状況に応じて、その一部ないし全部を中央サーバーに集約し、インターネットなどの通信回線で接続しても良い。中央サーバーにおいて、各施設システムの実装は物理サーバーごとに別々に割り当てても、同一物理サーバーを論理的に分割した仮想サーバーとしても良い。さらには、サーバー実体を保有せず、クラウドサービスをＳａａＳの形態で利用しても良い。また、複数施設文書表示手段は、端末に実装しても良いし、サーバー内で表示イメージを作成して、端末画面に送信しても良い。さらに、アクセス可能文書参照手段については、部分的に、従来例２で示した参照システムを含んだものであっても良い。 【００３１】 図７は複数施設文書表示手段によって表示されたカレンダー形式画面の一例を示す。横軸は日付、縦軸は文書カテゴリーの分類枠である。ここでは、医師記事、医師オーダー、看護記事などを例示している。この縦横軸の枠組み内に、文書の日付、文書カテゴリーの属する文書分類枠に各々の文書が表示されている。５月９日現在の表示であるが、５月９日午前まではＡ病院に入院、同日午後にＢ介護施設に転入所している。５月１０日以降は未来日付で入力されている予定が表示されている。このようにすることで、施設を移動しても、記事や指示の一連の流れが一覧でき、状況の把握が容易であり、見落としによる事故を予防できる。この文書カテゴリーの分類枠は、施設毎、スタッフ毎に任意に設定可能としている。」 「【００４０】 以上、実施例を説明したが、本発明の具体的な構成は前記実施例に限定されるものではなく、発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。 たとえば、本発明の施設毎文書カテゴリー毎文書記録手段では、文書データはＸＭＬ形式で記録し、アクセス可能文書参照手段においてもＸＭＬ形式で参照する実施例としているが、記録や送受信が可能であれば、ＪＳＯＮ、ＨＬ-７、ＣＳＶ等でも構わない。また、リレーショナルデータベースに記録された文書を、参照の際に適切な形式に変換する 構成とすることも可能である。」 「【図４】 ［図：0001429000000010.jpg］ 」 「【図６】 ［図：0001429000000011.jpg］ 」 イ 甲１－２（特開２０２１－５６８０７号公報） 甲１－２には、以下のとおりの記載がある。 「【００１３】 フェーズ１の本プラットフォームの位置づけは、「業務オートメーション」である。つまり、フェーズ１の本プラットフォームは、従来よりマニュアルにより行われていた、業務の自動化（オートメーション化）を実現させる。 フェーズ１の本プラットフォームで利用されるデータの取り扱いは、「ＳａａＳ間のデータ連携」である。ここで、「ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）」とは、インターネット経由で必要な機能を必要な分だけサービスとして利用できるソフトウェアのことをいう。つまり、フェーズ１の本プラットフォームは、複数のアプリケーションソフトウェア（以下、「アプリ」と呼ぶ）の相互間のデータ連携を実現させる。 フェーズ１の本プラットフォームの利用対象となるユーザは、「業務部門担当者」である。つまり、フェーズ１の本プラットフォームのユーザは、パートやアルバイトを含む、業務部門の担当者レベルの者となる。 フェーズ１の本プラットフォームの提供価値は、「業務工数削減（人件費、残業代）」である。つまり、フェーズ１の本プラットフォームは、企業等における人件費や残業代を抑えることを主目的として提供される。 フェーズ１の本プラットフォームに活用されるテクノロジーは、ＲＰＡ、及びＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。」 「【００５９】 図９には、ユーザＵの業務のうち、採用業務と、人事・労務業務との夫々に適用される本サービスの具体例が示されている。 【００６０】 採用業務では、例えば求人メディアＭに求人情報を提供する業務と、求人メディアＭを介してユーザＵに応募した転職希望者Ｈに関する応募者情報を、ＡＰＩによって採用管理システムに登録する業務と、求人メディアを介して転職希望者Ｈにスカウトメールや面接結果メールを送信する業務と、採用管理システムから進捗分析レポートを出力する業務とが発生する。また、応募者（転職希望者Ｈ）が採用に至った場合には、その者に関する情報（以下、「入社者情報」と呼ぶ）を人事情報システムに提供する業務が発生する。 本サービスによれば、これらの採用業務のうち、応募者情報を受付ける業務と、転職希望者Ｈにスカウトメールや面接結果メールを送信する業務と、人事情報システムに入社者情報を提供する業務と、採用管理システムから進捗分析レポートを出力する業務との夫々をＲｏｂｏＲｏｂｏ２００に行わせることができる。 【００６１】 人事・労務業務では、例えば採用管理システムにより提供される入社者情報を、ＡＰＩを介して人事情報システムに登録する業務と、労務申請を行う業務と、入退社に伴うアクセス権の付与や廃棄を人事データベース（ＤＢ）に登録する業務と、人事評価システムにより提供される評価情報を、ＡＰＩを介して人事情報システムに登録する業務と、勤怠管理システムにより提供される勤怠情報を、ＡＰＩを介して給与管理システムに登録する業務と、給与管理システムにより提供される給与情報を、ＡＰＩを介して人事情報システムに登録する業務とが発生する。また、給与管理システムにより提供される給与情報を会計システムに提供する業務も発生する。 本サービスによれば、これらの人事・労務業務のうち、採用管理システムにより提供される入社者情報を人事情報システムに登録する業務と、入退社に伴うアクセス権の付与や廃棄を人事データベース（ＤＢ）に登録する業務とをＲｏｂｏＲｏｂｏ２００に行わせることができる。」 「【図１】 ［図：0001429000000012.jpg］ 」 「【図９】 ［図：0001429000000013.jpg］ 」 ウ 甲１－３（特表２０１５－５２８１６８号公報） 甲１－３には、以下のとおりの記載がある。 「【０００４】 ＯＡｕｔｈ（Open Authorization）は、承認のためのオープンスタンダードプロトコルであり、利用者（企業の従業員等）が自分のアカウント認証情報（例えばパスワード）を共有することなしに、所与の位置（例えば所与のウェブサイト上）に記憶されているその利用者に関連する情報、又はその利用者のデータの全範囲へのアクセス権をサードパーティアプリケーションに付与することを可能にする。一部の知られているシステムはＯＡｕｔｈトークンを使用し、様々な装置（例えばラップトップコンピュータ、携帯情報端末（ＰＤＡ:personal digital assistant）、標準的な携帯電話、タブレットパーソナルコンピュータ（ＰＣ）等）の利用者のためにアプリケーションを認証する。しかし、知られているそのようなシステムでは、各アプリケーションが適切なＯＡｕｔｈ承認サーバにトークンを別々に要求する。このような要求は、利用可能な帯域幅及びプロセッサ時間を著しく使用することを概して伴い、一般に利用者の使い勝手を損なう原因になる。加えて、アプリケーションにアプリケーショントークンを発行することに、従業員が働く企業が直接関与することはなく、従って利用者のアプリケーションへのアクセスに対する所望のポリシ管理水準から外れる。」 「【００２６】 アプリケーションモジュール１４４は、ネットワーク１２０を介してクライアントアプリケーション１１６及び／又は１１８にアプリケーションデータを与えるように構成される、ハードウェアモジュール及び／又は（メモリ１３２内に記憶され且つ／又はプロセッサ１３４内で実行される）ソフトウェアモジュールとすることができる。例えば、クライアントアプリケーション１１６が給与支払アプリケーションである例では、アプリケーションモジュール１４４が与えるアプリケーションデータは、従業員の給与、労働時間、税金や他の源泉徴収、支払方法等に関するデータを含み得る。一部の実施形態では、かかるアプリケーションデータは、アプリケーショントークンプロビジョニング対応のアプリケーション承認システム１００に関連するモジュール、プロセス、及び／又は機能を、クライアントアプリケーション１１６及び／又は１１８が実行することを可能にし得る。一部の実施形態では、及び本明細書で更に詳細に説明するように、アプリケーションモジュール１４４が、クライアントアプリケーション１１６及び／又は１１８にアプリケーションデータを与える前に、通信装置１１０からアプリケーショントークンを受け取り、検証することができる。 【００２７】 アプリケーションサーバ１５０は、エンタープライズサーバ１３０が関連するエンティティ（例えば企業）とは別のサードパーティサーバとすることができる。アプリケーションサーバ１５０は、例えばウェブサーバ、プロキシサーバ、テレネットサーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、メールサーバ、リストサーバ、コラボレーションサーバ等とすることができる、サービス型ソフトウェア（ＳａａＳ:Software as a Service）ホストであり得る。」 「【００３０】 図２は、一実施形態による、利用者及び利用者に関連する通信装置上の承認済みクライアントアプリケーションを認証する方法を示すメッセージ流れ図である。図２は、アプリケーショントークンプロビジョニング対応のアプリケーション承認システム１００に関して論じる。２１０で、インストールクライアント１１４が、ネットワーク１２０を介してユーザ認証情報を送ることにより、アプリケーション配布モジュール１４０における利用者の認証を開始する。一部の実施形態では、認証がインストールクライアント１１４によって開始されても良く、別の実施形態では認証が、通信装置１１０において動作しているモバイルブラウザウィンドウによって開始されても良い。より具体的には２１０で、ユーザ認証情報は、ＯＡｕｔｈ２．０プロトコルを使用する通信装置１１０の各利用者に固有の識別情報を含むことができる。各利用者に関連する識別情報は、例えばユーザログイン、ユーザパスワード、従業員ＩＤ番号、個人識別番号（ＰＩＮ:personal identification number）、バイオメトリク情報（例えば指紋走査、網膜走査等に関連するデータ）、従業員のセキュリティ／アクセスレベル、企業の部門コード等が含まれ得る、ユーザ認証情報とすることができる。 【００３１】 アプリケーション配布モジュール１４０が、ネットワーク１２０を介してユーザ認証情報をインストールクライアント１１４（又はモバイルブラウザウィンドウ）から受け取り、２１２でその利用者を認証する。一部の実施形態では、アプリケーション配布モジュール１４０が、エンタープライズサーバ１３０のメモリ１３２内に記憶されているユーザ認証データベース又はルックアップテーブル内の特定のエントリに対して、ユーザ認証情報を突き合わせることによって利用者を認証することができる。ユーザ認証データベースは、例えば従業員並びに従業員の対応する役職及びセキュリティ／アクセスレベル、社会保障番号、従業員の個人識別番号（ＰＩＮ）等の一覧を含み得る。他の実施形態では、ネットワーク１２０に動作可能に結合される別の装置（例えば不図示のサーバ）のメモリ内にユーザ認証データベースを記憶することができる。様々な実施形態において、アプリケーション配布モジュール１４０は、例えばセキュアソケットレイヤ（ＳＳＬ:Secure Sockets Layer）、セキュアシェル（ＳＳＨ:Secure Shell）、ケルベロス、セキュリティ表明マーク付け言語（ＳＡＭＬ:Security Assertion Markup Language）等の連合プロトコル等、任意の適切な認証プロトコルを使用して利用者を認証することができる。」 エ 甲２－２（米国特許公開公報第２０１７／０３３７２５４号明細書） 甲２－２には、以下のとおりの記載がある。（なお、外国語文献の日本語翻訳文は、申立人の提出した甲号証の抄訳を採用し、一部、合議体が変更した。以下、同様。） 「[0008] コンピュータシステムの複数のインスタンスが、中央データ記憶システムにサブスクライブする。中央データ記憶システムは、インスタンスが互いに同期することを望むエンティティのセットを、それらのエンティティを表すスキーマとともに、各インスタンスから受信する。中央データ記憶システムは、様々なインスタンスから、識別されたエンティティに対する変更を受信し、競合を識別し、所定のインスタンスからの変更を他のサブスクライブインスタンスに同期する。」 「[0021] 図1は、全体的なビジネスシステムアーキテクチャ100の一実施形態のブロック図である。アーキテクチャ100は、複数のビジネスシステムインスタンス102および104を含み、これらは互いに地理的に離れていてもよい。図1はまた、ビジネスシステムインスタンス102または104のうちの1つ、あるいは全く別のインスタンスとすることができるビジネスシステム本部インスタンス106も示している。図1は、インスタンス102～106がすべて中央データ記憶システム108にアクセスできることを示している。アクセスは、直接、またはネットワーク110を介して行うことができる。本論では、ネットワーク110を介してシステム108にアクセスするインスタンス102～106に関して説明を進める。ネットワーク110は、ローカルエリアネットワーク、ワイドエリアネットワーク等とすることができる。また、以下により詳細に説明するように、アーキテクチャ100は、クラウドコンピューティングアーキテクチャにおいても展開することができる。 [0022] 図1はまた、複数の異なるユーザ112、114および116が、ビジネスシステムの異なるインスタンス102～106にアクセスすることを示す。ユーザ112～116は、ビジネスシステムに直接、またはそれぞれのユーザ装置 118、120、122 を介してアクセスすることができる。図1に示す実施形態では、ビジネスシステムのインスタンス102～106は、CRMシステム、ERPシステム、LOBシステム、または他のビジネスシステムなどのビジネスシステムの異なるインスタンスである。 [0023] 図1は、ビジネスシステムインスタンス102 が、プロセッサ124、ビジネスデータストア126、ビジネスアプリケーション128、顧客データ同期システム130、およびユーザインタフェースコンポーネント 132 を含むことを示している。もちろん、他のアイテムまたはコンポーネントも含んでよい。ビジネスデータストア126は、例示的に、エンティティ134、ワークフロー136、および他の情報138などのビジネスデータを格納する。一実施形態では、ビジネスアプリケーション128は、ビジネスデータストア126内のデータおよびワークフローその他の情報にアクセスし、インスタンス102をデプロイする組織のビジネスを実施するために、ユーザ112がタスク、アクティビティ、またはその他の操作を実行するためのユーザインタフェース表示を生成する。例えば、ビジネスアプリケーション128は、総勘定元帳アプリケーション、他の会計アプリケーション、ビジネスチャンスを開発および追跡するためのアプリケーション、在庫アプリケーション、出荷アプリケーション、または他のアプリケーションを含むことができる。 [0024] ビジネスシステムインスタンス104は、例示的に、プロセッサ140、ビジネスデータストア142、ビジネスアプリケーション144、顧客データ同期システム146、およびユーザインタフェースコンポーネント148を含む。ビジネスシステムデータストア142 はまた、エンティティ150、ワークフロー152、および他の情報156などのデータを例示的に格納する。ビジネスシステムインスタンス104の項目は、ビジネスシステムインスタンス102に関して説明したものと同様であってもよく、異なっていてもよい。 [0025] 図1は、ビジネスシステムインスタンス106 が、プロセッサ158、ビジネスデータストア160、ビジネスアプリケーション162、顧客データ同期システム164、およびユーザインタフェースコンポーネント166を含むことを示している。ビジネスデータストア160は、例示的に本部データ168を含み、それはインスタンス102および104に格納されたデータと同様であってもよく、異なっていてもよく、あるいは追加情報を含んでいてもよい。」 「[0027] また、組織が異なるビジネスシステムのインスタンス間で同期させたい情報である場合もあることに留意すべきである。例えば、ビジネスシステムを展開する組織は、顧客関係管理システムと企業資源計画システムにまたがって、顧客とベンダーの情報を同期することを望むかもしれない。また、給与計算システム、企業資源計画システム、人事要員名簿にまたがって従業員情報を同期させたい場合もある。組織は、操作価格設定ツール（価格設定エンジンなど）、企業資源計画システム、および組織内に配備されたベンダーシステム間で、製品および価格設定情報を同期することを望むかもしれない。もちろん、地理的または部門的に離れた場所に配備された同じビジネスシステムの異なるインスタンス間で情報を同期させたい場合もある。したがって、本議論では、ビジネスインスタンス102～106が同じビジネスシステムの異なるインスタンスであることを前提に進めるが、インスタンスを展開する組織によって様々なエンティティのデータ同期が望まれる場合、同じ組織によって展開される異なるビジネスシステムのインスタンスである可能性があることは理解されよう。」 「[0029] データ同期のセットアップおよび操作プロセスのより詳細な議論は、残りの図に関して後述するが、理解を深めるために、ここでは簡単な概要を提供する。各顧客データ同期システム 130、146 および164は、それぞれ、インスタンス102～106が同期のために所定の中央データ記憶システム108に接続できるようにするための機能を例示的に提供する。これらはまた、インスタンス102～106が、様々なインスタンス間で同期が保たれることをインスタンスが望む様々なエンティティ、またはエンティティのグループを識別することを可能にする。システム130、146および164は、例示的に、所定のユーザが同期を維持すべきエンティティの1つに変更を加えたことを識別する変更追跡コンポーネントを含む。顧客データ同期システムは、中央データ記憶システム108に断続的に接続し、それらのエンティティに変更をアップロードする。中央データ記憶システム108のデータ同期システム174は、例示的に、それらの変更を受信し、その変更がどの他のインスタンスと同期される必要があるかを識別する。また、解決する必要のある競合も図解的に特定する。インスタンス102～106のいずれかが、システム108に変更をアップロードするためにシステム108に接続するか、またはその所定のインスタンスに同期される必要がある変更を探すためにシステム108に接続すると、システム108内のデータ同期システム174は、所定のインスタンスにダウンロードされる必要がある同期データを準備する。所定のインスタンスの顧客データ同期システムは、中央データ記憶システム108から同期データをダウンロードし、それを自身のビジネスデータストアに同期させ、再び、解決する必要のある競合を識別する。」 「[0031] 図2および図2-1（まとめて図2）は、ビジネスシステムインスタンス102および104、ならびに中央データ記憶システム108を示すブロック図である。図2は、インスタンス102および104、ならびにシステム108からいくつかの項目を省略しているが、顧客データ同期システム130および146、ならびにシステム108上のデータ同期システム174をより詳細に示していることがわかる。また、説明はビジネスシステムインスタンス102とビジネスシステムインスタンス104の間のデータの同期に関して進むが、これらのインスタンスのいずれかとビジネスシステムインスタンス106、または他のインスタンスに関しても同じ操作を実行できることに留意されたい。インスタンス102とインスタンス104の間の同期は、例示のためだけに記述されている。 [0032] 図2は、インスタンス102のビジネスデータストア126が、インスタンス104と同期されるエンティティのセット180を含むことを示している。エンティティは、エンティティ182およびエンティティ184として識別される。これらのエンティティは、例えば、顧客エンティティ、ベンダーエンティティ、製品エンティティなどである。図2はまた、顧客データ同期システム130が、例示的に、変更追跡コンポーネント186、データ同期コンポーネント188、データインポート／エクスポートコンポーネント190、顧客構成コンポーネント192、プロビジョニングコンポーネント194、競合処理システム196、同期管理コンポーネント198、およびステージングデータストア200を含むことを示している。 [0033] 図2はまた、インスタンス104のビジネスデータストア142が、同期されるエンティティのセット 202 を含むことを示している。それらのエンティティは、エンティティ204およびエンティティ206を含む。インスタンス104の顧客データ同期システム146はまた、変更追跡コンポーネント208、データ同期コンポーネント210、データインポート／エクスポートコンポーネント212、顧客構成コンポーネント214、プロビジョニングコンポーネント216、同期管理コンポーネント218、競合処理システム220、およびステージングデータストア222を含む。 [0034] 図2は、中央データ記憶システム108のデータストア172が、インスタンス102および104から同期されるエンティティのスーパーセットを含むだけでなく、インスタンス102および104からのそれらのエンティティのスキーマも含むことを示している。同期されるエンティティは、それらのスキーマとともに、図2のブロック224で示されている。 [0035] インスタンス102と104で同じエンティティを表現するために使用されるスキーマがわずかに異なる場合がある。例えば、インスタンス104の顧客エンティティを表すために使用されるスキーマは4つのアドレスフィールドを含むかもしれないが、インスタンス104の顧客エンティティを表すために使用されるスキーマは2つの追加アドレスフィールドを含むかもしれない。このように、システム108は、スキーマのスーパーセットを保持するが、たとえそれらが任意の所与のエンティティに関して主に重複していてもよい。 [0036] システム108のデータ同期システム174は、例示的に、変更追跡コンポーネント226、および競合処理システム228（競合検出コンポーネント230および競合解決コンポーネント232を含む）を含む。また、例示的に、データインポート／エクスポートコンポーネント234およびステージングデータストア236を含む。 [0037] 様々なコンポーネントのより詳細な説明は後述する。しかし、簡単に説明すると、インスタンス102および104の変更追跡コンポーネント186および208は、ユーザが同期されるエンティティにいつ変更を加えたかを例示的に追跡する。データ同期コンポーネント188および210は、変更が中央データ記憶システム108に同期され、システム108から同期されるデータ（例えば、他のインスタンスで行われた変更）が所定のビジネスインスタンスにダウンロードされる同期プロセスを断続的に開始する。データインポート／エクスポートコンポーネント190および212は、例示的に、システム108にアップロードされる情報を準備し、そこからダウンロードされた情報を受信する。顧客構成コンポーネント192および214は、ユーザが（顧客構成コンポーネントが属する）ビジネスシステムインスタンスを中央データ記憶システム108に接続するように構成できるように、ユーザインタフェース表示を生成する。プロビジョニングコンポーネント194は、例示的に、ユーザが同期される特定のエンティティを識別することを可能にするユーザインタフェース表示を生成し、同期管理コンポーネント198および218は、例示的に、ユーザが、同期プロセスの特定の詳細（手動で開始されるか自動的に開始されるか、および自動的に開始される場合には、開始されるスケジュールなど）を設定することを可能にする。ステージングデータストア 200 および222は、システム108に送信されるデータ、およびシステム108から受信されるデータを格納する。競合処理システム196および220は、同期されるデータ内の競合を識別し、それらの競合を（自動的に、または手動で解決できるようにユーザインタフェース表示を生成することによって、または他の方法で）処理することを例示的に示す。 [0038] 中央データ記憶システム 108 内のコンポーネントについても、以下でより詳細に説明する。しかしながら、簡単に説明すると、変更追跡コンポーネント226は、他のインスタンスから受信した様々なエンティティへの変更に基づいて、どの特定のインスタンスにデータを同期させる必要があるかを識別する。例として、インスタンス102が、インスタンス104に同期されるべき所定のエンティティに変更を送信する場合、変更追跡コンポーネント226は、インスタンス104が次にデータを要求するときに、インスタンス102からのデータが識別され、インスタンス104に送信されるように、これを識別する。ステージングデータストア236は、競合処理システム228が競合検出コンポーネント230を使用して競合を検出し、競合解決コンポーネント232を使用して競合を解決できるように、様々なインスタンスから受信した同期データを格納する。データの準備が整うと、データインポート／エクスポートコンポーネント234によって、様々なインスタンス102および104に（要求に応じて）データを送信することができる。」 「[0048] 図3Fは、ユーザがその所与のインスタンスの同期操作を管理できるように生成することができるユーザインタフェース表示306の一実施形態を示す。ディスプレイ306は、例示的に、ユーザがタイムゾーンを指定することを可能にするタイムゾーンメカニズム308と、ユーザが同期操作の反復スケジュールを設定することを可能にする一連のユーザ入力メカニズム310とを含むことがわかる。メカニズム310は、ユーザが同期を開始する開始日時を設定し、同期スケジュールを終了する終了日時または同期操作の回数を設定することを可能にする。ユーザインタフェースディスプレイ306は、ユーザが同期操作の繰り返しパターンを設定することを可能にする一連の入力メカニズム312も例示的に含む。例えば、ユーザは、ある分数、時間数、日数、週数、月数、年数などの後に反復が発生するように設定することができる。一実施形態では、ユーザは、同期操作を手動で開始することを指示することもできる。同期動作を設定するユーザ入力を受信することは、図3のフロー図のブロック314で示されている。自動か手動かの設定はブロック316で示され、開始時刻と終了時刻の設定はブロック318で示される。繰り返しパターンの設定はブロック320で示される。もちろん、ユーザは他の管理入力も提供でき、これはブロック322によって示される。」 「[0053] インスタンス102のデータ同期コンポーネント188は、最初に、データを同期する時間であるかどうかを決定する。その際、データ同期コンポーネント188は、構成プロセス中にユーザによって入力された反復スケジュールおよび他の同期設定情報に例示的にアクセスする。同期プロセスを開始すべきかどうかの決定は、図5のブロック350によって示される。」 「[0061] 変更追跡コンポーネント226は、データをデータストア172に格納されたデータと比較し、どのような他のインスタンスにデータを同期させる必要があるかを決定する。競合検出コンポーネント230もデータを調べて競合を検出する。ステージデータとデータストア172内のデータとの比較および競合の検出は、図6のブロック384によって示される。 [0062] 競合が検出された場合、競合解消コンポーネント232は競合の解消を例示的に試みる。これは、図6のブロック386および388によって示される。いくつかの競合は、ブロック390によって示されるように、例示的に自動的に解決することができる。他のものは、後の解決（手動解決など）のために単に保持される。これはブロック392で示される。競合を処理するために他のアクションも取ることができ、これはブロック394によって示される。 [0063] 例として、競合は、競合解決ルールのセットにアクセスすることで自動的に解決することができる。例えば、特定のインスタンスにのみ、特定のエンティティを変更する権限を与えることができる。さらに、競合が発生したときに、あるインスタンスの変更が別のインスタンスの変更よりも優先されるように、変更の階層を設定することもできる。この場合、次の同期操作では、最上位のインスタンスによる変更のみが他のインスタンスに同期される。競合の解決には他のルールも使用できる。 [0064] いずれにしても、競合が解決されると、競合していないすべての同期データがデータストア172に置かれる。これは図6のブロック396で示されている。所定のインスタンスが同期データの受信を呼び出すと、そのインスタンスに同期する必要があるすべてのデータが、データインポート／エクスポートコンポーネント234によって準備される。これは図6のブロック398で示されている。その後、同期データは所定のビジネスシステムインスタンスに送信され、そこで図5に関して上述したように処理される。これは図6のブロック400で示されている。」 「[0071] 中央データ記憶システム108の観点からは、インスタンス102と104の両方が、他方が行った変更について知ることなく、アカウントA222の顧客名を変更する。したがって、競合が存在し、競合解決が求められる。この場合も、中央データ記憶システム108の競合解決コンポーネント232は、競合解決規則が許可する場合、競合を自動的に解決することができ、または、競合を手動解決のために脇に置くことができ、または、そうでない場合もある。」 「[0077] 図7は、クラウドアーキテクチャの別の実施形態も示している。図7は、システム108のいくつかの要素がクラウド502に配置される一方で、他の要素が配置されないことも企図されていることを示している。一例として、データストア126、142、160、および172は、クラウド502の外部に配置され、クラウド502を介してアクセスされ得る。別の実施形態では、データ同期システム174もクラウド502の外部にある。それらがどこに配置されているかにかかわらず、それらは、ネットワーク（ワイドエリアネットワークまたはローカルエリアネットワークのいずれか）を介して、インスタンス102、104、106によって直接アクセスすることができ、サービスによってリモートサイトでホストすることができ、またはクラウドを介してサービスとして提供することができ、またはクラウドに存在する接続サービスによってアクセスすることができる。また、インスタンス102、104、106の1つ以上をクラウド502に配置することもできる。これらのアーキテクチャはすべて、本明細書において企図される。」 「 ［図：0001429000000014.jpg］ 」 「 ［図：0001429000000015.jpg］ 」 「 ［図：0001429000000016.jpg］ 」 「 ［図：0001429000000017.jpg］ 」 オ 甲３－１（米国特許第１０４６７４２６号明細書） 甲３－１には、以下のとおりの記載がある。 「本開示は、クラウドベースのソフトウエアサービスに対してなされる動作を管理するプラットホームに関する。プラットホームは、データオブジェクトを管理する。 ソフトウエアサービスよって処理されるデータオブジェクト及び／又は処理イベントを開始するそれたオブジェクトのエンティティを管理する。プラットホームは、処理イベントを追跡するために、例えば永続識別子（ＩＤ）などのような様々な識別子を使用する。プラットホームは、管理対象データオブジェクト及び／又は管理対象エンティティに関するルール及び／又は権限を実行し、処理イベントが要求に従っているか否かを決定する。プラットホームは、データベースレコードを更新し、アラートを送信し、データグラフを送信し、又は、管理対象データオブジェクト及び／又は管理対象エンティティに関するリアルタイムのストリームを提供することができる。」（ABSTRACT） 「本開示は、クラウドコンピューティング環境における複数のSaaSアプリケーションで操作されるデータオブジェクト（例えば、ファイル、カレンダ、ユーザ、グループ、装置、ハードウエアなど）を管理する方法及びシステムに関する。本開示の実施例は、コンピュータハードウエア及びソフトエアで構成されるクラウドコンピューティング環境で実行される。ハードウエアは、一又は二以上のクライアント装置でソフトウエアサービスを提供する分散型環境で構成される一又は二以上のサーバを含む。クライアント装置は、サーバサイドのソフトウエアアプリケーションのインスタンスで実行できる。クライアント装置は、これらのソフトウエアサービスを使用して、データオブジェクトを操作する。」（第１欄第７～１８行） 「SaaSアプリケーションへのシフトが新しいフレームワーク及びツールを必要とし、ＩＴのプロフェッショナルが、それらの組織で重要なアプリケーションを管理、保証、及びサポートすることを可能にするという結果となる。しかしながら、現在、エンタープライズSaaSアプリケーションを管理する構造的な方式は存在しておらず、さらに、クラウドコンピューティング環境で様々なユーザ、プログラム、及び装置の中及びそれらの間で移動するデータに関する安全なゴール及び要求をＩＴのプロフェッショナルが達成することを促進するツール及び技術も存在していない。要するに、複数のSaaSアプリケーションを備えたコンピューティング環境でデータオブジェクトを管理する機能を向上させる必要性が存在している。本開示は、これら及び他の効果を提供する。」（第６欄第１０～２２行） 「管理対象データオブジェクト若しくは管理対象エンティティの一方又は両方は、それぞれ独立して、複数の管理対象データオブジェクトのそれぞれ又は管理対象エンティティのそれぞれによって定義可能な一又は二以上の権限に関連付けされる。」（第９欄第３２～３６行） 「管理対象データオブジェクトに対して非準拠通知が生成された場合、管理対象データオブジェクト、管理対象エンティティ、および/またはサードパーティ実行者に関連付けられた 1 つ以上の権限を、その管理対象データオブジェクトに関連して変更できる。このような権限の変更は、システム(コンプライアンスモジュールなど)、ＩＴ管理者、またはその両方によって自動的に生成できる。理解されるように、管理対象データオブジェクト、管理対象エンティティ、および/または実行者ごとに多数の権限が存在する可能性がある。非限定的な例では、これらには、管理データオブジェクトのアクセス、作成、表示、結合、変更、共有、送信、コピー、印刷、削除、または変更が含まれ得る。管理対象データオブジェクトが 1 人以上のユーザ、グループなどによって不適切に共有され、コンプライアンス違反通知が生成された場合、そのユーザまたはグループの権限を変更して、そのようなコンプライアンス違反操作の将来の発生を軽減または排除できる。たとえば、ユーザの権限を「読み取り、書き込み、共有、印刷」から「読み取り、書き込みのみ」または「読み取り専用」のみに変更できる。」（第２０欄第８～２８行） 「さらに、本開示のシステム及び方法は、管理対象データオブジェクトの選択で実行される処理イベントに視認性を与えることによって、管理上のルールアプリケーションを追跡、管理、監査などすることを可能にする。これに関し、選択された管理対象データオブジェクトで取られる動作は、動作がネットワークの管理者のレベルでは実際に見ることができないにも関わらず、SaaSアプリケーションに関連付けされる権限を推測することを可能にする。理解されるように、これは、ユーザやグループなどに関連付けされる権限の数を削減するような効果をもたらすことができる。これに関し、SaaSアプリケーション、特に、発展的な形式での発達が十分でないSaaSアプリケーションは、最高管理者及び最終ユーザなどのような、それらの間を設定できない二値的な管理上の選択肢のみ提供する。したがって、最高管理者として指定されるであろうユーザがいくつかの権限のみを必要とするとしても、最高管理者は、全システムの管理上のSaaSアプリケーションにおける制御及び特徴へのフルアクセスを有するユーザとなる。ユーザは、最高レベルの権限を有することによって、最高レベルのセキュリティ及び管理設定を含むユーザが有するその権限のSaaSアプリケーション全ての側面を管理できる。したがって、ユーザは、ユーザの権限がコーポレートレベルにおける権限より劣るとしても、SaaSアプリケーションレベルにおける管理対象データオブジェクトへ全ての作成、参照、更新、及び削除（create、read、update、及びdelete “CRUD”）権限を有する。もし、CRUD権限情報が受信された場合、最高管理者権限の通知が提供され、それにより、関連する動作が取られ得る。例えば、いずれの管理上の機能をもたらすアクセスロールは、ユーザ（例えば、管理対象エンティティ及び／又はサードパーティ実行者など）が実行できる又は実行できないように定義され得る、そして、ユーザは、SaaSアプリケーションレベルでのこれらの値への彼の権限を調整するように指示される。例えば、ユーザには、彼のポジションや、部門などに応じて特定のロール及びセキュリティレベルが割り当てられ得る。特定のロール及びセキュリティレベル上で取られるそのような通知や動作は、自動によって、管理者によって、又はその両方によってなされる。」（第２４欄第４３行～第２５欄第１０行） 「この実装の非限定的な例として、人事またはその他のデータベースでユーザの内部職務記述が更新されると、そのようなステータスの変更は通知を介して管理者に自動的に提供される。例えば、ユーザの部門番号が変更された場合、その変更をＩＴ部門に提供することができ、管理対象データオブジェクトへのアクセスとそれに関連付けられた権限を自動的に生成できる。システムは、本開示の態様に従って処理されたすべての管理対象データオブジェクトを実質的に自動的に識別するように構成可能であり、そのような管理対象データオブジェクトは、ユーザの以前のポジションに関連付けられており、それらの管理対象データオブジェクトへのアクセスは取り消されるか、または取り消されることができる。生成されたポリシに従って変更されます。ステータス変更前にユーザが第三者と共有した、またはユーザが第三者にアクセスを許可した管理対象データオブジェクトを識別し、それに対して適切なアクションを実行できる。このような共有またはアクセスは、第三者のステータスまたは所在地に関連して特定できる。たとえば、第三者が組織の従業員である場合、または組織の従業員として認められていない人である場合は、第三者の許可に関する。識別された管理対象データオブジェクトは、生成されたポリシに従って取り消したり変更したりすることができる。」（第２８欄第７～３０行） 「図１は、本開示の様々な実施形態によるコンピューティング環境100の図である。コンピューティング環境は複数のプロバイダコンピューティングシステム101a-nを含む。プロバイダコンピューティングシステム101は、例えば、サーバコンピュータ、またはコンピューティング機能を提供する他の任意のシステムを含む。あるいは、プロバイダコンピューティングシステム101は、たとえば 1 つ以上のサーバーバンク、コンピューターバンク、またはその他の配置で配置される複数のコンピューティングデバイスを採用してもよい。そのようなコンピューティングデバイスは単一のインストール内に配置される場合もあれば、地理的に多くの異なる地域に分散している可能性もある。例えば、プロバイダコンピューティングシステム101は、ホスト型コンピューティングリソース、グリッドコンピューティングリソースおよび/またはその他の分散型コンピューティング構成を一緒に備え得る複数のコンピューティングデバイスを含むことができる。これに関し、プロバイダコンピューティングシステム101は、処理、ネットワーク、ストレージ、又は他のコンピューティング関連のリソースなどに割り当てられた容量が時間の経過とともに変化する可能性がある場合、融通性のあるコンピューティングリソースに対応させることができる。プロバイダコンピューティングシステムは、コンピューティングシステムのそれらリソースを使用する１つ以上の仮想マシンを実装することができる。 各プロバイダコンピューティングシステム101は、クラウドコンピューティング環境内のSaaSアプリケーションの形式で１つまたは複数のソフトウエアサービス103を提供する。上記説明したように、クラウドコンピューティング環境内で動作する1つ以上のSaaSアプリケーションは、本開示において定義されるような異種混合とすることができる。たとえば、特定のプロバイダコンピューティングシステム101aは、メッセージングまたは通信サービス、ドキュメント作成・管理サービス、CRMサービソフトウエアサービスーションサービス、ハードウェアデバイス制御などのソフトウエアサービス103を実行することができる。 プロバイダコンピューティングシステム内では、さまざまなデータがデータベース106、またはプロバイダコンピュータシステム101へアクセス可能な他のメモリに格納される。データベース106は、１つまたは複数のデータベース106として表すことができる。データベース106は、管理対象データオブジェクト109およびユーザアカウント112を格納することができる。ユーザアカウント112は、ユーザに、ソフトウエアサービス103に登録し、ソフトウエアサービス103にアクセスし、及びソフトウエアサービス103によって処理される管理対象データオブジェクト109を作成、編集、その他の操作をさせることを可能にする情報を含むことができる。ソフトウエアサービス103のユーザアカウント112は、ユーザのログインを容易にするために使用される。特定のプロバイダコンピューティングシステム101ａは、対応するユーザアカウント112に応じた各ユーザに対して、異なるアプリケーションインスタンスを作成します。ソフトウエアサービス103は、通常、ユーザアカウント112にしたがって追跡されるサブスクリプションのようなサブスクリプションベースで提供される。」（第３１欄第５～５１行） 「プラットホーム118は上記説明したクラウドコンピューティング環境の一部を形成する。プラットホーム118は、管理対象データオブジェクト109及びエンティティ127に関して上記説明した機能を提供する管理アプリケーション121を実行する。異なるプロバイダコンピューティングシステム101a-nのさまざまな異種ソフトウエアサービス103とインタフェースするマルチテナントSaaSアプリケーションとして実装される。 プラットホーム118内では、様々なデータが、データベース124またはプラットホーム118にアクセス可能なその他のメモリに格納される。データベース124は、１つまたは複数のデータベース124を意味することができる。データベース124は、管理対象エンティティ127、管理対象エンティティ識別子（ＩＤ）130、永続ＩＤ（PIDs）、コンプライアンスレコード136、ルール139、及び権限142を格納することができる。管理対象エンティティ127は、例えば、管理対象データオブジェクト109とやりとりするユーザのような実行者についての情報を反映する。これには、ユーザ名、アカウント情報、またはユーザ又は実行者に関連するその他のデータを含めることができる。管理対象エンティティＩＤは、管理対象エンティティ127を一意に識別するための識別子である。PID133は、対応する管理対象データオブジェクト109に割り当てられ、管理対象データオブジェクト109の管理及び追跡を可能にする。コンプライアンスレコード（また、不遵守コンプライアンスレコードと呼ばれる）などのようなデータベースレコード139は、管理対象データオブジェクト109でとられた動作及びその動作が１つ以上の権限又はルールに準拠しているかどうかのしるしを反映するデータログである。ルール139は、管理対象データオブジェクト109がコンピューティング環境100でどのように処理される又は他の操作がされるべきかを管理するポリシ又はプロトコルを含むことができる。ルール139の生成は、１つまたは複数の権限142に関連付けることができる。これに関し、権限142は、管理対象のデータオブジェクト109または識別された管理対象エンティティ127いずれかまたは両方に対して定義できる追加のルールに、及び識別された管理対象エンティティ127により管理対象データオブジェクト109に対して実行可能な１つ以上の処理イベントに関連付けることができる。 コンピューティング環境100は、さらに、ネットワーク115に接続されたクライアント環境145を含む。クライアント環境には、特定の組織に関連付けされたさまざまなクライアント装置を含むことができる。これは、組織のラップトップ、モバイル装置、デスクトップ、サーバ、タブレット、IoT装置、車両、または、コンピューティング機能を備えたその他のハードウェア装置のコレクションとすることができる。これらのクライアント装置のユーザは、クラウドコンピューティング環境100のソフトウエアサービス103と対話することができる。管理アプリケーション121は、ユーザが管理対象データオブジェクト109を処理するときに、クライアント環境109から開始される動作及び行動を追跡する。クライアント環境145は、管理対象データオブジェクト109を処理するために使用される任意のクライアントデバイスを意味する。ここで説明したクライアント環境145は、さらに、組織のセキュリティを侵害する身元を偽った不正なユーザによって使用されるクライアント装置を指すこともある。」（第３２欄第１６～６７行） 「コンピューティング環境100内では、処理イベント148がクライアント環境145からトリガされる。処理イベント148は、クライアント環境145内のクライアント装置を使用する管理対象エンティティによって、または、１つ以上の管理対象データオブジェクト109に関連付けされたクライアント環境の外部で動作するサードパーティ実行者によってトリガされてもよい。処理イベント145は、生成される処理イベント145を自動化するスクリプトまたはプログラムによって自動的にトリガされてもよい。 処理イベント145は、管理対象データオブジェクト109へのアクセス（例えば、ダウンロード）、作成、表示、マージ、変更、共有、送信、コピー、印刷、削除、または変更を目的として、特定のソフトウエアサービス103に送信される命令またはコマンドを含む。 コンピューティング環境100内では、処理イベント情報151が管理プラットホーム118によって受信される。例えば、プラットホームは、さまざまなソフトウエアサービス103が実行する操作を監視することによって、あらゆる処理イベント148を認識することができる。管理アプリケーション121は、SaaSベンダーが利用可能なAPIを使用して、管理対象データオブジェクト109の処理に関連するデータ変更およびイベントについての情報を受信することができる。」（第３３欄第１～２３行） 「図３は、図１の管理アプリケーション121がどのようにエンティティ（図１）を管理するかの例を示す。エンティティは、様々な実施形態に従って、複数のプロバイダコンピューティングシステム101a-n（図１）によって提供されるサービス103（図１）を使用する。図３の例では、第１のプロバイダコンピューティングシステム101aは、ファイルをリモートからアクセスでき、場合によっては公衆と共有できるように、ユーザが自分のファイルをアップロードおよびダウンロードできるようにするクラウドストレージシステムである。管理アプリケーション121は、永続ＩＤ（PID）133（図１）を作成し、ユーザに割り当てる。この例では、管理対象エンティティのPIDは「[email protected]」である。ユーザは、ファイルなどの管理対象データオブジェクト109に関連する処理イベント148（図１）（例えば、ダウンロード、アップロード、編集など）を実行することができる。この場合、ユーザは管理対象エンティティとみなされる。図２Ａには示されていない、管理対象エンティティがコンピューティング環境100内で対話できる１人以上のユーザは、管理対象エンティティでない。この点において、外部ユーザは、本開示の枠組みにおける「実行者」である。追加または代替として、ユーザは、スクリプトを実行するか、自動プロセスを使用してイベント148の処理を開始することができる。」（第３４欄第３３～５４行） 「図３は、第２のプロバイダコンピューティングシステム101bから受信した文書が、第１のプロバイダコンピューティングシステム101aを使用して不注意で公衆にどのように共有されるかを示す。管理アプリケーション121は、そのような望ましくない動作を監視するように構成されている。管理アプリケーション121は、財務グループによって作成されたファイルのパブリック共有を禁止するルール139に関する動作を監視するように構成され得る。管理アプリケーション121は、様々なプロバイダコンピューティングシステム101aおよび101bに関する処理イベント情報151（図１）を継続的に追跡する。PID133（図１）に関連付けられた処理イベント情報151が特定のルール139の対象である場合、管理アプリケーション121は、アラート154（図１）を生成することによって、または権限142を変更または取り消すことによってなどの動作を実行することができる。図３の例では、第１のプロバイダコンピューティングシステム101aを使用するユーザが、ルール139によって禁止されているファイルを公的に共有する場合、管理アプリケーション121は、アラート154を生成することによって応答する。」（第３５欄第４～２２行） 「図５は、様々な実施形態による管理アプリケーション121の動作の一例を示すフローチャートである。図５のフローチャートは、本明細書で説明するソフトウエアアプリケーションの一部の動作を実装するために使用できる多くの異なるタイプの機能構成の一例を提供するに過ぎないと理解される。代替として、図５のフローチャートは、１つまたは複数の実施形態によるコンピューティング環境100（図１）に実装される方法の要素の一例を示すものとして見ることができる。 502から始まり、管理アプリケーション121は、コンピューティング環境100内で発生する処理イベントを監視する。いくつかの実施形態によれば、管理アプリケーション121は、様々なプロバイダコンピューティングシステム101a-n（図１）からAPI情報を受信する。管理アプリケーション121は、特定の組織のコンピューティング環境に関連付けられたSaaSアカウントを使用する様々なユーザ（例えば、管理対象エンティティおよびサードパーティの実行者）によって行われるSaaS動作を監視する。処理イベント情報151（図１）が受信されると（５０２）、管理アプリケーション121は、プロバイダコンピューティングシステム101で実行されるソフトウエアサービス103によって生成されるAPIから情報を抽出することを含むことができる処理イベント情報を解析する。」（第３５欄第４７～６０行） 「505で、管理アプリケーション121は、処理イベント情報151に関連付けられた管理対象データオブジェクト109（図１）を識別する。例えば、処理イベント情報151は、「ファイルｘ」がパブリックＵＲＬを介して利用可能であることを示し得る。この場合、「ファイルｘ」は管理データオブジェクト109であり、「リンクを介した共有」のイベントは、クライアント環境145（図１）に関連付けられた実行者によってトリガされる処理イベント148（図１）である。管理アプリケーション121は、管理対象データオブジェクト109がPID133に関連付けられているか否かを判定する。管理アプリケーション121は、データベース124（図１）を相互参照して、管理対象データオブジェクト109のPIDが存在するか否かを判定する。PIDが存在しない場合、508で、管理アプリケーション121はその管理対象データオブジェクトのPIDを生成し、将来の使用に備えてデータベース124に格納する。PIDが存在する場合、511で、管理アプリケーション121は、処理イベント148に関連付けられたPIDを取得する。」（第３５欄第６１行～第３６欄第１０行） 「メモリ606に記憶され、プロセッサ603によって実行可能な他のアプリケーションが存在し得ることが理解される。ここで説明するコンポーネントがソフトウェアの形式で実装される場合、C、C++、C#、Objective C、Java（登録商標）、JavaScript（登録商標）、Perl、PHP、Visual Basic（登録商標）、Python（登録商標）、Ruby、Flash（登録商標）またはその他のプログラミング言語などの多数のプログラミング言語のいずれかを採用し得る。」（第３６欄第６５行～第３７欄第５行） 「 ［図：0001429000000018.jpg］ 」 「 ［図：0001429000000019.jpg］ 」 「 ［図：0001429000000020.jpg］ 」 カ 甲３－２（米国特許公開公報第２０１２／０３２４５３９号明細書） 甲３－２には、以下のとおりの記載がある。 「一態様では、サービスとしてのソフトウェアプラットフォームにおける動的アプリケーション適応は、共有データ管理および展開された複数のアプリケーションを有するサービスとしてのソフトウェアプラットフォーム内の公開された共有データ管理データオブジェクトに関連付けられたアクセス権限を受け取ることができ、受け取ったアクセス権限に基づいて、サービスとしてのソフトウェアプラットフォーム上に展開されたアプリケーションの１つ以上の機能に関連付けられた１つ以上のルールを検索し、前記１つ以上のルールに基づいて、前記複数のアプリケーションに関連付けられた前記１つ以上の機能をアクティブ化または非アクティブ化することができる。」（ABSTRACT） 「[0001]本出願は、一般にコンピュータおよびアプリケーションに関し、より詳細には、サービスとしてのソフトウェアプラットフォームにおける動的アプリケーション適応に関する。」 「[0005] 地方自治体は独立したアプリケーション間の統合に料金を支払う選択肢があるが、その費用は通常法外に高い。さらに、ITアプリケーションを単一の特定の部門に関連付けることが、サービス提供の制限要因になる可能性がある。アプリケーションは新しいニーズに柔軟に対応できないため、現時点では、この情報を複数の部門のソフトウェアに反映させる唯一の方法は、手動で継続的に送信および入力を行うことである。」 「[0006]サービスとしてのソフトウェアプラットフォームにおける動的アプリケーション適応のための方法およびシステムが提供され得る。この方法は、一態様では、共有データ管理および複数のアプリケーションが展開されたサービスとしてのソフトウェアプラットフォームにおいて公開された共有データ管理データオブジェクトに関連付けられたアクセス許可を受信することを含むことができる。この方法はまた、受信したアクセス許可に基づいて、サービスとしてのソフトウェアプラットフォーム上に展開されるアプリケーションの１つまたは複数の機能に関連付けられた１つまたは複数のルールを検索することを含んでもよい。この方法はさらに、前記１つまたは複数のルールに基づいて、前記複数のアプリケーションに関連付けられた前記１つまたは複数の機能をアクティブ化または非アクティブ化することを含んでもよい。」 「[0008] 本明細書に記載される１つまたは複数の方法を実行するために機械によって実行可能な命令のプログラムを記憶するコンピュータ可読記憶媒体も提供され得る。」 「[0013] 共有データ管理(SDM)は、例えば、Software-as-a-Serviceプラットフォームにおいて、アプリケーション間でのプラットフォームを介したデータ共有を可能にする。Software-as-a-Service(SaaS)とは、ソフトウェアやアプリケーションをオンデマンドで、例えば「従量課金制」モデルなどのサブスクリプション方式で提供することを指す。顧客またはユーザは、たとえば、顧客の必要に応じて、ソフトウェアアプリケーションの使用をサブスクライブする。典型的には、サービスとして提供されるアプリケーションは、顧客がネットワーク(例えば、ブラウザまたは類似のインタフェースを介したインターネット)を介してアクセスすることができる遠隔プラットフォーム上で実行される。リモートプラットフォームには、さまざまなアプリケーションが含まれ得る。たとえば、SaaSのプロバイダは、アプリケーションを実行するためのコンピューティングプラットフォームとリソースを提供する。アプリケーションは、プロバイダによって開発されたものでなくてもよく、独立系ソフトウェアベンダによってプラットフォームに展開およびセットアップされているものであってもよい。SDMは、共通データベースシステム、共通データオブジェクトスキーマまたはモデル、およびそれらのアプリケーションがデータを共有できるようにするためのロジックまたはアルゴリズムを提供する。SDMについては、「Shared Data Management in Software-As-A-Service Platform」と題した 2011年3月18日付け共同出願の米国特許出願１３／０５１，３０３号に詳細に記載されている。この明細書は、その全体が参照により本明細書に組み込まれる。ＳＤＭは、動的なデータ取引のためのデータマーケットプレイスまたはデータブローカとして機能し、アプリケーション間のデータ取引を可能にする。ここでのデータ取引とは、アプリケーションによって指定されたオファーおよび要求を意味する。アプリケーションはデータ (共有オブジェクトや属性など) の更新を提案する場合があります。アプリケーションは、データ（共有オブジェクトや属性など)への読み取りアクセスを要求することができる。「Open Data Marketplace for Municipal Services」と題された(代理人整理番号 YOR920110339)共同出願の米国特許出願、______日に出願された第______号は、データ マーケットプレイスについて説明している。 「Enforcing Data Sharing Policy through Shared Data Management」と題され(代理人整理番号 YOR920110340)、______日に出願された第______号には、データ共有の施行について記載されている。これらの出願は、その全体が参照により本明細書に組み込まれる。 [0014] データ取引では、アプリケーションが共有オブジェクトの特定の属性を更新することを提案することができる。一態様では、更新オファーはオプションである。SDM 管理者は、アップデートのオファーを受け入れるか拒否することができる。また、データ取引では、アプリケーションが共有オブジェクトの特定の属性への読み取りアクセスを要求することができる。読み取りリクエストは、アプリケーションによってオプションまたは必須として指定できる。必須の読み取りリクエストが拒否された場合、アプリケーションは基本的な機能を実行できなくなる可能性がある。たとえば、税務アプリケーションに土地区画の評価額への読み取りアクセスがない場合、アプリケーションは税額の計算を実行できないことがある。オプションの読み取り要求は、たとえばビジネス要件に基づいて、SMD 管理者によって許可または拒否され得る。オプションの読み取りリクエストが拒否された場合、機能が低下してアプリケーションの動作が継続することとなる。本開示の一実施形態では、アプリケーションは権限の変更に適切に適応できるようになる。 [0015] アプリケーションは、例えば権限関連の対話およびデータ対話など、異なるモードでSDMと対話することができる。たとえば、アプリケーションがサブスクリプションセットに追加されるとき、アプリケーションがデータ取引（たとえば、データの更新の申し出および/またはデータの読み取りの要求）をSDMに送信し、アプリケーションが許可または拒否された権限の通知を受け取るような、権限に関連した対話が存在する。アプリケーションの通常の動作中、権限に関連する対話は、SDMの管理者による権限の変更に応じてアプリケーションに権限変更通知を送信し、アプリケーションが通知を受信することが含まれる場合がある。SDMとのデータ対話は、アプリケーションの通常の動作中に発生する可能性があり、SDMによって管理されるデータのアプリケーションによる読み取りおよび/または更新が含まれる場合がある。 [0016]データアクセスに対する権限の変更は、プレゼンテーション層、プログラムロジック、永続層などのSaaSプラットホーム上で実行されるアプリケーションのすべての部分に影響を与える可能性がある。例として、Web ページと、ユーザがオブジェクトの属性値を更新できるようにするページ上のフィールドとを含むプレゼンテーション層を考えてみる。その属性の更新オファーが受け入れられない場合、そのフィールドを無効にして Web ページをユーザに表示する必要がある。別の例として、読み取りアクセス要求がオプションの属性に対して拒否された場合、その属性は Web ページなどのプレゼンテーション層に表示されるべきではない。また、拒否された権限に関連付けられたデータを処理するプログラムロジックの変更が必要になる場合もある。さらに、永続層では、許可または拒否された権限に基づいてデータベースアクセスパターンを変更する必要もあり得る。たとえば、更新オファーが受け入れられた場合、アプリケーションは独自のデータベースでもデータの更新を続行できるが、データは常に SDM から読み取られる必要がある。そのデータにアクセスする他のアプリケーションも、データの一貫性を確保するためにSDMから読み取る必要がある。 [0017] 図１は、SaaSプラットホーム内のアプリケーションが共有データ内の権限の変更に動的に適応できるようにするためのシステムのコンポーネントを示す。SaaSプラットホーム上にプラットホームケーション106は、プレゼンテーション層108およびプログラムまたはアプリケーションロジックコンポーネント110を含むことができる。プレゼンテーション層は、ユーザまたはクライアントと対話するためのコンピュータ（マシン）ロジックまたはコンピュータ（マシン）命令を含むことができる。例えば、対話は、ブラウザ112などのクライアントユーザインターフェースを介して実行される。例示的なブラウザ112には、ウェブブラウザが含まれる。SDM104の統合ＤＢ（データベース）永続層114は、アプリケーションのローカルデータベース116に対するデータを格納する。SDM１プラットホームプラットフォーム上で実行されるアプリケーション間の共有データを管理する。 SaaSプラットホーム上で実行されるアプリケーションは、例えば、アプリケーションが開始されると、SDM104と通信し、権限適応ハーネスモジュールまたはコンポーネント102を介してSDM104から最新の権限を取得する。権限適応ハーネスモジュールまたはコンポーネント102は、アプリケーション106にリンクされ得るライブラリ機能として実装され得る。通常の動作中、権限適応ハーネスコンポーネント102は、SDM104から権限関連の更新通知を受信し続け、アプリケーション106が権限情報を取得できるようにする便利なアプリケーションプログラミングインターフェース（API）を提供する。権限適応ハーネスコンポーネント102は、権限に基づいてSDM104との間でデータをルーティングするために、プレゼンテーション層108と緊密に統合され得る。プレゼンテーション層108における変更は、プログラムロジック106の変更に伝播され、さらに永続層114にも伝播され得る。」 「[0019] 別の態様では、ユーザは、例えば、アプリケーションが異なる権限シナリオに基づいてどのように異なる動作をするかを決定または視覚化するために、what-ifシナリオを実行することができる。たとえば、ルールや権限を変更することによって、さまざまな仮定のシナリオをテストすることができる。 [0020] 図２は、別の態様における本開示のシステムコンポーネントを示す図である。 [0021] SaaSプラットホーム管理者は、管理されているSDMデータモデルを公開することができる。データモデルには、SDM202で管理されるデータオブジェクトおよびその属性が含まれる。公開されたSDMデータモデル上のオファーおよびリクエストを用いて開発されたアプリケーション204a、204b、204c、204nは、SaaSプラットホーム206に登録され得る。さらに、SaaSプラットホーム管理者は、SaaSプラットホーム206上のアプリケーションのカタログ208に新しいアプリケーションを追加する。アプリケーションのカタログ208は、SaaSプラットホームに登録されているアプリケーションのリストを含むことができる。アプリケーションがSaaSプラットホームに登録されると、アプリケーションは、アプリケーションカタログまたはサービスカタログ208に表示される。SaaSプラットホームのエンドユーザはカタログを閲覧し、カタログから１つ以上のアプリケーションを購読する。購読されたアプリケーションは、エンドユーザのサブスクリプションセットに表示される。ポータル216は、SaaSプラットホームで利用可能なさまざまなサービスを表示する。これには、(1)ユーザがプラットホームで利用可能なサービスを閲覧し、１つまたは複数を購読できるアプリケーションカタログ、(2)ユーザのサブスクライブされたアプリケーションセット、 (3)サブスクライブされた各アプリケーションのユーザ インターフェース。(4)ユーザがアカウント情報やその他の情報を編集できるアカウントページまたは管理ページ、(5)カスタマーサービスページ、(6)その他のサービスページが含まれる。ポータルに表示されるサービス及びページは、例えば、エンドユーザや管理者などの役目に応じてユーザごとに異なるようにすることができる。たとえば、エンドユーザには、オファーや要求についての権限を付与または拒否するために管理者が使用するSDMエディターが表示されない。 [0022] データモデルで公開されたデータを所有するシステムの管理者は、例えば、共有データエディタ210を介して、データ取引要求に対する権限を付与または拒否することができる。ワークスペースステージングエリア212が提供され、そこでは、管理者が権限を変更するときに、管理者は、変更された許可によって影響を受ける可能性のあるアプリケーション214の１つまたは複数の作業コピーを呼び出すことができる。アプリケーションの作業用コピーはアプリケーション (アプリ1、...、アプリ N) であるが、現在のデータ取引権限設定が適用される。管理者は、共有データエディタで権限設定を変更する。ただし、管理者は、プレゼンテーション層、ビジネスロジック、永続化ロジックなどについて、変更がアプリケーションにどのような影響を与えるかをエディタで完全に確認することはできない。変更を永続化する前に、管理者はエンドユーザには表示されない作業ステージング領域にアプリケーションを展開し、アプリケーションの変更の影響を確認することができる。管理者は、アプリケーションが許可の変更によって適切に動作していることを確認すると、その変更を永続化し、アプリケーションをエンドユーザが閲覧するポータル216に展開することができる。ワークスペースステージングエリア212を使用して、管理者は、変更されたプレゼンテーション層（例えば、ユーザインターフェース）および変更された権限に基づく機能を調査することによって、「仮定」分析を実行することができる。ワークスペースまたはステージング領域212は、アプリケーションおよび他のサービスが表示される一時的な場所である。すべてのサービスは、ポータル内で機能しているかのように動作します。違いは、ステージング領域が管理者のみに表示され、エンドユーザには表示されない。通常、エンドユーザはステージング領域の存在を認識しない。 [0023] ワークスペースステージ領域212で実行された仮定分析の結果から、管理者は、アプリケーションの作業用コピーを選択し、SaaSプラットフォームポータル214内のサブスクリプションセットにコミットすることができる。選択及びコミットされたアプリケーションのコピーは顧客のために展開され、構成されたプレゼンテーション層および機能とともにSaaSポータル214に表示される。 [0024] 図３は、本開示の一実施形態における動的アプリケーション適応を示すフロー図である。302で、SaaSプラットフォーム管理者は、SDMデータモデルを公開することができる。データモデルは、SDMによって管理されるオブジェクトのデータ構造、たとえばオブジェクトの属性やタイプを記述することができる。304で、公開されたSDMデータモデル上のオファーおよびリクエストを使用してアプリケーションを開発することができる。306で、アプリケーションをSaaSプラットフォームに登録することができる。308で、SaaSプラットフォーム管理者は、SaaSプラットフォーム上のアプリケーションのカタログに新しいアプリケーションを追加することができる。310で、顧客管理者はデータ取引要求に権限を与えることができる。 [0025] 本開示の一実施形態では、SaaSプラットフォームは「共有サービス」を提供する。「マルチテナンシー」機能を提供する。プラットフォームは一定レベルの「分離」を提供するため、複数のテナントは、他のテナントの存在を認識することなく、プラットフォームに展開されたハードウェアインフラストラクチャとアプリケーションとを共有できる。地方自治体向けのSaaSプラットフォームの例では、ニューヨーク州向けに設定されたSaaSプラットフォームは、複数の地方自治体、つまりテナント (例えば、ニュー キャッスルの町、コホーズ市、ママロネックの村、ウエストチェスタの郡) によって共有できる。プラットフォーム全体に対して１人の「SaaSプラットフォーム管理者」が存在する。このシステム管理者は、プラットフォームに登録されたアプリケーションを管理し、アプリケーションをプラットフォームのアプリケーション/サービスカタログに登録する。さらに、各テナントには「顧客管理者」または「SDM 管理者」と呼ばれる管理者が１人存在している。このセットアップでは、各テナントにSDM設定がある。物理的なSDMシステムは１つだけであるが、論理的には複数のテナントで共有される。各テナントには異なる「アプリケーションサブスクリプションセット」があり、データ取引の権限設定が異なる。各テナントのSDM管理者（顧客管理者とも呼ばれる）は、共有データエディタでデータ取引権限を変更できる。」 「 ［図：0001429000000021.jpg］ 」 「 ［図：0001429000000022.jpg］ 」 「 ［図：0001429000000023.jpg］ 」 キ 甲３－３（Haitham Yaish, Madhu Goyal and George Feuerlicht、「A NOVEL MULTI-TENANT ARCHITECTURE DESIGN FOR SOFTWARE AS A SERVICE APPLICATIONS」、平成２４年（２０１２年）、p．８２－８８） 甲３－３には、以下のとおりの記載がある。 「Software as a Service (SaaS) は、サードパーティプロバイダがマルチテナント アーキテクチャ設計に基づいて無制限の数のテナントにソフトウェアサービスを提供できるようにする web ベースの配信モデルである。マルチテナントは、SaaSの主な特徴であり、SaaS ベンダーは、同じハードウェアおよびソフトウェアインフラストラクチャ上で複数のテナントをサポートする単一インスタンスアプリケーションを実行できる。このアプリケーションは、テナントの期待とビジネス要件を満たすために高度に構成可能である必要がある。それにもかかわらず、マルチテナントアプリケーションの構成は、達成するのが困難で複雑な作業である。この論文では、構成可能なマルチテナントデータベーススキーマ、ユーザインターフェイス、およびアクセスコントロールの設計と開発において、マルチテナントアプリケーションをサポートするための構成可能なアーキテクチャ設計を提供するというコンテキストで、SaaSのマルチテナントに焦点を当てている。この新しい構成可能なマルチテナントアーキテクチャ設計は、マルチテナントSaaSアプリケーションの開発に重要かつ基本的なソリューションを提供し、それが実現されると、SaaS業界に極めて重要な貢献となる。」（第８２頁、要約） 「１ イントロダクション マルチテナントは、SaaSの主な特徴であり、SaaSベンダは、同じハードウェアおよびソフトウェアインフラストラクチャ上で複数のテナントをサポートする単一インスタンスアプリケーションを実行できる。これは、アプリケーション、ミドルウェア、仮想マシン、オペレーティングシステムの4つのソフトウェア層に適用できる(Kwok et al. 2008)。SaaSのアプリケーション層は、(1)アドホック/カスタム、(2)構成可能、(3)構成可能、およびマルチテナント効率、および (4)スケーラブル構成可能、およびマルチテナント効率の4つの層からなる成熟モデルを有する(Frederick and Carraro 2006; Hudli et al. 2009; Kwok et al. 2008)。この論文では、構成可能でマルチテナント効率の高いレベルに焦点を当てる。この成熟度レベルでは、単一のコードベースとメタデータサービスを備えたマルチテナント対応の設計が必要である。これにより、テナント間でリソースを共有し、異なるテナントに属しているデータ、情報、構成、設定を分離して区別する機能により、アプリケーションの表示と動作を構成できる。マルチテナント対応アプリケーションを使用すると、各テナントがアプリケーションのさまざまな部分を設計し、アプリケーションを再デプロイすることなく実行時にその動作を自動的に調整できる (Chong 2006)。したがって、マルチテナント対応アプリケーションの構成は、システムのダウンタイムを最小限に抑えるために、通常はアプリケーションの動作中に実行されるテナントのセルフサービスであり、テナントがアプリケーションを使用しているのは自分だけであるかのように感じることができる (Mietzner et al. 2009）。」（第８２頁左欄第１行～同頁右欄第８行） 「2.3 マルチテナント構成 マルチテナントアプリケーションの構成により、SaaSベンダは単一のインスタンスを実行して、構成可能なメタデータを使用して複数のテナントをサポートできる。これにより、マルチテナントアプリケーションの構成手段が提供され、ビジネスニーズを満たし、特定のビジネスドメインアプリケーションを使用する可能性のある複数のテナントごとに異なる要件の問題を解決できる。この成熟度レベルでは、単一のコードベースとメタデータサービスを備えたマルチテナント対応設計が必要である。これにより、テナント間でリソースを共有し、異なるテナントに属しているデータ、情報、構成、設定を分離して区別する機能を使用して、マルチテナントアプリケーションの表示と動作を構成できる。マルチテナント対応アプリケーションを使用すると、各テナントがアプリケーションのさまざまな部分を設計し、アプリケーションを再デプロイすることなく実行時の動作を自動的に調整できる (Chong 2006)。 3 アーキテクチャの概要 図1で提案されているシステムのアーキテクチャの概要は、webユーザインターフェイス、ユーザインターフェイスサービス、データベースサービス、アクセスコントロールサービス、およびデータベースを含む主要な 5 つの成果物を示している。データベースは、共通テナントテーブル (CTT)、エラスティック拡張テーブル (EET)、および仮想拡張テーブル (VET) の3種類のテーブルを含む。 このアーキテクチャは、3層アーキテクチャ設計に基づいて設計されている。webユーザインターフェイスは、プレゼンテーション層、サービスはアプリケーション層、そしてデータベースはデータ層である。」（第８３頁右欄下から６行～第８４頁左欄最終行） 「４ 概念的なアーキテクチャ設計 このセクションでは、SaaSベンダが、同じハードウエア及びソフトウエアインフラストラクチャ上でマルチテナントをサポートする単一インスタンスアプリケーションを実装できるようにする概念アーキテクチャ設計を提案する。この単一インスタンスアプリケーションには、マルチテナントアプリケーションの3つの側面(データベースモデル、ユーザインターフェイス、アクセスコントロール)を柔軟に構成できる。このアーキテクチャ設計は、顧客関係管理(CRM)、サプライチェーンマネジメント(SCM)、人事(HR)、またはその他のビジネスドメインなど、マルチテナントアプリケーションであらゆるビジネスドメインを実装するために使用できる。図2は、概念的なアーキテクチャ設計の重要な要素を非常に高いレベルで示している。」（第８４頁右欄第１～１７行） 「・エラスティック拡張テーブル (EET): これらのテーブルは、2種類のテーブルで構成されるエラスティックテナントデータベースを設計および作成する新しい方法を提案する。1番目のタイプは共通テナントテーブル(CTT)、2番目のタイプは仮想拡張テーブル (VET)であり、それぞれは、特定テナントのニーズを満たすために使用できる。たとえば、「テナント」テーブルは、情報を保存するために全てのテナントによって使用および共有されるCTTの1つであり、VETは、「テナント」共通テーブルにまだ含まれていない列をさらに含むことができる「テナント」テーブルの拡張であるとすることができる。(Yaish et al. 2011)。」（第８４頁右欄下から１４～最終行） 「・共通テナント テーブル (CTT): これらのテーブルは、同じ単一インスタンスのマルチテナントアプリケーションを使用しているテナント間で共有される。これらは、特定のビジネスドメインアプリケーションの基本スキーマを構築できる物理テーブルである。たとえば、販売ビジネスドメインのマルチテナントアプリケーションには、販売担当者、顧客、製品、販売事実、その他の販売テーブルなどの販売スキーマテーブルが含まれ得る。これらのテーブルには、ほとんどのテナントによって使用される列があるため、これらのテーブルは CTTと見なされる(Yaish et al. 2011)。また、CTTには、 (1)異なるテナントのユーザインターフェイス設定、基本設定、フィールドの検証、およびビジネスルールを保存するユーザーインターフェイステーブル、 (2)データ層およびプレゼンテーション層のさまざまなテナントのアクセスコントロール設定、基本設定を保存するアクセス制御テーブル、という2つのテーブルセットが含まれている。」（８５頁 左欄１～１９行） 「・仮想スキーマハンドラーサービス： このサービスは、CTTを更新することによって、また、VETを作成、更新、または削除することによって、テナントデータベーステーブルを構成する。これは、データベース構成ユーザインターフェイス画面で使用されるように公開されているサービスであり、これらの画面は、テナントデータベースCTTおよびVETの構成に使用される。このサービスは、(1)ユーザーインターフェイスアクセスコントロール設定及びおよび基本設定を使用して、データベース構成ユーザインタフェースへのアクセスを管理する、ユーザーインターフェイスアクセスコントロール設定サービス、(2)データベースのアクセスコントロール設定および基本設定を使用して、データベース構成ユーザインターフェイス画面へのアクセスを管理する、データベース アクセス制御サービス、(3)CTT および/またはVETの1つ以上のテーブルからテーブル構造とフィールドの詳細を取得および変更するためのプロキシサービス、のような他のサービスを利用する。 4.2 マルチテナントユーザインターフェイスの構成 使いやすいマルチテナントユーザインターフェイスの開発には複雑さが伴うため、CTT、EET、およびVETに関連付けることができる柔軟なユーザインターフェイスを作成するために、アーキテクチャ設計で構成可能なユーザインターフェイスが提案される。このユーザインターフェイスは、テナントの管理者によって構成され、実行中にコードを記述することなく、テナントのユーザに対して動的かつ即座にレンダリングが行える。このユーザインターフェイス設計は、ユーザインターフェイス構成サービスとユーザインターフェイスレンダリングサービスの2つのユーザインターフェイスサービスで構成される。 ・ユーザインターフェース設定サービス： いくつかの構成ユーザインターフェイス画面は、このサービスを利用して、ビジネスドメインのページ、メニュー、およびフィールドを構成することにより、マルチテナントアプリケーションのユーザインターフェイスを構成する。このサービスは、構成ユーザインターフェイス画面およびユーザインターフェイスレンダリングサービスによって使用されるように公開される。また、(1)構成ユーザーインターフェイス画面のためのユーザインターフェイスのアクセスコントロール設定と基本設定を使用する、ユーザインターフェイスアクセスコントロールサービス、(2)ユーザインターフェイス画面およびフィールドの設定に使用されるCTTおよび/またはVETの1つ以上のテーブルからテーブル構造及びフィールドの詳細を取得するプロキシサービスの2つの他のサービスも利用される。」（第８６頁左欄第４～最終行） 「4.3 マルチテナントのアクセスコントロールの構成 このセクションでは、ベンダが実装でき、テナントがマルチテナントアプリケーションと対話するユーザのアカウントを設定するために使用できるアクセスコントロール設計について説明する。これらのアカウントは、認証機能を使用して認証され得る。通常、マルチテナントアプリケーションは、特定の機能またはシステム機能にマップされるロールを使用することによって、リソースおよびビジネス機能にアクセスする。各ロールには1つ以上のパーミッションを持たせることができ、1つ以上のテナントのユーザに割り当てて、ユーザがテナントのビジネスルールに従って動作を実行できるようにすることができる。アクセスコントロール設計は、認証サービス、ユーザインターフェイスアクセスコントロールサービス、データベースアクセスコントロールサービスの3つのサービスで構成される。 ・ 認証サービス: このサービスは、テナントの管理者とテナントのユーザがマルチテナントアプリケーションにログインするときに認証するためにユーザインターフェイス画面で使用されるように公開される。これらのユーザインターフェイス画面には、エンタープライズポータルユーザインターフェイス、構成ユーザインターフェイス、アクセスコントロールユーザインターフェイス、およびデータベース構成ユーザインターフェイスが含まれる。このサービスは、プロキシサービスを介して認証CTTにアクセスするためにのみプロキシサービスを利用する。 ・ユーザインターフェースアクセスコントロールサービス： このサービスは、アクセスコントロールユーザインターフェイス画面で使用されるように公開されており、テナントの管理者がロールとパーミッションを作成し、ロール及びパーミッションをテナントのユーザにマッピングする。また、ユーザインターフェイスカスタマイズサービスと仮想スキーマハンドラサービスを含む他の2つのサービスでも使用できるように公開される。このサービスは、プロキシサービスを介してユーザインターフェイスのアクセスコントロールCTTにアクセスするためにのみ、このプロキシサービスを利用する。」（第８６頁右欄第１６行～第８７頁左欄第３行） 「4.4 ユーザーインタフェース このセクションは、構成ユーザインターフェイス、エンタープライズポータルユーザインターフェイス、データベース構成ユーザインターフェイス、およびアクセスコントロールユーザインターフェイスの4つのサブセクションに分かれている。 ・ 構成ユーザーインターフェイス: これは、テナント管理者がビジネスドメインのページ、メニュー、およびフィールドを構成することによって、マルチテナントアプリケーションのユーザインターフェイスを構成できるようにする管理ユーザインターフェイスである。次に、このユーザインターフェイスはエンタープライズ ポータルのユーザインターフェイスとしてレンダリングされる。このユーザーインターフェイスは、1つ目がテナント管理者がこのユーザインターフェイスにログインしようとしたときに認証を行う認証サービスである、2つのサービスを使用する。2つ目は、セクション4.2で説明したユーザインターフェイス構成サービスである。」（第８７頁 左欄第１４～３１行） 「 ［図：0001429000000024.jpg］ 」 「 ［図：0001429000000025.jpg］ 」 ク 本件訂正前の請求項４に係る発明に関する技術事項が記載された文献及び周知技術として提出された甲号証 上記第２の２（１）で示したように、本件訂正後の請求項１に係る発明である本件発明１は、本件訂正前の請求項４に係る発明に相当するものであるところ、申立人１～申立人３によって本件訂正前の請求項４に係る発明に関する技術事項が記載された文献及び周知技術として提出された甲号証は、次のとおりである。なお、申立人２は、本件訂正前の請求項４に係る発明に関する引用文献として、引用文献１のほか、上記エを提出した。 （ア）甲１－９（特開２０００－８２０８１号公報） 甲１－９には、以下のとおりの記載がある。 「【要約】 【課題】 サーバー装置内のマスタデータベースの内容の一部を、端末装置内のローカルデータベースに格納するようにしたネットワークシステムに於いて、ローカルデータベースに格納されているローカル情報の最新性を保証できるようにする。 【解決手段】 スケジュール設定部123には、ローカルデータベース121に格納するローカル情報それぞれの取得時期が設定されている。この取得時期は、マスタデータベース21に於けるマスタ情報の更新時期を考慮して決定されている。情報取得部131は、スケジュール設定部123の内容に基づいて取得時期になったローカル情報が存在すると判断した場合は、上記ローカル情報の取得要求をサーバー装置２に対して送信する。この要求に応答してサーバー装置２からローカル情報が送られてくると、情報取得部131はそれをローカルデータベース121に格納する。」 （イ）甲１－１０（特開２０００－９９３７７号公報） 甲１－１０には、以下のとおりの記載がある。 「【要約】 【課題】 予め任意のレコードを更新予定の対象レコードとして指定すると共に、いつどのような更新を行わせるかを指示する更新指示データをレコード別に設定しておくだけで更新予定の対象レコードをその設定時期に設定通りに更新する。 【解決手段】 社員情報ファイル１２-１内の社員レコードのうち任意のレコードを更新予定の対象レコードとして指定すると共に、この指定レコードを更新するための更新データをその更新時期を発令データとしてレコード別に未決裁発令ファイル１２-２に設定する。この状態において、更新時期に到達している発令データに基づいてＣＰＵ１は社員情報ファイル１２-１内の該当する社員レコードを更新する。」 （ウ）甲１－１１（特開平８－１２９５０１号公報） 甲１－１１には、以下のとおりの記載がある。 「【要約】 【目的】オンラインデータベースシステムにおいて、複数レコードの更新又は参照を予約登録することにより、オンラインシステムを停止することなくそれらの更新又は参照処理を実行できるようにすることを目的とする。 【構成】多数のレコードからなるデータベーステーブルを格納する記憶装置と、該テーブルの任意のレコードにアクセスするための処理装置を有するデータベース処理装置において、複数のレコードの更新又は参照処理をあらかじめ予約登録することにより、該予約されたアクセス処理を指定された予約アクセス時刻に（見掛け上）実行する。該予約更新処理は、該処理を予約登録するための前処理と、予約更新時刻以降の当該レコードへの最初のアクセス時に行なわれる予約更新後処理とで実行され、該予約参照処理は、該処理を予約登録するための前処理と、予約参照時刻以降に実行される後処理と、予約参照時刻以降かつ後処理以前の間に発生する当該レコードへの更新処理時に実行される予約参照バックアップ処理とで実行される。」 （エ）甲１－１２（特開平９－４４３８４号公報） 甲１－１２には、以下のとおりの記載がある。 「【要約】 【目的】 現在とは異なる任意の指定時刻においてデータベースをアクセスし、追加、変更、削除等の修正を可能にする。 【構成】 検索対象のデータベースはデータベース管理システム１に格納されている。時刻指定部４はいつの時点のデータベースに対しアクセスを行うかを設定する。問合せ発行部３は任意のアプリケーションから成り、アクセス時は指定時刻を意識することなく一般的な問合せを発行する。この問合せはアクセスフィルタ部１０において解釈され、指定時刻におけるアクセスとなるように定型的な問合せの組合せが生成される。これにより、あたかも指定時刻に問合せがあったようにデータベース管理システム１に対し問合せが発行され、その結果がアクセスフィルタ部１０を介して問合せ発行部３に返される。」 （オ）甲２－３（特許第３９２６６７４号公報） 甲２－３には、以下のとおりの記載がある。 「【請求項１】 複数の関連会社にそれぞれ設けられ、当該関連会社の財務管理を行う複数のアプリケーションシステムに共通のデータ項目を、前記複数のアプリケーションシステムからのデータに基づき前記関連会社全体の財務管理を統一的に行うアプリケーションシステムである財務管理システムにおいて管理するデータベースシステムであって、 前記複数のアプリケーションシステムに共通のデータ項目を、前記財務管理システムにおいて一括的に登録するためのマスタユニットと、 操作者による入力操作に基づいて前記共通のデータ項目の入力を行う端末装置と、 前記財務管理システムにおいて、該端末装置にて入力された前記共通のデータ項目を上記マスタユニットに登録すると共に、該共通のデータ項目を当該データベースシステムに情報通信可能に接続された前記複数のアプリケーションシステムにそれぞれ設けられた複数のデータベースシステムに対して登録する共通マスタ登録手段とを有し、 前記アプリケーションシステムにそれぞれ設けられた複数のデータベースシステムの各々は、前記複数のアプリケーションシステム毎に登録されたデータ項目とともに、前記共通マスタ登録手段によって登録された前記共通のデータ項目を保持することを特徴とするデータベースシステム。」 「【請求項４】 前記マスタユニットは、前記データ項目に関連する所定の管理項目に応じて複数設けられ ていることを特徴とする請求項１記載のデータベースシステム。 【請求項５】 請求項４記載のデータベースシステムにおいて、 上記統合マスタ登録手段は、上記端末装置にて上記データ項目と共に入力された当該データ項目を上記財務管理のアプリケーションシステムにおいて有効とすべき時期的条件を現時点が満足しない場合、上記データ項目が関連する管理項目に対応した複数のマスタユニットへの登録を行うことなく、当該データ項目を対応する時期的条件と共に保存する予約登録手段と、 上記時期的条件と共に保存されたデータ項目を、当該時期的条件を満足するタイミングにて上記複数のマスタユニットに一括的に登録する登録実行手段とを有するデータベースシステム。」 「【００３４】 図２において、共通データベースシステム３００は、データベースサーバ３０５にて実現される共通マスタ登録部３０５１を有している。この共通マスタ登録部３０５１は、端末装置３０６の入力画面から入力されたデータ項目の登録処理（科目登録、取引先登録、社員登録、銀行登録等）を実行する。この共通マスタ登録部３０５１は、入力されたデータ項目を当該共通データベースシステム３００に備えられた各個別マスタユニット３０１～３０３への書込みを行う。また、データ項目の個別マスタユニット３０１～３０３への書込みと共に、共通マスタ登録部３０５１は、その入力されたデータ項目を関係会社データベースシステム３２０に登録すべきデータ項目としてネットワークＮＷを介して送信する。そして、関係会社データベースシステム３２０のデータベースサーバ３２５の制御のもと、そのデータ項目が、個別マスタユニット３２１、３２２または財務マスタユニット３２３に書き込まれる。」 「【００３６】 また、上記共通マスタ登録部３０５１は、データ項目の予約登録を行うことができる。このデータ項目の予約登録は、次のようにしてなされる。 【００３７】 例えば、銀行の統合で銀行名が変わることが予定されている場合等、将来アプリケーションシステムで有効になるデータ項目を前もって共通データベースシステム３００の端末装置３０６から入力すると、そのデータ項目は、その時点では、各関係会社データベースシステム３２０、３４０に登録されることなく、共通データベースシステム３００の個別マスタユニット３０１～３０２だけに書き込まれる。そして、例えば、毎日午前０時にバッチ処理にてアプリケーションシステムに有効にすべきデータ項目の有無が判定される。そのようなデータ項目があると、そのデータ項目が共通マスタ登録部３０５１により登録すべきデータ項目として各関係会社データベースシステム３２０、３４０にネットワークＮＷを介して送られる。 【００３８】 登録されているデータ項目の更新及び新たなデータ項目の登録がタイムリーに行うことができるようになる。」 「【図１】 ［図：0001429000000026.jpg］ 」 「【図２】 ［図：0001429000000027.jpg］ 」 （カ）甲３－９（特開２０１３－２１８５７５号公報） 甲３－９には、以下のとおりの記載がある。 「【要約】 【課題】 ＩＤ情報を管理するＩＤ情報管理ＤＢの更新を自動的に行うと共に、その更新内容を事前登録する際の作業負荷を低減する。 【解決手段】 ＩＤ情報管理サーバ１０は、ＩＤ情報が登録されているＩＤ情報管理ＤＢ１０４と、ＩＤ情報管理ＤＢ１０４を更新するための予約情報が登録された予約情報管理ＤＢ１０２と、を備える。ＩＤ情報管理サーバ１０のＩＤ情報更新部１０３は、所定のタイミングで予約情報管理ＤＢ１０２にアクセスして、検索した予約情報に含まれる更新予定日が当日であるか否かを判定し、当日である場合には、当該予約情報の内容に基づいてＩＤ情報管理ＤＢ１０４の内容を更新する。予約情報登録部１０１は、アップロードデータ受信部１００によって受信された、端末装置からの第１の格納形式又は第２の格納形式のアップロードデータに基づいて予約情報管理ＤＢ１０２に予約情報を登録する。」 「【００２４】 ＩＤ情報更新部１０３は、ＣＰＵ等が、ＲＯＭ又は外部記憶装置に記憶されている、所定のプログラムを実行することで実現する機能部であり、所定のタイミング（例えば、定期的）に予約情報管理ＤＢ１０２にアクセスして、登録されている全ての予約情報を参照する。そして、有効開始日４０４に格納されている情報が示す年月日と、当日の年月日と、が一致する場合には、当該予約情報の内容に基づいて、ＩＤ情報管理ＤＢ１０４の対応するＩＤ情報の内容を更新する。そして、ＩＤ情報更新部１０３は、当該予約情報を予約情報管理ＤＢ１０２から削除する。」 「【図２】 ［図：0001429000000028.jpg］ 」 （キ）甲３－１０（特開２０１０－１１７８９９号公報） 甲３－１０には、以下のとおりの記載がある。 「【００１３】 管理部１０６は人事データベース１０７の更新を制御するように動作する。人事データベース１０７は、人事管理用の情報を保持するものであれけれども、この実施例との関係では、ユーザの所属する部門の情報、下位の部門が所属する上位の情報を保持する。通信ネットワーク４０を介してサーバコンピュータ２０（ジョブログ集計システム１００）に接続されたホスト端末３０Ｂを利用して人事データベース１０７の内容を異動情報に基づいて更新するよう指示できる。なお、この実施例では、実際の異動の前日に人事データベース１０７が更新されているものとする。前日の更新は、ユーザが直接に前日に更新指示を行ってもよいし、予め事前に指示を管理部１０６に供給しておくと管理部１０６が指示の前日に人事データベース１０７を更新するようにしてもよい。以下の例では、更新のタイミングは暦の上で予め定められているものとする。典型的には、月の初日に異動が行われ、更新が前月の末日に行われるけれども、これに限定されず、暦の上で予め定められ、システム上、既定のものであればどのようなものでもよい。週の初日、年の初め、年度の初めに異動が行われてもよい。」 （ク）甲３－１１（特開２００７－２４９５４０号公報） 甲３－１１には、以下のとおりの記載がある。 「【００４９】 更新フラグは、レコードのデータの更新内容を把握するために用意したフラグであり、０はデフォルト、１は新規（追加）、２は変更、３は削除、をそれぞれ表している。データ更新日付は、データ更新が行われた日付であり、人事異動では、その異動が行われる予定の日付となる。状態を示す値としては、変更無し或いは反映済みを表す０、未承認を表す１、及び承認済みを表す２、の何れかが格納される。 【００５０】 組織業務支援部２０２の更新部２１２は、バッファＢＦの内容を更新したレコードでは状態を示す値として１を格納する。異動日が設定されていれば、それをデータ更新日付として格納する。更新フラグとしては、そのレコードを新規に追加したのであれば１、変更したのであれば２、削除したのであれば３を格納する。そのようにして、バッファＢＦのなかで承認が必要なレコードを特定できるようにする。 【００５１】 承認部２１３は、状態を示す値が１となっているレコードを対象に、承認権を持つ端末装置１１２のユーザにその承認を行わせるものである。承認の対象とするレコードは、特に詳細な説明は省略するが、そのリストを提示して選択させるようにしている。それにより、そのユーザの要求に応じて、図１０に示すような業務用画面を表示させ、その画面上の「承認」ボタンをユーザがクリックすると、承認されたとして、状態を示す値を１から２に変更する。 【００５２】 更新管理部２１５は、状態を示す値が２となっているレコードを対象にして、図１１に示すように、その更新内容を更新反映部２１４によりワークＷＫ、マスタＭＳに反映させる。図１２に示すように、バッファＢＦからワークＷＫへの反映は、更新フラグの値に応じて行い、ワークＷＫからマスタＭＳへの反映は、上書きする形で行う。更新フラグの値に応じた反映は、その値が０であれば行わず、その値が１であればレコードを追加して行い、その値が２であればレコードの内容を変更して行い、その値が３であればレコードをワークＷＫから削除することで行う。」 「【図２】 ［図：0001429000000029.jpg］ 」 （ケ）甲３－１２（特開２００４－２９５８４７号公報） 甲３－１２には、以下のとおりの記載がある。 「【００２５】 注文の発注処理を実行すべき日が翌日以降である場合（Ｓ１０：Ｎｏ）、注文データ処理部１４０は、取引時使用データ格納部１３０が格納している更新予定データが、いつ現在データに更新されるかを確認する。この更新予定日が注文を発注すべき日以前である場合（Ｓ２０：Ｙｅｓ）、注文データ処理部１４０は、更新予定データを用いて取引注文データを処理する（Ｓ３０）。また更新予定日が注文の発注処理を実行すべき日の翌日以降である場合（Ｓ２０：Ｎｏ）、注文データ処理部１４０は、現在データを用いて取引注文データを処理する（Ｓ３０）。そして処理後の取引注文データを処理後注文データ格納部１５０に格納する（Ｓ５０）。」 （２）特許法第２９条第１項第３号、特許法第２９条第２項についての当審の判断 ア 本件発明１について 上記第６の１（１）ケで示したとおり、本件発明１と甲２－１に対応する引用文献１に記載された発明との間には、上記［相違点］があるところ、上記［相違点］に係る、複数の情報処理サービスシステムのそれぞれが相互に利用する管理用データベースに含まれる、複数の項目に関する複数のデータの部分（一部又は全部）のデータを更新する時期を管理することについては、上記（１）アの甲１－１、同エの甲２－２、同オの甲３－１、同カの甲３－２、同キの甲３－３、上記第５の２の引用文献２に対応する甲３－４のいずれにも記載されておらず、本件発明１は、甲１－１、甲２－２、甲３－１～甲３－４のいずれに記載された発明でもない。 さらに、本件発明１の上記［相違点］に係る、複数の情報処理サービスシステムのそれぞれが相互に利用する管理用データベースに含まれる、複数の項目に関する複数のデータの部分（一部又は全部）のデータを更新する時期を管理することは、申立人１～３が証拠として用いた甲号証、すなわち、甲第１－１号証～甲第１－１３号証、甲第２－１号証～甲第２－１５号証、甲第３－１号証～甲第３－１７号証のいずれにも記載されておらず、周知技術であるともいえない。 したがって、本件発明１は、甲１－１、甲２－２、甲３－１～甲３－４のいずれに記載された発明でもない。 また、本件発明１は、甲１－１、甲１－２、甲２－２、甲３－１～甲３－４のそれぞれに記載された発明、及び甲１－３に記載された技術事項並びに周知技術に基いて、当業者が容易に発明をすることができたものでもない。 イ 本件発明２、３、５、６について 本件発明２、３、５、６は、本件発明１の構成に限定を加えて減縮したものであるから、いずれも、上記アと同様の理由により、甲２－２、甲３－１～甲３－４のいずれに記載された発明でなく、また、申立人１～３が証拠として用いた甲号証のいずれにも記載されていないから、いずれも、甲１－１、甲１－２、甲２－２、甲３－１～甲３－４のそれぞれに記載された発明、及び甲１－３、甲１－４、甲１－１３、甲２－３、甲２－１５に記載された技術事項並びに周知技術に基づいて、当業者が容易に発明をすることができたものではない。 ウ 本件発明７、本件発明８について 本件発明７は、本件発明１の「データ処理システム」の発明を「データ処理方法」として記載した発明であって、本件発明８は、本件発明１の「データ処理システム」の発明を「データ処理プログラム」として記載した発明であって、いずれも、上記アと同様の理由により、甲１－１、甲２－２、甲３－１～甲３－４のいずれに記載された発明でもなく、また、いずれも、甲１－１、甲１－２、甲２－２、甲３－１～甲３－４のそれぞれに記載された発明、及び甲１－３に記載された技術事項並びに周知技術に基いて、当業者が容易に発明をすることができたものでもない。 ３ 特許法第３６条第６項第２号についての当審の判断 （１）申立人の主張する理由 申立人１は、特許異議申立書（第６０～６１頁）において、請求項６に記載の「人事データ」及び「人事関連業務に関する情報処理サービス」は、本件明細書の段落【００２１】に「人事データ又は労務データ」に基づく「人事関連業務又は労務関連業務に関する情報処理サービス」という記載があるものの、本件明細書には、人事データと労務データ、人事関連業務に関する情報処理サービスと労務関連業務に関する情報処理サービス、のそれぞれについて、どのように区別するのか記載されていないため、いずれが「人事データ」の範囲に含まれ、また、いずれが「人事関連業務に関する情報処理サービス」の範囲に含まれるのか明確でない旨、主張する。 （２）当審の判断 本件発明６の「人事データ」及び「人事関連業務に関する情報処理サービス」に関し、発明の詳細な説明の段落【００２１】には、「例えば採用管理、タレントマネジメント、勤怠管理、経費管理、労務管理、個人情報管理、給与管理等の、人事関連業務又は労務関連業務」との例示が記載されており、また、段落【００２４】には、「具体的には、例えば第１情報処理サービスシステム２１０が人事データに基づいて人事関連業務に関する情報処理サービスを提供する場合、管理用データベース１０１には、例えば、「標準月額給与」「課長評価」「部長評価」等の複数の項目のそれぞれに対応する複数のデータが記憶されている。」と記載されており、本件発明６の「人事データ」及び「人事関連業務に関する情報処理サービス」について、如何なるものを意図したものであるのかが全く把握できないようなものであるとはいえない。 また、たとえ発明の詳細な説明において、人事データと労務データ、人事関連業務に関する情報処理サービスと労務関連業務に関する情報処理サービス、のそれぞれについて、どのように区別するのか明確に記載されていないとしても、そのことにより、特許請求の範囲の記載が第三者の利益が不当に害されるほど不明確であるとはいえない。 したがって、本件発明６に関する、申立人１の特許法第３６条第６項第２号の申立て理由に理由はない。 なお、申立人３は、申立人３意見書第３０～３１頁において、本件発明１は、訂正によって発明特定事項が不明確となり、明確性の取消理由が新たに生じた旨主張するが、上記第２の２（１）に示したとおり、本件訂正後の請求項１に係る発明である本件発明１は、本件訂正前の請求項４に係る発明と同一であり、本訂正請求に付随して新たな技術的事項は付加されていないものであるところ、申立人３は異議申立て３において明確性の申立て理由を主張していないから、上記主張は特許異議の申立ての理由に実質的に新たな内容を付加するものであり、審理の対象にならない。 ４ 特許法第３６条第６項第１号についての当審の判断 （１）申立人の主張する理由 申立人３は、特許異議申立書（第１３９～１４２頁）において、本件発明１の構成要件である「前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をするデータ処理部」（以下、「構成要件１Ｃ」という。）は、発明の詳細な説明等の段落【００４９】、【００５０】の「データ処理部１５０」に関する記載、段落【００３６】及び図３の「権限データ」に関する記載、段落【００４２】及び図４の「データ処理要求」に関する記載を参照しても、「権限データ」及び「データ処理要求」に基づいて、いずれのデータが処理対象であるかを特定できるのか不明であるから、発明の詳細な説明には、処理対象のデータを「権限データ」及び「データ処理要求」に基づいて特定する実施例の記載はなく、段落【０００６】（当審注：申立人３による特許異議申立書第１４０、１４１頁に記載の「（段落【０００７】）」は「（段落【０００６】）」の誤記と認められる。）に記載された「特許文献１に記載されているデータ処理システムでは、複数の情報処理サービスシステムが連携してサービスを提供することは考慮されておらず、当該システムは、複数の情報処理サービスシステムが利用するプラットフォームとして機能することができない。」という課題を解決するための手段は開示されておらず、本件発明１は、発明の詳細な説明において、発明の課題が解決できることを当業者が認識できるように記載された範囲を超えており、特許法第３６条第６項第１号に規定するサポート要件を満たしていない旨主張する。また、本件発明１に従属する本件発明２～６、本件発明１の構成要件１Ｃと同様の構成要件を有する本件発明７、８についても、同様の理由により、サポート要件を満たしていない旨主張する。 （２）当審の判断 発明の詳細な説明の記載によれば、本件発明が解決しようとする課題は、「特許文献１に記載されているデータ処理システムでは、複数の情報処理サービスシステムが連携してサービスを提供することは考慮されておらず、当該システムは、複数の情報処理サービスシステムが利用するプラットフォームとして機能することができない。」（【０００６】）という課題認識の下、「複数の情報処理サービスシステムが利用するプラットフォームとして機能するデータ処理システムを提供すること」（【０００７】）を解決しようとする課題とするものである。 これに対し、発明の詳細な説明には、次のとおり記載されている。 「【００１２】 データ処理システム１００は、データ処理プログラムによって実現される情報処理システムであり、複数の情報処理サービスシステム２００のそれぞれと通信して、当該複数の情報処理サービスシステム２００のそれぞれから受け付けるデータの処理（参照及び更新の少なくともいずれか）の要求に応じて、管理用データベース１０１に記憶されるデータを処理する情報処理システムである。 【００１３】 データ処理システム１００は、情報処理サービスシステム２００から受け付けるデータの参照及び更新の少なくともいずれかの要求に応じて、管理用データベース１０１に記憶されるデータを、情報処理サービスシステム２００に提供し、また、当該データを更新する（Ｓ１０１）。また、データ処理システム１００は、他の情報処理サービスシステム２００に対し、情報処理サービスシステム２００からデータの処理要求の受信及び当該データ処理要求に応じたデータ処理を通知する通知データを出力する（Ｓ１０２）。 【００１４】 このように、データ処理システム１００は、複数の情報処理サービスシステム２００が扱うデータを管理用データベース１０１として管理し、当該データの参照及び更新の少なくともいずれかの処理を行う。すなわち、データ処理システム１００は、いわば、複数の情報処理サービスシステム２００を連携するプラットフォームとして機能することができる。」 以上の記載によれば、発明の詳細な説明には、「データ処理システム１００」は、「複数の情報処理サービスシステム２００のそれぞれと通信して、当該複数の情報処理サービスシステム２００のそれぞれから受け付けるデータの処理（参照及び更新の少なくともいずれか）の要求に応じて、管理用データベース１０１に記憶されるデータを処理する」（【００１２】）ものであり、「情報処理サービスシステム２００から受け付けるデータの参照及び更新の少なくともいずれかの要求に応じて、管理用データベース１０１に記憶されるデータを、情報処理サービスシステム２００に提供し、また、当該データを更新する」（【００１３】）ことにより、「複数の情報処理サービスシステム２００を連携するプラットフォームとして機能する」（【００１４】）ことが記載されている。 そして、本件発明１の「データ処理システム」は、「前記複数の情報処理サービスシステムのそれぞれは、前記管理用データベースに基づいて、 ＳａａＳを含むそれぞれ異なる所定の情報処理サービスを」提供するものであって、「前記管理用データベースは、前記複数の情報処理サービスシステムのそれぞれが相互に利用するデータベースであり」、「前記複数の情報処理サービスシステムに含まれる第１情報処理サービスシステムから、前記複数のデータに含まれる少なくとも１つのデータの参照及び更新の少なくともいずれかの要求に関するデータ処理要求を受信する」と、「前記権限データ及び前記データ処理要求に基づいて、前記少なくとも１つのデータの提供及び更新の少なくともいずれかの処理をする」ことが特定されているから、当該発明特定事項により、発明の詳細な説明の段落【０００７】に記載の「複数の情報処理サービスシステムが利用するプラットフォームとして機能するデータ処理システムを提供する」という課題を解決し得るものである。 そのため、本件発明１の発明特定事項により、発明の詳細な説明に記載された上記の課題を解決するための手段が反映されているといえ、本件発明１が、発明の詳細な説明に記載した範囲を超えたものであるとはいえない。 また、本件発明１の構成に限定を加えて減縮した本件発明２、３、５、６、本件発明１の「データ処理システム」の発明を「データ処理方法」として記載した発明に関する本件発明７、本件発明１の「データ処理システム」の発明を「データ処理プログラム」として記載した発明に関する本件発明８に関しても、同様の理由により、発明の詳細な説明に記載した範囲を超えたものであるとはいえない。 したがって、申立人３が主張する特許法第３６条第６項第１号の申立て理由には、理由がない。 ５ 特許法第３６条第４項第１号についての当審の判断 （１）申立人の主張する理由 申立人３は、特許異議申立書（第１４２～１４３頁）において、本件発明１の構成要件１Ｃの構成は、上記４（１）で主張した理由により、発明の詳細な説明に記載したものでないから、当業者は、発明の詳細な説明を参照したとしても、構成要件１Ｃを含む本件発明１を実施することができず、発明の詳細な説明は実施可能要件を満たしていない旨主張する。 また、発明の詳細な説明は、本件発明１に従属する本件発明２～６、本件発明１の構成要件１Ｃと同様の構成要件を有する本件発明７、８についても実施することができず、実施可能要件を満たしていない旨主張する。 （２）当審の判断 上記４（２）で示したとおり、本件発明１～３、５～８のいずれについても、発明の詳細な説明に記載した範囲を超えたものであるとはいえず、また、発明の詳細な説明の記載を参照した当業者が、本件発明１～３、５～８を実施するに際し、過度な試行錯誤を要するものでもない。 したがって、申立人３が主張する特許法第３６条第６項第１号の申立て理由には、理由がない。 第８ むすび 以上のとおりであるから、本件特許請求の範囲を、本件訂正請求書に添付した訂正特許請求の範囲のとおり、本件訂正後の請求項１～８について訂正することを認める。 本件請求項１～３、５～８に係る特許は、取消理由通知に記載した取消理由及び特許異議申立書に記載された申立て理由によっては、取り消すことができない。また、他に本件請求項１～３、５～８に係る特許を取り消すべき理由を発見しない。 さらに、本件訂正前の請求項４は、上記のとおり削除された。これにより、申立人による特許異議の申立てについて、請求項４に係る申立ては、申立ての対象が存在しないものとなったため、特許法第１２０条の８第１項で準用する特許法第１３５条の規定により却下すべきものである。 よって、結論のとおり決定する。