特許 6232427 メッセージ配信における添付ファイルの重複排除および添付ファイルの自動修復

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

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

(11)【特許番号】6232427

(24)【登録日】2017年10月27日

(45)【発行日】2017年11月15日

(54)【発明の名称】メッセージ配信における添付ファイルの重複排除および添付ファイルの自動修復

(51)【国際特許分類】

   G06F 12/00 20060101AFI20171106BHJP

   G06F 13/00 20060101ALI20171106BHJP

【ＦＩ】

   G06F12/00 510B

   G06F12/00 514Z

   G06F12/00 511A

   G06F13/00 625

【請求項の数】11

【全頁数】19

(21)【出願番号】特願2015-526613(P2015-526613)

(86)(22)【出願日】2013年8月6日

(65)【公表番号】特表2015-525936(P2015-525936A)

(43)【公表日】2015年9月7日

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

(87)【国際公開番号】WO2014028261

(87)【国際公開日】20140220

【審査請求日】2016年7月5日

(31)【優先権主張番号】13/572,900

(32)【優先日】2012年8月13日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(74)【代理人】

【識別番号】100108213

【弁理士】

【氏名又は名称】阿部 豊隆

(72)【発明者】

【氏名】ルーンプ，クリストフ

(72)【発明者】

【氏名】ダリワル，アロック

(72)【発明者】

【氏名】ディミトロブ，イヴァイロ

(72)【発明者】

【氏名】ホー，チェン

(72)【発明者】

【氏名】リウ，リンカーン

(72)【発明者】

【氏名】パイ，ブランドン

(72)【発明者】

【氏名】パスマーシー，クマー

(72)【発明者】

【氏名】ピティゴイ−アロン，グルイア

(72)【発明者】

【氏名】ロドリゲス，ジョン

【審査官】 後藤 彰

(56)【参考文献】

【文献】 特開２０１２−０９３８２７（ＪＰ，Ａ）

【文献】 特開２００６−２６８３２９（ＪＰ，Ａ）

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

【文献】 特開２００３−２２３４０４（ＪＰ，Ａ）

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

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

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

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

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

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １３／００

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

【請求項1】

ファイルシステムにおけるデータを重複削除するための方法であって、前記ファイルシステムが１つまたは複数のファイルを含み、各々の前記ファイルがデータの組を含み、前記データの組が２人以上のユーザによって共有することができる、方法において、
ファイルシステム内に格納されるファイルを受け取ること、
前記ファイル内のデータの組が前に前記ファイルシステムに格納されていたかどうかをチェックすること、
前記データの組が前記ファイルシステムに格納されていた場合、前記格納されたデータの組の状態をチェックすること、
前記格納されたデータの組の状態が前記ファィルのコピーを共有するのに適当である場合、前記データの組を共有するコマンドのあったときに前記ファイルへの参照を提供し、前記格納されたデータの組に関連した参照カウントを増加すること、
前記参照カウントをチェックすること、および、
前記参照カウントがゼロである場合、前記格納されたデータの組の状態を、暫定と、削除中と、孤立と、回復済みからなる群のうちの１つに遷移することを含み、
前記遷移することが、前記参照カウントがゼロである場合、前記格納されたデータの組の状態が全部破損または一部破損であるとき暫定に遷移することを含む、方法。

【請求項2】

前記ファイルシステムが、Ｅメールシステムであり、前記ファイルが、Ｅメールを含み、前記データの組が、前記Ｅメールへの添付ファイルを含み、
前記ファイルシステム内に格納されるファイルを受け取ることが、さらに、
Ｅメールを受け取ることであって、前記Ｅメールが添付ファイルをさらに含むことを含む、請求項１に記載の方法。

【請求項3】

前記ファイルシステム内に格納されるファイルを受け取ることが、
前記Ｅメールに関するメタデータを格納することをさらに含み、前記メタデータが、前記Ｅメールに関するメタデータと、前記Ｅメールへの添付ファイルに関するメタデータと、前記Ｅメールに関する状態メタデータと、前記添付ファイルに関する状態メタデータと、前記添付ファイルをどのように共有するかに関するメタデータと、前記添付ファイルの重複に関するメタデータとを含む群のうちの１つを含む、請求項２に記載の方法。

【請求項4】

前記格納されたデータの組の状態を前記チェックすることが、
前記添付ファイルに関連した状態を割り当てることをさらに含む、請求項３に記載の方法。

【請求項5】

前記添付ファイルに関連した前記状態が、良好と、一部破損と、全部破損と、暫定と、削除中と、孤立と、回復済みとを含む群のうちの１つを含む、請求項４に記載の方法。

【請求項6】

前記格納されたデータの組の状態が前記ファイルのコピーを共有するのに適当である場合、前記データの組を共有するコマンドのあったときに前記ファイルへの参照を提供することが、
前記格納されたデータの組のための参照カウントを増加させること、および、
前記格納されたデータの組へのポインタ参照を目標実体に送ることをさらに含む、請求項１に記載の方法。

【請求項7】

データの組が破損しているかどうかを検知すること、
破損していた場合、前記データの組に関連した前記状態を良好から破損に遷移させること、
前記破損したデータの組を修復すること、および、
前記データの組に関連した前記状態を破損から良好に遷移させることをさらに含む、請求項１に記載の方法。

【請求項8】

Ｅメールシステムにおけるデータを重複排除するためのシステムであって、前記Ｅメールシステムが、
Ｅメールクライアントの組と通信するＥメールサーバと、
Ｅメールおよび関連する添付ファイルを格納するためのデータベースであって、群のうちの少なくとも１つを格納し、前記群が、Ｅメールメッセージ、関連する添付ファイル、前記Ｅメールメッセージに関するメタデータおよび前記関連する添付ファイルに関するメタデータを含むデータベースと、
前記Ｅメールクライアントの組の間で添付ファイルの共有を管理するためのモジュールとを含み、
前記Ｅメールクライアントの組の間で前記添付ファイルの共有を管理する前記モジュールが、添付ファイルの状態を検知することができ、前記添付ファイルの状態に応じて前記添付ファイルへの参照ポインタを共有することができ、
さらに、前記Ｅメールクライアントの組の間で前記添付ファイルの共有を管理する前記モジュールが、前記添付ファイルに関連した参照カウントをチェックすることができ、前記添付ファイルが共有された場合前記参照カウントを増加することができ、前記参照カウントがゼロである場合前記添付ファイルの前記状態を、暫定と、削除中と、孤立と、回復済みからなる群のうちの１つに遷移することができ、前記参照カウントがゼロである場合前記格納されたデータの組の状態が全部破損または一部破損であるとき暫定に遷移することができる、システム。

