特許 6994587 グラフィカルユーザインタフェイスを備えるシステムパフォーマンスモニタ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2021-12-15

(45)【発行日】2022-01-14

(54)【発明の名称】グラフィカルユーザインタフェイスを備えるシステムパフォーマンスモニタ

(51)【国際特許分類】

   G06F 16/28 20190101AFI20220106BHJP

【ＦＩ】

G06F16/28

【請求項の数】 13

(21)【出願番号】P 2020560317

(86)(22)【出願日】2019-04-23

(65)【公表番号】

(43)【公表日】2021-08-19

(86)【国際出願番号】 US2019028651

(87)【国際公開番号】W WO2019209790

(87)【国際公開日】2019-10-31

【審査請求日】2020-11-25

(31)【優先権主張番号】62/661,117

(32)【優先日】2018-04-23

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】29/661,850

(32)【優先日】2018-08-31

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520412615

【氏名又は名称】ノボタルスキー，マーク，エス．

(74)【代理人】

【識別番号】100109896

【弁理士】

【氏名又は名称】森 友宏

(72)【発明者】

【氏名】ノボタルスキー，マーク，エス．

(72)【発明者】

【氏名】メディナ－ベルナル，ディエゴ，アイ．

【審査官】田川 泰宏

(56)【参考文献】

【文献】特表２００７－５１０９８６（ＪＰ，Ａ）

【文献】特開２０１５－０６０２５９（ＪＰ，Ａ）

【文献】特開平０８－２２１４３５（ＪＰ，Ａ）

【文献】特開２００２－１７５３１４（ＪＰ，Ａ）

【文献】特開２００６－２１５６７５（ＪＰ，Ａ）

【文献】国際公開第２０１５／１３６６２４（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１２／０１７９５１３（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

１以上のタスクを実行するシステムのパフォーマンスを表示するように適合されたシステムパフォーマンスモニタであって、
ａ）コンピュータにより実現されるフロントエンドであって、
ｉ）マイクロプロセッサと、
ii）固定記憶装置と、
iii）入力デバイスと、
iv）出力デバイスと
を含むフロントエンドと、
ｂ）コンピュータにより実現されるバックエンドと、
ｃ）コンピュータにより実現される１以上のサブシステムスキーマデータベースであって、それぞれサブシステムスキーマに関連付けられた１以上のサブシステムスキーマデータベースと
を備え、
ｄ）上記１以上のタスクを実行する上記システムは、上記サブシステムスキーマのうち１つ以上に系統立てられ、
ｅ）上記サブシステムスキーマのそれぞれは、メンバIDを有する１以上のメンバを含み、
ｆ）上記メンバのそれぞれは、上記タスクのうちの１つ以上の少なくとも一部を実行し、
ｇ）上記タスクのそれぞれは、タスクデータベースに格納された関連するタスクレコードを有しており、
ｈ）それぞれのタスクレコードは、
ｉ）タスクインデックスと、
ii）上記タスクレコードに関連付けられた上記タスクの少なくとも一部を実行する１以上のメンバの１以上のメンバIDを含むメタデータと、
iii）イベントにそれぞれ関連付けられた１以上のイベントレコードと
を含み、それぞれのイベントレコードは、
１）上記関連するイベントのイベント種別と、
２）上記関連するイベントが発生した時点のタイムスタンプと
を含み、
ｉ）サブシステムスキーマに関連付けられた上記サブシステムスキーマデータベースのそれぞれは、
ｉ）上記関連するサブシステムスキーマのそれぞれのメンバに関連付けられたメンバレコード
を含み、
ｊ）上記メンバレコードのそれぞれは、
ｉ）上記関連するサブシステムスキーマのメンバに関連付けられたメンバIDインデックスと、
ii）上記メンバIDインデックスに関連付けられた上記メンバにより少なくとも部分的に実行されるタスクに関連付けられたそれぞれのタスクレコードの少なくとも一部と
を含み、
ｋ）上記フロントエンドは、上記フロントエンドの上記固定記憶装置上に格納されたコンピュータ読取可能な命令を含み、上記フロントエンドの上記コンピュータ読取可能な命令は、上記フロントエンドの上記マイクロプロセッサに
ｉ）上記サブシステムスキーマのうちの１つの選択及び上記選択されたサブシステムスキーマの上記メンバのうちの１つの選択をユーザから上記入力デバイスを介して受け取るステップと、
ii）上記選択されたサブシステムスキーマ及び選択されたメンバを用いて上記バックエンドを呼び出すステップと、
iii）上記選択されたメンバに関連付けられた０個以上の選択タスクレコードと、上記選択されたメンバに関連付けられた０個以上の非選択タスクレコードとを含むフォーマット済みのメンバレコードを、上記選択されたサブシステムスキーマに関連付けられたサブシステムスキーマデータベースから上記バックエンドを介して受け取るステップと、
iv）上記選択タスクレコードのマークをフォーマットして上記出力デバイス上に表示するステップと
を物理的に実行させることを可能にする、
システムパフォーマンスモニタ。

