STORING ELECTRONIC CONTENT WITH TIME-VARYING PROPERTIES

[0001] Embodiments are described relating to systems and methods for storing electronic content and, more particularly, efficiently storing electronic content with time-varying properties.

[0002] Conventional systems and methods for data tracking and storage track document versions over time (e.g., documents, distribution lists, etc.) by creating a new version record in the database for each revision made to the document. As a result, data storage requirements were significantly increased because every revision to a document resulted in a new version of the document, and all versions of the document had to be maintained in database storage.

[0003] This was especially problematic when dealing with electronic mail distribution lists because these lists were always changing. Each time a change was made to a list (e.g., member added, member deleted, etc.) a new version of the list was created such that all member records were duplicated per revision. Additional storage was required because nested lists were flattened for every stored version of the list. Furthermore, for messages including lists as recipients, all lists were recursively expanded for efficient searching of indirect recipients of a message. As a result excessive amounts of database storage were used to archive this data.

[0004] Moreover, conventional data tracking and storage also lacked storage efficient methods for tracking other time-varying properties of a document (e.g., flag states, document states, etc.) because, again, every change in a time-varying property results in a new version of the document or record. To save on storage, only the last value of such dynamic attributes of a document might be retained, and this was not a viable solution for tracking document properties over the life of a document.

[0010] Systems and methods for controlling document storage and tracking model dynamic attributes of a document in a time-varying manner, and enable reconstruction of a document's state at any point in time. The time-varying model identifies dynamic components of documents, where dynamic components include time-varying properties that changes over time. A set of validity parameters are associated with each state of a document (the state of a document corresponds to a new version of the document that results from changes to the document), and the set of validity parameters define a validity period for the state. Instead of archiving each new version of the document that corresponds to each new state of the document, the document is archived in storage by archiving information of the states along with the set of validity parameters corresponding to each state.

[0011] FIG. 1 is a block diagram of a system for data tracking and storage 100 (e.g., archiving), under an embodiment. The system 100 comprises a server 101 and/or other processor-based device coupled or connected to at least one database or archive 102. The database can be of any type/configuration, storing data in one or more different formats. The data comprising documents and other electronic content described herein are processed by an archiving program or application 103 running on the server 101 for storage or archiving in the database 102. When the document includes dynamic or time-varying components, the archiving program 103 described herein enables compact and efficient data storage and tracking by maintaining a record of changes to a received document along with an effective or validity period corresponding to each change. More particularly, the embodiments identify components of the document that change over time as the time-varying components, and then track and record the state of each time-varying component along with the validity period of each state. The record or tables of changes with corresponding validity periods 110/120 are tracked over the life of the document instead of archiving each new version of the document resulting when changes are made to the document.

[0012] Generally, FIG. 2 is a flow diagram for storing documents having time-varying components 200, under an embodiment. The document storing operations comprise receiving a document and identifying a dynamic component of the document 202. The document comprises electronic content, and the dynamic component includes at least one time-varying property that changes over time. The states of the dynamic component are detected or identified 204, with each state corresponding to a new version of the document that results from subsequent changes to the document. The operations include associating a set of validity parameters with each state such that the set of validity parameters define a validity period for the state 206. The document is archived by archiving the states and the set of validity parameters corresponding to each state instead of archiving each new version of the document that corresponds to each state of the document.

[0013] FIG. 3 is a flow diagram for generating validity parameters corresponding to states of the dynamic or time-varying components 300, under an embodiment. Operations for generating validity parameters corresponding to states of the dynamic components include, for each state of the dynamic component, generating a set of validity parameters that includes a start time at which the state came into existence and an end time at which the state changed to a different state 302. The end time is set at a null value until such time as a state change is detected in the dynamic component 304, and the null value indicates the dynamic component is currently remaining in the state. When a change in the dynamic component is detected the change is identified as a state change to the different state, and the end time of the set of validity parameters is reset to a time of the state change 306. An embodiment generates a different set of validity parameters that includes a start time at which the different state came into existence and an end time at which the different state ceased to exist 308. The end time of the different set of validity parameters is set at a null value until such time as a state change is detected in the dynamic component. As described herein, the null value indicates the dynamic component is currently remaining in the different state. Examples follow of use of time-varying components in the storage and tracking of documents.