【請求項9】

前記添付ファイルの共有を管理するための前記モジュールが、添付ファイルが破損しているかどうかを検知するためのモジュールをさらに含む、請求項８に記載のシステム。

【請求項10】

前記添付ファイルの共有を管理するための前記モジュールが、添付ファイルの状態を維持するためのモジュールをさらに含む、請求項９に記載のシステム。

【請求項11】

ファイルシステムにおけるデータを重複削除することをコンピュータに実行させるためのプログラムであって、前記ファイルシステムが１つまたは複数のファイルを含み、各々の前記ファイルがデータの組を含み、前記データの組が２人以上のユーザによって共有することができ、
ファイルシステム内に格納されるファイルを受け取ること、
前記ファイル内のデータの組が前に前記ファイルシステムに格納されていたかどうかをチェックすること、
前記データの組が前記ファイルシステムに格納されていた場合、前記格納されたデータ
の組の状態をチェックすること、
前記格納されたデータの組の状態が前記ファィルのコピーを共有するのに適当である場合、前記データの組を共有するコマンドのあったときに前記ファイルへの参照を提供し、前記格納されたデータの組に関連した参照カウントを増加すること、
前記参照カウントをチェックすること、および、
前記参照カウントがゼロである場合、前記格納されたデータの組の状態を、暫定と、削除中と、孤立と、回復済みからなる群のうちの１つに遷移すること
を実行させるためのプログラムであって、
前記遷移することが、前記参照カウントがゼロである場合、前記格納されたデータの組の状態が全部破損または一部破損であるとき暫定に遷移することを含む、プログラム。

【発明の詳細な説明】

【背景技術】

【0001】

[0001] データベースおよびメモリ管理の領域では、所与のコンピュータ内、いくつかのコンピュータ内、またはコンピューティングおよびネットワーク化された環境にわたって、重複ファイル（「BLOB」と呼ばれる）の数を削減することが望ましいことがある。このようなプロセスを自動化するために、コンピュータまたは環境は、これらのＢＬＯＢを識別し、その後適当な処置をする必要がある。

【0002】

[0002] 重複ファイルを避けるための努力は、付随するディスク空き容量の節約、Ｉ／Ｏおよびネットワーク帯域幅の節約で報われる。したがって、重複ファイルを正確におよび効率的に処理し管理することが望ましいことがある。

【発明の概要】

【課題を解決するための手段】

【0003】

[0003] 以下に、本明細書に説明するいくつかの態様の基本的な理解を得るようにするために本発明の簡略化された概要を提示する。この概要は、特許請求される主題の広範な概説ではない。この概要は、特許請求される主題の主要なまたは重要な要素を識別することも、本発明の範囲を画定することも意図していない。その唯一の目的は、特許請求される主題のいくつかの概念を後に提示されるより詳細な説明の前置きとして簡略化された形で提示することにある。

【0004】

[0004] ファイルシステム内のファイルおよび／またはＢＬＯＢを重複排除するシステムおよび技法が提示される。一実施形態において、Ｅメールシステムが開示され、Ｅメールシステムは、関連する添付ファイルの組を含むＥメールメッセージを受け取る。システムは、関連する添付ファイルが前にＥメールシステムに格納されていたかどうかと、格納された添付ファイルの状態と、添付ファイルの状態が添付ファイルのコピーを共有するのに適当である場合、添付ファイルを共有する要求のあったときに添付ファイルへの参照を提供することとを決定する。別の一実施形態では、システムは、格納された添付ファイルが破損しているかどうかを検知し、そうであるならば、場合によっては、添付ファイルへの参照を共有する前に、添付ファイルを修復することを試みることができる。

【0005】

[0005] 一実施形態において、ファイルシステムにおけるデータを重複排除するための方法が開示され、その場合、ファイルシステムは、１つまたは複数のファイルを含み、各ファイルは、データの組を含み、データの組は、２人以上のユーザによって共有することができる。方法は以下のステップを含むことができる。すなわち、ファイルシステム内に格納されるファイルを受け取ること、前記ファイル内のデータの組が前に前記ファイルシステムに格納されていたかどうかをチェックすること、前記データの組が前記ファイルシステムに格納されていた場合、格納されたデータの組の状態をチェックすること、および、格納されたデータの組の前記状態が前記ファイルのコピーを共有するのに適当である場合、前記データの組を共有するコマンドのあったときに前記ファイルへの参照を提供することである。

【0006】

[0006] 別の一実施形態において、Ｅメールシステムにおけるデータを重複排除するためのシステムが開示され、その場合、システムは、Ｅメールクライアントの組と通信するＥメールサーバと、Ｅメールおよび関連する添付ファイルを格納するためのデータベースであって、群のうちの少なくとも１つを格納し、前記群が、Ｅメールメッセージ、関連する添付ファイル、Ｅメールメッセージに関するメタデータおよび前記関連する添付ファイルに関するメタデータを含むデータベースと、前記Ｅメールクライアントの組の間の添付ファイルの共有を管理するためのモジュールとを含み、さらに、前記Ｅメールクライアントの組の間の添付ファイルの共有を管理する前記モジュールが、添付ファイルの状態を検知し、前記添付ファイルの状態に応じて前記添付ファイルへの参照ポインタを共有することができる。

【0007】

[0007] 本システムの他の特徴および態様は、本出願内に提示される図面に関連して読むとき以下に発明を実施するため形態において提示される。

【0008】