【請求項2】

上記フロントエンドの上記コンピュータ読取可能な命令は、上記フロントエンドの上記マイクロプロセッサに、
ａ）上記フォーマット済みのメンバレコードの上記受取に応答して、上記出力デバイス上にタイムクラウド散布図を表示するステップ
をさらに物理的に実行させることを可能にし、上記タイムクラウド散布図は、
ｉ）Ｘ軸と、
ii）Ｙ軸と、
iii）上記フォーマット済みメンバレコード中の選択タスクレコードのそれぞれに対するデータ点マークと
を含み、
ｂ）上記フォーマット済みメンバレコード中の上記選択タスクレコードは、それぞれタイムスタンプ付きの開始イベントとタイムスタンプ付きの終了イベントとを含み、
ｃ）上記データ点マークのそれぞれは、上記終了イベントの上記タイムスタンプに基づいたＸ値を有し、
ｄ）上記データ点マークのそれぞれは、上記開始イベントの上記タイムスタンプに基づいたＹ値を有する、
請求項１に記載のシステムパフォーマンスモニタ。

【請求項3】

上記Ｘ軸は水平方向に延び、上記Ｙ軸は垂直方向に延びる、
請求項２に記載のシステムパフォーマンスモニタ。

【請求項4】

上記表示されるデータ点マークは半透過的なものである、請求項２又は３に記載のシステムパフォーマンスモニタ。

【請求項5】

上記タイムクラウド散布図は、
ａ）ＹがＸと等しくなる位置にある第１のマーク線と、
ｂ）特定のタスクについての開始イベントから終了イベントまでの間に予想される時間量をＸに加えた値にＹが等しくなる位置にある第２のマーク線と
をさらに含む、
請求項２から４のいずれか一項に記載のシステムパフォーマンスモニタ。

【請求項6】

上記データ点マークは、上記ユーザに対して対話的なものである、請求項２から５のいずれか一項に記載のシステムパフォーマンスモニタ。

【請求項7】

データ点マークを上記ユーザがアクティベートすると、上記データ点マークのそれぞれが、上記関連するデータ点マークの上記関連タスクに関連付けられたメタデータを表示する、請求項６に記載のシステムパフォーマンスモニタ。

【請求項8】

上記タイムクラウド散布図は、上記選択されたメンバの上記選択タスクレコードと上記選択されたメンバの上記非選択タスクレコードとに基づく統計項目をさらに含む、請求項２から７のいずれか一項に記載のシステムパフォーマンスモニタ。

【請求項9】

上記タスクを実行する上記システムは、上記タスクの少なくとも一部を実行する人を含む、請求項１から８のいずれか一項に記載のシステムパフォーマンスモニタ。

【請求項10】

上記サブシステムスキーマのうちの少なくとも１つは、上記人のグループを含む、請求項９に記載のシステムパフォーマンスモニタ。

【請求項11】

コンピュータにより実現可能なデータマンガーであって、
ａ）マイクロプロセッサと、
ｂ）固定記憶装置であって、上記データマンガーの上記マイクロプロセッサに、
ｉ）上記タスクデータベースに格納された上記タスクレコードのうちの１つを読み込むステップと、
ii）上記読み込まれたタスクレコードの上記メタデータにおける上記メンバのそれぞれに対してメンバレコードを生成するステップと、
iii）上記生成されたメンバレコードを上記システムスキーマデータベースに格納するステップと
を物理的に実行させるためのコンピュータ読取可能な命令を含む固定記憶装置と
を含むデータマンガーをさらに備える、請求項１から10のいずれか一項に記載のシステムパフォーマンスモニタ。

【請求項12】