[0014] As an example, and with reference to FIG. 1, a received document includes a list comprising multiple members or elements. The list can include, for example, one or more of a list having membership changes over time, an electronic mail distribution list, a security access list, a user group list, and an access rights list, to name a few. A dynamic component of this document (list) as described herein is a period of time each member is on the list. As such, an embodiment generates and maintains a membership list record or table 110 that includes a list identification 111 for the list to which it corresponds and, for each member, a member identification 112 that identifies the member along with at least one set of validity parameters 114 that define at least one validity period for that member. The format of the list record 110 can be any format as appropriate to the data contents of the list record 110 and/or the structure of the corresponding database. Under this example, the validity period 114 includes the use of a set of validity parameters that include an “effective from” validity parameter 114A and an “effective to” validity parameter 114B to define a period of time during which the member was a member of the list. The “effective from” parameter 114A specifies the time of inclusion of the member on the list, and the “effective to” parameter 114B specifies the time of termination of membership on the list. The “effective from” validity parameter 114A is also referred to herein as the “start time” and the “effective to” validity parameter 114B is also referred to herein as the “end time.” When the member is added to and removed from the list multiple times, the list membership record 110 for that member includes multiple sets 114/116 of validity parameters, with each set of validity parameters 114/116 specifying the validity period for each corresponding time spent as a member of the list.

[0015] Use of the storage and tracking solution of an embodiment eliminates the need to introduce an explicit list version on each change to the list and, instead, just tracks membership changes over time, with each member having a validity period (e.g., “effective from” and “effective to”). An embodiment uses a special value (null value) to indicate a member is currently active on the list. The storage and tracking of an embodiment also eliminates the need to expand nested distribution lists in place and does not expand distribution list members for every message sent to a distribution list. Instead, distribution lists are treated like any other list member or mail recipient.

[0016] Generating and maintaining a membership list record of an embodiment with validity parameters corresponding to each member or element of the list includes generating a first set of validity parameters that defines a first validity period corresponding to a first state of the element. When the document is received it includes the element in the first state. The first validity period includes a start time and an end time. The end time is set at a null value until such time as a change in state is detected, and the null value indicates the element is remaining in the first state.

[0017] When a change associated with the element is detected, the change is identified as a change in state from the first state to a second state. The change in state includes, but is not limited to, adding the element to the list, removing the element from the list, and/or revising the element on the list, to name a few. In response to the state change, the end time of the first validity parameter is reset to a time of the change in state. Further, an embodiment generates a second set of validity parameters that defines a second validity period corresponding to the second state. The second validity period includes a start time that is the time of the change in state. The end time of the second validity period is set to the null value until such time as a subsequent change in state is detected. The process of maintaining the membership list record in response to detected changes in the element repeats upon detection of all subsequent changes in state of the list.