[0008] 例示的な実施形態が図面の参照される図に示される。本明細書に開示する実施形態および図は制限的ではなく例示的とあるとみなすことが意図されている。

【図面の簡単な説明】

【0009】

【図1】[0009]本出願の原理により、本出願の様々な実施形態が動作し持続し得る１つの例示的なコンピューティングおよび／またはネットワーク化された環境を示す図である。

【図2】[00010]本出願の原理により製作されたときのＢＬＯＢ管理システムの状態表／流れ図の一実施形態を示す図である。

【図3】[00011]本出願の原理により製作されたときのＥメール配信システムおよび関連するＢＬＯＢ管理システムの高レベル流れ図の一実施形態を示す図である。

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

【0010】

[00012] 本明細書に利用するように、「構成要素」、「システム」、「インターフェース」などの用語は、ハードウェア、ソフトウェア（例えば、実行時）、および／またはファームウェアのいずれかであるコンピュータ関係の実体を表すことを意図している。例えば、構成要素は、プロセッサ上で稼働するプロセス、プロセッサ、オブジェクト、実行ファイル、プログラム、および／またはコンピュータであり得る。例示として、サーバ上で稼働するアプリケーションおよびサーバの両方は、構成要素であり得る。１つまたは複数の構成要素は、プロセス内に常駐することができ、１つの構成要素は、１つのコンピュータ上に局在させ、および／または２つ以上のコンピュータ間に分散させることができる。

【0011】

[00013] 特許請求される主題は、図面を参照して説明し、同じ参照番号を全体にわたって同じ要素を表すために使用する。以下の説明では、説明のために、数多くの具体的な詳細を本発明の完全な理解が得られるようにするために記載する。しかし、特許請求される主題がこれらの具体的な詳細なしで実施できることは明らかであり得る。他の事例では、本発明の説明を容易にするためによく知られている構造およびデバイスをブロック図に示す。

【0012】

序論
[00014] ファイルシステム、データベース、Ｅメールシステムなどのスペース、処理時間および全費用の節約のために、システム全体にわたってファイル（BLOB）の重複排除を効果的に管理することができるシステムを実施することが望ましいことがある。このようなシステムは、とりわけデータセキュリティ、データ回復、およびデータの完全性などの考えに関係することもある。

【0013】

[00015] 図１は、本出願の実施形態が動作し常駐することができるコンピューティング／ネットワークキング環境（１００）の一例である。図１はＥメールシステムの形で示されるが、本出願の原理は、データベース管理またはファイルシステム管理の用途においても同程度の能力があり得る。

【0014】

[00016] 環境１００において、複数のＥメールクライアント１０２ａ、１０２ｂ、および１０２ｃがあり得る。この例では、クライアント１０２ａは、添付ファイルを付けてＥメール１０４を書き、別のクライアント１０２ｂに向かうことになっている、ネットワーク化されたシステム１０６にそれを送る。クライアント１０２ｂは、今度は、添付ファイルの付いたＥメールを第３のクライアント１０２ｃに転送することを決定することができる。

【0015】

[00017] ネットワーク化されたシステム１０６内では、場合によってはいくつかの他のサーバ、ルータおよび当技術分野で知られている他のネットワーク構成要素と共に、Ｅメールサーバ１０８が存在し得る。例えば、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（登録商標）Ｅメールシステムの設計において、システムはデータのコピーが独立したハードドライブ、コントローラ、およびマシン上に常駐することを確実にする。この種のシステムは、「単純ディスク束」を表す「ＪＢＯＤ」というニックネームが付いている。ＪＢＯＤシステムでは、ハードライブコントローラが邪魔にならないようにすることを試みる、すなわち、ソフトウェアはコントローラが以前に処理した障害に関してより関心がある。これらの障害は、ハードドライブ自体のファームウェアのバグから、以前にはコントローラによって自動的に修理された「回復不能読込みエラー」などの問題までの範囲にわたることがある。さらに、ソフトウェアは、次に、「ビット腐敗」（すなわち、何らかの理由で読み込み不能または破損になったデータ）がないかデータをチェックするために定期的にドライブをスクラブすることがある。この場合、分散型「ＲＡＩＤ」コントローラを完全にソフトウェアで構築することが可能であり、それは業界標準のファームウェアのものに取って代わるものである。

【0016】

[00018] このようなＪＢＯＤシステムのソフトウェアは、ハードドライブを監視することができ、修復措置をスケジュールし、障害を検知し、修復を診断する。このソフトウェアは、ある一定の種類の障害がないか絶えず監視する、いくつかの「監視機構」を含むこともできる。監視機構は、探している障害を検知した場合、警報を発し、それにより自動的に修復プロセスを作動することができる。この修復プロセスは、マシンの再起動またはプロセスの再始動から、データ破損の修理または進展がなされ得ない場合の人員の関与にまでの範囲にわたることがある。

【0017】

[00019] 全システムのうちの一部（１１０）として、メタデータ１１２および冗長メタデータ１１４を使用することができ、したがって、ソフトウェアは、システムがアクセスできるＥメールメッセージ（例えば、１１６における）の良好なコピーが正確にいくつあるのか（例えば、１１８ａおよび１１８ｂ）を知ることもできる。コピーが少なすぎることが分かった場合、ソフトウェアは潜在的に危険な状況を避けるため修復処置を優先順位付けすることができる。修復に時間がかかり過ぎる状況では、データをそっくり別の場所に移動させることが可能である。

【0018】

[00020] システムは、オリジナルのＥメールメッセージを配信されたときと正確に同じままで格納することにより、複製されたＥメールメッセージを効果的に管理し格納することができる。変化するＥメールメッセージに関するデータ（既読／未読、フォルダー内の場所など）は、例えば、メタデータストア１１２などに、別個に格納される。

【0019】

[00021] システムは、マシンの組を含むことができ、マシンの各々は、到着し到着日付別に整理されたＥメールメッセージとジャーナルレコーディングメッセージとを有することができる。マシンは時々互いに対話することができ、それらのジャーナルを比較し、全マシンに対してコピーされていないとマシンが認識する任意のメッセージをコピーすることができる。これは、様々な理由で、ほとんどがマシン、ネットワーク、またはハードドライブの障害により、起きることがある。場合によっては、ジャーナルは極端に同期がずれていることがあり、その場合、システムは完全な比較／コピーを行う。