ａ）メンバIDの選択がサブシステムスキーマの選択ともなるように上記メンバIDはそれぞれのサブシステムスキーマに対して特有なものであり、
ｂ）上記フロントエンドの上記コンピュータ読取可能な命令は、上記フロントエンドの上記マイクロプロセッサに、
ｉ）上記選択されたメンバIDを受け取るための上記フロントエンドの上記入力デバイス上に１つの入力フィールドを提示するステップと、
ii）上記メンバIDを上記バックエンドに転送するステップと
をさらに物理的に実行させることを可能にし、
ｃ）上記バックエンドは、上記選択されたメンバIDから上記選択されたサブシステムスキーマを決定するように構成される、
請求項１から11のいずれか一項に記載のシステムパフォーマンスモニタ。

【請求項13】

ａ）第１のサブシステムスキーマは、知的財産権についての出願の分類であり、
ｂ）第２のサブシステムスキーマは、知的財産権についての出願の審査部門であり、
ｃ）第３のサブシステムスキーマは、知的財産権についての出願の審査官である、
請求項12に記載のシステムパフォーマンスモニタ。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書で述べられる発明は、グラフィカルユーザインタフェイスを備えるシステムパフォーマンスモニタの分野に属する。

【背景技術】

【0002】

特定のシステム又は上記特定のシステム内のサブシステムが所定のタスクをいかに速く実行することができるかを図で示すことができるシステムパフォーマンスモニタが長い間にわたって必要とされている。このシステムは、インターネット上でメッセージを配信するためのコンピュータシステムのように完全に自動化されたシステムであり得る。また、このシステムは、特定の企業の従業員のようなタスクを実行する人を含み得る。サブシステムは、サーバファーム内のサーバのような自動装置のグループを含み得る。また、サブシステムは、組織内の部署のような人のグループを含み得る。サブシステムは、ネットワークに接続されたワークステーションでそれぞれ作業する人のグループのように自動装置と人の両方を含む場合がある。

【発明の開示】

【0003】

本発明の開示は、本発明を理解するためのガイドとして提供される。本発明の開示は、本発明の最も包括的な実施形態や最も広い範囲の別の実施形態を必ずしも述べているものではない。

【0004】

図１は、１以上のタスク（例えばＲ₁，Ｒ₂，Ｒ₃）を実行するシステム150のパフォーマンスを表示するように適合されたシステムパフォーマンスモニタ100の概念図である。このシステムパフォーマンスモニタは、
ａ）コンピュータにより実現されるフロントエンド110であって、
ｉ）マイクロプロセッサと、
ii）固定記憶装置と、
iii）入力デバイス111と、
iv）出力デバイス160と
を含むフロントエンド110と、
ｂ）コンピュータにより実現されるバックエンド120と、
ｃ）コンピュータにより実現される１以上のサブシステムスキーマデータベース140であって、それぞれサブシステムスキーマに関連付けられた１以上のサブシステムスキーマデータベース140と
を含み得る。

【0005】

１以上のタスクを実行するシステム150は、上記サブシステムスキーマ151（例えばＡ、Ｂ、及びＣ）のうちの１つ以上に系統立てられている。サブシステムスキーマのそれぞれは、メンバID（例えばＡ₁，Ａ₂，Ａ₃，Ｂ₁，Ｂ₂，Ｂ₃，Ｃ₁，Ｃ₂，Ｃ₃）を有する１以上のメンバを含んでいる。メンバのそれぞれは、上記タスク（例えばＲ₁，Ｒ₂，Ｒ₃）のうちの１つ以上の少なくとも一部を実行する。

【0006】

タスクのそれぞれは、タスクデータベース130内に格納された関連タスクレコード131を有している。それぞれのタスクレコードは、
ｉ）タスクインデックス132と、
ii）上記タスクレコードに関連付けられた上記タスクの少なくとも一部を実行する１以上のメンバの１以上のメンバID（例えばＡ₁，Ｂ₃，Ｃ₂）を含むメタデータ133と、
iii）イベントにそれぞれ関連付けられた１以上のイベントレコード（例えば134）と
を含み、それぞれのイベントレコードは、
１）上記関連するイベントのイベント種別（例えば135）と、
２）上記関連するイベントが発生した時点のタイムスタンプ（例えば136）と
を含んでいる。

【0007】

