2026-700272

特許第７７４５９４５号発明「処理装置、処理プログラム及び処理方法」の特許異議申立事件について、次のとおり決定する。

結 論 特許第７７４５９４５号の請求項１に係る特許を維持する。

理 由 第１ 手続の経緯 特許第７７４５９４５号の請求項１～１１に係る特許についての出願は、令和６年９月２０日に出願した特願２０２４－１６４４１８の一部を令和７年６月２６日に新たに特許出願したものであって、令和７年９月１９日にその特許権の設定登録がされ、同年９月３０日に特許掲載公報が発行された。その後、その特許について、令和８年３月３１日に異議申立人新エネルギー開発合同会社（以下、「申立人」という。）により特許異議の申立てがされた。 本件特許異議申立て以後の経緯は、次のとおりである。 令和８年４月４日 手続補正書の提出（申立人） 第２ 本件発明 特許第７７４５９４５号の請求項１の特許に係る発明（以下、「本件発明」という。）は、その特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。 「【請求項1】 情報提供装置からカルテ情報を取得する手段と、 取得された前記カルテ情報から医用情報を抽出する手段と、 抽出された前記医用情報を正規化する手段と、 正規化された前記医用情報に基づく入力情報を学習済みモデルに入力することで医用文書を生成する手段と、 を有する処理装置。」 第３ 申立理由の概要 申立人は、甲第１号証～甲第６号証（以下、それぞれ「甲１」～「甲６」という。）を証拠として提出し、次のように主張する。 １ 取消理由 本件発明は、甲１記載の発明に甲２～甲６記載の技術事項を適用することで、当業者が容易に発明をすることができたものであるから、本件発明についての特許は、特許法第２９条第２項の規定に違反してされたものである。 ２ 証拠方法 甲第１号証：米国特許出願公開第２０２３／００８１３７２号明細書 甲第２号証：特表２０１５－５２４１０７号公報 甲第３号証：特開２０１２－１３８０２４号公報 甲第４号証：特開２０２０－１３５７３５号公報 甲第５号証：特表２０２２－５０８３５０号公報 甲第６号証：中国特許出願公開第１１６３１２９３０号明細書 第４ 甲号証について １ 甲１に記載されている事項、甲１に記載された発明 （１） 甲１に記載されている事項 甲１には、次の事項が記載されている（下線は、当審が付与した。以下同じ。）。 「ABSTRACT A method and a device are provided for generating a summary of a hospital stay by a patient, including maintaining a database of electronic medical records (EMRs) where the EMRs include clinical notes pertaining to a patient during a time interval, identifying a set of significant physician notes for the time interval, generating a candidate set of summaries for each of the significant physician notes, for each significant physician note, analyzing the factuality of each of the candidate summaries and selecting the most factual summary, and generating a daily section for inclusion in a hospital course section of a discharge note that includes the selected factual summary for each of the significant physician notes. （当審訳）要約 患者の入院経過のサマリを生成するための方法及び装置が提供される。当該方法は、電子医療記録（EMR）のデータベースを維持すること（当該EMRは所定の時間区間における患者に関する臨床ノートを含む）、当該時間区間について有意な医師ノートのセットを識別すること、有意な医師ノートの各々についてサマリの候補セットを生成すること、有意な医師ノートの各々について候補サマリの事実性を分析して最も事実に即したサマリを選択すること、及び各有意な医師ノートについて選択された事実的サマリを含む退院ノートの入院経過セクションに収録するための日次セクションを生成すること、を含む。」 「[0025] Clinical notes－refers to all notes in a medical record. The notes provide information about a patient and are typically in text, i.e. unstructured, format. There are many different types of clinical notes, including: Progress Note, Admit Note, Discharge Note, History & Physical Note, and Consult Note. （当審訳） [0025] 臨床ノート（Clinical Notes）――医療記録中の全てのノートを指す。ノートは患者に関する情報を提供し、通常はテキスト形式（非構造化）である。臨床ノートには多くの種類があり、経過記録、入院記録、退院記録、病歴・身体診察（H&P）記録、コンサルト記録などが含まれる。」 「[0039] It may be appreciated that the medical records data used as input may come from a variety of sources. Some of the data may be in standardized formats and other may be in proprietary formats. The most substantial source of medical record data is data from hospital centers 332 and local health clinics 334, as described hereinbelow. However, other sources of data may be included without departing from the scope and spirit of the present invention （当審訳）入力として使用される医療記録データは様々なソースから取得され得ることが理解されるべきである。データの一部は標準化されたフォーマットであり、他は独自フォーマット（proprietary formats）である場合がある。医療記録データの最も実質的なソースは、以下に説明する病院センター332 及びローカル健康クリニック334のデータである。ただし、本発明の範囲及び精神から逸脱することなく、他のデータソースを含めることができる。」 「[0046] MRAS server 320 typically stores data and executes MRAS architecture 325 described hereinbelow with reference to FIG. 4. （当審訳）[0046] MRASサーバ320は通常、図４を参照して以下に説明するMRASアーキテクチャ325を格納・実行する。」 「[0048] FIG. 4 illustrates an embodiment of a medical record data flow and processing architecture, referred to as MRAS architecture 400, that includes machine learning processing components and models. MRAS architecture 400 is an embodiment of MRAS architecture 325. [0049] Generally, MRAS architecture 400 can be grouped into five overall components, which are (1) input data, (2) data extraction and formatting, (3) storage, (4) standardization and summarization, and (5) results. Each of the five components is discussed hereinbelow. （当審訳） [0048] 図４は、機械学習処理コンポーネント及びモデルを含むMRASアーキテクチャ400と称する医療記録データフロー及び処理アーキテクチャの実施形態を示す。MRASアーキテクチャ400はMRASアーキテクチャ325の実施形態である。 [0049] 一般に、MRASアーキテクチャ400は5つの全体的なコンポーネントに分類でき、それらは(1)入力データ、(2)データ抽出及びフォーマット化、(3)ストレージ、(4)標準化及びサマリ化（standardization and summarization）、並びに(5)結果、である。5つのコンポーネントの各々について以下に説明する。」 「[0051] EMR data 402 represents, in the context of architecture 400, the repository or repositories of data that are accessed. EMR Data 402 is typically retrieved from a patient's medical record, which is maintained in one or more specialized computer systems such as an Electronic Medical Record (EMR) systems. EMR data 402 for a patient may include a wide range of data or document types, including clinical notes, and other data, including inter alia labs, vitals, and demographic information. （当審訳） [0051] EMR データ402は、アーキテクチャ400の文脈において、アクセスされるデータのリポジトリを表す。EMRデータ402は通常、電子医療記録（EMR）システム等の1つ以上の専用コンピュータシステムに保持される患者の医療記録から取得される。患者のEMRデータ402は、臨床ノートを含む広範なデータまたは文書タイプを含み得、その他のデータとしてとりわけラボ値、バイタル、及び人口統計情報等を含む。」 「[0053] EMR data 402 typically includes both structured and unstructured data from the patient. Structured data is defined as data that is organized, categorical, and formatted for search within a database, while unstructured data, typically in the form of text, is not. Examples of unstructured data include text files, audio, videos, and images. 2. Extract & Format [0054] EMR data 402 is retrieved by an API interface engine 404 through an API layer. An international standard, HL7, for exchanging data from one healthcare entity to another is used in certain embodiments. Use of HL7 facilitates transfer of data between the multiple different entities, enabling all parties to format and parse the data. FHIR is a recent version of the HL7 standard that is implemented with a RESTful web service and data formats such as XML and JSON. API interface engine 404 is designed to receive messages from the healthcare entity and translate the messages into a known format. 3. Store [0055] Once the incoming data is properly formatted in the interface engine, it is stored in a database referred to as OMOP database 406. The data is stored using the Observation Medical Outcomes Partnership (OMOP) Common Data Model (CDM) which is a standardized format for medicalterminologies. A benefit of OMOP is the ability to store clinical notes from different sources and link them to the proper patients and visits. Additionally, OMOP has a data structure that extends integration with insights gained from machine learning tools such as natural language processing (NLP). 4. Classify and Summarize [0056] With the data properly stored in OMOP database 406, it may be transmitted to or received by an NLP algorithm layer 408. The NLP algorithm layer 408 constructs the narrative summary by first filtering the data through three processing pipelines, referred to as processing layers herein, as follows: history of present illness (HPI) processing layer 420, a daily processing layer 430, and follow-up processing layer 440. [0057] Each processing layer includes a summarization step, specifically steps 424, 436 and 442, that summarizes or extracts the most important sentences or phrases from clinical notes. Thus far, the most successful machine learning model, in terms of generating accurate results, used for purposes of extraction and summarization of text is a transformer model. A transformer model is a neural network that learns context and thus meaning by tracking relationships in sequential data such as words in a sentence. First described in a 2017 paper from Google, “Attention Is All You Need” by Ashish Vaswani et al. [Vaswani], which is hereby incorporated by reference in its entirety, transformers have been widely used for processing text and speech. So, while other types of machine learning models can be used, and the invention is not restricted to the use of neural networks or transformer models, use of the transformer model will be assumed for subsequent discussion. More specifically, in the embodiment of the subject invention described herein steps 424, 434, 436, and 442 are implemented using transformer models. In each case, different combinations of data sets used to train the models are used, as discussed hereinbelow with reference to FIGS. 5A, 5B, 5C. （当審訳） [0053] EMRデータ402は通常、患者からの構造化データと非構造化データの両方を含む。構造化データはデータベース内での検索のために整理・分類・フォーマット化されたデータとして定義され、非構造化データは通常テキストの形式であり、そのようには整理されていない。非構造化データの例としてはテキストファイル、音声、動画、及び画像が挙げられる。 ２．抽出及びフォーマット化 [0054] EMRデータ402は、APIレイヤーを通じてAPIインターフェースエンジン404によって取得される。ある実施形態においては、ある医療機関から別の医療機関へのデータ交換のための国際標準であるHL7が使用される。HL7の使用により、複数の異なる主体間のデータ転送が容易になり、全ての当事者がデータをフォーマット化及びパースできる。FHIRはRESTfulウェブサービスとXML・JSON等のデータフォーマットで実装されるHL7標準の最新版である。APIインターフェースエンジン404は、医療機関からのメッセージを受信し、そのメッセージを既知のフォーマット（a known format）へ変換するよう設計されている。 ３．ストレージ [0055] 受信データがインターフェースエンジンにて適切にフォーマット化されると、OMOPデータベース406と称されるデータベースに格納される。データはObservation Medical Outcomes Partnership（OMOP）Common Data Model（CDM）を用いて格納される。これは医療用語のための標準化されたフォーマット（a standardized format for medical terminologies）である。OMOPの利点は、異なるソースからの臨床ノートを格納し、適切な患者及び受診に紐付ける能力にある。さらにOMOPは、NLP等の機械学習ツールから得られた知見との統合を拡張するデータ構造を有する。 ４．分類及びサマリ化 [0056] データが、OMOPデータベース406に適切に格納されると、NLPアルゴリズム層408へ送信または受信され得る。NLPアルゴリズム層408は、データをまず以下の3つの処理層（本明細書では処理パイプラインと称する）を通じてフィルタリングすることにより、ナラティブサマリを構築する。すなわち、現病歴（HPI）処理層420、日次処理層430、及びフォローアップ処理層440である。 [0057] 各処理層は、臨床ノートを要約するステップ424、436及び442という要約ステップを含み、臨床ノートから最も重要な文または語句を抽出または要約する。これまでのところ、抽出及びテキスト要約に使用される最も成功した機械学習モデルは、文中の語等の逐次データにおける関係を追跡することによりコンテキスト及び意味を学習するニューラルネットワークであるトランスフォーマーモデルである。トランスフォーマーモデルは、Googleの「Attention Is All You Need」（Ashish Vaswaniら、Vaswaniと称する）という2017年の論文で初めて説明され、その全体が参照により本明細書に組み込まれる。それ以来、トランスフォーマーはテキスト及び音声の処理に広く使用されてきた。そのため、他の機械学習モデルも使用できるが、トランスフォーマーモデルの使用が以後の説明で仮定される。より具体的には、本明細書に記載された主題の実施形態において説明されるステップ424、434、436及び442はトランスフォーマーモデルを使用して実装される。各ケースで、異なる組み合わせのデータセットがモデルの訓練に使用され、図５Ａ、５Ｂ、５Ｃを参照して以下に説明する。」 「[0063] At step 410, clinical notes and data from database 406 are classified into one of these three pipelines or processing layers, an HPI processing layer 420, a daily processing layer 430 and a follow-up processing layer 440. The classification algorithm performed by section classifier 410 may be as simple as a rule-based approach that looks at the categorical values of the type of data or it may a more robust approach such as a machine learning model that classifies data based on previous performance. In one embodiment, a rule-based approach that assigns documents to a processing layer based on both the type of clinician that authored a clinical note and the type of note is used. The clinical note author may be, for example, a MD, RN, NP. And common clinician note types, as previously discussed, include Admission Note, History & Physical Note, and Progress Note. （当審訳） [0063] ステップ410において、データベース406からの臨床ノート及びデータは、HPI処理層420、日次処理層430、フォローアップ処理層440の3つのパイプラインまたは処理層のいずれかへ分類される。セクション分類器410による分類アルゴリズムは、データのタイプの分類値を調べる単純なルールベースのアプローチであってもよく、または以前のパフォーマンスに基づいてデータを分類する機械学習モデルのようなより堅牢なアプローチであってもよい。一実施形態において、ルールベースのアプローチは、臨床ノートを記録した臨床医のタイプとノートのタイプの両方に基づいて文書を処理層に割り当てる。臨床ノートの記録者は、例えばMD、RN、NPである場合がある。また一般的な臨床医のノートタイプは、前述のとおり、入院記録、病歴・身体診察記録、経過記録を含む。」 「HPI Section Processing [0065] For HPI processing layer 420, the primary data source is the Admission Note which can be named differently at healthcare institutions, for example it may be referred to as a History & Physical (H&P) note or an Emergency Department (ED) note, as determined by policies and regulations established by the medical provider. Accordingly, section classifier 410 classifies based on a set of rules based on specific note type and medical provider. [0066] At step 422 a regular expression, or regex, processing algorithm is performed on the clinical notes to extract the most salient and useful content. Regexes use pattern matching rules to match and format data. By passing the clinical note through a series of regexes, it reduces the overall content passed to the next processing step. Specifically, at step 422 a regex processing algorithm filters incoming clinical notes to remove unnecessary information so the machine learning model, executed in the next step, does not get overburdened by too much data. For example, physicians often include sentences like “I confirm that this medical note accurately reflects all work, treatment, procedures, and medical decision making performed by me” in a clinical note; such statements may be included for legal or billing purposes but don't provide any useful clinical insights for the model. A regex can pattern match on such sentences to remove them before prior to execution of a ML model such as that which is executed at step 424. （当審訳） HPI処理セクション [0065] HPI処理層420において、主要なデータソースは入院記録であり、医療機関のポリシー及び規制によって病歴・身体診察（H&P）記録または救急部門（ED）記録と異なる名称で呼ばれることがある。従って、セクション分類器410は特定のノートタイプと医療プロバイダに基づく一連のルールに基づいて分類する。 [0066] ステップ422において、最も顕著で有用なコンテンツを抽出するために、正規表現（regex）処理アルゴリズムが臨床ノートに対して実行される。正規表現はパターンマッチングルールを使用してデータを照合及びフォーマット化する。臨床ノートを一連の正規表現に通すことにより、次の処理ステップへ渡す全体的なコンテンツを削減する。具体的には、ステップ422において正規表現処理アルゴリズムは入力臨床ノートをフィルタリングして不要な情報を除去し、次のステップで実行される機械学習モデルがデータ過多で過負荷にならないようにする。例えば医師は臨床ノートに「私はこの医療記録に記載された全ての業務、治療、及び医療的意思決定を正確に反映していることを確認する」等の文を含めることが多いが、そのような記述は法的または請求目的のために含まれるものであり臨床的洞察を提供しないため、正規表現によりパターンマッチングしてステップ424で実行されるMLモデルの実行前に除去できる。」 「[0068] Once preprocessed at step 422, the text is input as the source content to a transformer model at step 424 to generate a table or matrix that includes potential summaries, each assigned a probability. Each potential, summary generated at step 424 consists of a few predicted sentences that make up the first portion of the resulting Hospital Course Section of the Discharge Summary as illustrated in section 202 of FIG. 2. The transformer model employed at this step is pre-trained on the BART-CNN/Dailymail dataset and fine-tuned using a dataset constructed using data from the hospital course section of the discharge summary, prior to its use in inference, i.e. prior to operational use, as discussed hereinbelow with reference to FIG. 5A. （当審訳） [0068] ステップ422で前処理されると、テキストはステップ424においてトランスフォーマーモデルへのソースコンテンツとして入力され、各々に確率が割り当てられた候補サマリを含むテーブルまたはマトリクスを生成する。ステップ424で生成された各候補サマリは、図２のセクション202に示される退院サマリの入院経過セクションの最初の部分を構成するいくつかの予測文からなる。このステップで使用されるトランスフォーマーモデルは、BART-CNN/Dailymailデータセットで事前訓練され、退院サマリの入院経過セクションのデータを使用して構築されたデータセットでファインチューニングされており、推論での使用前（すなわち運用的使用の前）に行われる。これは図５Ａを参照して以下に説明する。」 「Daily Section [0070] Daily processing layer 430 summarizes all significant clinical notes relative to a patient's hospital stay and abstracts the salient content from each of these notes. Daily processing layer 430 generates one or more sentences for each consecutive time interval, typically a day, for the duration of a patient's hospital stay, as illustrated in section 204 of FIG. 2. When combined together, these daily summaries create a complete narrative of a patient's daily events and status from admission to discharge. （当審訳） 日次セクション [0070] 日次処理層430は、患者の入院経過に関する全ての有意な臨床ノートを要約し、これらの各ノートから要点コンテンツを抽出する。日次処理層430は、患者の入院期間を通じて各連続的な時間区間（通常1日）ごとに1つ以上の文を生成し、図２のセクション204に示される。これらの日次サマリを組み合わせると、入院から退院までの患者の日々の事象及び状態の完全なナラティブが形成される。」 「[0075] At step 432 each filtered clinical note resulting from step 410 is pre-processed using regex processing, as previously discussed with reference to step 422, to improve performance of the machine learning model that executes in the next step. [0076] At step 434, the clinically significant notes are identified. Those deemed to be of lesser importance are discarded, i.e. they are not included in subsequent processing steps. The objective of this step is to decide, on a note-by-note basis, which clinical notes are important enough to summarize in order to keep the patient hospital summary generated by daily processing layer 430 concise; otherwise, if all relevant clinical notes were summarized the summary might contain hundreds or even thousands of sentences, depending on the length of the patient's hospital stay. Generally, for purposes of readability, a patient summary with at most 30-50 sentences is considered desirable. [0077] In one embodiment, step 434 classifies each clinical note as to whether it is significant using a BERT transformer model, fine-tuned with a custom-created training dataset of clinical notes from the Daily section. The fine-tuning is described hereinbelow with reference to FIG. 5B. A different approach may also be used at this step, such as a rule-based approach. This step typically generates a list of documents to be summarized, or not, in the following step. There may be probabilities or confidence scores assigned to each document, or there may simply be a binary value that indicates whether or not the document is to be summarized for inclusion in the daily course summary. [0078] At step 436 the clinical notes selected for further processing at step 434 are passed through a fine-tuned transformer model that generates a matrix, or ranked list of candidate abstractive summaries. Each summary includes one or more sentences. These constitute an abstractively generated summary of the hospital course section of the clinician note. In one embodiment, each candidate summary is limited to one or two sentences. Thus, the result from executing step 436 is a matrix or list of summaries for each clinician note deemed significant for the time interval being evaluated. （当審訳） [0075] ステップ432において、ステップ410から得られた各フィルタリング済み臨床ノートは、次のステップで実行される機械学習モデルの性能を向上させるために、ステップ422に関して前述したとおり正規表現処理を用いて前処理される。 [0076] ステップ434において、臨床的に有意なノートが識別される。重要度が低いと判断されたノートは廃棄され、後続の処理ステップに含まれない。このステップの目的は、日次処理層430によって生成される患者サマリを簡潔に保つために要約するほど重要な臨床ノートはどれかを、ノートごとに決定することである。そうでなければ、全ての関連する臨床ノートが要約された場合、患者の入院の長さによっては、サマリは数百または数千もの文を含む可能性がある。一般的に、可読性のためにせいぜい30～50文の患者サマリが望ましいと考えられる。 [0077] 一実施形態において、ステップ434は、日次セクションの臨床ノートからカスタム作成された訓練データセットでファインチューニングされたBERTトランスフォーマーモデルを使用して各臨床ノートを有意かどうか分類する。ファインチューニングは図５Ｂを参照して以下に説明する。このステップには別のアプローチも使用できる。このステップは通常、以下のステップで要約される文書のリスト、またはそうでないものを生成する。各文書に確率や信頼スコアが割り当てられることもあれば、文書を要約に含めるかどうかを示す単純な二値が割り当てられることもある。 [0078] ステップ436において、ステップ434でさらなる処理のために選択された臨床ノートは、候補の抽象的サマリのマトリクスまたはランク付けリストを生成するファインチューニング済みトランスフォーマーモデルを通じて処理される。各サマリは1つ以上の文を含む。これらは臨床医ノートの入院経過セクションの抽象的に生成されたサマリを構成する。一実施形態において、各候補サマリは1～2文に限定される。従って、ステップ436の実行結果は、評価される時間区間に対して有意とみなされた各臨床ノートのサマリのマトリクスまたはリストである。」 「Follow-Up Processing [0081] Follow-up processing layer 440 identifies any clinical content from the patient visit that needs to be acted upon by downstream clinicians after the patient is discharged from the hospital. The primary data source for follow-up processing layer 440, is hospital discharge planning information, which includes any information about what will happen to the patient after discharge. Discharge planning information is captured across a number of different clinical notes, i.e. it is not exclusive to or contained within any one type of note. Clinical notes that typically include hospital discharge planning information include case management notes, social work notes, and progress notes made prior to patient discharge, and death notes. （当審訳） フォローアップ処理 [0081] フォローアップ処理層440は、患者が退院した後に下流の臨床医が対応する必要があるあらゆる臨床コンテンツを識別する。フォローアップ処理層440の主要なデータソースは病院退院計画情報であり、患者の退院後に何が起こるかについてのあらゆる情報を含む。退院計画情報はさまざまな臨床ノート（単一の種類のノートに限定されず、また単一の種類のノートに含まれない）にわたってキャプチャされる。退院計画情報を通常含む臨床ノートにはケースマネジメント記録、ソーシャルワーク記録、患者退院前に作成された経過記録が含まれる。」 「[0086] Step 442, then, extracts follow-up sentences to be included in follow-up section 206. In one embodiment, a pre-trained BERT transformer model is used at this step for text classification. The result of step 442 is a list of extracted follow-up sentences. Other types of text classification methods may be used at this step including regression, logistic regression, random forest, or other machine learning models. （当審訳） [0086] ステップ442は、次にフォローアップセクション206に収録されるフォローアップ文を抽出する。一実施形態において、このステップにはテキスト分類のための事前訓練済みBERTトランスフォーマーモデルが使用される。ステップ442の結果は抽出されたフォローアップ文のリストである。このステップには回帰・ロジスティック回帰・ランダムフォレスト・その他の機械学習モデルを含む他の種類のテキスト分類方法も使用される場合がある。」 「Results Processing [0087] Lastly, step 450 takes the results from steps 424, 436, and 442 and sequentially compiles or generates an automated summary, intended for inclusion in a discharge summary that is automatically generated at the conclusion of a patient's hospital stay. The three sections addressed herein, namely HPI section 202, daily course section 204 and follow-up section 206, when taken together form an automated narrative summary of a patient's hospital stay. In certain embodiments, each of the three sections are generated automatically using abstractive summary technology that generates consists of a sequence of predicted sentences. In one embodiment, the HPI section 202 and daily course section 204 are abstractively summarized while follow-up section 206 is generated using extractive summarization. Additionally, at step 450 the sentences may be passed through a duplicate algorithm to remove any repeated sentences. The automated summary produced at step 450 is typically referred to as a Hospital Course Section. （当審訳） 結果処理 [0087] 最後に、ステップ450はステップ424、436及び442の結果を受け取り、患者の入院終了時に自動生成される退院サマリへの収録を目的とした自動サマリを順次コンパイルまたは生成する。本明細書で取り上げられる3つのセクション（HPIセクション202、日次経過セクション204及びフォローアップセクション206）は、組み合わさって患者の入院経過の自動化されたナラティブサマリを形成する。ある実施形態において、3つのセクションの各々は予測文のシーケンスからなる抽象的サマリ技術を使用して自動的に生成される。一実施形態において、HPIセクション202及び日次経過セクション204は抽象的に要約される一方、フォローアップセクション206は抽出型要約を使用して生成される。また、ステップ450において文は重複した文を除去するための重複除去アルゴリズムを通じて処理される場合がある。ステップ450で生成された自動サマリは通常、入院経過セクションと称される。」 「[0090] FIGS. 5A, 5B, 5C each illustrate the processing steps required to train the models used in each of the three sections: HPI, daily, and follow-ups. Although a variety of neural networks may be used, the best results have been obtained using transformer models; thus, the discussion below focuses on transformer embodiments. [0091] The specific type of transformer model employed is an encoder-decoder transformer model designed for document summarization. The encoder-decoder structure as used in transformer models was introduced in [VASWANI]. The transformer model is first pre-trained on a large data set to learn language and the general task of document summarization. In embodiments described herein, pre-trained encoder-decoder transformers are selected from a Python library of ‘transformers’ available from Hugging Face. Hugging Face is a data science platform that provides tools that enable users to build, train and deploy machine learning (ML) models based on open source (OS) code and technologies. ML Models provided by organizations such as Hugging Face, Google and Microsoft are typically pre-trained on a particular dataset to provide certain capabilities. Some examples of pre-trained models that are designed for document summarization and which may be used include RoBERTA, BART, Pegasus, and T5. （当審訳） [0090] 図５Ａ、５Ｂ、５Ｃは各々、HPIセクション・日次セクション・フォローアップセクションで使用されるモデルの訓練に必要な処理ステップを示す。さまざまなニューラルネットワークが使用される場合があるが、最良の結果はトランスフォーマーモデルを使用して得られているため、以下の議論はトランスフォーマーの実施形態に焦点を当てる。 [0091] 使用される特定のトランスフォーマーモデルの種類は、文書要約のために設計されたエンコーダ・デコーダトランスフォーマーモデルである。トランスフォーマーモデルはまず言語を学習し、文書要約の一般的なタスクのために大規模なデータセットで事前訓練される。本明細書に記載された実施形態において、事前訓練済みエンコーダ・デコーダトランスフォーマーはHugging Faceが提供するPythonライブラリ「transformers」から選択される。Hugging Faceは、ユーザがオープンソースコードとテクノロジーを使用して機械学習（ML）モデルを構築・訓練・デプロイするためのツールを提供するデータサイエンスプラットフォームである。Hugging Face・Google・Microsoftなどの組織が提供するMLモデルは通常、特定の機能を提供するために特定のデータセットで事前訓練されている。文書要約のために設計された事前訓練済みモデルの例としてはRoBERTA、BART、Pegasus、T5などがある。」 「[0097] The set of banned words W is constructed from a list of medical words maintained by SNOMED International, referred to SNOMED CT, by removing any words that appear in a source document. Other strategies may be deployed, such as altering the encoder-decoder model and adding a reinforcement learning approach to teach the model factuality. Lastly, before loading into the transformer model, the words within the source text are translated into integers through a pre-defined tokenizer. （当審訳） [0097] 禁止語セットWは、SNOMED Internationalが管理する医学用語リスト（SNOMED CT）に基づき、ソース文書に含まれる単語をすべて除外して構築される。他にも、エンコーダー・デコーダーモデルの変更や、モデルに事実性を学習させるための強化学習アプローチの追加など、さまざまな手法が採用される可能性がある。最後に、トランスフォーマーモデルに読み込む前に、ソーステキスト内の単語は、あらかじめ定義されたトークナイザーを通じて整数に変換される。」 「[0109] In one embodiment a dictionary of 79,521 medical words from a standard list of terminology, SNOMED CT, is used to construct Wbanned. SNOMED-CT is a standard for electronic exchange of clinical health information used by the U.S. Federal Government. It includes a comprehensive, multilingual health terminology. It is available from the National Library of Medicine. [0110] In one embodiment, the terminology available for summarization is obtained by selecting words from SNOMED CT that are used in a selection of clinical notes. For example, in one embodiment of HPI processing layer 420 only technical words from SNOMED CT that are also present in an original Admission Note or History & Physical note are available for use in a summary. [0111] A two-part algorithm for constructing and then using Wbanned for inference as part of the processing of a machine learning model, including encoder-decoder transformer models, is given in Listing 1. [0112] Part A of the algorithm, given in Lines A1-A5, provide a method for constructing a banned word list Wbanned. Lines A1-A3 first construct an approved list of word, which includes the intersection of words used in a standard terminology list, for example, SNOMED CT, and the words contained in all source documents, i.e. clinical notes, provided to the algorithm. Line A4 adds to the approved list all synonyms. Then at line A4 Wbanned is formed by eliminating all approved words from the standard terminology list. [0113] The result of Part A is that words not used in the original source document or words that are not synonyms of such cannot be used to produce an abstractive summary. This effectively reduces the likelihood that extraneous, non-factual statements, which have no basis in the source text of a corpus of clinical notes will be introduced into a summary. （当審訳） [0109] 一実施形態において、標準用語リストであるSNOMED CTからの79,521語の医学用語辞書がWbannedの構築に使用される。SNOMED-CTは米国連邦政府が使用する臨床健康情報の電子交換の標準であり、包括的な多言語の健康用語を含む。米国国立医学図書館から入手可能である。 [0110] 一実施形態において、要約に使用可能な用語は、選択された臨床ノートで使用されているSNOMED CTの語彙を選択することにより取得される。例えば、HPI処理層420の一実施形態において、元の入院記録またはH&P記録にも存在するSNOMED CTの専門用語のみがサマリに使用可能である。 [0111] エンコーダ・デコーダトランスフォーマーモデルを含む機械学習モデルの処理の一部として、Wbannedを構築し推論に使用するための2部構成アルゴリズムがListing 1に示されている。 [0112] A1～A5行に示されるアルゴリズムのPart Aは、Wbannedを構築する方法を提供する。A1～A3行ではまず、標準用語リスト（例えばSNOMED CT）で使用される語彙と、アルゴリズムに提供される全ソース文書（臨床ノート）に含まれる語彙との積集合を含む承認語彙リストを構築する。A4行では承認リストに全同義語を追加する。次にA4行でWbannedは、標準用語リストから全承認語を除去することにより形成される。 [0113] Part Aの結果として、元のソース文書で使用されていない語彙またはその同義語でない語彙は、要約文の生成に使用できない。これにより、臨床ノートのコーパスのソーステキストに根拠を持たない外来の非事実的な記述がサマリに導入される可能性が効果的に低減される。」 「[Claim 1] A computer-implemented method for generating a summary of a hospital stay by a patient, comprising: maintaining a database of electronic medical records (EMRs) for patients, the EMRs include clinical notes written by clinicians that provide details about a patient's hospital stay; selecting from the database physician notes that provide information about the patient's hospital stay during a designated time interval; identifying from the selected physician notes a set of significant physician notes for the time interval; generating a candidate set of summaries for each of the significant physician notes, wherein a summary of a physician note includes one or more automatically generated sentences that summarize the physician note; for each significant physician note, analyzing the factuality of each of the candidate summaries and selecting the most factual summary; and generating a daily section for inclusion in a hospital course section of a discharge note, the generated daily section including the selected factual summary for each of the significant physician notes. [Claim 2] The method of claim 1 further comprising: retrieving electronic medical records for a patient; translating the received medical records into a standard format; and storing the translated medical records in the database. （当審訳） 請求項１ 患者の入院経過のサマリを生成するコンピュータ実装方法であって、 患者の電子医療記録（EMR）のデータベースを維持すること（当該EMRは患者の入院経過の詳細を提供する臨床医が記録した臨床ノートを含む）； 指定された時間区間における患者の入院経過に関する情報を提供する医師ノートをデータベースから選択すること； 選択された医師ノートから当該時間区間の有意な医師ノートのセットを識別すること； 有意な医師ノートの各々について候補サマリのセットを生成すること（医師ノートのサマリは当該医師ノートを要約する1つ以上の自動生成文を含む）； 有意な医師ノートの各々について候補サマリの事実性を分析して最も事実的なサマリを選択すること；及び 退院ノートの入院経過セクションに収録するための日次セクションを生成すること（生成された日次セクションは有意な医師ノートの各々について選択された事実的サマリを含む）； を含む方法。 請求項２ 請求項１に記載の方法であって、さらに、 患者の電子医療記録を取得すること； 受信した医療記録を標準フォーマット（a standard format）へ変換すること；及び 変換した医療記録をデータベースに格納すること； を含む方法。」 「[Claim 13] A server computer, comprising: a processor; a communication interface in communication with the processor; a data storage for storing a database of clinical notes, wherein a clinical note is written by a clinician and provides details about a patient's hospital stay; and a memory in communication with the processor for storing instructions, which when executed by the processor, cause the server: to select from the database physician notes that provide information about the patient's hospital stay during a designated time interval; to identify from the physician notes a set of significant physician notes for the time interval; to generate a candidate set of summaries for each of the significant physician notes, wherein a summary of a physician note includes one or more automatically generated sentences that summarize the physician note; for each significant physician note, to analyze the factuality of each of the candidate summaries and select the most factual summary; and to generate a daily section for inclusion in a hospital course section of a discharge note, the generated daily section including the selected factual summary for each of the significant physician notes. （当審訳） 請求項１３ サーバコンピュータであって、 プロセッサと； プロセッサと通信する通信インターフェースと； 臨床ノートのデータベースを格納するデータストレージ（臨床ノートは臨床医により記録され患者の入院経過の詳細を提供する）と； プロセッサと通信するメモリ（命令を格納し、プロセッサにより実行されると、サーバに以下を行わせる）： データベースから患者の入院経過に関する情報を提供する医師ノートを指定された時間区間に対して選択すること； 当該時間区間の有意な医師ノートのセットを医師ノートから識別すること； 有意な医師ノートの各々について候補サマリのセットを生成すること（医師ノートのサマリは当該医師ノートを要約する1つ以上の自動生成文を含む）； 有意な医師ノートの各々について候補サマリの事実性を分析して最も事実的なサマリを選択すること；及び 退院ノートの入院経過セクションに収録するための日次セクションを生成すること（生成された日次セクションは有意な医師ノートの各々について選択された事実的サマリを含む）； とを備えるサーバコンピュータ。」 「[FIG.4] ［図：0001437440000001.jpg］ 」 （２） 甲１の記載から把握できる事項 ア MRASサーバ320について 上記（１）[0046][0048]の記載から、甲１には、「MRASアーキテクチャ400を実行するMRASサーバ320であって」が記載されているといえる。 また、上記（１）FIG.4から、MRASアーキテクチャ400は、APIインターフェースエンジン404、OMOPデータベース406、NLPアルゴリズム層408、自動サマリ450を含んでいることが看取される。 したがって、甲１には、「MRASアーキテクチャ400を実行するMRASサーバ320であって、 MRASアーキテクチャ400は、APIインターフェースエンジン404、OMOPデータベース406、NLPアルゴリズム層408、自動サマリ450を含む」ことが記載されているといえる。 イ APIインターフェースエンジン404について 上記（１）[0053]～[0055]の記載から、甲１には、「APIインターフェースエンジン404は、患者からの構造化データと非構造化データの両方を含むEMRデータ402を取得し、医療機関からのメッセージを受信し、そのメッセージを既知のフォーマット（a known format）へ変換し、適切にフォーマット化されたデータは、OMOPデータベース406に格納される」ことが記載されているといえる。 上記（１）[0025][0051]の記載から、甲１には、「EMRデータ402は、臨床ノートを含み、電子医療記録（EMR）システムに保持され、臨床ノートには、経過記録、入院記録、退院記録、病歴・身体診察（H&P）記録、コンサルト記録などが含まれる」ことが記載されているといえる。 さらに、上記（１）[0054]の記載から、EMRデータ402は、APIインターフェースエンジン404が受信するメッセージに含まれていることは明らかであり、既知のフォーマットへ変換される対象であることは明らかである。 したがって、甲１には、「APIインターフェースエンジン404は、EMRデータ402を取得し、EMRデータ402を既知のフォーマットへ変換し、適切にフォーマット化されたデータは、OMOPデータベース406に格納され、EMRデータ402は、臨床ノートを含み、電子医療記録システムに保持され、臨床ノートには、経過記録、入院記録、退院記録、病歴・身体診察（H&P）記録、コンサルト記録などが含まれる」ことが記載されているといえる。 ウ NLPアルゴリズム層408について 上記（１）[0055]～[0057]の記載、FIG.4から、甲１には、「NLPアルゴリズム層408は、データがOMOPデータベース406に適切に格納されると、データを受信し、データを、現病歴（HPI）処理層420、日次処理層430、及びフォローアップ処理層440の処理層を通じて、フィルタリングすることにより、ナラティブサマリを構築し、各処理層は、臨床ノートを要約する」ことが記載されているといえる。 エ 現病歴（HPI）処理層420の処理について 上記（１）[0057][0066][0068][0090][0091]の記載、FIG.4から、甲１には、「現病歴（HPI）処理層420は、臨床ノートから最も重要な文または語句を抽出または要約するものであって、正規表現（regex）処理アルゴリズムが臨床ノートに対して実行されることで、入力臨床ノートをフィルタリングして不要な情報を除去し、トランスフォーマーモデルへのソースコンテンツとして入力され、各々に確率が割り当てられた候補サマリを含むテーブルまたはマトリクスを生成する」ことが記載されているといえる。 オ 日次処理層430の処理について 上記（１）[0057][0070][0076][0078][0090][0091]の記載、FIG.4から、甲１には、「日次処理層430は、臨床ノートから最も重要な文または語句を抽出または要約するものであって、選択された臨床ノートを、ファインチューニング済みトランスフォーマーモデルを通じて処理し、候補の抽象的サマリのマトリクスまたはランク付けリストを生成する」ことが記載されているといえる。 カ フォローアップ処理層440の処理について 上記（１）[0057][0086][0090][0091]の記載、FIG.4から、甲１には、「フォローアップ処理層440は、臨床ノートから最も重要な文または語句を抽出または要約するものであって、テキスト分類のための事前訓練済みBERTトランスフォーマーモデルを使用して、フォローアップ文を抽出する」ことが記載されているといえる。 キ 自動サマリ450の処理について 上記（１）[0087]の記載、FIG.4から、甲１には、「自動サマリ450は、現病歴（HPI）処理層420、日次処理層430及びフォローアップ処理層440の結果を受け取り、患者の入院終了時に自動生成される退院サマリへの収録を目的とした自動サマリを順次コンパイルまたは生成する」ことが記載されているといえる。 （３）甲１に記載された発明 上記（２）から、甲１には、 「MRASアーキテクチャ400を実行するMRASサーバ320であって、 MRASアーキテクチャ400は、APIインターフェースエンジン404、OMOPデータベース406、NLPアルゴリズム層408、自動サマリ450を含み、 APIインターフェースエンジン404は、EMRデータ402を取得し、EMRデータ402を既知のフォーマットへ変換し、適切にフォーマット化されたデータは、OMOPデータベース406に格納され、EMRデータ402は、臨床ノートを含み、電子医療記録システムに保持され、臨床ノートには、経過記録、入院記録、退院記録、病歴・身体診察（H&P）記録、コンサルト記録などが含まれ、NLPアルゴリズム層408は、データがOMOPデータベース406に適切に格納されると、データを受信し、データを、現病歴（HPI）処理層420、日次処理層430、及びフォローアップ処理層440の処理層を通じて、フィルタリングすることにより、ナラティブサマリを構築し、各処理層は、臨床ノートを要約し、 現病歴（HPI）処理層420は、臨床ノートから最も重要な文または語句を抽出または要約するものであって、正規表現（regex）処理アルゴリズムが臨床ノートに対して実行されることで、入力臨床ノートをフィルタリングして不要な情報を除去し、トランスフォーマーモデルへのソースコンテンツとして入力され、各々に確率が割り当てられた候補サマリを含むテーブルまたはマトリクスを生成し、 日次処理層430は、臨床ノートから最も重要な文または語句を抽出または要約するものであって、選択された臨床ノートを、ファインチューニング済みトランスフォーマーモデルを通じて処理し、候補の抽象的サマリのマトリクスまたはランク付けリストを生成し、 フォローアップ処理層440は、臨床ノートから最も重要な文または語句を抽出または要約するものであって、テキスト分類のための事前訓練済みBERTトランスフォーマーモデルを使用して、フォローアップ文を抽出し、 自動サマリ450は、現病歴（HPI）処理層420、日次処理層430及びフォローアップ処理層440の結果を受け取り、患者の入院終了時に自動生成される退院サマリへの収録を目的とした自動サマリを順次コンパイルまたは生成する MRASサーバ。」との発明（以下「甲１発明」という。）が記載されている。 ２ 甲２に記載されている事項 甲２には、次の事項が記載されている。 ア 「【００３１】更なる一例において、ＮＬＰエンジン１３２は、コード化されたプロトコル基準とあまり良く合致しないコード化された患者インジケーションの記述を生成する。患者撮像注文が“患者はＧＩ領域内に位置する出血の症状を示している”なる記述を含む場合、ＮＬＰアルゴリズムは、例えば２つの特定された医学概念（又はコード）：“出血”（例えば、ＳＮＯＭＥＤ：５０９６０００５）及び“消化管構造”（例えば、ＳＮＯＭＥＤ：１２２８６５００５）の形態などの、異なる結果を生成し得る。この場合、生成された２つのコードは、より断片化されており、この患者を適切なプロトコル（例えば、“消化管出血”とコード化された臨床インジケーションを有する）に自動マッチングするのにいっそうの困難をもたらす。 【００３２】この第２の例に示される問題は、ＮＬＰエンジン１３２からの結果の第２段階の後処理により、断片化されている可能性がある結果を、ステップ２２０にて規定されるプロトコルの臨床基準に記述される医学概念に適合する１つ以上の概念へと組み合わせることによって解決され得る。すなわち、先の例では、“出血”及び“消化管構造”なる結果から、推薦エンジン１３４が論理的に“消化管出血”を推論する。」 イ 「【００４２】カテゴリー７ － このカテゴリーは、２つの文字列（例えば、アルファベット文字の順序集合）がどれだけ類似しているかを決定する類似スコアアルゴリズムを用いる文字列マッチングに基づく。２つの与えられるＮＬＰ結果に対し、ＮＬＰエンジン１３２は、複合概念記述（“好適用語”）と各ＮＬＰ結果との間の類似スコアを決定する。双方のスコアが４以上である必要があり、少なくとも一方の結果が５以上のスコアを有するべきである。一例は、“血栓塞栓性疾患”及び“動脈の”なるＮＬＰ結果を与えられて、複合概念“動脈血栓症”（列３４０）を見い出すものである。ここで、“動脈血栓症”は、最初の６つのカテゴリーの何れかによって捕捉されるその定義内に“血栓塞栓性疾患”又は“動脈の”を有しない。ここで使用される具体的な文字列マッチングアルゴリズムは、最長共通部分列アルゴリズムである。なお、例えばレーベンシュタイン距離、ハミング距離などの、その他の標準的なマッチングアルゴリズムも使用されることができ、あるいは代替として使用され得る。与えられた例において、“Arterial thrombosis”（動脈血栓症）と“Thromboembolic disorder”（血栓塞栓性疾患）との類似スコアは７であり、“Arterial thrombosis”（動脈血栓症）と“Arterial”（動脈の）との間の類似度は８である。 【００４３】従って、ＮＬＰ結果は順々に上述のカテゴリーにマッチングされる（すなわち、所与のＮＬＰ結果がカテゴリー１を満たす場合、後続のカテゴリーは無視される）。ＮＬＰ結果の後処理モジュールは、コードのこれら断片を用いて、これら断片に関係する医学概念に関してオントロジーを検索する。結果として、この後処理モジュールは複数の候補を生成する。例えば、“出血”及び“消化管構造”に関して、論理的制約を満たす複数の概念は、“下部消化管出血”、“消化管出血”及び“急性消化管出血”である。このような候補の数を最小化するために、２つのフィルタリング技術を使用することができる。 【００４４】第１のフィルタリング技術は、候補間に階層関係が存在するかを決定するために使用される。そうである場合、それは、より具体的な概念を指し示すのに十分な詳細事項をＮＬＰエンジン１３２が有しなかったことを暗示しているので、最も一般的な用語を除く全てがフィルタリング除去される。非階層的な概念に対して第２のフィルタリング技術が使用され、そこでは、最長共通部分列アルゴリズムを用いて結果がフィルタリングされ、少なくとも３つの共通文字を有しない候補がフィルタリング除去される。フィルタリング後にも複数の複合概念が推論されるとき、それら全てが考え得る候補概念として返される。」 ウ 「【００４６】当業者が理解するように、上述の例示実施形態は、別個のソフトウェアモジュールとして、ハードウェアとソフトウェアとの組み合わせとして、等々を含む幾つもの手法で実装されることができる。例えば、システム１００及び関連サブシステム１１０-１４０は、非一時的なコンピュータ読み取り可能記憶媒体に格納された、コンパイルされるときにプロセッサ上で実行され得る命令行を含んだプログラムとし得る。また、以上の記載から明らかなように、例示実施形態は、例えば、収集された患者からの臨床情報をフォーマット化することによって、標準化された用語集を用いて各撮像プロトコルをコード化することによって、コード化されたプロトコルデータを、処理された患者データと組み合わせて、１つ以上の撮像プロトコルを自動的に推薦するようにすることによって、等々でユーザがシステム１００を実装するときに、処理装置がいっそう効率的に動作することを可能にする。」 ３ 甲３に記載されている事項 甲３には、次の事項が記載されている。 ア 「【００２６】登録情報特定装置１は、例えば、保険会社における保険の支払査定業務に用いられる。登録情報特定装置１には、顧客からの保険請求の際に提出された医師の診断書の記載内容（後述の各項目）が、入力部１４から文字入力される（データエントリ）。登録情報特定装置１の制御部１１は、文字入力される文字列を受け付け、入力された文字列を、保険会社の保険支払いの査定に使用される、予め保険会社に登録されている医療用語（本実施形態における登録情報）に当てはめる処理を行う（本実施形態では、このあてはめをコード化という。）。本実施形態では、特に、手術名として入力された文字列（以下、入力文字列という。）を、統一された手術名称（以下、標準名称という。）に当てはめる場合について説明する。このようなコード化をする理由は、同じ手術であっても、医師によって、診断書における手術名の表記が異なる場合があるからである。つまり、同じ手術を示すものであるのに、入力文字列が、診断書によって異なる場合があるからである。このため、後の査定等の業務において、同じ査定結果になるべきなのに、診断書の記載内容によって査定結果が異なってしまう等の不都合を解消するため、コード化が行われる。 【００２７】例えば、内視鏡を使用した手術では、手術名として、単に「内視鏡・・・」と入力されたり、「内視鏡下・・・」又は「内視鏡的・・・」と入力されたりする（表記揺れ）。これらは、全て内視鏡を使用した手術であるという点で共通する。 【００２８】また、例えば、「・・・切除術」が「・・・・摘除術」と入力されることもある（同義語の使用）。 【００２９】また、例えば、同じ手術であるのに、「大腸ポリープ内視鏡切除術」や、「内視鏡大腸ポリープ切除術」等、語句の順番が入れ違う場合がある。」 イ 「【００３１】上記のように、入力文字列が異なる態様は様々であり、特に、前記の語句の順番が異なる、又は、語句が足りないと、従来では、コード化が出来ず、コード化の精度（入力文字列に対応する標準名称の特定の精度）が悪かった。本実施形態では、以下のコード化処理によって、標記揺れや同義語による不都合の他、前記の語句の順番が異なる、語句が足りないといった問題を解消し、精度良くコード化ができる。」 ４ 甲４に記載されている事項 甲４には、次の事項が記載されている。 ア 「【００４５】後述する照合辞書記憶部１４を参照して，表記揺らぎ処理を実行してもよい。表記揺らぎ処理とは，同一の事象に対して複数の表記がある場合，それを標準的な表記に統一する処理である。」 イ 「【００５３】検出した対象情報や関連情報について，後述する照合辞書記憶部１４を参照し，その対象情報や関連情報が症状名，病名，薬剤名を示す表現の有無を判定し，これらのいずれかである場合には，照合辞書記憶部１４で一致する文字列を特定し，検出した対象情報や関連情報を，照合辞書記憶部１４であらかじめ定めた標準的な表記や標準的なコードを追加または変更し，その表記を統一する処理を実行してもよい。」 ５ 甲５に記載されている事項 甲５には、次の事項が記載されている。 ア 「【０００１】本発明は、用語標準化分野に関し、特に汎用医療用語ライブラリに基づくマルチセンタ医療用語標準化システムに関する。」 イ 「【０００３】汎用医療用語ライブラリは、『医学用語システムの命名-臨床用語』（ＳＮＯＭＥＤーＣＴ）、『国際疾患の分類とコード』（ＩＣＤー１０）、臨床薬物標準命名法（ＲｘＮｏｒｍ）、『観測指標の識別子の論理命名のプリコーディングシステム』（ＬＯＩＮＣ）などの国際汎用医療用語セットを中核とする、医療の全過程をカバーする医療概念用語標準ライブラリである。マルチセンタの医療データを統一された汎用医療用語ライブラリにマッピングした後、ビッグデータ分析などの操作を便利に行うことができる。マルチセンタ医療データを利用してデータ分析を行う前に、異なる医療情報システムの医療データをどのように用語標準化及びクリーニングするかは、難題となっている」 ウ 「【００１９】さらに、前記自動マッピングモジュールは、ソースデータベース内に国際汎用医療用語ライブラリの標準コードが存在する用語について、そのコードの属する標準を特定した後、マッピングされる目標用語セットを選択し、ソースデータベース内の用語の属する標準用語セットのコードと目標用語セットコードとの間に参照可能なマッピング関係があれば、この部分の用語は、マッピングＳＱＬ文を自動的に生成でき、ソースデータベース内の用語に対する自動マッピング、及び対応するデータのロードを完了させる。 【００２０】さらに、前記曖昧マッチングモジュールでは、曖昧マッチングの具体的な方法は、以下の通りであり、 （１）用語の単語分割であって、汎用医療用語ライブラリにおける全ての語彙に対して単語分割を行い、それぞれの単語分割に対して出現頻度を統計し、基礎語彙の頻度として、曖昧マッチングが必要なソース医療用語Ｍに対してマッチングする前に単語分割を行い、 （２）曖昧マッチングであって、医療用語間の確率差を比較することで、類似度の大きさの基準とし、具体的な操作は、以下の通りであり、 （２.１）汎用医療用語ライブラリから単語分割を含む全ての用語をスクリーニングし、単語分割を行い、用語セットＡに組み合わせ、 （２.２）以下の式（１）を用いてマッチング度の計算を行い、用語Ｍ、用語セットＡにおける全ての用語の加重平均確率を求め、但し、ｎは、単語分割が得られた各用語の数であり、Ｐ１、Ｐ２、Ｐ３、Ｐ４ … Ｐｎは、各単語分割の基礎語彙における対応する確率であり、 【数１】 （１） ［図：0001437440000002.jpg］ （２.３）用語セットＡにおける全ての標準用語の加重平均確率と、曖昧マッチングが必要な用語Ｍとの差を求め、得られた数値に対して負値を取ってマッチング度とし、マッチング度が大きいほど、両者の類似度が高くなり、その数式（２）は、 【数２】 ［図：0001437440000003.jpg］ である。 【００２１】さらに、前記カスタム用語モジュールは、カスタム用語と既知の標準用語との相互衝突を回避するように、事前に制約を定義し、カスタム用語を追加する際、各医療データセンタの間に追加されたカスタム標準用語の整合性を保つ必要があり、重複追加を防止するとともに、マルチセンタ医療データが用語マッピング標準化された後、データ共有が実現可能であることを保証し、カスタム用語を追加する前に、マルチセンタ・インタラクションモジュールに、カスタム用語を追加する申請を提出する必要があり、申請内容は、追加するカスタム用語、カスタム用語の具体的な説明及びカスタム用語のコードを含み、マルチセンタ・インタラクションモジュールの関連する操作者による審査に合格した場合、類似して重複する医療用語のカスタムコードがないと判断し、１つのカスタム標準用語コードを生成し、そして、自動マッピングモジュールを呼び出し、用語マッピング及び関連するデータのロードを完了させ、審査に合格しなかった場合、当該医療データセンタが、後続のマッピングを完了させるために、既存のカスタム用語コードを返送し、或いは、カスタム用語の生成に失敗した原因を返送し、エラードキュメントを生成してユーザに提示する。」 ６ 甲６に記載されている事項 甲６には、次の事項が記載されている。 ア「 ［図：0001437440000004.jpg］ （当審訳） ２．請求項1に記載の方法であって、そのベクトルは、前記ターゲットユーザ識別子に対応するカルテ情報を取得し、前記カルテ情報に基づいてベクトル表現抽出を行い、前記ターゲットユーザ識別子に対応するカルテ表示ベクトルを取得することは、以下を含む：前記ターゲットユーザ識別子に対応する各カルテデータ及び前記各カルテデータに対応する生成時間を取得する。前記各カルテデータにおけるテキストカルテデータに対して名称エンティティ識別を行い、カルテエンティティデータを取得し、前記カルテエンティティデータと対応する生成時間に基づいてカルテエンティティデータシーケンスを取得する。前記各カルテデータ中の数値カルテデータを正規化し、正規化カルテデータを得て、前記正規化カルテデータと対応する生成時間に基づいて正規化カルテデータシーケンスを取得する。前記各カルテデータにおける離散カルテデータに対してホットコードを行い、エンコードカルテデータを取得し、前記エンコードカルテデータと対応する生成時間に基づいてエンコードカルテデータ系列を取得する;前記カルテ実体データ系列、前記正規化カルテデータ系列及び前記エンコードカルテデータ系列に基づいて前記カルテ情報を取得する。」 イ「 ［図：0001437440000005.jpg］ （当審訳） [0091] ここで、ターゲットユーザ識別子はターゲットユーザを識別することに用いられ、該ターゲットユーザは対応する医療記録情報が存在する患者を指す。医療記録情報はターゲットユーザが病院診断治療全過程のオリジナル記録を行うことを指し、ホームページ、病程記録、検査結果、医師の指示、手術記録、看護記録、及び薬処方等を含む。このカルテ情報は、異なるソースから取得されたマルチモーダル情報とすることができる。カルテは、カルテ情報の意味ベクトルを特徴づけるためにベクトルが使用されることを示す。」 ウ「 ［図：0001437440000006.jpg］ （当審訳） [0104］ ステップ302 ターゲットユーザ識別子に対応する各カルテデータ及び各カルテデータに対応する生成時間を取得する。 [0105] ここで、カルテデータとは、さまざまな情報源から得られた初期の記録データを指す。具体的には、検査によって得られた検査データ、医師が入力した現在の診断データ、データベースから取得した過去の診断データ、データベースから取得したターゲットユーザに対応する過去の投薬データ、およびターゲットユーザに対応する手術記録データなど、多岐にわたる形式の診療記録データが含まれる。生成時刻とは、当該診療記録データが取得された時点を指す。」 エ「 ［図：0001437440000007.jpg］ （当審訳） [0107] ステップ304 各カルテデータにおけるテキストカルテデータに対して名称エンティティ識別を行い、カルテエンティティデータを取得し、カルテエンティティデータと対応する生成時間に基づいてカルテエンティティデータシーケンスを取得する。 [0108] ここで、テキストカルテデータとはテキストフォーマットのカルテデータを指し、例えば現在の診断記録テキストである。医療実体データとは、症状を特徴付けるために使用される実体を意味する。カルテ実体データ系列とは、カルテ実体データが生成時間に応じて配列されたものをいう。」 オ「 ［図：0001437440000008.jpg］ （当審訳） [0111] ステップ306 各カルテデータ中の数値カルテデータを正規化し、正規化カルテデータを得て正規化カルテデータと対応する生成時間に基づいて正規化カルテデータシーケンスを取得する。 [0112] ここで、数値カルテデータは数値フォーマットのカルテデータである。例えば、血圧値、心拍数値等である。 [0113] 具体的には、サーバは正規化アルゴリズムを用いて正規化を行い、該正規化アルゴリズムは線形関数を用いて正規化することができ、平均値正規化を用いて正規化医療記録データを得て、次に正規化医療記録データを対応する生成時間に基づいて配列して正規化医療記録データ系列を得ることができる。 [0114] ステップ308 各カルテデータにおける離散カルテデータに対してホットコードを行い、エンコードカルテデータを得てエンコードカルテデータと対応する生成時間に基づいてエンコードカルテデータ系列を取得する。」 カ「 ［図：0001437440000009.jpg］ ［図：0001437440000010.jpg］ （当審訳） [0120] ステップ310 カルテエンティティデータシーケンス、正規化医療記録データシーケンス及び符号化カルテデータシーケンスに基づいてカルテ情報を取得する。 [0121]具体的には、サーバはすべてのカルテエンティティデータシーケンス、正規化カルテデータシーケンス及びエンコードカルテデータシーケンスを最終前処理として取得されたカルテ情報とする。」 第５ 当審の判断 １．対比 本件発明と甲１発明とを対比する。 （１）「情報提供装置からカルテ情報を取得する手段と、」について ア 甲１発明は、「APIインターフェースエンジン404は、EMRデータ402を取得し、EMRデータ402を既知のフォーマットへ変換し、適切にフォーマット化されたデータは、OMOPデータベース406に格納され、EMRデータ402は、臨床ノートを含み、電子医療記録システムに保持され」るものである。 イ そうすると、甲１発明の「EMRデータ402」は、本件発明の「カルテ情報」に相当する。また、甲１発明の「電子医療記録システム」は、本件発明の「情報提供装置」に相当する。 ウ したがって、甲１発明の「電子医療記録システム」から「EMRデータ402」を取得する「APIインターフェースエンジン404」は、本件発明の「情報提供装置からカルテ情報を取得する手段」に相当する。 （２）「取得された前記カルテ情報から医用情報を抽出する手段と、」について ア 甲１発明は、「EMRデータ402は、臨床ノートを含み」、「臨床ノートには、経過記録、入院記録、退院記録、病歴・身体診察（H&P）記録、コンサルト記録などが含まれ」る。また、甲１発明は、「NLPアルゴリズム層408」は、既知のフォーマット変換されたEMRデータ402を「現病歴（HPI）処理層420、日次処理層430、及びフォローアップ処理層440の処理層を通じて、フィルタリングすることにより、ナラティブサマリを構築し、各処理層は、臨床ノートを要約する」ものである。 イ そうすると、甲１発明の「経過記録、入院記録、退院記録、病歴・身体診察（H&P）記録、コンサルト記録」を含む「臨床ノート」は、本件発明の「医用情報」に相当する。 そして、甲１発明は、EMRデータ402から臨床ノートを含むことは明らかである。 ウ したがって、甲１発明のEMRデータ402から臨床ノートを抽出する手段は、本件発明の「取得された前記カルテ情報から医用情報を抽出する手段」に相当する。 （３）「抽出された前記医用情報を正規化する手段と、」について 甲１発明は、臨床ノートを正規化するものではないことから、甲１発明は、「抽出された前記医用情報を正規化する手段」を有していない点で、本件発明と相違する。 （４）「正規化された前記医用情報に基づく入力情報を学習済みモデルに入力することで医用文書を生成する手段と、」について ア 甲１発明は、「NLPアルゴリズム層408」は、既知のフォーマット変換されたEMRデータ402を「現病歴（HPI）処理層420、日次処理層430、及びフォローアップ処理層440の処理層を通じて、フィルタリングすることにより、ナラティブサマリを構築し、各処理層は、臨床ノートを要約する」ものであって、「現病歴（HPI）処理層420」は、「トランスフォーマーモデル」を使用して「候補サマリを含むテーブルまたはマトリクス」を生成し、「日次処理層430」は、「ファインチューニング済みトランスフォーマーモデル」を使用して「候補の抽象的サマリのマトリクスまたはランク付けリスト」を生成し、「フォローアップ処理層440」は、「事前訓練済みBERTトランスフォーマーモデル」を使用して「フォローアップ文」を抽出するものである。 イ そうすると、甲１発明の「トランスフォーマーモデル」、「ファインチューニング済みトランスフォーマーモデル」及び「事前訓練済みBERTトランスフォーマーモデル」は、本件発明の「学習済みモデル」に相当する。 また、甲１発明の「既知のフォーマット変換されたEMRデータ402」と、本件発明の「正規化された前記医用情報に基づく入力情報」とは、「前記医用情報に基づく入力情報」との点で共通する。 他方、上記（３）に関連して、本件発明は、入力情報が「正規化された前記医用情報」に基づくものであるのに対して、甲１発明は、「トランスフォーマーモデル」、「ファインチューニング済みトランスフォーマーモデル」及び「事前訓練済みBERTトランスフォーマーモデル」への入力である、既知のフォーマット変換されたEMRデータ402が、「正規化された」ものではない点で相違する。 さらに、甲１発明の「候補サマリを含むテーブルまたはマトリクス」、「候補の抽象的サマリのマトリクスまたはランク付けリスト」、「フォローアップ文」と、本件発明の「医用文書」とは、「医用関連情報」との点で共通する。 他方、本件発明は、「医用文書」を生成するのに対して、甲１発明は「候補サマリを含むテーブルまたはマトリクス」、「候補の抽象的サマリのマトリクスまたはランク付けリスト」、「フォローアップ文」であって、「医用文書」といえるか判然としない点で相違する。 ウ したがって、甲１発明の「NLPアルゴリズム層」は、本件発明の「正規化された前記医用情報に基づく入力情報を学習済みモデルに入力することで医用文書を生成する手段」と、「前記医用情報に基づく入力情報を学習済みモデルに入力することで医用関連情報を生成する手段」との点で共通する。 他方、本件発明と甲１発明とは、上記イの２点で相違する。 （５）「処理装置」について 甲１発明の「MRASサーバ320」は、上記（１）～（４）のとおりの手段を備える点で、後述する相違点は別にして、本件発明の「処理装置」に相当する。 （６）一致点及び相違点 以上の検討から、本件発明と甲１発明との間には、次のとおりの一致点及び相違点がある。 ＜一致点＞ 「情報提供装置からカルテ情報を取得する手段と、 取得された前記カルテ情報から医用情報を抽出する手段と、 前記医用情報に基づく入力情報を学習済みモデルに入力することで医用関連情報を生成する手段と、 を有する処理装置。」 ＜相違点＞ （相違点１） 本件発明は、「抽出された前記医用情報を正規化する手段」を有しているのに対し、甲１発明は、そのような手段を有していない点。 （相違点２） 本件発明は、入力情報が「正規化された前記医用情報」に基づくものであるのに対して、甲１発明は、「トランスフォーマーモデル」、「ファインチューニング済みトランスフォーマーモデル」及び「事前訓練済みBERTトランスフォーマーモデル」への入力である、既知のフォーマット変換されたEMRデータ402が、「正規化された」ものではない点。 （相違点３） 本件発明は、「医用文書」を生成するのに対して、甲１発明は「候補サマリを含むテーブルまたはマトリクス」、「候補の抽象的サマリのマトリクスまたはランク付けリスト」、「フォローアップ文」であって、「医用文書」といえるか判然としない点。 ２．相違点の判断 （１）相違点１、２について 事案に鑑み、相違点１及び２をまとめて検討する。 ア 甲１発明は、「臨床ノート」のサマリを作成するものであるから、「臨床ノート」を正規化する必要はないため、「臨床ノート」を正規化しようとする動機付けはない。 したがって、甲１発明に基づいて、相違点１及び２に係る構成とすることは、当業者が容易に想到することができたものではない。 イ また、甲２～甲６には、上記第４の２～６のとおりの事項が記載されている。すなわち、甲２には、ＮＬＰ（自然言語処理）結果の後処理により、断片化された医学概念を組み合わせて、プロトコルの臨床基準に適合する概念へと統合することが記載されており、甲３及び甲４には、医療用語の表記（標記）揺れや同義語、語順相違等に対処して、標準名称又は標準表記に当てはめる処理（表記の統一やコード化）が記載され、甲５には、汎用医療用語ライブラリを用いた用語標準化、曖昧マッチング等が記載されている。また、甲６には、カルテデータのうち、テキストカルテデータに対して名称エンティティ識別を行い、数値カルテデータを正規化し、離散カルテデータをホットコードすることが記載されている。 しかしながら、上記アのとおり、甲１発明には、「臨床ノート」を正規化しようとする動機付けはないため、甲１発明に、甲２～６に記載された事項を適用しようとする動機付けもなく、さらに、甲２～甲６には、カルテ情報から抽出して正規化した医用情報を、「医用文書」を生成するための学習済みモデルに入力する入力情報とすることは記載されていないから、甲１発明及び甲２～甲６に記載された事項に基づいて、相違点１及び２に係る構成とすることは、当業者が容易に想到することができたものではない。 ウ そして、本件発明は、上記相違点１及び２に係る構成を採用することで、「より効率的に医用文書を生成することができる」（本件特許明細書段落【０００８】）との格別顕著な作用効果を奏するものである。 （２）申立人の主張について ア 申立人の主張の概要 申立人の主張の概要は次のとおりである。 （主張１） 甲１発明は、EMRデータを標準フォーマットへ変換し（Claim2・［0054］）、OMOP CDMに従った標準化フォーマットでデータベースに格納し（［0055］）、さらにSNOMED CTに基づく語彙統制処理（［0097］・［0109］～［0113］）を施すことにより、一貫して医用情報の標準化・正規化を実施するものであり、一致点である旨。（特許異議申立書４（４）ウ（イ）「【構成要件Ｃ】について」） （主張２） 甲第２号証ないし甲第５号証の各開示により、医療NLP・電子カルテ処理の技術分野において、抽出された医用情報の表記・コード・形式の差異を吸収して標準的統一表現へ変換する正規化処理が周知技術である旨。（特許異議申立書４（４）ウ（オ）（ａ）） （主張３） 甲第６号証は、本件特許発明の「抽出された医用情報を正規化する手段」に最も直接的に対応する開示を有する旨。（特許異議申立書４（４）ウ（オ）（ｂ）） イ 主張の検討 申立人がする主張１～３について検討する。 （ア）主張１について 上記１（３）のとおりであるから、相違点である。なお、甲１発明のEMRデータ402の標準フォーマットへの変換は、甲１の記載（[0025]、[0053]、[0055]等）を参照すると、OMOPデータベースに格納するために行われるものであって、本件発明のような「正規化」とは関係のない処理である。 よって、申立人の主張する主張１に理由はない。 （イ）主張２、３について 申立人は、甲１に周知技術や甲６に記載された事項を適用することのできる理由（動機付け）を述べていない。そして、上記（１）アのとおり、甲１発明は、「臨床ノート」のサマリを作成するものであるから、「臨床ノート」を正規化する動機付けはない。 よって、申立人の主張する主張２、３に理由はない。 なお、申立人は、特許異議申立書（特許異議申立書４（４）ウ（ウ））で、「本件特許発明と甲１発明との間に実質的な相違点は認められない。」と主張するが、上述したとおり、特許法第２９条第２項の主張については、本件発明と甲１発明との間には相違点１～３があり、相違点１及び２に係る構成は、当業者が容易に想到することができたものではなく、そもそも、申立人は、特許法第２９条第１項第３号に基づく理由を主張していないため、この主張は失当である。 （３）小括 以上のとおりであるから、上記相違点３について判断するまでもなく、本件発明は、甲１発明及び甲２～甲６の記載に基づいて、当業者が容易に発明をすることができたものではない。 第６ むすび 以上の次第であるから、特許異議の申立ての理由及び申立人の提出した証拠によっては、本件特許の請求項１に係る発明を取り消すことはできない。 また、他に本件特許の請求項１を取り消すべき理由を発見しない。 よって、結論のとおり決定する。