【0020】

[00022] ハードドライブは、より大型化し、より安価になったが、ハードドライブがデータを読み出すことができる速度はあまり変わっていない。すなわち、ハードドライブは、より大きなハードドライブにより多くのデータを詰め込むことができるが、結局のところ要求率を処理することができない。この領域で有望な１つの技術は、フラッシュストレージ（SSDまたは半導体ドライブとも呼ばれる）である。ＳＳＤは、ＳＤカードやＵＳＢスティックで見られる技術と類似の技術を使用するが、より速い内部チップセットとずっと長い寿命を有する。通常のハードドライブが、毎秒１００回を少し超える読み取り／書き込み動作を実施することができるのに対して、最速ＳＳＤの中には、毎秒１０万回を超える動作を行うことができるものもある。しかし、これらのデバイスはストレージの１ギガバイト当たりに支払う金額をみると、ハードドライブより１０倍から１００倍高価なことがあるので、これは高価なものとなる。

【0021】

[00023] Ｅメールメッセージを格納する際、システムは、フォルダ内のメッセージのリスト、メッセージの既読／未読状態、会話のスレッド、携帯電話の同期など、これらのメッセージに関する軌跡情報（メタデータ１１２）の記録も付けることがある。このメタデータは、全記憶スペースの非常に小さな部分を占める傾向があるが、その絶えず変化する性質により、ハードドライブ上の負荷の大半を消費することがある。

【0022】

[00024] この小さなおよび急速に変化するデータの組にＳＳＤを使用することにより、ならびにメッセージの格納に利用可能な最大のハードドライブを使用することにより、システムは、システムの性能に何ら犠牲を払うことなく、より大きなおよびより安価なハードドライブの傾向を利用することができ得る。

【0023】

[00025] 一実施形態において、システムは、ファイルおよび／またはメッセージを配信すると、ファイルおよび／またはメッセージが所与の閾値サイズ（例えば、Y）より大きいかどうか、またはファイルおよび／またはメッセージが、所与の閾値サイズ（例えば、Y）より大きい、添付ファイル（例えば、X）を有するかどうかを検知することができる。そうであるならば、システムは、正確なファイル、メッセージまたは添付ファイルＸがすでに配信されたのか、システム上のユーザによって共有されたのか（または格納されたのか）をチェックすることができる。ファイル、メッセージおよび／または添付ファイルが配信され、および／またはシステム上のユーザと共有されたのかどうかを確認するために、システムは、ファイル、メッセージおよび／または添付ファイルに対してハッシュ関数を実施し、前のハッシュ結果と一致するか比較することができる。さらに、システムは、状態メタデータ、すなわち、どのようにおよび／または誰と共有および／または重複が起きたかもしれないことに関するメタデータを含む、ファイル、Ｅメールメッセージおよび／または添付ファイルに関するメタデータを格納および／または保持することができる。

【0024】

[00026] ファイル、メッセージおよび／または添付ファイルが配信され、共有され、「ＢＬＯＢ」が良好な状態にあり、わずかに別の閾値参照数（例えば、Z）しかなく、および／またはすでにＸへのリンクしかない場合、ファイルシステムで再度Ｘをセーブするのではなく、新たなメッセージ配信のためにそのＢＬＯＢへの参照カウントおよびそのＢＬＯＢへの「ポイント」を増加させる。このプロセスの間、システムは、ディスク上の「ＢＬＯＢ」が破損しているかどうかも検知し、そうであるならば、修復するかまたは良好なＸに置き換えるかのいずれかをすることもできる。例えば、図１の文脈において、クライアント１０２ｂがＥメール１０４を同じ添付ファイルを付けて別の対象クライアントおよび／または実体に転送したとき、システムは別の添付ファイルの重複を作成せずに添付ファイルへのポインタ参照を転送することができる。

【0025】

[00027] データベース、Ｅメールシステムおよび／または他のファイルシステムなど、他のシステムは、図１を参照して説明するアーキテクチャとは異なるアーキテクチャを有することができるが、本出願の技法はそのようなほかのアーキテクチャにも利益になることができることを理解されよう。

【0026】

重複排除の実施形態
[00028] Ｅメールシステムの文脈において（単に例示のため）、システムの一実施形態は、メール配信すると重複する添付ファイルを識別するように設計することができ、ファイル保存するとそれらを重複排除することができ、それによって場合によっては３４％以上のディスクの節約およびＩ／Ｏおよびネットワークの帯域幅の節約を達成することができる。添付ファイルを一意的に識別することに加えて、システムは、「ＢＬＯＢ」が消失または破損した場合、「ＢＬＯＢ」のライフサイクル、他のソースマシンまたはディスクドライブから「ＢＬＯＢ」の再複製をどのように実施するかを理解することも組み込むことができ、ファイルシステムのストレージおよびＩ／Ｏの効率を確実にするためのホットスポット「ＢＬＯＢ」管理を実施することができる。

【0027】

[00029] 多くのＥメールシステムでは、コンテンツの大部分が、多くのＥメールアカウントにわたって格納される大きな添付ファイルの小さな組を含むことが留意される。この観察から、本出願の他の実施形態は、これらの添付ファイルがいったん（または限定された数の回数）格納され、複数のアカウント内でまたは複数のアカウントにわたって共有されることを可能にすることによって利用することを望む。一実施形態において、システムは、メッセージファイルから添付ファイルを抽出することおよび別個に格納された添付ファイルを抽出することができ、したがって、添付ファイルは、発生したアカウントとは独立して参照し、追跡することができる。

【0028】