サブシステムスキーマに関連付けられたサブシステムスキーマデータベース（例えば141）のそれぞれは、
ｉ）上記関連するサブシステムスキーマのそれぞれのメンバに関連付けられたメンバレコード（例えば147）
を含んでいる。

【0008】

メンバレコードのそれぞれは、
ｉ）上記関連するサブシステムスキーマのメンバに関連付けられたメンバIDインデックス（例えば142）と、
ii）上記メンバインデックスに関連付けられた上記メンバにより少なくとも部分的に実行されるタスクに関連付けられたそれぞれのタスクレコードの少なくとも一部（例えば143）と
を含んでいる。

【0009】

フロントエンドは、上記フロントエンドの上記固定記憶装置上に格納されたコンピュータ読取可能な命令を含んでおり、上記フロントエンドの上記コンピュータ読取可能な命令は、上記フロントエンドの上記マイクロプロセッサに
ｉ）上記サブシステムスキーマのうちの１つ（例えば115）の選択及び上記選択されたサブシステムスキーマの上記メンバのうちの１つ（例えばＡ₃）の選択（112）をユーザから上記入力デバイスを介して受け取るステップと、
ii）上記選択されたサブシステムスキーマ及び選択されたメンバを用いて上記バックエンドを呼び出す（114）ステップと、
iii）上記選択されたメンバに関連付けられた０個以上の選択タスクレコード144と、上記選択されたメンバに関連付けられた０個以上の非選択タスクレコード146とを含むフォーマット済みのメンバレコード123を、上記選択されたサブシステムスキーマに関連付けられたサブシステムスキーマデータベースから上記バックエンドを介して受け取るステップと、
iv）上記選択タスクレコードのマーク（例えば164）をフォーマットして上記出力デバイス上に表示する（161）ステップと
を物理的に実行させることを可能にする。

【図面の簡単な説明】

【0010】

【図1】図１は、システムパフォーマンスモニタの概念図である。

【図2】図２は、上記システムパフォーマンスモニタの出力デバイス上に表示されるタイムクラウド散布図である。

【発明を実施するための最良の形態】

【0011】

この詳細な説明は、非限定的な例示的実施形態について述べるものである。いずれの個々の特徴も、少なくとも本明細書で述べられる利点を得るために異なる用途によって必要とされる場合には、他の特徴と組み合わせることができる。本明細書で使用される場合には、「約」という語は、特に示さない場合を除いて特定の値のプラスマイナス10％を意味する。

【0012】

本特許文書の開示の一部は、著作権の主張がなされている事項を含んでいる。本著作権者は、特許商標庁の特許ファイル又は記録上の本特許文書及び本特許の開示を第三者がファクシミリにより複製することについては異議を申し立てることはないが、他のすべての著作権についてはいかなるものであってもこれを留保する。

【0013】

本明細書で使用される場合には、「コンピュータシステム」は、データを受け取るための入力デバイス（例えば、キーボード、タッチスクリーン、又は他のデバイスからの電子デジタル入力）と、データを出力するための出力デバイス（例えば、プリンタ、コンピュータスクリーン又は他のデバイスへのデジタル接続）と、データ、コンピュータコード又は他のデジタル命令を格納するための固定デジタルメモリと、デジタル命令を実行するためのデジタルプロセッサとを含んでいる。上記固定記憶装置に保存されている上記デジタル命令は、上記入力デバイスを介してデータを読み込み、上記マイクロプロセッサ内の上記データを処理し、上記出力デバイスを介して上記処理されたデータを出力することを物理的に上記デジタルプロセッサにさせるものである。

【0014】

本明細書において使用される場合には、「形状」という語は、特定の形状の純粋な形態に対してわずかなバリエーションが存在したとしても、全体の外観としてその特定の形状を有していることを意味する。

【0015】

本明細書において使用される場合には、「概して」という語は、形状に関して言及している場合には、一般的な観察者が、その形状からわずかに変化していたとしても物体がその形状を有していると把握することを意味している。

【0016】

本明細書において使用される場合には、「上」、「下」、「上部」、「下部」、「左」、「右」、「垂直」、「水平」、「遠位」、及び「近位」などの相対的な方向に関する語は、物体に関する当初の説明に関して規定されるものであり、特に言及しない限り、その物体がその後に別の方向で説明されている場合であっても、その物体の同一の部分を意味するものである。

【0017】

