(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-29
(45)【発行日】2022-10-07
(54)【発明の名称】分散コンピューティングデバイスの自動制御
(51)【国際特許分類】
G06F 11/07 20060101AFI20220930BHJP
【FI】
G06F11/07 193
G06F11/07 190
G06F11/07 140A
G06F11/07 140V
(21)【出願番号】P 2021522934
(86)(22)【出願日】2019-07-02
(86)【国際出願番号】 US2019040408
(87)【国際公開番号】W WO2020010149
(87)【国際公開日】2020-01-09
【審査請求日】2022-06-02
(32)【優先日】2018-07-02
(33)【優先権主張国・地域又は機関】US
【早期審査対象出願】
(73)【特許権者】
【識別番号】521000769
【氏名又は名称】アテラ ネットワークス リミテッド
【氏名又は名称原語表記】ATERA NETWORKS LTD.
【住所又は居所原語表記】Allenby 105, 6513444 Tel Aviv, Israel
(74)【代理人】
【識別番号】110002789
【氏名又は名称】弁理士法人IPX
(72)【発明者】
【氏名】モヤル オシュリ
(72)【発明者】
【氏名】ペケルマン ギル
(72)【発明者】
【氏名】ディクスタイン エリエゼル
【審査官】多賀 実
(56)【参考文献】
【文献】米国特許出願公開第2008/172574(US,A1)
【文献】特開2000-148538(JP,A)
【文献】米国特許出願公開第2005/278789(US,A1)
【文献】米国特許出願公開第2015/379520(US,A1)
【文献】特開2014-142872(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 11/07
G06F 11/28-11/36
G06Q 50/10
(57)【特許請求の範囲】
【請求項1】
少なくとも1つのプロセッサーと、及び
前記少なくとも1つのプロセッサーによる実行のための命令を記憶するように構成された非一時的コンピュータ読取可能媒体とを有しており、
前記命令は、次のものを含むものである:
クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ること;
前記サービスチケットを技術者に割り当てること;
技術者デバイスと前記クライアントデバイスとの間の遠隔制御セッションを調整すること、ここで、前記技術者デバイスは、前記技術者の制御下にあるものであり;
前記クライアントデバイスを前記所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、前記技術者により実行されるアクションのセットを取得すること、ここで、前記アクションのセットのうちの各アクションは、前記クライアントデバイスとの1つまたは複数のユーザーインターフェース(UI)の相互作用を表現しているものであり;
前記サービスチケットの特性に基づいて、キーワードのセットを識別すること;
前記識別したキーワードを前記アクションのセットと関連付けること;
前記アクションのセット及び前記識別したキーワードを前記技術者へ提示すること;
前記技術者からの入力を受け取ることに応じて、前記アクションのセットを選択的に変更すること;
前記変更したアクションのセットの技術者承認に応じて、
前記変更したアクションのセット及び前記識別したキーワードに基づき、解決プロファイル(RP)を保存すること;及び
第2クライアントデバイスのために提出された第2サービスチケットを受け取ることに応じて
:
自然言語処理を用いて前記第2サービスチケットを分析すること;及び
前記第2サービスチケットに適用可能とするように前記RPを分類する前記自然言語処理に応じて:
技術者介在なしに、前記第2クライアントデバイスにおいて、前記RPからの前記アクションのセットをプログラム的に再生するために、前記第2クライアントデバイスで実行するソフトウエアエージェントに選択的に指示すること;及び
前記アクションのセットの前記プログラム的な再生が、前記第2クライアントデバイスを、前記RPに関連する所望するシステム状態へ移行させたことを検証すること、を有するように構成されたシステム。
【請求項2】
前記アクションのセットのうちの各アクションは、基本的解決ステップ(BRS)データ構造に保存されており、前記BRSデータ構造は、BRSデータ構造定義に準拠するものである、及び
前記RPは、前記BRSデータ構造の実行順序をエンコードするものである、請求項1に記載のシステム。
【請求項3】
前記アクションのセットのうちの第1アクションに対応する第1基本的解決ステップ(BRS)データ構造は、前記第1アクションが実行される前に取り込まれた前記クライアントデバイスのスクリーンショットを含むものである、請求項1に記載のシステム。
【請求項4】
前記第1BRSデータ構造は、コマンドを保存しており、前記コマンドにおいては、実行が前記クライアントデバイスを前記所望でないシステム状態から第2システム状態へ移行させる、請求項3に記載のシステム。
【請求項5】
前記アクションのセットのうちの第1アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも1つを含むものである、請求項1に記載のシステム。
【請求項6】
前記第2クライアントデバイスが前記所望でないシステム状態にあることに応じて、前記命令は、前記第2クライアントデバイスで前記RPを再生することを含むものである、請求項1に記載のシステム。
【請求項7】
前記RPは、前記アクションのセットと1対1で対応するファイルの集まりとして、保存される、請求項1に記載のシステム。
【請求項8】
前記アクションのセットを取得することは、前記遠隔制御セッションの完了時に、前記クライアントデバイスまたは前記技術者デバイスのうちの1つから前記アクションのセットを受け取ることを含むものである、請求項1に記載のシステム。
【請求項9】
前記アクションのセットを取得することは、前記技術者デバイスにより前記クライアントデバイスへ送付されたものとして、前記アクションのセットを記録することを含むものである、請求項1に記載のシステム。
【請求項10】
前記サービスチケットを前記技術者に割り当てることは、前記技術者による前記チケットの要求に応じて実行される、請求項1に記載のシステム。
【請求項11】
前記命令は、前記技術者からの変更要求に応じて、前記キーワードのセットを変更することを含むものである、請求項1に記載のシステム。
【請求項12】
前記キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも1つを含むものである、請求項1に記載のシステム。
【請求項13】
前記命令は、ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも1つから前記サービスチケットを生成することを含むものである、請求項1に記載のシステム。
【請求項14】
前記命令は、前記保存することの後、他の技術者と共有するために、前記RPを知識ベース(KB)アーティクルに選択的に変換することを含むものである、ここで、前記KBアーティクルは、シリーズ化したRPを含むものである、請求項1に記載のシステム。
【請求項15】
クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ること、
前記サービスチケットを技術者に割り当てること、
技術者デバイスと前記クライアントデバイスとの間の遠隔制御セッションを調整すること、ここで、前記技術者デバイスは、前記技術者の制御下にあるものであり、
前記クライアントデバイスを前記所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、前記技術者により実行されるアクションのセットを取得すること、ここで、前記アクションのセットのうちの各アクションは、前記クライアントデバイスとの1つまたは複数のユーザーインターフェース(UI)の相互作用を表現しているものであり、
前記サービスチケットの特性に基づいて、キーワードのセットを識別すること、
前記識別したキーワードを前記アクションのセットと関連付けること、
前記アクションのセット及び前記識別したキーワードを前記技術者へ提示すること、
前記技術者からの入力を受け取ることに応じて、前記アクションのセットを選択的に変更すること、
前記変更したアクションのセットの技術者承認に応じて、
前記変更したアクションのセット及び前記識別したキーワードに基づき、解決プロファイル(RP)を保存すること、及び
第2クライアントデバイスのために提出された第2サービスチケットを受け取ることに応じて
:
自然言語処理を用いて前記第2サービスチケットを分析すること;及び
前記第2サービスチケットに適用可能とするように前記RPを分類する前記自然言語処理に応じて:
技術者介在なしに、前記第2クライアントデバイスにおいて、前記RPからの前記アクションのセットをプログラム的に再生するために、前記第2クライアントデバイスで実行するソフトウエアエージェントに選択的に指示すること;及び
前記アクションのセットの前記プログラム的な再生が、前記第2クライアントデバイスを、前記RPに関連する所望するシステム状態へ移行させたことを検証すること、を有する方法。
【請求項16】
前記アクションのセットのうちの各アクションは、基本的解決ステップ(BRS)データ構造に保存され、前記BRSデータ構造は、BRSデータ構造定義に準拠するものである、及び
前記RPは、前記BRSデータ構造の実行順序をエンコードするものである、請求項15に記載の方法。
【請求項17】
前記アクションのセットのうちの第1アクションに対応する第1基本的解決ステップ(BRS)データ構造は、前記第1アクションが実行される前に取り込まれた前記クライアントデバイスのスクリーンショットを含むものであり、及び
前記第1BRSデータ構造は、コマンドを保存しており、前記コマンドにおいては、実行が前記クライアントデバイスを前記所望でないシステム状態から第2システム状態へ移行させる、請求項15に記載の方法。
【請求項18】
前記第2クライアントデバイスが前記所望でないシステム状態にあることに応じて、前記第2クライアントデバイスで前記RPを再生すること、をさらに有する請求項15に記載の方法。
【請求項19】
前記RPは、前記アクションのセットと1対1で対応するファイルの集まりとして、保存される、請求項15に記載の方法。
【請求項20】
前記アクションのセットを取得することは、次のうちの少なくとも1つを含むものである:
前記遠隔制御セッションの完了時に、前記クライアントデバイスまたは前記技術者デバイスのうちの1つから前記アクションのセットを受け取ること;及び
前記技術者デバイスにより前記クライアントデバイスへ送付されたものとして、前記アクションのセットを記録すること、を有する請求項15に記載の方法。
【請求項21】
前記サービスチケットを前記技術者に割り当てることは、前記技術者による前記チケットの要求に応じて実行されるものであり、及び
前記方法はさらに、前記技術者からの変更要求に応じて、前記キーワードのセットを変更すること、を有する請求項15に記載の方法。
【請求項22】
前記アクションのセットのうちの第1アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも1つを含むものであり、及び
前記キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも1つを含むものである、請求項15に記載の方法。
【請求項23】
ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも1つから前記サービスチケットを生成すること、をさらに有する請求項15に記載の方法。
【請求項24】
前記保存することの後、他の技術者と共有するために、前記RPを知識ベース(KB)アーティクルに選択的に変換することをさらに有し、ここで、前記KBアーティクルは、シリーズ化したRPを含むものである、請求項15に記載の方法。
【発明の詳細な説明】
【関連出願の相互参照】
【0001】
本出願は、2018年7月2日に出願した米国仮出願番号62/693,410のPCT国際出願である。上記出願の全開示は、参照することにより本明細書に組み込まれる。
【技術分野】
【0002】
本開示は、分散コンピューティングデバイスに関し、またより具体的には、分散コンピューティングデバイスを遠隔制御するための装置及び方法に関する。
【背景技術】
【0003】
コンピュータの存在する環境では、コンピュータのユーザーは、ユーザーのコンピュータで様々なインシデントに遭遇する可能性がある。例えば、ユーザーがファイルをネットワークハードドライブに保存できない、ドキュメントを印刷できない、特定のアプリケーションを起動できない、などの可能性がある。ユーザーは、インシデントを解決するための知識とリソースを持っているであろう情報技術(IT)技術者に連絡する場合がある。しかしながら、例えば技術者が他のユーザーを支援している場合や、インシデントが通常の営業時間外に発生した場合など、技術者がユーザーに即時の支援を提供することができない可能性がある。
【0004】
一旦、技術者が支援を提供できるようになると、技術者がユーザーのコンピュータに遠隔接続する前に、技術者はユーザーに許可を要求し、そしてユーザーからの承認を得られなければならない。技術者は、ユーザーのインシデントを解決するために、アクションのセットを実行することがある。インシデントの解決に応じて、技術者は他の技術者とその解決策について話し合うことにより、もしも他の技術者がそのインシデントに遭遇した場合に、他の技術者は、同様の解決策を実行することができる。
【0005】
ここで記載された背景技術の説明は、開示の文脈を一般的に示すことを目的とするものである。現在の発明者の研究は、この背景技術のセクションに記載されている範囲において、並びに出願時点でさもなければ先行技術となり得ない記述の態様は、明示的または黙示的に、本開示に対する先行技術として、認めるものではない。
【発明の概要】
【発明が解決しようとする課題】
【0006】
【課題を解決するための手段】
【0007】
システムは、少なくとも1つのプロセッサーと、少なくとも1つのプロセッサーによる実行のための命令を記憶するように構成された非一時的コンピュータ読取可能媒体とを有している。命令は、クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ることを含んでいる。命令は、サービスチケットを技術者に割り当てることを含んでいる。命令は、技術者デバイスとクライアントデバイスとの間の遠隔制御セッションを調整することを含んでおり、ここで、技術者デバイスは、技術者の制御下にあるものである。命令は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、技術者により実行されるアクションのセットを取得することを含んでおり、ここで、アクションのセットのうちの各アクションは、クライアントデバイスとの1つまたは複数のユーザーインターフェース(UI)の相互作用を表現しているものである。命令は、サービスチケットの特性に基づいて、キーワードのセットを識別することを含んでいる。命令は、識別したキーワードをアクションのセットと関連付けることを含んでいる。命令は、アクションのセット及び識別したキーワードを技術者へ提示することを含んでいる。命令は、技術者からの入力を受け取ることに応じて、アクションのセットを選択的に変更することを含んでいる。命令は、技術者承認に応じて、解決プロファイル(RP)を保存することを含んでおり、ここで、RPは、変更したアクションのセット及び識別したキーワードに基づくものである。命令は、第2クライアントデバイスのために提出された第2サービスチケットを受け取ることに応じて、第2クライアントデバイスにおいて、RPからのアクションのセットを選択的に再生することを含んでいる。
【0008】
他の特徴では、アクションのセットのうちの各アクションは、基本的解決ステップ(BRS)データ構造に保存され、BRSデータ構造は、BRSデータ構造定義に準拠し、そしてRPは、BRSデータ構造の実行順序をエンコードするものである。他の特徴では、アクションのセットのうちの第1アクションに対応する第1BRSデータ構造は、第1アクションが実行される前に取り込まれたクライアントデバイスのスクリーンショットを含むものである。他の特徴では、第1BRSデータ構造は、コマンドを保存しており、コマンドにおいては、実行がクライアントデバイスを所望でないシステム状態から第2システム状態へ移行させるものである。
【0009】
他の特徴では、アクションのセットのうちの第1アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも1つを含むものである。他の特徴では、第2クライアントデバイスが所望でないシステム状態にあることに応じて、命令は、第2クライアントデバイスでRPを再生することを含むものである。他の特徴では、RPは、アクションのセットと1対1で対応するファイルの集まりとして、保存されるものである。他の特徴では、アクションのセットを取得することは、遠隔制御セッションの完了時に、クライアントデバイスまたは技術者デバイスのうちの1つからアクションのセットを受け取ることを含むものである。
【0010】
他の特徴では、アクションのセットを取得することは、技術者デバイスによりクライアントデバイスへ送付されたものとして、アクションのセットを記録することを含むものである。他の特徴では、サービスチケットを技術者に割り当てることは、技術者によるチケットの要求に応じて実行されるものである。他の特徴では、命令は、技術者からの変更要求に応じて、キーワードのセットを変更することを含むものである。
【0011】
他の特徴では、キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも1つを含んでいる。他の特徴では、命令は、ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも1つからサービスチケットを生成することを含んでいる。他の特徴では、命令は、保存することの後、他の技術者と共有するために、RPを知識ベース(KB)アーティクルに選択的に変換することを含んでおり、ここで、KBアーティクルは、シリーズ化したRPを含んでいる。
【0012】
方法は、クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ることを含むものである。この方法は、サービスチケットを技術者に割り当てることを含むものである。この方法は、技術者デバイスとクライアントデバイスとの間の遠隔制御セッションを調整することを含むものである。技術者デバイスは、技術者の制御下にあるものである。この方法は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、技術者により実行されるアクションのセットを取得することを含むものである。アクションのセットのうちの各アクションは、クライアントデバイスとの1つまたは複数のユーザーインターフェース(UI)の相互作用を表現しているものである。この方法は、サービスチケットの特性に基づいて、キーワードのセットを識別することを含むものである。この方法は、識別したキーワードをアクションのセットと関連付けることを含むものである。この方法は、アクションのセット及び識別したキーワードを技術者へ提示することを含むものである。この方法は、技術者からの入力を受け取ることに応じて、アクションのセットを選択的に変更することを含むものである。この方法は、技術者承認に応じて、解決プロファイル(RP)を保存することを含むものである。RPは、変更したアクションのセット及び識別したキーワードに基づくものである。この方法は、第2クライアントデバイスのために提出された第2サービスチケットを受け取ることに応じて、第2クライアントデバイスにおいて、RPからのアクションのセットを選択的に再生することを含むものである。
【0013】
他の特徴では、アクションのセットのうちの各アクションは、基本的解決ステップ(BRS)データ構造に保存され、BRSデータ構造は、BRSデータ構造定義に準拠するものである。RPは、BRSデータ構造の実行順序をエンコードするものである。他の特徴では、アクションのセットのうちの第1アクションに対応する第1基本的解決ステップ(BRS)データ構造は、第1アクションが実行される前に取り込まれたクライアントデバイスのスクリーンショットを含むものである。第1BRSデータ構造は、コマンドを保存しており、コマンドにおいては、実行がクライアントデバイスを所望でないシステム状態から第2システム状態へ移行させるものである。他の特徴では、この方法は、第2クライアントデバイスが所望でないシステム状態にあることに応じて、第2クライアントデバイスでRPを再生することを含むものである。他の特徴では、RPは、アクションのセットと1対1で対応するファイルの集まりとして、保存されるものである。
【0014】
他の特徴では、アクションのセットを取得することは、遠隔制御セッションの完了時に、クライアントデバイスまたは技術者デバイスのうちの1つからアクションのセットを受け取ること、及び技術者デバイスによりクライアントデバイスへ送付されたものとして、アクションのセットを記録すること、のうちの少なくとも1つを含むものである。他の特徴では、サービスチケットを技術者に割り当てることは、技術者によるチケットの要求に応じて実行されるものである。この方法は、技術者からの変更要求に応じて、キーワードのセットを変更することを含むものである。他の特徴では、アクションのセットのうちの第1アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも1つを含むものである。キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも1つを含むものである。他の特徴では、この方法は、ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも1つからサービスチケットを生成することを含むものである。他の特徴では、この方法は、保存することの後、他の技術者と共有するために、RPを知識ベース(KB)アーティクルに選択的に変換することを含むものである。KBアーティクルは、シリーズ化したRPを含むものである。
【0015】
本開示の適用可能なさらなる領域は、発明を実施するための形態、特許請求の範囲、及び図面から明らかになるであろう。発明を実施するための形態及び特定の例は、例示のみを目的としており、開示の範囲を限定することを意図するものではない。
【0016】
本開示は、発明を実施するための形態及び添付の図面からより完全に理解されるだろう。
【図面の簡単な説明】
【0017】
【
図1】
図1は、例示的な分散コンピューティングシステムのブロック図である。
【
図2】
図2は、制御サーバの例示的な実施形態の機能ブロック図である。
【
図3】
図3は、解決ストーリー作成モジュールの例示的な実施形態の機能ブロック図である。
【
図4】
図4は、本開示の原理による例示的なデータ構造定義のグラフィカルな図表である。
【
図5】
図5は、自動化モジュールの例示的な実施形態の機能ブロック図である。
【
図6】
図6は、例示的な解決プロファイル(RP)記録のフローチャートである。
【
図7】
図7は、仮想のサービスチケットの例示的な自動解決のフローチャートである。
【
図8A】
図8Aは、解決ストーリーアプリケーションの例示的な解決ストーリー作成スクリーンである。
【
図8B】
図8Bは、解決ストーリーアプリケーションの例示的な解決ストーリー作成スクリーンである。
【
図9】
図9は、解決ストーリーアプリケーションの例示的な注釈付き解決ストーリー作成スクリーンである。
【発明を実施するための形態】
【0018】
図面において、参照番号は、類似及び/または同一の要素を識別するために再使用される場合がある。
【0019】
<イントロダクション>
本開示によれば、分散コンピューティングシステムは、遠隔制御セッション中に、アクションのセット及びクライアントデバイスの付随的なスクリーンショットを記録することができる。記録は、遠隔制御セッション中にクライアントデバイスに保存されることができる。遠隔制御セッションにより、技術者はサービスチケットを解決するために、クライアントデバイスにおいて、アクションのセットを遠隔で実行することができる。アクションのセットのうちの各アクションは、例えばマウスイベント及び/またはキーボードイベントなどのように、クライアントデバイスとの1つまたは複数のユーザーインターフェース(UI)の相互作用を表現している。サービスチケットは、クライアントデバイスの所望でないシステム状態に対応する場合がある。サービスチケットには、インシデント、要求、クライアントデバイスのシステム状態に特化しない要求(例えば、メールシステム配布リストの作成、ログイン資格証明のリセットなど)などを含むことができる。例えば、所望でないシステム状態は、クライアントデバイスのユーザーがクライアントデバイスで経験している課題である可能性がある――これはインシデントとも呼ばれる。別の例として、所望でないシステム状態は、クライアントデバイス上に、特定のアプリケーションが存在しないことである場合がある――これは要求とも呼ばれる。
【0020】
記録が完了する時、記録は圧縮され、そしてクライアントデバイスから制御サーバに送付される。様々な実施形態では、記録は、制御サーバ上で、または技術者によって操作される技術者デバイス上で実行されることができる。キーワードのセットは、サービスチケットの特性に基づいて識別されることができる。キーワードのセットは、記録と関連付けられることができる。
【0021】
記録とキーワードのセットは、技術者に提示される。技術者は、記録とキーワードのセットをレビュー及び変更することができる。技術者は、アクションのセットからいくつかのアクションを削除することができる。なぜなら、それらのアクションは関係性がない、または冗長な場合があるためである。技術者はまた、スクリーンショットに注釈(例えば、矢印、強調表示、テキスト、ラベルなど)を追加することができる。技術者は、アクションに説明(例えば、追加の指示――ウィンドウを下にスクロールするなど――、コメントなど)を追加することができる。レビューと編集が完了する時、変更されたアクションのセットとキーワードのセットが解決ストーリーとして保存されることができる。
【0022】
解決ストーリーは、遠隔制御セッション中に技術者によって実行されたアクションのセットを表現している。解決ストーリーは、他の技術者に提示されることにより、サービスチケットをどのように解決するかを他の技術者に説明することができる。様々な実施形態では、解決ストーリーは、技術者によって実行されたアクションのセットを説明するために、ユーザーに示されることができる。
【0023】
解決ストーリーはまた、第2ユーザーによって操作された第2クライアントデバイスのために提出された第2サービスチケットをすばやく解決するために使用されることができる。様々な実施形態では、サービスチケットは、例えばパフォーマンスメトリクスなどの監視データを受け取る異常検出プロセスによって検出された異常に応じて、自動的に提出されることができる。
【0024】
第2サービスチケットは、例えば、自然言語処理(NLP)及び/または機械学習を使用して分類される。一旦、第2サービスチケットが分類されると、第2サービスチケットを解決するための最適な手法に対応する最短経路が決定される。例えば、最短経路は、例えば解決までの時間、変更の数、再起動の必要の有無などの、1つまたは複数の基準に従って決定される。もしも、解決ストーリーからのアクションのセットが最短経路に寄与するならば、解決ストーリーからのアクションのセットは、第2クライアントデバイスにおいて実行されることにより、第2サービスチケットを解決することができる。
【0025】
<環境>
図1は、例示的な分散コンピューティングシステム100のブロック図である。分散コンピューティングシステム100は、制御サーバ102、クライアントデバイス104、及び技術者デバイス106を含んでいる。制御サーバ102、クライアントデバイス104、及び技術者デバイス106は、例えば、ローカルエリアネットワーク(LAN)、インターネットなどのワイドエリアネットワーク(WAN)、及び/または他のタイプのネットワークなどの、ネットワーク107を介して互いに通信することができる。制御サーバ102がsoftware-as-a-service(SaaS)モデルに従って提供されることができ、またはクラウドインフラを使用して提供されることができることを単に説明するために、制御サーバ102は、ネットワーク107内に示されている。制御サーバ102、クライアントデバイス104、及び技術者デバイス106は、無線及び/または有線接続を使用してネットワーク107に接続することができる。クライアントデバイス104及び技術者デバイス106は、制御サーバ102とは異なる地理的位置に配置されることができる。クライアントデバイス104は、技術者デバイス106とは異なる地理的位置に配置されることができる。
【0026】
クライアントデバイス104及び技術者デバイス106のそれぞれは、タブレット、ラップトップコンピュータ、パーソナルコンピュータ(PC)などであることができる。クライアントデバイス104は、ウェブブラウザ108及び遠隔支援エージェント110を含んでいる。例えば、遠隔支援エージェント110は、制御サーバ102を制御するオペレータによって提供されることができる。
【0027】
クライアントデバイス104のユーザーは、ウェブポータルにログインし、そしてウェブブラウザ108を使用してサービスチケットを開くことができる。サービスチケットは、インシデント――すなわち、異常または予期しない動作(例えば、既存のファイルにアクセスすることができないなど)――、またはより優れた機能または異なる機能のための要求(例えば、新しいファイルストアへアクセスすることができることなど)、に関連する場合がある。インシデントまたは要求は、クライアントデバイス104(おそらく特別な管理者特権を必要とするが)を単独で使用して解決可能であるか、別のリソース(例えば、メールサーバを構成するものなど)を単独で使用して解決可能であるか、またはクライアントデバイス104及び1つまたは複数の他のリソースを必要とする場合がある。本出願は、それら3つのシナリオすべてに適用可能であるが、説明の簡潔さのため、サービスチケットがクライアントデバイス104を単独で使用して解決され得るシナリオを以下に説明する。
【0028】
システム(クライアントデバイス104がその一部である)の現在の状態は、所望でないものとして説明されることができる――例えば、インシデントが異常な動作を明らかにした、または要求が幾つかの認識された欠陥を示しているなどである。したがって、サービスチケットは、クライアントデバイス104の所望のシステム状態とは異なる所望でないシステム状態に対応する。さらなる例として、すでにインストールされているアプリケーションが開かないという障害は、インシデントとして表現されることができる――その一方、ユーザーがクライアントデバイスにおいて特定のアプリケーションを起動することができないということで、インストールされる新しいアプリケーションのための要求がされる場合がある。
【0029】
ユーザーは、サービスチケットが提出される前に、例えば、タイトル、発生した症状の説明、連絡先情報(例えば、名前、ユーザー名、電子メールアドレス、電話番号など)などを、サービスチケットのある特定のフィールドに挿入する必要がある場合がある。サービスチケットの連絡先情報などのいくつかのフィールドは、例えばチケット作成日、チケットID、チケット番号などの追跡フィールドなどのように、自動挿入される場合がある。これらのタイプのフィールドは、自動挿入フィールドと呼ばれる場合がある。
【0030】
技術者デバイス106を操作する技術者は、例えば、技術者の連絡先情報(例えば、名前、電子メールアドレス、電話番号など)、チケットの優先順位、チケットのソースなどを、サービスチケットのある特定のフィールドに挿入する必要がある場合がある。一旦、ユーザーがサービスチケットを提出すると、新しいサービスチケットが受信されたことを技術者に知らせる通知が、技術者デバイス106に送信される場合がある。技術者は、チケット管理システムにログインすることにより、ウェブブラウザ118を使用してサービスチケットを閲覧することができる。技術者は、サービスチケットの割り当てを要求することができる。技術者に割り当てられているサービスチケットに応じて、技術者は、サービスチケットを診断及び解決するために、クライアントデバイス104に遠隔接続することができる。
【0031】
ウェブブラウザ118は、制御サーバ102を介してクライアント制御モジュール112に遠隔制御の初期化要求を送信することができる。遠隔制御の初期化要求は、ユーザーに対して、遠隔制御セッションへの同意を求めさせるものである。いくつかの実施形態では、ユーザーは、事前に同意を与えている場合がある――その場合には、ユーザーは遠隔セッションの開始のために居合わせる必要はない。一旦、ユーザーによって同意が与えられると、遠隔制御ソフトウェア120は、ネットワーク107を介してクライアント制御モジュール112との遠隔制御セッションを確立する。遠隔制御セッションにより、技術者は、クライアントデバイス104を遠隔制御することができる。様々な実施形態では、クライアント制御モジュール112は、Splashtop遠隔制御ソフトウェア、TeamViewer遠隔制御ソフトウェア、または他のタイプの遠隔制御ソフトウェアであることができる。
【0032】
遠隔制御セッションの確立に応じて、記録モジュール116は、遠隔制御セッションを記録する。遠隔制御セッション中に、技術者は、サービスチケットを解決するために、入力デバイスを使用してアクションのセットを実行することができる。例えば、キーボード、タッチパッド、マウス、タッチスクリーンなどの入力デバイスは、技術者デバイスに接続されることができる。アクションのセットのうちの各アクションは、クライアントデバイス104との1つまたは複数のユーザーインターフェース(UI)の相互作用を表現している。UIの相互作用は、マウスのマウスイベント及び/またはキーボードのキーに対応することができる。例えば、マウスイベントは、ボタンダウン、ボタンアップ、クリック(例えば、ボタンダウンのすぐ後にボタンアップが続く)などであることができる。キー押下げは、すぐ後にキーアップが続くキーダウンとして表現されることができる。
【0033】
上述のとおり、アクションのセットのうちの各アクションは、1つまたは複数のUIの相互作用を表現する。例えば、ダイアログボックスは、すべてチェックのついていない5つのチェックボックスを含むことができる。技術者は、チェックボックスでマウスイベント(例えば、クリック)を実行して、チェックボックスを確認済みとしてチェックマークをつけることができる。5つのチェックボックスのすべてをチェックすることは、5つのマウスイベントを必要とする場合がある――各チェックボックスに対して1つのマウスイベント。この場合、5つのマウスイベントは、一括して1つのアクションと呼ぶことができる。その他の場合、5つのマウスイベントは、5つの個別のアクションとして記録されることができる――1つのアクションに対応している各マウスイベント。
【0034】
遠隔制御セッションの記録は、アクションのセットと、及び各アクションが実行される前のクライアントデバイス104のスクリーンショットとを含むことができる。例えば、もしも技術者がウィンドウを開き、その後テキストボックスまでウィンドウを下にスクロールし、そしてテキストボックスにテキストを入力すると、2つのスクリーンショットが記録されることができる。1番目のスクリーンショットは開かれたウィンドウを含むことができ、そして2番目のスクリーンショットは、入力されたテキストを含むテキストボックスを含むことができる。クライアントデバイス104のスクリーンショットは、第1のアクションが実行される前に記録されることができる。例えば、もしも技術者がダイアログボックスを閉じたい場合は、技術者は、X上でマウスイベント(例えば、クリック)を実行する前に、X上でマウスポインタを操作することができる。スクリーンショットは、X上でマウスイベントを実行した結果ではなく、X上でのマウスポインタを含むことができる。様々な実施形態では、第1のアクションの実行の後にスクリーンショットが記録されることができる。
【0035】
遠隔制御セッションの終了に応じて、記録は完了する。技術者がクライアントデバイス104との接続を切断したときに、遠隔制御セッションは終了することができる。記録は、圧縮(例えば、rarまたはzip形式を使用して)されることができ、そして制御サーバ102に送信されることができる。様々な実施形態では、遠隔制御セッション中に様々な時間間隔(例えば、毎分、3分ごと、10分ごとなど)で、記録は、制御サーバ102に部分的に送信されることができる。記録モジュール116は、クライアントデバイス104に配置されているように示され、そして表現されているが、記録モジュール116及び記録は、制御サーバ102、技術者デバイス106、または別の場所に配置されることができる。
【0036】
監視モジュール114は、クライアントデバイス104のメトリクスを監視するものであり、このメトリクスは、パフォーマンスメトリクス、インストールされたアプリケーション、ユーザーリストなどを含むことができる。メトリクスは、例えば、プロセッサー使用率、メモリ(例えば、揮発性または不揮発性メモリ、キャッシュなど)の使用率、大容量記憶装置(例えば、フラッシュメモリ、磁気ハードディスクドライブ(HDD)など)の使用率、ネットワークの接続性(例えば、有線、無線など)などの、クライアントデバイス104のシステムリソースを含むことができる。監視モジュール114は、所定のスケジュールに基づいて、メトリクスを制御サーバ102に送信することができる。例えば、所定のスケジュールは、1日1回、1日2回、週1回などであることができる。様々な実施形態では、メトリクスにおいて検出された異常に応じて、メトリクスは制御サーバ102に直ちに送信されることができる。様々な実施形態では、メトリクスにおいて異常が検出されたことを知らせる通知が技術者に送信されることができる。監視モジュール114からの情報(例えば、オペレーティングシステム、インストールされたRAM、パッチレベル、CPU利用率など)は、クライアントデバイス104のために作成されたサービスチケットに追加されることができる。
【0037】
図2は、制御サーバ102の例示的な実施形態の機能ブロック図である。制御サーバ102は、ウェブポータル202、電子メールインターフェース204、チャットモジュール206、チケット管理モジュール208、チケットデータベース210、遠隔調整モジュール212、解決ストーリー作成モジュール214、メトリクスデータストア216、異常検出モジュール218、自動化モジュール220、手動作成モジュール222、及び解決ストーリーデータストア224を含んでいる。
【0038】
ユーザーは、ウェブポータル202にログインし、そしてウェブブラウザ108を使用してサービスチケットを開くことができる。チケット管理モジュール208は、提供されたフィールドに基づいてサービスチケットを生成し、またある特定のフィールドに自動挿入することもできる。
【0039】
様々な実施形態では、例えば電子メール、チャット、または電話を使用して、ユーザーは、ヘルプデスクまたは技術者に直接連絡をすることができる。電子メールインターフェース204は、ユーザーの電子メールから関連情報を識別し、そしてその関連情報に基づいてサービスチケットのフィールドに自動挿入することができる。
【0040】
チャットモジュール206は、ユーザーと技術者またはヘルプデスクスタッフとの間で交換されるチャット会話で提供される関連情報を識別することができる。チケット管理モジュール208は、関連情報に基づいてサービスチケットを生成する。ユーザーと技術者との間で交換されるチャット会話は、サービスチケットに添付されることができる。サービスチケットは、チャット会話が終了した後に生成されることができる。様々な実施形態では、サービスチケットは、チャット会話中に生成されることができる。様々な他の実施形態では、チケットは、ユーザーと技術者との間の電話中に交換される関連情報から生成されることができる。
【0041】
チケット管理モジュール208は、ウェブポータル202、電子メールインターフェース204、及びチャットモジュール206を含む様々なソースから受信したサービスチケットを生成及び管理する。技術者は、ウェブブラウザ118からチケット管理モジュール208にログインすることにより、サービスチケットのステータス(例えば、割り当て待ち、オープン、進行中、クローズなど)を含むサービスチケットを閲覧することができる。チケット管理モジュール208は、「割り当て待ち」とマークされたサービスチケットを対応可能な技術者に割り当てることができる。チケット管理モジュール208は、サービスチケットを要求した技術者にサービスチケットを割り当てるか、またはサービスチケットの特性について最も関連のある知識を有する技術者にサービスチケットを割り当てることができる。例えば、もしもサービスチケットがネットワークの接続性のインシデントを示しているならば、ネットワークについて最も知識のある技術者がサービスチケットを解決するために割り当てられることができる。一旦、チケットが技術者に割り当てられると、チケット管理モジュール208は、サービスチケットのステータスを「割り当て待ち」から「オープン」に更新することができる、またチケット管理モジュール208は、技術者がサービスチケットを割り当てられたことを技術者に知らせる通知を、技術者に送信することができる。
【0042】
通知に応じて、技術者は、チケット管理モジュール208から対応するサービスチケットを選択することができる。技術者は、サービスチケットの技術者フィールドの一部を挿入することができる。付加的に、チケット管理モジュール208により、技術者が「オープン」ステータスの下で技術者に割り当てられたすべてのオープンサービスチケットのリストを閲覧することが可能になる。
【0043】
技術者がサービスチケットを解決する準備ができた時、技術者はクライアントデバイス104に遠隔接続することができる。ウェブブラウザ118は、遠隔調整モジュール212を介してクライアント制御モジュール112に遠隔制御の初期化要求を送信することができる。一旦、クライアントデバイス104のユーザーによって同意が与えられると、遠隔制御ソフトウェア120は、クライアント制御モジュール112と直接遠隔制御セッションを行うことができる。チケット管理モジュール208は、遠隔制御セッションに応じて、サービスチケットのステータスを「オープン」から「進行中」に更新することができる。
【0044】
記録モジュール116は、遠隔制御セッションを記録するように構成されている。チケット管理モジュール208は、技術者による遠隔制御セッションの終了に応じて、サービスチケットのステータスを「進行中」から「クローズ」に更新することができる。遠隔制御セッションが終了される時、記録は圧縮され、そして解決ストーリー作成モジュール214に送信されることができる。記録は、解決ストーリーとして解決ストーリーデータストア224に保存される前に、技術者によって閲覧及び変更されることができる。解決ストーリーは、遠隔制御セッション中に技術者によって実行されたアクションのセットを表現している記録であることができる。解決ストーリーは、サービスチケットをどのように解決するかを他の技術者に説明するために他の技術者に提示されることができ、技術者によって実行されたアクションのセットを説明するためにユーザーに示されることができ、また第2クライアントデバイスのために提出された第2サービスチケットを受信することに応じて、第2クライアントデバイスにおいて、解決ストーリーからのアクションのセットを自動的に実行するために使用されることができる。
【0045】
手動作成モジュール222は、アクションのセットのうちの各アクションを手動で作成するものである。例えば、技術者は、JavaScript Object Notation(JSON)ドキュメントとして構築された、1つまたは複数のUIの相互作用を含むテキストドキュメントを作成することができる。手動で作成されたアクションはまた、スクリーンショット操作アプリケーション(例えば、ウィンドウズ(登録商標)切り抜きツールなど)を使用して、技術者によって手動で記録されたスクリーンショットを含むことができる。付加的にまたは代替的に、手動作成モジュール222は、知識ベース(KB)アーティクルをアクションのセットに変換することによって、アクションのセットのうちの各アクションを手動で作成することができる。手動で作成された解決ストーリーは、解決ストーリーデータストア224に保存される。
【0046】
メトリクスデータストア216は、監視モジュール114からクライアントデバイス104のメトリクスを受信する。異常検出モジュール218は、メトリクスデータストア216に保存されたメトリクスを処理し、そして例えば履歴動作エンベロープ範囲外の逸脱などの、メトリクスの異常を検出するものである。一旦、異常が検出されると、異常検出モジュール218は、メトリクスから関連情報を識別し、そして関連情報に基づいてサービスチケットを生成することができる。チケット管理モジュール208は、必須のフィールド及び自動挿入されたフィールドに基づいてサービスチケットを生成する。
【0047】
自動化モジュール220は、保存された解決ストーリーに基づいて、新しいサービスチケットを自動的に解決しようと試みるものである。もしも関連のある解決ストーリーが利用可能であるならば、遠隔調整モジュール212は、自動化モジュール220とクライアント制御モジュール112との間の接続を確立することができる。一旦、接続が確立されると、自動化モジュール220は、クライアント制御モジュール112と直接通信することにより、解決ストーリーの一部として保存されたUIの相互作用を再生することができる。自動化モジュール220は、完全に自動化されることができ、そのため、ある特定のサービスチケットは、技術者のいかなる介入なしに自動的に解決されることができる。様々な実施形態では、自動化モジュール220は、部分的に自動化されることができ、そのため、ある特定のサービスチケットが技術者の助けを借りて解決されることができる。例えば、技術者は、解決ストーリーのうちのどのアクションを実行するのかを選択することができ、そして自動化モジュール220は、サービスチケットを解決するために、選択されたアクションを実行することができる。
【0048】
<解決ストーリー作成>
図3は、解決ストーリー作成モジュール214の例示的な実施形態の機能ブロック図である。解決ストーリー作成モジュール214は、記録データストア302、キーワード識別モジュール304、レビューモジュール306、及び解決ストーリー承認モジュール308を含んでいる。解決ストーリー作成モジュール214は、記録モジュール116から受信した記録に基づいて解決ストーリーを生成することができる。記録は、記録データストア302に保存される。解決ストーリーは、遠隔制御セッション中に技術者によって実行されたアクションのセットを表現する記録を含むことができる。解決ストーリーは、解決プロファイル(RP)データ構造内に保存された、基本的解決ステップ(BRS)データ構造のセットとして保存されることができる。アクションのセットのうちの各アクションは、
図4に記載されているように、BRSとして保存され、そのBRSはBRSデータ構造定義に準拠するものである。RPは、各アクションごとに、BRSへのポインタを保存または含んでいるデータ構造である。
【0049】
キーワード識別モジュール304は、サービスチケットの特性に基づいて、キーワードのセットを識別するものである。キーワード識別モジュール304は、例えば、サービスチケットと関連づけられている、例えば、タイトル及び/または説明などのテキストからキーワードのセットを識別することができる。キーワード識別モジュール304は、例えば、自然言語処理(NLP)を使用して、キーワードのセットを識別することができる。もしもNLPが何のキーワードも識別できない場合は、キーワードのセットは、最初は空のセットである場合がある。サービスチケットの特性は、クライアントデバイス104のオペレーティングシステムタイプ、アプリケーション名、及び/またはハードウェアのカテゴリ(例えば、ネットワークハードウェア、プリンタハードウェア、入力デバイスハードウェアなど)を含むことができる。キーワード識別モジュール304は、キーワードのセットを記録に関連付け、これにより記録を迅速に分類する。
【0050】
レビューモジュール306によって、遠隔制御セッション中に技術者が実行したアクションのセットを、技術者が、レビュー及び編集することを可能になる。アクションのセットのうちの各アクションは、BRSに対応することができる。技術者は、BRSのセットを編集することができる。例えば、技術者は、関係性がない、または冗長なスクリーンショット及び/またはアクションを削除し、スクリーンショットに注釈(例えば、矢印、強調表示、テキストなど)を追加し、またはアクションに説明(例えば、追加の指示、コメントなど)を追加することができる。レビューモジュール306はまた、技術者が、記録に関連づけられているキーワードのセットを編集(例えば、追加または削除などによって)することを可能にする。一旦、レビューと編集が完了すると、変更されたBRSのセットとキーワードのセットは、RPとして保存されることができる――RPは解決ストーリーとも呼ばれる。
【0051】
解決ストーリー承認モジュール308は、解決ストーリーがベストプラクティスに従っていると決定するものである。例えば、解決ストーリーが、サービスチケットを最も少ない副作用(例えば、ユーザーのウィンドウズ(登録商標)プロファイルの削除や再作成など)で解決するための最も効率的な方法であると決定するために、IT管理者は、解決ストーリーをレビューすることができる。効率とは、アクションの最小量、使用されるリソースの最小量などによって定義されることができる。承認された解決ストーリーは、解決ストーリーデータストア224に保存される。
【0052】
<データ構造>
図4は、BRS402及びRP412を含む例示的なデータ構造定義の図表である。BRS402は、BRS402の説明及び指示を提供するステップデータ404を含んでいる。ステップデータ404は、テキスト説明、作成者、作成日、BRS識別(ID)、及び名前を含んでいる。テキスト説明は、自動的に生成されることができるBRS402の説明であり、それは技術者が変更することができる。作成者は、BRS402を作成した技術者、またはBRS402の生成に使用されるツールであることができる。作成日は、BRSが生成された日付である。BRS IDは、BRS402を独自に識別する識別子であり、また数字または英数字の値を含むことができる。BRS402の名前は、テキスト説明から導き出されることができる。
【0053】
ステップデータ404はまた、画像フィールド、オーバーレイ、重みの配列、BRS402に必要なリソース、コマンド、及び検証を含んでいる。画像フィールドは、関連のあるスクリーンショットが保存されるユニフォームリソースロケーター(URL)を指定することができる。重みの配列は、例えば、解決までの時間、変更の数、再起動の必要の有無など、所定の基準のセットの各々の基準ごとに数値的重みを含んでいる。BRS402に必要なリソースは、クライアントデバイスでBRS402を実行するために必要とされるハードウェアまたはソフトウェアコンポーネントを表現することができる。コマンドは、クライアントデバイスでアクションを実行する方法の概要を示すことができ、また、検証は、コマンドが首尾よく実行されたことを検証する方法の概要を示すことができる。
【0054】
BRS402はまた、パラメータデータ406、メディアコンテナ408、及びオーバーレイコンテナ410を含んでいる。パラメータデータ406は、ユーザーのタイプに基づいてBRS402を実行するために挿入された、予め定義されたパラメータのセットである。例えば、パラメータデータ406は、経路、ホスト名、及びユーザー名を含むことができる。メディアコンテナ408は、クライアントデバイスの1つまたは複数のスクリーンショットを含むことができる。様々な実施形態では、メディアコンテナ408は、クラウド記憶装置に配置されることができる。オーバーレイコンテナ410は、スクリーンショットの上に付けられる注釈(例えば、矢印、ハイライト、形状、テキストなど)を含んでいる。
【0055】
BRS402は、ファイルシステム内のディレクトリ(例えば、圧縮されたフォルダなど)であることができる。ステップデータ404及びパラメータデータ406は、JSONファイルまたはドキュメント、ハイパーテキストマークアップ言語(HTML)ファイルまたはドキュメント、または拡張可能マークアップ言語(XML)ファイルまたはドキュメント(そのディレクトリに保存されている)であることができる。
【0056】
RP412は、例えばファイルシステムフォルダなどのBRSコンテナ413に保存されたBRSのセットを含んでいる。BRSコンテナ413は、BRS414-1,414-2,・・・,及び414-Nのセット(集合的に、BRS414)を含んでおり、ここで、Nは、1以上の整数である。BRSのそれぞれは、BRS IDによって特徴付けられる。BRS IDは、BRSがBRSコンテナ413でリストに載せられている順序に対応することができる。例えば、BRS414-1は、BRS414-2のBRS IDより1つ低いBRS IDを有することができ、またBRS-(n-l)のIDは、BRS414-NのIDより1つ低いものであることができる。様々な実施形態では、BRS IDは、ステップデータ404の一部としてそれぞれのBRSに保存される。
【0057】
RP412はまた、テキスト説明416、作成者418、作成日420、及びRP ID422を含んでいる。テキスト説明416は、自動的に生成されることができるRP412の説明であり、またそれは技術者が修正することができる。作成者418は、RP412の作成者、またはRP412を生成するために使用されるツールであることができる。作成日420は、RPが生成された日付である。RP ID422は、RP412を識別する独自の識別子であり、また数字または英数字の値を含むことができる。
【0058】
RP412はまた、第1のステップID424及び解決ステップリスト426を含んでいる。第1のステップID424は、BRSコンテナ413内のどのBRS414から開始するかを識別する。例えば、第1のステップID424は、BRS414-2を識別することができる。様々な実施形態では、解決ステップリスト426は、BRS414の実行の順序を説明する配列である。
【0059】
解決ステップリスト426の各エントリは、次のステップに進むための条件、現在のステップのBRS ID、現在のステップが終了した際の遅延、条件が満たされた時の次のステップのID、及び条件が満たされない時の次のステップのIDを含んでいる。次のステップの条件は、どのステップが次に実行されるかを決定する。具体例として、RPは、10のステップに対応する10個のBRSを含んでおり、ここで、ステップ6は、クライアントデバイス上に特定のフォルダを作成する。簡単な説明としては、複数のBRS414の複数のIDは、単にそれぞれ、オフセット+1からオフセット+Nまでの整数であることができる、ここで、オフセットとは、RP412に以前に記録されたBRSの最後に使用されたIDである。
【0060】
解決ステップリスト426の最初の4つのエントリは、単にBRS414-1から414-4までをそれぞれ指定し、関連付けられた条件を持たず、そして単に次のステップとしてその次のIDを指定することができる。言い換えれば、最初のエントリは、現在のステップとしてBRS414-1を指定し、そして次のステップとしてBRS414-2を指定する。様々な実施形態では、条件のテストを回避するために、条件を空値に設定することができる。一方、この例では、解決ステップリスト426の第5のエントリは、現在のステップとしてBRS414-5を指定し、もしも条件が満たされた場合には次のステップとしてBRS414-7を指定し、そしてもしも条件が満たされない場合には次のステップとしてBRS414-6を指定する。条件は、クライアントデバイスのファイルシステム内の特定のフォルダの存在の有無のテストをする。BRS414-7は、特定のフォルダを作成するコマンドをエンコードし、これにより、特定のフォルダが既に存在する場合にはスキップされる。
【0061】
RP412は、ファイルシステム内の、例えば、圧縮ファイル(例えば、zip、rar、または7z圧縮方式を使用して)などの集まりであることができる。テキスト説明416、作成者418、作成日420、RP ID422、第1のステップID424、及び解決ステップリスト426は、集合的に、JSONファイルまたはドキュメント、HTMLファイルまたはドキュメント、またはXMLファイルまたはドキュメントであることができる。
【0062】
<自動修正>
図5は、自動化モジュール220の例示的な実施形態の機能ブロック図である。自動化モジュール220は、サービスチケットを解決するために、解決ストーリーからのアクションのセットを実行する。自動化モジュール220は、分類モジュール502、解決策決定モジュール504、及び自動化実行モジュール506を含んでいる。
【0063】
分類モジュール502は、サービスチケットをチケット管理モジュール208から分類する。分類モジュール502は、例えば、NLP及び/または機械学習を使用してサービスチケットを分類することができる。分類モジュール502は、サービスチケットで識別された症状のタイトル及び説明を処理することによってサービスチケットを分類することができる。ある特定の症状は、様々なインシデントまたは要求と関連付けられることができる。分類モジュール502は、インシデントを分類するために追加のテスト結果を取得することができる。
【0064】
例えば、もしもサービスチケットが、ファイルを遠隔ディスクに保存できないことを識別している場合は、1つまたは複数の条件により、この所望でない状態を結果として生じさせた可能性がある――例として、遠隔ディスクへの接続の欠如、遠隔ディスクに書き込むために許可が不十分であること、または遠隔ディスクのスペース(残りのクォータ割り当ての物理スペースのどちらかの一方)が利用できないことなどがある。分類モジュール502は、遠隔ディスクへの接続性テスト、ユーザー許可の問い合わせ、及び遠隔ディスク上での利用可能な空きスペースの問い合わせを含む、テストを要求することができる。追加情報からの結果に基づき、分類モジュール502は、サービスチケットを分類することができる。様々な実施形態では、もしも分類モジュール502がサービスチケットを分類することができないならば、技術者がサービスチケットを分類するように求められる場合がある。
【0065】
解決策決定モジュール504は、サービスチケットの分類に基づいて、解決ストーリーまたはRPが利用可能であるかどうかを決定する。もしも関連のある解決ストーリーが利用可能であるならば、解決策決定モジュール504は、解決ストーリーデータストア224から解決ストーリーを回収することができる。もしも利用可能な解決ストーリーがない場合には、チケット管理モジュール208は、サービスチケットのステータスを「解決ストーリー利用不可」に更新することができる。その後、チケットは技術者によって手動で処理されることができる。
【0066】
自動化実行モジュール506は、解決策実行モジュール508、解決策検証モジュール510、及び遠隔制御ソフトウェア120と類似していることができる遠隔制御ソフトウェア512を含んでいる。遠隔制御ソフトウェア512は、サービスチケットと関連付けられたクライアントデバイスと自動化実行モジュール506との間の接続を確立する。
【0067】
接続が確立された後、解決策実行モジュール508は、クライアントデバイス上に読み込まれた解決ストーリーからのアクションのセットを実行する。解決策実行モジュール508は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行するために、解決ストーリーからアクションのセット(それぞれが1つまたは複数のUIの相互作用を含む)を再生することができる。解決策検証モジュール510は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行することによって、解決ストーリーがサービスチケットを解決したことを検証することができる。アクションのセットがサービスチケットを解決したことを首尾よく検証することに応じて、チケット管理モジュール208は、サービスチケットのステータスを「クローズ」に更新することができ、そして遠隔制御ソフトウェア512は、接続を終了することができる。
【0068】
<制御>
図6は、例示的なRP記録及び使用のフローチャートである。制御は600から開始し、ここでクライアントデバイスのユーザーがサービスチケットを開くことになる。602において、制御は、サービスチケットを技術者に割り当てる。技術者は、サービスチケットをその技術者に割り当てるように要求することができる。604において、制御は、チケットに関連のあるRPが既に利用可能であるかどうかを決定する。もしも利用可能であれば、制御は608に移る。そうでない場合には、制御は606へ続行する。608において、制御は、技術者が利用可能なRPを承認するかどうかを決定する。もしも承認された場合には、制御は610へ続行する。そうでない場合には、制御は606に移る。610において、制御は、技術者がアクションを実行するためにRPを表示する。これは、技術者がステップスルーできる一連のスクリーンショットを技術者に表示することを含むことができる。その後、制御は終了する。
【0069】
606において、制御は、クライアントデバイスの遠隔制御セッションの記録を開始する。612において、制御は、サービスチケットの解決策を見つけられるかどうかを決定する。もしも解決策が見つけられた場合には、制御は614で続行される。そうでない場合には、制御は612に戻る。614において、制御は、サービスチケットを閉じ、遠隔制御セッションの記録を停止し、そして616において続行する。616において、制御は、キーワードのセットを識別するために、サービスチケット及び遠隔制御セッションの記録を構文解析する。618において、制御は、技術者にキーワードと記録のドラフトを示す。
【0070】
620において、制御は、技術者が記録のドラフトに対する変更があるかどうかを決定する。もしも変更がある場合には、制御は622に移る。そうでない場合には、制御は624へ続行する。622において、制御は、記録のドラフトに技術者の変更を加え、624へ続行する。624において、制御は、記録をRPとして保存する。制御は、624の後に終了することができる。様々な実施形態では、制御は626まで継続することができ、そこで制御は、RPをKBアーティクルに変換し、その後、終了する。
【0071】
KBアーティクルは、スクリーンショットのセットと共に、RPを人間に解読可能なドキュメント(例えば、ウェブドキュメント、ポータブルドキュメント形式(PDF)ドキュメントなど)にシリーズ化することができる。KBアーティクルは、RPでマウスイベントが発生した所の同等の位置に近接するテキストを識別することができる。KBアーティクルは、識別したテキストをスクリーンショットに関連付けることができる。結果としてのKBアーティクルは、テキスト、スクリーンショット、テキスト、スクリーンショット、テキストなどを含むことができる。
【0072】
図7は、サービスチケットの例示的な自動修正のフローチャートである。サービスチケット――関連する解決ストーリーが存在する可能性のある――が受け取られた後、制御は、700から開始する。700において、制御は、サービスチケットで識別されたインシデントまたは要求のための根本原因を識別する。例えば、ファイルを開くことができないことは、インストールされた適切なアプリケーションの欠如、接続性の問題、アクセス制限などにより引き起こされている可能性がある。別の例では、特定のプリンタの使用要求は、所望でないシステム状態、つまり印刷できないこと、として表現されることができる。この状態の根本原因は、プリンタドライバーの欠如、クライアントのオペレーティングシステムに対してプリンタが識別されていない、ネットワークの接続性の問題、ある特定のドメインからのクライアントのコンピュータの不存在、対応するプリントスプーラーへのアクセス権の欠如などである可能性がある。
【0073】
702において、制御は、サービスチケットによって関係づけられる所望でないシステム状態に対し、単一の根本原因があるかどうかを決定する。単一の根本原因がある場合には、制御は710に移る。そうでない場合は、制御は704へ続行する。704において、制御は、サービスチケットの根本原因を決定するために、追加のテストを実行する。 706において、制御は、テストに基づいてサービスチケットの根本原因を分類しようと試みる。708において、制御は、根本原因(または原因)が分類されることができるかどうかを決定する。分類されることができる場合には、制御は710へ続行する。そうでない場合は、制御は728に移る。728において、制御は、すべての追加のテストが仕尽くされたかどうかを決定する。仕尽くされた場合には、制御は、730においてエラー処理を実行し、その後、終了する。そうでない場合は、制御は704に戻る。
【0074】
710において、制御は、インシデントの分類された原因を扱うために、予め定義されたRPの存在の有無を決定する。存在する場合には、制御は714へ続行し、ここで制御は予め定義されたRPを選択する。そうでない場合は、制御は712へ続行する。712において、制御は、サービスチケットを解決するための最適なステップ(例えば、BRS)を決定する。簡単な例として、システムの現在の状態を状態Aと呼び、一方、システムの所望の状態を状態Dと呼ぶことができる。最適なステップは、以下を含むことができる:
・システムを状態Aから状態Bに移行する第1BRS;
・システムを状態Bから状態Dに移行する第2BRS;
・システムを状態Aから状態Cに移行する第3BRS;及び
・システムを状態Cから状態Dに移行する第4BRS。
【0075】
例えば、これらのBRSは、例えばコンボリューショナルニューラルネットワーク、ディープニューラルネットワーク、ディープビリーフネットワークなどのディープラーニング分析を使用して決定されることができる。
【0076】
716において、制御は、決定された最適なステップからBRSのセットを選択する。例えば、この選択は、コンボリューショナルニューラルネットワーク、ディープニューラルネットワーク、ディープビリーフネットワークなどのディープラーニング分析を使用して実行されることができる。様々な実施形態では、最短経路アルゴリズムは、サービスチケットを解決するために、予め定義されたBRSを選択することができる。上記の例を継続すると、2つの可能な組み合わせがある――第1及び第2BRSを使用するか、または第3及び第4BRSを使用するかである。最短経路アルゴリズムは、2つの可能な組み合わせのうちのどちらを使用するかを決定する。最短経路アルゴリズムは、例えば各BRSについて上述した重みの配列の幾つかまたはすべてなどのように、1つまたは複数の基準に基づいて、経路長を評価することができる。これらの重みは、例えば、解決までの時間、変更の数、再起動の必要の有無などを含むことができる。
【0077】
718において、制御は、選択された解決策(すなわち、予め定義されたRP、または選択されたBRSのセット)を実行する。720において、制御は、選択された解決策が有効であったかどうかを検証する。722において、制御は、選択された解決策がサービスチケットを解決したかどうかを決定する。解決した場合には、制御は、724においてサービスチケットを閉じ、その後、終了する。そうでない場合は、制御は、726においてエラー処理を実行し、その後、終了する。
【0078】
<アプリケーションユーザーインターフェース>
図8A及び
図8Bは共に、解決ストーリーアプリケーションの例示的な解決ストーリー作成スクリーンを形成し、このアプリケーションは、ウェブアプリケーションまたはネイティブアプリケーションであることができる。解決ストーリーアプリケーションは、技術者が解決ストーリーアプリケーション内をナビゲートすることを可能にするナビゲーション区画ウィンドウ802を含むことができる。例えば、
図8A及び
図8B(集合的に
図8とも呼ばれる)のナビゲーション区画ウィンドウ802は、ダッシュボードタブ、チケットタブ、アラートタブ、デバイスタブ、顧客タブ、解決タブ、知識ベースタブ、オンラインバックアップタブ、メールセキュリティタブ、ウェブルートタブ、支払い請求タブ、レポートタブ、及び管理者タブを含んでいる。チケットタブにより、サービスチケットのリストが提供され、そして技術者は特定のサービスチケットを閲覧することができる。解決タブは、
図8の例に示すように、既存の解決ストーリーを閲覧するために、または新しい解決ストーリーを作成するために使用されることができる。
【0079】
選択された解決ストーリー(作成されたばかりの可能性がある)に対して、注釈ツールバー804は、スクリーンショットに注釈を付けるために使用される。注釈ツールバー804は、スクリーンショットにオーバーレイを追加する、例えば、ポインタ、テキストカーソル、クロッピングツール、ハイライトマーカー、形状セレクタなどのようなツールを含むことができる。
【0080】
図9は、解決ストーリーアプリケーションの例示的な注釈付き解決ストーリー作成スクリーンである。技術者が、バッテリーセーバーの設定を強調するために、スクリーンショットに長方形形状のハイライトで注釈を付けたものである。長方形の形状は、注釈ツールバー804の形状セレクタツールから選択された。縦線とテキスト挿入カーソルによって示されているように、長方形の形状の右に、技術者が、テキストを入力する用意ができている。
【0081】
<結論>
前述の説明は、本質的に単なる例示であり、また、本開示、その適用、または使用を限定することを決して意図するものではない。本開示の広範な教示は、様々な形態で実施することができる。したがって、本開示には特定の例が含まれるが、本図面、本明細書、および以下の特許請求の範囲を検討することにより、他の変更が明らかになるため、本開示の真の範囲は、限定されるべきではない。方法内の1つまたは複数のステップは、本開示の原理を変更することなく、異なる順序で(または同時に)実行できることを理解すべきである。さらに、本実施例のそれぞれは、特定の特徴を有するものとして上に記載されているが、本開示の任意の実施例に関して記載されているこれらの特徴のいずれか1つまたは複数は、たとえその組み合わせが、明確に説明されていないとしても、任意の他の実施例の特徴中で、及び/またはそれと組み合わすことによって、実施されることができる。言い換えれば、記述された実施例は、相互に排他的ではなく、そして、1つまたは複数の実施例の相互の順序の変更は、本開示の範囲内である。
【0082】
要素間(例えば、モジュール間)の空間的、及び機能的関係は、「接続」、「係合」、「インターフェース」、及び「結合」を含む様々な用語を使用して説明される。「直接」であると明示的に説明されていない限り、第1の要素と第2の要素との間の関係が上述の開示に記載されている場合、その関係は、第1の要素と第2の要素との間に他の介在要素が存在しない直接的な関係、及び、1つまたは複数の介在要素が第1要素と第2要素との間に存在する(空間的または機能的に)間接的な関係も包含する。本明細書で使用される場合、A、B、及びCの少なくとも1つの句は、非排他的論理「OR」を使用して、論理(A OR B OR C)を意味すると解釈されるべきであり、また、その句は、「Aの少なくとも1つ、Bの少なくとも1つ、及びCの少なくとも1つ」を意味すると解釈されるべきではない。サブセットという用語は、必ずしも適切なサブセットを必要としない。言い換えれば、第1のセットの第1のサブセットは、第1のセットと同一の広がりを有する(等しい)と解釈されることができる。
【0083】
図面において、矢印で示されている矢の方向は、一般に、イラストに関係する情報(データや指示など)の流れを示すものである。例えば、要素Aと要素Bが様々な情報を交換する場合で、要素Aから要素Bに送信される情報がイラストに関連する場合、矢印は要素Aから要素Bを指すことができる。この一方向の矢印は、要素Bから要素Aに送信される他の情報がないことを意味するものではない。さらに、要素Aから要素Bに送信される情報について、要素Bは、情報の要求または受信確認を要素Aに送信することができる。
【0084】
本出願において、以下の定義を含むものである。「モジュール」という用語または「コントローラ」という用語は、「回路」という用語に置き換えることができる。「モジュール」という用語は、コードを実行するプロセッサーハードウェア(共有、専用、またはグループ)及びプロセッサーハードウェアによって実行されるコードを保存するメモリハードウェア(共有、専用、またはグループ)を指すか、その一部であるか、またはそれを含む場合がある。
【0085】
モジュールは、1つまたは複数のインターフェース回路を含むことができる。いくつかの例では、インターフェース回路は、ローカルエリアネットワーク(LAN)、インターネット、ワイドエリアネットワーク(WAN)、またはそれらの組み合わせに接続する有線または無線のインターフェースを含むことができる。本開示の任意の所与のモジュールの機能は、インターフェース回路を介して接続された複数のモジュール間で分散されることができる。例えば、複数のモジュールで負荷分散が可能になる。さらなる例では、サーバ(遠隔またはクラウドとしても知られる)モジュールは、クライアントモジュールに代わっていくつかの機能を達成することができる。
【0086】
上述で使用されたコードという用語は、ソフトウェア、ファームウェア、及び/またはマイクロコードを含むことができ、また、それは、プログラム、ルーチン、関数、クラス、データ構造、及び/またはオブジェクトを指すことができる。共有プロセッサーハードウェアは、複数のモジュールからの幾つかまたはすべてのコードを実行する単一のマイクロプロセッサーを包含するものである。グループプロセッサーハードウェアは、1つまたは複数のモジュールからの幾つかまたはすべてのコードを実行する、追加のマイクロプロセッサーと組み合わされたマイクロプロセッサーを包含するものである。複数のマイクロプロセッサーと言及する時は、個別のダイ上の複数のマイクロプロセッサー、単一のダイ上の複数のマイクロプロセッサー、単一のマイクロプロセッサーの複数のコア、単一のマイクロプロセッサーの複数のスレッド、または上述の組み合わせを含むものである。
【0087】
共有メモリハードウェアは、複数のモジュールからの幾つかまたはすべてのコードを記憶する単一のメモリデバイスを包含するものである。グループメモリハードウェアは、他のメモリデバイスと組み合わせて、1つまたは複数のモジュールからの幾つかまたはすべてのコードを記憶するメモリデバイスを包含するものである。
【0088】
メモリハードウェアという用語は、コンピュータ読取可能媒体という用語のサブセットである。本明細書で使用されるコンピュータ読取可能媒体という用語は、媒体(搬送波上など)を通って伝搬する一時的な電気信号または電磁信号を包含するものではない。従って、コンピュータ読取可能媒体という用語は、有形で非一時的であると見なされるものである。非一時的なコンピュータ読取可能媒体の非限定的な例は、不揮発性メモリデバイス(フラッシュメモリデバイス、消去可能なプログラム可能な読取専用メモリデバイス、またはマスク読取専用メモリデバイスなど)、揮発性メモリデバイス(静的ランダムアクセスメモリデバイスまたは動的ランダムアクセスメモリデバイスなど)、磁気記憶装置メディア(アナログまたはデジタル磁気テープまたはハードディスクドライブなど)、及び光記憶装置メディア(CD、DVD、またはブルーレイディスクなど)である。
【0089】
本出願で説明される装置および方法は、コンピュータプログラムに具体化された1つまたは複数の特定の機能を実行するように汎用コンピュータを構成することによって作成された専用コンピュータによって、部分的または完全に実施されることができる。上述の機能ブロック及びフローチャート要素は、ソフトウェア仕様として機能し、熟練した技術者またはプログラマーの定型業務によって、コンピュータプログラムに変換することができる。
【0090】
コンピュータプログラムは、少なくとも1つの非一時的なコンピュータ読取可能媒体に記憶されているプロセッサー実行可能命令を含んでいる。コンピュータプログラムはまた、記憶されたデータを含むか、またはそれに依存することができる。コンピュータプログラムは、専用コンピュータのハードウェアと情報を交換する基本的な入出力システム(BIOS)、専用コンピュータの特定のデバイスと情報を交換するデバイスドライバ、1つまたは複数のオペレーティングシステム、ユーザーアプリケーション、バックグラウンドサービス、バックグラウンドアプリケーションなどを含むことができる。
【0091】
コンピュータプログラムは、次のものを含むことができる:(i)HTML(ハイパーテキストマークアップ言語)、XML(拡張マークアップ言語)、またはJSON(JavaScriptオブジェクト表記)などの解析される説明文、(ii)アセンブリコード、(iii)コンパイラによってソースコードから生成されたオブジェクトコード、(iv)インタプリタによる実行用のソースコード、(v)ジャストインタイムコンパイラによるコンパイル及び実行用のソースコードなど。単なる例として、ソースコードは、次に挙げる言語の構文を使用して記述できる:C,C++,C#,Objective-C,Swift,Haskell,Go,SQL,R,Lisp,Java(登録商標),Fortran,Perl,Pascal,Curl,OCaml,Javascript(登録商標),HTML5(Hypertext Markup Language 5th revision),Ada,ASP(Active Server Pages),PHP(PHP:Hypertext Preprocessor),Scala,Eiffel,Smalltalk,Erlang,Ruby,Flash(登録商標),VisualBasic(登録商標),Lua,MATLAB(登録商標),SIMULINK,及びPython(登録商標)。