[00030] 本出願の他の諸実施形態は、以下に影響するモジュールを含むことができる。
（１）重複を探し出す工程：新たに配信されたコンテンツが重複排除の候補として識別され、既存の重複が位置を突き止められ利用されることを可能にするインデックス機構に影響するモジュール。
（２）重複を維持する工程：ハードドライブ障害およびデータ破損に直面して、および他の諸実施形態において、単一の重複排除されたＢＬＯＢの消失は多くのアカウントに影響し得るので特に注意深く、重複排除されたデータを修復し維持するモジュール。
（３）ガーベジコレクション：もはや参照されない添付ファイルを安全に除去するモジュール。

【0029】

[00031] いくつかの実施形態では、単一のＳＱＬデータベースの範囲と一致するように重複排除の範囲を選択することが可能である。このような場合、同じＳＱＬデータベース内に格納される、アカウントによって参照される重複ＢＬＯＢが発見されることがある。このような実施形態では、このような範囲により、システムがスペースの節約を達成することが可能になり、同時に重複の発見およびガーベジコレクションを単純化することが可能になる。いくつかの実施形態では、単一の添付ファイルの消失によって生じ得る損傷の量を制限するために同じ重複の複数のコピーが異なるディスクグルーピングに格納できることが可能になり得る。

【0030】

Ｅメール部分／添付ファイルの識別および管理
[00032] いくつかの実施形態では、様々なＥメール部分を識別するためのモジュールが、場合によっては重複排除を受けるので、それらの部分（例えば、添付ファイルなど）を検知および／または識別することが望ましいことがある。識別モジュールの別の一態様では、このモジュールは、同じまたは別の個人のためにすでに破棄され得た、およびプライバシーまたはデータ破損の懸念なしで同じ破棄された添付ファイルへの複数のアカウントポイントを有する添付ファイルを判別および／またはうまく識別することもできる。例えば、添付ファイル間に一意性をなすために暗号学的ハッシュを使用することができる。

【0031】

[00033] さらに、重複排除された添付ファイルがディスク上にすでに存在する場合、添付ファイルをディスクに書き込むことはもはや望ましくないことがあるが、システムは、単純に参照カウントを増加させ、それを再書き込みしないことによって、ディスクスペース、ＩＯ、およびネットワーク帯域幅を節約することができる。モジュールがＢＬＯＢのライフサイクルに注意を払い、追跡することが望ましいことがある。より詳しくは、モジュールは、いつそれを削除するか、それへの参照を減少／増加させるか、またはそれを置換するかなど、破棄された添付ファイルが取り得る様々な状態を通じてＢＬＯＢを追跡することができる。ＢＬＯＢが消失しおよび／または破損した場合、他のソースマシン／ディスクからの自動再複製が望ましいことがある。さらに、自動的に、消失したメタデータを回復しストアに一貫性を取り戻すこと、参照カウントを増加させるために添付ファイルを優先順位付けすること（本明細書に説明するように）、および参照に需要があるときホットスポットを減少させる波及機構を有することなど、もっと多くの技法が望ましいことがある。

【0032】

[00034] ＢＬＯＢを含むことがある添付ファイルおよび他のオブジェクトの識別に向けて、ある実施形態は、ＭＩＭＥ部分の境界でこの識別を行うことができる。この実施形態では、システムによって使用／認識される複数のメッセージの表現があり得る。
（１）「リテラルＭＩＭＥ」：これはＳＭＴＰを介して受け取ったときのＭＩＭＥメッセージそのものであり得る。添付ファイルは、ｂａｓｅ６４または２進コード化ストリームとして含むことができる。
（２）「圧縮ＭＩＭＥ」または「Ｖ１」：これはＸｐｒｅｓｓを介して圧縮されたリテラルＭＩＭＥフォーマットであり得る。
（３）「ＡｔｔａｃｈＳｔｏｒｅ」メッセージフォーマット：これは添付ファイルを抽出し、それらをファイルの終わりに別個に置いたコンテナであり得る。

【0033】

[00035] 一実施形態において、「ＡｔｔａｃｈＳｔｏｒｅ」フォーマットを強化してディスク上に別々のファイルとして格納されたＢＬＯＢへのポインタを支持することが望ましいことがある。このような実施形態では、以下のようにＡｔｔａｃｈＳｔｏｒｅにおける変更をすることが可能であり得る。
（１）ｂｌｏｂｌｄおよびハッシュをＡＴＴＡＣＨＭＥＮＴ＿ＬＩＳＴ＿ＮＯＤＥに格納することができる。
（２）完全なファイルＣＲＣをファイルの終わりに格納してＣＲＣ妥当性確認を簡略化することができる。

【0034】

[00036] さらに、ＢＬＯＢは、メッセージを以下のように格納することができる場所と並行して、ファイルシステム上の別個のディレクトリ構造に格納することができる：ｍｓｇ、ｉｎｄｅｘ、ｐｔｆ、ｂｌｏｂ（ハッシュの最初の２文字；添付ファイルのハッシュ）。

【0035】

[00037] 一実施形態において、ＢＬＯＢファイルは単一の大きなディレクトリとしてではなく、結果として、大きな数の入力にいったん達すると大幅に断片化されたディレクトリファイルになり得るものとして格納することが望ましいことがある。したがって、一実施形態において、ハッシュの最初の２文字をディレクトリ名として使用し、次いで１ディレクトリ当たりのファイルの数を所望の数に、例えば、数千に制限することが望ましいことがある。

【0036】

[00038] この実施形態は、さらに、マシン／ｄｂレベルで重複排除を実施することができる。この方式は、直接大規模に、例えば、マシンの群またはデータセンタ（DC）全体にさえ適用可能であり得る。破損されたことが見つけられた個々の重複排除されたＢＬＯＢは、次いで、ローカル内にまたは遠隔ＤＣにさえ存在する他のコピーから回復することができる。例外的な処理は、破滅的なデータ障害の後に回復に対して行うことができる。

【0037】