本明細書において使用される場合には、特に示されない限り、単数形での開示事項は、複数形での開示事項を示唆するものであり、その逆もしかりである。

【0018】

再び図１を参照すると、フロントエンドのコンピュータ読取可能な命令は、
ａ）フォーマット済みのメンバレコードの受取に応答して、出力デバイス160上にタイムクラウド散布図（例えば161）を表示するステップをさらに含み得る。このタイムクラウド散布図は、
ｉ）Ｘ軸162と、
ii）Ｙ軸163と、
iii）フォーマット済みメンバレコード中の選択タスクレコードのそれぞれに対するデータ点マーク（例えば164）と
を含み得る。

【0019】

上記フォーマット済みメンバレコード中の選択タスクレコードは、それぞれタイムスタンプ付きの開始イベントとタイムスタンプ付きの終了イベントとを含み得る。表示されるデータ点マークのそれぞれは、上記終了イベントの上記タイムスタンプに基づいたＸ値を有している。上記表示されるデータ点マークのそれぞれは、上記開始イベントの上記タイムスタンプに基づいたＹ値を有している。

【0020】

Ｘ軸は水平方向に延びていてもよい。Ｙ軸は垂直方向に延びていてもよい。このＸ軸を持つことの驚くべき利点は、ユーザが左から右に向かってタイムクラウド図を読み取り、選択されたメンバのパフォーマンスが時間とともにどのように変化しているかを理解できることにある。あるいは、Ｙ軸が水平方向に延びていてもよく、Ｘ軸が垂直方向に延びていてもよい。この方向の利点は、水平軸がイベントの開始した時点に対応することにある。

【0021】

表示されるデータ点マークは半透過的なものであってもよい。これにより、２つのデータ点マークが重なった場合（例えば166）には、重なっている範囲が目に見えることとなる。

【0022】

タイムクラウド散布図は、ＹがＸと等しくなる位置に第１のマーク線165を有していてもよい。この線は、現時点を表している。上記線上のデータ点マークは、開始した直後に完了したタスクに対応する。

【0023】

タイムクラウド散布図は、特定のタスクについての開始イベントから終了イベントまでの間に予想される時間量173をＸに加えた値にＹが等しくなる位置に第２のマーク線171を有していてもよい。これにより、ユーザは、タイムクラウド図を見て直ちにタスクが予想された時間量の間に完了しているのかを把握することができる。データ点マークが第２のマーク線の下側に位置している場合（例えば172）には、ユーザは、この遅れの原因が何であったのかを突き止めるためにさらに調査をしたいと考えるかもしれない。

【0024】

データ点マークは、ユーザに対して対話的なものであってもよい。例えば、データ点マークを上記ユーザがアクティベートすると、上記データ点マークのそれぞれが、上記関連するデータ点マークの上記関連タスクに関連付けられたメタデータ167を表示してもよい。

【0025】

タイムクラウド散布図は、上記選択されたメンバの上記選択タスクレコードと上記選択されたメンバの上記非選択タスクレコードとに基づく統計項目169をさらに含んでいてもよい。この統計項目は、表示されたデータ点マークの状況を提供するのに役立つ。例えば、表示される統計項目は、全タスクレコード（すなわち、選択タスクレコードに非選択タスクレコードを加えたもの）に対する選択タスクレコードの割合であってもよい。これにより、ユーザは、表示されているデータ点マークの数が多いのか少ないのかを把握することが可能となる。

【0026】

ユーザが他の者にタイムクラウド散布図を見せることができるようにし、当該他の者がどのメンバが選択されているのかを知ることができるようにタイムクラウド散布図に選択メンバの表示168を提示してもよい。

【0027】

これに加えて、あるいはこれに代えて、メンバの表示及び統計項目をタイムクラウド散布図の外部、例えば余白に表示してもよい。

【0028】

システムパフォーマンスモニタは、コンピュータにより実現可能なデータマンガー124であって、
ａ）マイクロプロセッサと、
ｂ）固定記憶装置であって、上記データマンガーの上記マイクロプロセッサに、
ｉ）上記タスクデータベースに格納された上記タスクレコードのうちの１つ（例えば131）を読み込むステップと、
ii）上記読み込まれたタスクレコードの上記メタデータ（例えば133）における上記メンバ（例えばＡ₁，Ｂ₃，Ｃ₂）のそれぞれに対してメンバレコードを生成するステップと、
iii）上記生成されたメンバレコード（例えばＡ₁：ｒ₁，Ｂ₃：ｒ₁，Ｃ₂：ｒ₁）を上記システムスキーマデータベースに格納するステップと
を物理的に実行させるためのコンピュータ読取可能な命令を含む固定記憶装置と
を含むデータマンガー124をさらに備えていてもよい。