[0018] FIG. 4 shows an example database tree of tables for tracking electronic mail distribution list membership changes over time as a dynamic component, under an embodiment. In this example, the document or table “MembersForEmails” 410 includes information on all members along with attributes. This table 410 can be thought of as a directory that includes information on all members of a database that have an email account, where a member includes the likes of individuals, groups, lists of individuals, and/or lists of groups. Each member included in the table 410 corresponds to and is identified using a member identification 411 (e.g., “MemberID”). The table 410 also includes any number of attributes corresponding to a member (e.g., this example includes attribute fields “ADObject” 412 (links member to active directory information), “DisplayName” 413 (named used for display purposes), “SenderEmail” 414 (sender's email as known to active directory), “SmtpEmail” 415 (email address for SMTP protocol), “UniquenessHash” 416 (hash of {SenderEmail, SMTPEmail} of properties used for identifying a member), “IsInternal” 417 (identifies whether member is within or outside organization), and “IsList” 418 (identifies whether member is list or individual), but is not limited to these attributes).

[0019] The database includes a “ListMembershipEmail” table 420 that corresponds to each email distribution list in the database. The email distribution list to which a particular “ListMembershipEmail” table 420 corresponds is identified using the “MemberListID” field 421. The table 420 includes a record for each member included in the “MembersForEmails” table 410, to which it is linked, and the record identifies the member to which it corresponds using the “MemberID” field 422.

[0020] The dynamic component of this table 420 is a period of time each member is on the list. As such, the record for each member includes at least one set of validity parameters 423/424 that define at least one validity period for that member. Under this example, the validity period 423/424 includes the use of a set of validity parameters that include an “EffectiveFrom” parameter 423 and an “EffectiveTo” parameter 424 to define a period of time during which the member was a member of the list. The “EffectiveFrom” parameter 423 specifies the time of inclusion of the member on the list, and the “EffectiveTo” parameter 424 specifies the time of termination of membership on the list. When the member is added to and removed from the list multiple times, the list membership record for that member includes multiple sets of validity parameters (not shown), where each set of validity parameters specifies the validity period for each corresponding period spent as a member of the list. The table 420 also includes any number of attributes corresponding to a member (e.g., this example includes an attribute field “IsList” 425 (identifies whether member is list or individual), but is not limited to this attribute).

[0021] The database includes a “MemberIsInternal” table 430 that corresponds to each member in the database. The member to which a particular “MemberIsInternal” table 430 corresponds is identified using the “MemberID” field 431. The dynamic component of this table 430 is a period of time each member is internal to the organization. As such, the record for each member includes an attribute field “IsInternal” 432 along with at least one set of validity parameters 433/434 that define at least one validity period corresponding to that attribute 432. The validity period 433/434 includes a set of validity parameters comprising an “EffectiveFrom” parameter 433 and an “EffectiveTo” parameter 434 to define a period of time during which the member was internal to the organization. The “EffectiveFrom” parameter 433 specifies the time of inclusion of the member in the organization, and the “EffectiveTo” parameter 434 specifies the time of termination of membership in the organization. When the member joins and subsequently departs from the organization multiple times, the table 430 for that member includes multiple sets of validity parameters (not shown), where each set of validity parameters specifies the validity period for each corresponding period spent as a member of the organization.

[0022] In yet another example of tracking changes in dynamic components, and with reference to FIG. 1, a received document includes or is associated with multiple dynamic components. A dynamic component of this document can be any attribute or parameter that changes over the life of the document (e.g., flag state, document state, etc.). As such, an embodiment generates and maintains a document record or table 120 that includes, for each document, a document identification 122 that identifies the document along with a listing of each dynamic component 124 (e.g., dynamic components of this example are “DC1,” “DC2,” “DCX”, where “X” represents any number, but are not so limited) associated with the document and at least one set of validity parameters 126 that define at least one validity period for that dynamic component. Under this example, the validity period 126 includes the use of a set of validity parameters that include an “effective from” validity parameter 126A and an “effective to” validity parameter 126B to define a period of time corresponding to a state of the dynamic component. The “effective from” parameter 126A specifies the time the dynamic component entered a state, and the “effective to” parameter 126B specifies the time the dynamic component transitioned to a different state. When the dynamic component changes state multiple times, the document record for that document includes multiple sets (not shown) of validity parameters, with each set of validity parameters specifying the validity period for each corresponding time spent as a member of the list.

[0023] Generating and maintaining a document record of an embodiment with validity parameters corresponding to each dynamic component includes detecting a first state of the dynamic component at a start time. The dynamic component of an embodiment includes, but is not limited to, parameters like flag state, document state, and folder name, to name a few. The start time is either a time of the receiving of the document or a time of a preceding change in state occurring prior to the start time. A first set of validity parameters are generated defining a first validity period corresponding to the first state. The first validity period includes the start time along with an end time. The end time is set at the null value to indicate the dynamic component is currently remaining in the first state.

[0024] When a change associated with the dynamic component is detected, the change is identified as a change in state from the first state to a second state and, in response, the end time of the first validity parameter is reset to a time of the change in state. A second set of validity parameters are generated that define a second validity period corresponding to the second state, and the second validity period includes a start time that is the time of the change in state. The end time of the second validity period is set at the null value until such time as a subsequent change in state is detected. The process of maintaining the document record in response to detected changes in state of dynamic components repeats upon detection of all subsequent changes in state of the document content.

[0025] A more specific example of a dynamic component of a document includes the content of the document, and an embodiment uses the validity parameters to track changes in the message content. As such, an embodiment generates and maintains the document record described herein to include a record of differential changes corresponding to revisions of the document content. The differential changes are encoded in difference files that are generated each time a revised version of the document is generated. Each difference file corresponding to the document is included in the document record along with a set of validity parameters that define the validity period for that version of the document. The validity period includes the use of a set of validity parameters that include an “effective from” validity parameter and an “effective to” validity parameter to define a period of time corresponding the difference file, as described above. The “effective from” parameter specifies the time of creation of the document version corresponding to the difference file, and the “effective to” parameter specifies the time of creation of a subsequent document version. When multiple versions of the document are created, the document record for that document includes multiple difference files and sets of validity parameters, with each set of validity parameters specifying the validity period for each corresponding difference file.

[0026] An embodiment generates and maintains a document record of an embodiment that includes a dynamic component that is message or document content and corresponding validity parameters. The embodiment generates a first set of validity parameters that defines a first validity period corresponding to a first state of the message content. The first validity period includes a start time and an end time, and the document is received at the start time with the message content in the first state. The end time is set at the null value until such time as a change in state is detected. In response to detecting a change in the message content, the change is identified as a change in state from the first state to a second state, and the end time of the first validity parameter is reset to a time of the change in state. The change in state includes, but is not limited to, deletion of a portion of the message content, addition of new message content, and changes or revisions to the message content.

[0027] An embodiment generates a difference file at the end time in response to the detected state change. The difference file encodes differences in message content resulting from the change in state. A second set of validity parameters are generated to define a second validity period corresponding to the second state and the difference file is associated with the second set of validity parameters. The second validity period includes a start time that is the time of the change in state. The end time of the second validity period is set at the null value until such time as a subsequent change in state is detected. The process of generating a difference file in response to detected changes in the document repeats upon detection of any subsequent changes in state of the document content.

[0028] A further example of modeling dynamic components of a document in a time-varying matter involves folders, and FIG. 5 shows an example database tree of tables for tracking folder attributes over time as dynamic components, under an embodiment. In this example, the document or table “MembersForFolders” 510 includes information on all members along with attributes. This table 510 can be thought of as a directory that includes information on all members of a database that have access or rights to a folder, where a member includes the likes of individuals, groups, lists of individuals, and/or lists of groups. Each member included in the table 510 corresponds to and is identified using a member identification 511 (e.g., “MemberID”). The table 510 also includes any number of attributes corresponding to a member (e.g., this example includes attribute fields “ADObject” 512 (links member to active directory information), “UsersDomainName” 513 (named used for display purposes), “SID” 514 (security identification know to active directory), “UniquenessHash” 515 (hash of {SenderEmail, SMTPEmail} of properties used for identifying a member), “IsInternal” 516 (identifies whether member is within or outside organization), and “IsList” 517 (identifies whether member is list or individual), but is not limited to these attributes). The database includes a “FolderAccessRights” table 520 that tracks access rights on a folder. The folder to which a particular “FolderAccessRights” table 520 corresponds is identified using the “FolderID” field 521. The table 520 includes a record for each member included in the “MembersForFolders” table 510, to which it is linked, and the record identifies the member to which it corresponds using the “MemberID” field 522.

[0029] The dynamic component of this table 520 is a period of time each member has folder access rights. As such, the record for each member includes at least one set of validity parameters 523/524 that define at least one validity period for that member. Under this example, the validity period 523/524 includes a set of validity parameters that include an “EffectiveFrom” parameter 523 and an “EffectiveTo” parameter 524 to define a period of time during which the member had folder access rights. The “EffectiveFrom” parameter 523 specifies the time of inclusion of the member on access list, and the “EffectiveTo” parameter 524 specifies the time of termination of membership on the access list. When the member is added to and removed from the access list multiple times, the list membership record for that member includes multiple sets of validity parameters (not shown), where each set of validity parameters specifies the validity period for each corresponding period spent as a member of the access list. The table 520 also includes any number of attributes corresponding to the particular folder and member (e.g., this example includes an attribute field “Privileges” 525 (identifies privileges of the member), but is not limited to this attribute).

[0030] The database includes a “Folder” table 530 that corresponds to each folder in the database. The row identifier to which a particular “Folder” table 430 corresponds is identified using the “FolderID” field 531. The table 530 includes a “DocSrcID field 532 that is a unique identifier for a share, and an “Identifier” field 533 that is the identifier of the corresponding folder. The dynamic component of this table 530 is a period of time each folder is valid, so the record for each folder includes at least one set of validity parameters 534/535 that define at least one validity period corresponding to the folder. The validity period 534/535 includes a set of validity parameters comprising an “EffectiveFrom” parameter 534 and an “EffectiveTo” parameter 535 to define a period of time during which the folder was valid. The “EffectiveFrom” parameter 534 specifies the time at which the folder became valid, and the “EffectiveTo” parameter 535 specifies the time the folder became invalid. When a folder is made valid and subsequently becomes invalid multiple times, the table 530 for that folder includes multiple sets of validity parameters (not shown), where each set of validity parameters specifies the validity period for each corresponding period of folder validity.

[0031] The database includes a “FolderNameOverTime” table 540 that corresponds to each folder in the database. The folder to which a particular “FolderNameOverTime” table 540 corresponds is identified using the “FolderID” field 541. The folder name is specified in a “FolderName” field 542. The dynamic component of this table 530 is a period of time each folder name is valid, so the record for each folder includes at least one set of validity parameters 543/544 that define at least one validity period corresponding to the folder name. The validity period 543/544 includes a set of validity parameters comprising an “EffectiveFrom” parameter 543 and an “EffectiveTo” parameter 544 to define a period of time during which the folder name was valid. The “EffectiveFrom” parameter 543 specifies the time at which the folder name became valid, and the “EffectiveTo” parameter 544 specifies the time the folder name became invalid. When a folder name is made valid and subsequently becomes invalid multiple times, the table 540 for that folder includes multiple sets of validity parameters (not shown), where each set of validity parameters specifies the validity period for each corresponding period of folder name validity.

[0032] The database includes a “FolderParentsOverTime” table 550 that corresponds to each folder in the database. The folder to which a particular “FolderParentsOverTime” table 550 corresponds is identified using the “FolderID” field 551. The folder parent is specified in a “FolderParentID” field 552. The dynamic component of this table 550 is a period of time the identified parent folder was the parent, so the record for each folder includes at least one set of validity parameters 553/554 that define at least one validity period corresponding to the parent folder. The validity period 553/554 includes a set of validity parameters comprising an “EffectiveFrom” parameter 553 and an “EffectiveTo” parameter 554 to define a period of time during which the corresponding parent folder was the parent. The “EffectiveFrom” parameter 553 specifies the time at which the parent folder became the parent, and the “EffectiveTo” parameter 554 specifies the time at which the parent folder was removed as the parent. When a parent folder is a parent for a period and is subsequently changed from being the parent, the table 550 for that folder includes multiple sets of validity parameters (not shown), where each set of validity parameters specifies the validity period for each corresponding period of parent folder validity.

[0033] Moreover, with folders, an embodiment tracks all folders of which a message was a member using the validity parameters, as described herein. When tracking messages in folders, a table tracks each message and when it was placed in the folder and when the message was removed from the folder. The dynamic component of this table is a period of time the message was in the folder. The validity period includes a set of validity parameters comprising an “EffectiveFrom” parameter and an “EffectiveTo” parameter to define a period of time during which the corresponding message was in the folder. The “EffectiveFrom” parameter specifies the time at which the message was placed in the corresponding folder, and the “EffectiveTo” parameter specifies the time at which the message was removed from the folder. In this manner, the location of a message at any point in time can be established without creating new versions of the message for all contained messages when the containing folder is renamed or when a message is moved from one to another folder.

[0034] In the description above, numerous specific details are introduced to provide a thorough understanding of, and enabling description for, embodiments of the data storage and tracking. One skilled in the relevant art, however, will recognize that these embodiments can be practiced without one or more of the specific details, or with other components, systems, etc. In other instances, well-known structures or operations are not shown, or are not described in detail, to avoid obscuring aspects of the disclosed embodiments.

[0035] The systems and methods described herein include and/or run under and/or in association with a processing system. The processing system includes any collection of processor-based devices or computing devices operating together, or components of processing systems or devices, as is known in the art. For example, the processing system can include one or more of a portable computer, portable communication device operating in a communication network, and/or a network server. The portable computer can be any of a number and/or combination of devices selected from among personal computers, cellular telephones, personal digital assistants, portable computing devices, and portable communication devices, but is not so limited. The processing system can include components within a larger computer system.

[0036] The processing system of an embodiment includes at least one processor and at least one memory device or subsystem. The processing system can also include or be coupled to at least one database. The term “processor” as generally used herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASIC), etc. The processor and memory can be monolithically integrated onto a single chip, distributed among a number of chips or components of a host system, and/or provided by some combination of algorithms. The methods described herein can be implemented in one or more of software algorithm(s), programs, firmware, hardware, components, circuitry, any combination.

[0037] System components embodying the systems and methods described herein can be located together or in separate locations. Consequently, system components embodying the systems and methods described herein can be components of a single system, multiple systems, and/or geographically separate systems. These components can also be subcomponents or subsystems of a single system, multiple systems, and/or geographically separate systems. These components can be coupled to one or more other components of a host system or a system coupled to the host system.

[0038] Communication paths couple the system components and include any medium for communicating or transferring files among the components. The communication paths include wireless connections, wired connections, and hybrid wireless/wired connections. The communication paths also include couplings or connections to networks including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), proprietary networks, interoffice or backend networks, and the Internet. Furthermore, the communication paths include removable fixed mediums like floppy disks, hard disk drives, and CD-ROM disks, as well as flash RAM, Universal Serial Bus (USB) connections, RS-232 connections, telephone lines, buses, and electronic mail messages.

[0039] Unless the context clearly requires otherwise, throughout the description, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

[0040] The above description of embodiments of the data storage and tracking is not intended to be exhaustive or to limit the systems and methods described to the precise form disclosed. While specific embodiments of, and examples for, the data storage and tracking are described herein for illustrative purposes, various equivalent modifications are possible within the scope of other systems and methods, as those skilled in the relevant art will recognize. The teachings of the data storage and tracking provided herein can be applied to other processing systems and methods, not only for the systems and methods described above.

[0041] The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the data storage and tracking in light of the above detailed description.

[0042] The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the embodiments described above in light of the above detailed description.

[0043] In general, in the following claims, the terms used should not be construed to limit the embodiments described above to the specific embodiments disclosed in the specification and the claims, but should be construed to include all systems that operate under the claims. Accordingly, the embodiments described above are not limited by the disclosure, but instead the scope is to be determined entirely by the claims.

[0044] While certain aspects of the embodiments described above are presented below in certain claim forms, the inventors contemplate the various aspects of the embodiments described above in any number of claim forms. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the embodiments described above.