状態図の一実施形態
[00039] ＢＬＯＢは、それらのライフタイムの間、作成され、破損され、修理され、削除されたとき、様々な状態に遷移する傾向がある。この観察により、ＢＬＯＢのライフサイクルを説明する状態遷移方式を採用する一実施形態をもたらすことができる。状態は、どのＡＰＩをＢＬＯＢに適用する（に対して使用する）ことができるかを決定することができ、様々なタスクが確実に互いに侵害しないようにするために使用することができる。あるいは、別の一実施形態は、ＢＬＯＢを管理するために参照カウントを利用することがある。しかし、状態は、０の参照カウントに異なる解釈があり得るので使用することが望ましいことがあり、異なるように処理され得る。

【0038】

[00040] 別の一実施形態において、システムは、図２に示すような状態図（２００）に影響することがある。システム２００は、本明細書に説明するように、複数の状態、例えば、全部破損２０２、暫定２０４、削除中２０６、回復済み２０８、孤立２１０、一部破損２１２、良好２１４およびＴｂｌ＿ｂｌｏｂ行削除済み２１６を含むことがある。記載したように、システムは、ＢＬＯＢ（場合によってはメタデータストアで）へのポインタの数のカウンタ（すなわち「参照カウント」）を維持することができる。すべてのＢＬＯＢが「破損」と指定された場合、状態データは、２つの状態のうちの１つを反映することができる。（１）参照カウント＝０の場合、暫定，または（２）参照カウント＞０の場合、全部破損。システムは、暫定２０４への格納および／またはアクセスの要求を送ることができる。

【0039】

[00041] 所望する場合、システムは、暫定状態２０４においてＢｌｏｂ作成することができ、その場合、ＢＬＯＢはストアに「コミットされ」（例えば「HBM」）、システムは、良好状態２１４に移動することができる。一実施形態において、ＢＬＯＢが写しのすべてに物理的に書き込まれて初めてＢＬＯＢをストアにコミットすることが望ましいことがある。以下は、採用された様々な状態の説明である。

【0040】

良好状態
[00042] これはＢＬＯＢには通常の状態である。新しいメッセージの配信中にＡｄｄＲｅｆすることができるが、ガーベジコレクションはしない。一実施形態において、ＡｄｄＲｅｆは、ＢＬＯＢを再使用できることを指示することができる。ＢＬＯＢがすでに配信されており、この状態にある場合、ＢＬＯＢは「すでに存在する」し、ＢＬＯＢへの追加の参照によりＢＬＯＢの参照カウントを増加させることをもたらし（すなわち、ＢＬＯＢを再度格納することなく）、ＢＬＯＢの適正な再使用のためにポインタを更新することができる。

【0041】

[00043] 良好なＢＬＯＢは、参照の数に対してソフト制限を有することができ、それによって、ＢＬＯＢの追加のコピーを作成させることができる。

【0042】

孤立状態
[00044] これは、もはやアクティブな参照を有することができない、メッセージリムーバによる除去の候補であり得るＢＬＯＢである。実際にＢＬＯＢが削除中状態になるまで、ＢＬＯＢはＡｄｄＲｅｆされ、良好状態に戻ることができる。

【0043】

[00045] 暫定状態と同様に、所望の時間の後、メッセージリムーバがこれらのＢＬＯＢを削除する。

【0044】

回復済み状態
[00046] データベースの破損または最近のトランザクションログの消失の場合、「ｔｂｌ＿ｂｌｏｂ」をディスクから再構築することが望ましいことがある。一実施形態において、ｔｂｌ＿ｂｌｏｂは、各ＢＬＯＢの場所および状態に関する情報を保持するデータ構造であり得る。この表および／またはデータ構造が消失した場合、データ回復の当技術分野で知られている任意のやり方でデータを回復することが望ましいことがある。これを容易にするために、孤立に類似している「回復済み」と呼ばれる状態がある。回復済みＢＬＯＢはまだ妥当性確認されていない可能性があるので、システムは、回復済みＢＬＯＢを監視してから配信を介してまたは回復済みメッセージのためのいずれかにより、それらを再使用するはずである。任意のＡｄｄＲｅｆには、ＢＬＯＢが回復済み状態で見つかった場合、メール配信はＢＬＯＢを再書き込みしてすべてのコピーが確実に破損していないようにすることができる。

【0045】

[00047] データベース回復は、検証せずにＢＬＯＢを一部破損状態で再使用するか、または完全性を検証しそれを良好としてコミットするかのいずれかの選択肢を有することができる。場合によって、データベース回復は、共有がダウンしているときなど、ＢＬＯＢのすべてのコピーの完全性を検証することができない可能性がある。いったん回復が完了すると、ＢＬＯＢをまず妥当性確認／再書き込みすることなくＢＬＯＢを再使用することが望ましくない可能性があるので、任意の残りのＢＬＯＢは暫定状態に移動させることができる。ガーベジコレクションは、回復済みＢＬＯＢには実施することができない。クリーンアップへのデータベース回復プロセスの責任は、いったん完了したとすることができる。ＡｄｄＲｅｆは妥当性を確認して初めてＯＫになる。

【0046】

暫定状態
[00048] 「暫定」状態は、新たなＢＬＯＢをディスクに書き込むプロセスによって使用することができる。ＢＬＯＢ書き込みはネットワークエラー、一時的エラーなどにより失敗することがあるので、ＢＬＯＢが後に残された場合および／または決して使用されなかった場合、これらのＢＬＯＢが書き込まれた場所を記憶し、したがってそれらをクリーンアップできることが望ましいことがある。安全のために、ＢＬＯＢは、すべてのコピーがうまく書き込まれた場合、重複排除によって使用されるのに適切であり得る。これらの場合、完全冗長性を有する暫定ＢＬＯＢが書き込まれることに失敗した場合、完全なフォーマットでメッセージを書き込むことに戻ることが可能であり得る。発信者がまずＢＬＯＢを暫定状態で作成し、次いでＴｏｒｒｅｓを呼び出してファイルをすべての共有に書き込みさせ、次いでＣｏｍｍｉｔＨｅａｄｅｒＢｌｏｂＭａｐｐｉｎｇ（コミット＿HBM）を介してまたは状態を孤立に設定することによりＢＬＯＢを遷移することが期待される。一実施形態において、コミット＿ＨＢＭは、メタデータストアのＢＬＯＢ状態を暫定状態から適当な新たな状態（その場合、ＢＬＯＢは使用され、再使用される用意ができている）に移動させる内部関数呼び出しであり得る。さらに、コミット＿ＨＢＭは、ＢＬＯＢの参照カウントを増加させることができ、例えば、暫定状態のＢＬＯＢに対するコミット＿ＨＢＭの呼び出しは、その状態を変更するだけでなく、参照カウントを１に増加させることもできる。