【0029】

バックエンドは、さらに、フロントエンドからの呼び出し114を認証し、ルーティングする（121）ように構成されていてもよい。バックエンドは、さらに、選択されたサブシステムスキーマによるルーティング要求に基づいて適切なサブシステムスキーマデータベースを呼び出す（122）ように構成されていてもよい。

【0030】

フロントエンドは、さらに、どのサブシステムスキーマ（例えば115，116，117）かを決定するように構成されていてもよい。

【0031】

実施例１
米国特許商標庁（USPTO）は、１以上のタスクを実行するシステムである。上記タスクのうちの１つは特許出願の審査である。この審査は特許審査官により少なくとも部分的に行われる。特許庁のサブシステムスキーマのうちの１つは、特許出願に割り当てられた技術分類である。特許分類スキーマのメンバは異なるクラス（例えばクラス706－人工知能）を含んでいる。他のサブシステムスキーマは、特許出願が割り当てられる技術審査部門（art unit）である。技術審査部門スキーマのメンバは、個々の技術審査部門（例えばAU 2121）を含んでいる。他のサブシステムスキーマは、特許審査官である。特許審査官スキーマのメンバは、個々の審査官である。法律事務所スキーマ、出願人スキーマ、又は発明者スキーマなどの他のスキーマが考えられ得る。

【0032】

それぞれの特許出願には出願番号が割り当てられる（例えばSN 12/345,678）。USPTOは、特許出願の審査中に生じたすべてのイベントを把握している（例えば、処理履歴又は出願包袋）。これらのイベントは、イベント種別（例えば「最後ではない拒絶理由通知」）とタイムスタンプ（例えば05-05-2011又は月－日－年）とを有している。

【0033】

USPTOは、「特許審査データシステム」（PEDS）と呼ばれる一般の人々に利用可能なデータベースに、特許出願番号に関連付けられたメタデータとイベントに対するレコードを格納している。PEDS内のレコードは、出願番号によりインデックス化されている。それぞれのレコードに対するメタデータは、特許分類スキーマに対する３桁の技術クラス番号、技術審査部門スキーマに対する４桁の技術審査部門番号、審査官スキーマに対する英字名のようなサブシステムラベルを含んでいる。USPTOは、特定の特許分類クラス、技術審査部門、又は審査官に割り当てられた出願を選択するために検索エンジンを提供しているが、特定の検索に対してレコードのセットを取得するのにかかる時間が非常に長い場合がある（例えば大きな特許分類クラスについては10分以上）。さらに、上記レコードが検索エンジンにより返された後、上記レコードを処理してタイムクラウド図を生成するのに必要な時間は、非常に長くなり得る。１つの特許分類クラスに対するデータファイルは１GBになり得る。１つの特許分類クラスのデータを処理するために必要な時間は、１つのワークステーションで数時間になり得る。特許分類スキーマには約700のメンバがある。700のメンバすべてに対するデータを処理するには、巨大なクラウドベースのデータ処理サーバ上で数日がかかっている。

【0034】

この問題を解消するために、上記説明に係るシステムパフォーマンスモニタが開発された。このシステムパフォーマンスモニタは、一般的に、ユーザのクライアント端末から離れたクラウドベースのものである。フロントエンドは、ウェブサーバ（Netlify.com）上に置かれている。Netlifyに接続されたユーザのクライアント端末は、フロントエンドの一部であると考えられる。バックエンドは、アプリケーションサーバであるアマゾンウェブサーバ（aws.amazon.com）上に置かれている。サブシステムスキーマデータベースは、クラウドベースのサービスMongoDB Atlas（www.mongodb.com/cloud/atlas）上に置かれている。当業者であれば、フロントエンド、バックエンド、及びサブシステムスキーマデータベースをホストするために別のクラウドベースのサービスやメインフレームやサーバファームのような専用リソースを使用できることを理解するであろう。このように、本明細書で述べられる発明は、特定のコンピュータプラットフォームに限定されるものではない。

【0035】

フロントエンドには、ユーザからのサブシステムスキーマのメンバの選択を受け取るための１つの入力フィールドが設けられている。ドロップダウンメニューは、ユーザが入力したものに応じて３つのすべてのスキーマから利用可能なメンバを表示する。そして、ユーザは、ドロップダウンメニューから所望のメンバを選択することができる。メンバ名は、それぞれのサブシステムスキーマに特有なものであるため、バックエンドが、選択されたサブシステムスキーマを決定し、したがってどのサブシステムスキーマデータベースに問い合わせをすべきかを決定するには、メンバの選択が十分なものとなる。この例では、選択されたメンバIDが英文字を有している場合には、選択されたサブシステムスキーマは審査官となる。選択されたメンバIDが３桁の数字である場合には、選択されたサブシステムスキーマは特許分類クラスとなる。選択されたメンバIDが４桁の数字である場合には、選択されたサブシステムスキーマは技術審査部門となる。この例では、フロントエンドは、単に選択されたメンバIDをバックエンドに転送し、バックエンドが、選択されたサブシステムスキーマを決定する。

【0036】

バックエンドにおいてデータマンガーはプログラミング言語を用いて記述されている。データマンガーは、PEDSデータベース全体を読み込む（１TBを超える）。その後、データマンガーは、それぞれの出願レコードに対して注目するメタデータ及びイベントを選択し、データをフォーマットし直し、データをサブシステムスキーマデータベースに格納する。３つのサブシステムスキーマデータベースがセットアップされる。特許分類クラスに対して１つのサブシステムスキーマデータベースがセットアップされ、技術審査部門に対して１つのサブシステムスキーマデータベースがセットアップされ、審査官に対して１つのサブシステムスキーマデータベースがセットアップされる。登録された米国特許弁理士又は弁護士のようなユーザは、これらのスキーマのうちいずれかのメンバのパフォーマンスに関心があるであろう。ユーザは、例えば、特定の審査官のパフォーマンスが特定の技術審査部門におけるすべての審査官のパフォーマンスと合致するものであるかを判断することができる。同様に、同じ特許分類クラスの特許出願を審査している異なる技術審査部門のパフォーマンスを比較することができる。同様に、USPTO内の管理者は、特に同様のパフォーマンスを発揮すべき審査官、技術審査部門、又は分類の間に際立った不一致が存在するかに関心がある場合がある。

【0037】

注目するメタデータ（例えば、出願番号、発明の名称、分類、技術審査部門、審査官）とイベントデータ（例えば、ノンファイナルリジェクション、ファイナルリジェクション、許可通知）だけを含むようにPEDSデータをフィルタリングすると、データ量が35倍縮小される。しかしながら、３つのサブシステムスキーマデータベースが存在しており、それぞれのデータベースはそれぞれのサブシステムスキーマのメンバによりインデックス化された複製データを有しているため、データ全体の削減は約12倍である。それでも、サブシステムスキーマを選択し、上記サブシステムスキーマのメンバを選択し、出力デバイス上にタイムクラウド図が示されるまでの遅延は、100,000個のデータ点マークを示すタイムクラウド図についてであっても、わずか約10秒かそれ未満である。

【0038】

図２は、上記システムパフォーマンスモニタの出力デバイス200に表示される例示的タイムクラウド散布図202である。このサブシステムスキーマは特許分類クラスであった。特許分類クラスの選択されたメンバは、クラス706－人工知能であった。選択レコードは、この特許分類クラスの許可通知を受けたすべての出願のレコードであった。非選択レコードは、許可通知を受けなかったすべての出願のレコードであった。上記非選択レコードは、放棄された特許出願か、あるいは許可通知を受けることなく係属中の特許出願に対するものであり得る。１つのレコード中に複数の許可通知が存在する場合には、すべての許可通知が選択され、それぞれデータ点マークとして示された。

【0039】

Ｙ軸231は、特許出願の出願日である。Ｘ軸232は、許可通知日である。両方の軸は、2000年１月１日から始まり、PEDSデータがダウンロードされた日（すなわち2019年３月15日）で終わっている。ここでは、PEDSデータベースの全体を最初にダウンロードした後、その後のダウンロードは、先のダウンロード以降の新しいイベントを有する出願についてのレコードのみを含んでいてもよいと考えられる。その後のダウンロードからのデータは、サブシステムスキーマデータベースを更新するために使用することができる。