【0047】

[00049] ＢＬＯＢがすでに暫定状態で存在する場合、別のＢＬＯＢが同時に配信されると、競合状態の可能性がある。この状態はＴｏｒｒｅｓによって扱われ、それによって、ＢＬＯＢの書き込みが決して既存のデータを破壊しないことを確実にする。（完全な説明についてはTorresに関する項目参照）

【0048】

削除中状態
[00050] メッセージリムーバは、ディスク上のファイルを実際に削除することを決定すると、ＢＬＯＢに「削除中」とマークを付けてから削除操作を開始する。これにより、確実に誰も半分削除されたＢＬＯＢを使用することを試みない。すべてのコピーがディスクから削除されたという確認を受け取ると、ｔｂｌ＿ｂｌｏｂから行が除去される。エラーが起きた場合、削除が確認されるまでこの状態のままでいることが望ましいことがある（ファイルがもう存在しないか削除されたかのいずれかのため）。

【0049】

[00051] ＢＬＯＢが削除中状態にあり、発信者が同じハッシュを用いて新たなＢＬＯＢを作成することを試みた場合、異なるデータベース群が新たなＢＬＯＢに選ばれる。ＡｄｄＲｅｆはＮＯＴ ＯＫである。

【0050】

一部破損状態
[00052] ＢＬＯＢの任意のコピーが破損しているまたは読めないとして検知された場合、システムはＢＬＯＢに「一部破損」として、または他の何らかの名称の「破損」状態としてマークを付けることができる。システムがどの写しが破損しているのかに関する情報を格納しないことが望ましい。これは、破損したＢＬＯＢを検知するための、および／または破損したＢＬＯＢを修復するためのモジュール（別名「ターボFSS」）への両方の信号である。このモジュールは、破損したＢＬＯＢについて定期的に問い合わせを行うことができる。このモジュールは、このＢＬＯＢを任意の新たな配信に利用できないようにすることに加えて、修復を試みることもできる。システムがＢＬＯＢの正確な状態（何かが悪いということだけしか）を知らない可能性があるので、システムは、ＢＬＯＢを重複排除に使用しなくてよい。この用途のために、ターボＦＳＳとは、ファイルおよびＢＬＯＢがシステム内の複数の冗長コピーの間で同期状態に保持されることを確実にするモジュールを表す。

【0051】

[00053] ターボＦＳＳは、修復を実施するとき、あまりにも多くの回数修復することを試みることを避けるためにＢＬＯＢの最後の書き込み時間を考慮することもできる。ＢＬＯＢは、参照カウント０に達すると、ＢＬＯＢが再使用される前にＢＬＯＢを再書き込みさせることが望ましいことがあるので、暫定状態になることができる。新たなＢＬＯＢが一部破損の既存のＢＬＯＢとして同じハッシュと共に到着した場合、システムは新たな配信でそれを上書きする。すべての書き込みがうまくいくと、ＢＬＯＢには修復済みのマークを付けることができる。すべてのＢＬＯＢが全冗長性で書き込み得ない場合、システムは重複排除されない可能性があるので、配信の間共有がダウンしていたためまたはユーザ移動が一部破損状態にされていないため、部分的に冗長であるＢＬＯＢ。ＡｄｄＲｅｆはＮＯＴ ＯＫである。

【0052】

全破損状態
[00054] この状態は、所与のＢＬＯＢにデータ消失が起きたことおよびすべての修復の試みが失敗したことを指示する。さらなる修復の試みは、試みない可能性がある。ＢＬＯＢは、手動で修復されるかまたはすべての参照カウントが０に達しＢＬＯＢが削除されるまで、この状態にずっととどまることができる。

【0053】

[00055] ユーザ移動は、アカウント全体（欠落BLOBを含む）を移動させることができるので、全部破損ＢＬＯＢは、ＢＬＯＢがソースシステム上で完全に欠落していた場合、ユーザ移動によって宛先システム上で作成することができる。ＢＬＯＢがこの状態にあり、０の参照カウントに達した場合、ＢＬＯＢを妥当性確認および／または再書き込みさせてから再使用することが望ましいことがあるので、ＢＬＯＢは暫定となることができる。この用途のために、ユーザ移動は、ファイルシステムまたはＥメールシステムなどとの最適なバランスをとるためにＥメールアカウントを、イントラおよびインターデータセンタのあちこちに移動させるモジュールである。

【0054】

[00056] 一実施形態において、この状態のＢＬＯＢは、データベース内にとどまり、一部のユーザおよび／または実体はそれらを参照する。いくつかの実施形態では、このようなＢＬＯＢを修復するために以下を含む複数の技法があり得る。
（１）メール配信またはユーザ移動は、同じハッシュを有する新たなＢＬＯＢが配信された場合、既存のＢＬＯＢを修復することができる。
（２）添付ファイルがそこに存在するかどうか確認するために他のサーバまたはデータベース群を見る。
（３）ＡｃｔｉｖｅＳｙｎを使用するユーザには、システムは添付ファイルをそこから引っ張ることができる。

【0055】

[00057] 新たなＢＬＯＢが全部破損の既存のＢＬＯＢとして同じハッシュと共に到着した場合、一実施形態は、永続性ストレージが書き込みを有するべき等であることを保証することができるので、新たな配信でそれを上書きすることができる。すべての書き込みがうまくいくと、ＢＬＯＢは良好というマークが付けられ、ＡｄｄＲｅｆされる。ＡｄｄｒｅｆはＮＯＴ ＯＫである。

【0056】

参照カウンティング
[00058] ＢＬＯＢはユーザ間で共有することができるので、ＢＬＯＢが有する参照の数を追跡し、したがって参照の数がゼロの参照に達するとシステムが参照の数をクリーンアップできることが望ましいことがある。あるいは、システムは、所望の閾値のアカウントの数に影響することがあるデータ消失を軽減することが望ましい場合、ＢＬＯＢがあまりに多くの参照を有することを潜在的に妨げることができる。

【0057】

[00059] ＢＬＯＢの状態は、ある状態が参照カウントを０にし、他の状態が参照カウントを０より大きくすることを望むので、参照カウントへの影響を有することもあり得る。例えば、以下の表は、一実施形態の実施を反映する。

【0058】

【表1】

【0059】

[00060] 参照カウントは、行がｔｂｌ＿ＨｅａｄｅｒＢｌｏｂＭａｐｐｉｎｇ（すなわち、tbl_HBM）に追加されると、増加させることができ、行が除去されると減少させることができる。行は、メッセージがｔｂｌ＿ｄｅｌｅｔｅｄｍｅｓｓａｇｅから除去されると、ｔｂｌ＿ＨｅａｄｅｒＢｌｏｂＭａｐｐｉｎｇから除去することができる。システムはｔｂｌ＿ｈｅａｄｅｒからの削除により除去しないことが望ましいことがある。これにより、メッセージがメッセージリムーバによって削除される前に、ＢＬＯＢがガーベジコレクションする。一実施形態において、システムがメッセージリムーバを何らかの理由で元に戻すことを望む場合、添付ファイルを確実にまだ読むことができるようにすることが望ましいことがある。

【0060】

[00061] 参照カウントが０に達すると、トリガが以下のようにｔｂｌ＿ｂｌｏｂの表の状態を変更することができる。

【0061】

【表2】

【0062】

[00062] 部分的にまたは完全に破損しているＢＬＯＢは、暫定状態に遷移することができ、したがってシステムはそれらを修復することを試みない可能性がある。

【0063】

[00063] 一実施形態において、システムは、ソフト制限を参照カウントに実施して、ＢＬＯＢのコピーの消失が受けることがある損傷の量を制限することができる。この制限は構成ファイルから読むことができ、ＢＬＯＢ作成が呼び出されたとき実施することができる。ＢＬＯＢが構成された制限を超えていることにシステムが気付いた場合、システムは、既存のＢＬＯＢを返すのではなく、新たな場所の新たな暫定ＢＬＯＢを返すことができる。この用途のために、ＢＬＯＢ作成は、新たなＢＬＯＢの場所を作成するかまたは既存の場所を再使用するかのいずれかができる関数呼び出しである。

【0064】

[00064] いくつかの実施形態では、制限は対数的に実施することができ、したがって、各々の追加のコピーは、ＢＬＯＢの数に制限を乗じることができる。例えば、制限が１つのＢＬＯＢ当たり１００のコピーである場合、２つのコピーでは１００＊１００＝１００００のコピーが可能になり、３つのコピーでは１００^３のコピーが可能になる。

【0065】

[00065] 以下の表は、いくつかの異なる条件の下での可能なＢＬＯＢ修復状態の一実施形態である。

【0066】

【表3-1】

【0067】

【表3-2】

【0068】

Ｅメールシステムの一実施形態
[00066] 図３は、本出願の原理により製作されたときのＥメールシステムの一実施形態を示す。具体的には、システム３００は、重複排除操作のためのＥメール配信の流れ図を示す。Ｅメールシステム３００は、着信Ｅメールおよび／またはそれらの添付ファイルを受け取り、メッセージ構文解析３０２において、Ｅメールの様々な部分を構文解析することができる。メッセージ構文解析３０２は、様々な部分に対してハッシュを計算することができる。ハッシュの結果は、メッセージおよび／または添付ファイルを重複排除するのかどうかを決定する助けにするためにシステムによって使用することができる。

【0069】

[00067] システムは、図示するように、「良好」状態にある間、各ＢＬＯＢ作成３０４をすることを決定し継続する。ＢＬＯＢの状態が「書き込み」することを望む場合、ＢＬＯＢは３０６において永続性ストア３０６に書き込むことができる。システムがＢＬＯＢを終えると、システムは３０８においてコミットＨＢＭを従事させることができ、システムは、その後、３１０において「コンパクトな」メッセージを書き込むことができる。しかし、システムが「エラー」を検知すると、システムは、３１２において「完全な」メッセージを書き込むことができる。

【0070】

[00068] 上に説明してきたことは、本発明の例を含む。もちろん、特許請求される主題を説明するために構成要素または方法論の考えられる限りのあらゆる組合せを説明することは可能でないが、本発明の他の多くの組合せおよび順列が可能であることを当業者は認識することができる。したがって、特許請求される主題は、添付の特許請求の範囲の精神および範囲に含まれるそのような改変、修正、および変形をすべて包含することを意図している。

【0071】

[00069] 具体的にはおよび上記の構成要素、デバイス、回路、システムなどによって実施される様々な機能に関して、そのような構成要素を説明するのに使用された用語（「手段」への参照を含む）は、他に指示のない限り、特許請求される主題の本明細書に図示される例示的な態様において機能を実施する、開示された構造に構造的に同等ではなくても、説明された構成要素の指定された機能（例えば、機能的な同等物）を実施する任意の構成要素に対応することを意図している。この点において、本発明が特許請求される主題の様々な方法の動作および／または事象を実施するためのシステムならびにコンピュータ実行可能命令を有するコンピュータ可読媒体を含むことも認識されよう。

【0072】

[00070] さらに、本発明の特定の特徴はいくつかの実施のうちの１つのみに関して開示されたかもしれないが、そのような特徴は、いずれかの所与のまたは特定の用途に所望され有利であり得るとき、他の実施の１つまたは複数の他の特徴に組み合わせることができる。さらに、「含む（includes）」および「含む（including）」という用語およびそれらの変形が、詳細な説明または特許請求の範囲のいずれかに使用される程度まで、これらの用語は「含む（comprising）」という用語と類似の仕方で包含的であることを意図している。

【図1】

【図2】

【図3】