【0040】

第１のマーク線223は、ＹがＸと等しくなる位置にある。第２のマーク線224は、Ｘに３年を加えた値にＹが等しくなる位置にある。３年は、出願人が特許出願の審査を遅延させていないとして米国特許法により許可通知を受けるのに必要となる最大の時間量である。

【0041】

データ点マーク（例えば211）は、選択レコード（すなわち、許可通知を受領したすべての出願）のそれぞれについてタイムクラウド散布図上に表示されている。全部で約11,000個のデータ点マークが示されている。データ点マークは、中実黒色で境界線がなく、３ポイントの大きさを有している。データ点の透過度は80％である。これにより、１つのデータ点マーク（例えば212）がはっきりと見えると同時に、密度の高い領域（例えば213）を認識することができる。

【0042】

ユーザによりいずれかのデータ点マーク（例えば212）が選択されると、そのデータ点マークに関連付けられた出願の関連メタデータ（例えば、出願番号と発明の名称）を示すポップアップ214が表示される。

【0043】

タイムクラウド散布図上には選択された特許分類クラス（項目204）が表示される。別の実施形態では、これに代えて、特許分類クラスがタイムクラウド散布図の余白部分に表示される。

【0044】

また、算出された統計項目APOA₁₂の値（項目206）がタイムクラウド散布図上に示された。APOAは、「１回の拒絶理由通知に対する許可通知数（allowances per office action）」を意味している。下付文字の「12」は、このAPOAが、データがダウンロードされた日又は最後に更新された日の前12ヶ月の間の拒絶理由通知に対するものであることを示している。拒絶理由通知は、許可通知を受け取らなかった出願のような非選択レコードの最後ではない拒絶理由通知及び最後の拒絶理由通知を含んでいる。このため、APOA₁₂は、１つの許可通知を得るためにポートフォリオ中のすべての出願について全体でユーザが何回の拒絶理由通知に対して応答する必要があると考えられるのかをユーザに示すものとなる。APOA₁₂は、過去12ヶ月間で１つの許可通知を得るために出願人は約４回の拒絶理由通知に対して応答する必要があったことを示している。

【0045】

縦のグリッド線221と横のグリッド線222は、特定の出願がそれぞれ許可されたときと出願されたときをユーザが簡単に把握できるようにタイムクラウド散布図上に示されている。

【0046】

ユーザは、このタイムクラウドを見て、2017年の初めからデータ点マークが薄くなっている（242）ことに気づいた。そして、ユーザは、最後ではない拒絶理由通知又は最後の拒絶理由通知を含む出願がデータ点マークによって表されている場合に基づいて別のタイムクラウド図を生成した。ユーザは、2017年より後に拒絶理由を受けたいくつかの出願についてポップアップを用いて、その出願が過去に米国特許法第101条に基づく拒絶理由を受けていない場合には、多くの出願が米国特許法第101条に基づく拒絶を受けていると判断した。したがって、ユーザは、クラス706に割り当てられると考えられる出願を行うことに対して悲観的になった。しかしながら、より詳細に観察すると、ユーザは、2019年の最初の数ヶ月に許可通知のデータ点マークが突然濃くなっている（243）ことを見つけた。USPTOは、米国特許法第101条による特許出願の適切な審査に関して2019年１月に新しいガイドラインを発表した。ユーザが2019年初めに許可された出願の出願包袋を確認したところ、この分類の審査官は、2019年１月以前には拒絶していた出願を新しいガイドラインに基づいて許可していることを見つけた。このため、この分類に属する出願をし続けることをユーザに促すものとなった。ユーザは、異なるサブシステムスキーマの異なるメンバのパフォーマンスについてのわずかな変化及び急激な変化の両方を見て、特許出願の原稿をより効果的に作成し、その審査をより効果的に進めることができる。

【0047】

結論
本開示は、１以上の異なる例示的な実施形態を参照して述べられてきたが、本開示の範囲を逸脱することなく、様々な変更を行うことができ、その要素を均等物に代えることができることは、当業者により理解されるであろう。加えて、その本質的な範囲又は教示を逸脱することなく、特定の状態に適合させるために数多くの修正を行うことができる。したがって、本開示は、本発明を実施するために最良と考えられるものとして開示されている特定の実施形態に限定されるものではない。

【図1】

【図2】