In-place email acquisition and archiving system

Abstract

The present invention provides a method and an archiving system for an archiving system that facilitates the retrieval of in-place emails. [Solution] The method includes: retrieving a message identifier (ID) from a journal copy of an email in order to manage journal copies in a full-text index; providing the message ID to an API associated with the enterprise architecture in order to retrieve the processing point used by the enterprise architecture in response to a request to retrieve in-place email from the enterprise architecture associated with the message ID; and providing the retrieved processing point associated with the requested in-place email to the API in order to retrieve the requested in-place email from a device storing the in-place email.

Description

Technical Field

[0001] Cross - reference to Related Applications This Japanese patent application claims priority under the Paris Convention based on (i) U.S. Patent Application No. 19 / 264,745, filed on July 9, 2025 (which is a national stage application based on U.S. Provisional Patent Application No. 63 / 779,635, filed on March 28, 2025) and (ii) U.S. Provisional Patent Application No. 63 / 779,635, filed on March 28, 2025. The disclosure contents of these applications are hereby incorporated by reference in their entirety into this specification.

[0002] The present disclosure generally relates to an e - mail archive system, and more particularly to an in - place e - mail procurement and archive system.

Background Art

[0003] E - mail communication is common in every enterprise. To facilitate the reception, processing, archiving, and distribution of e - mails, many enterprises utilize an enterprise architecture that includes a series of solutions such as a client interface or software for the management and archiving of e - mails for each user / receiver, a server that implements the backbone of an enterprise solution for e - mail for receiving and distributing e - mails, a storage system for facilitating the archiving of e - mails, and other tools or solutions connected to or associated with the client interface or software for the user.

[0004] To comply with business rules, record keeping, or information governance such as discovery compliance, the implemented enterprise architecture may also need to archive such emails for at least a certain period. Such an enterprise architecture may utilize an archiving system that replicates received emails and documents and manages them in one or more storage systems. In some cases, such archived emails may be used by the company to perform data analysis using data analysis tools as needed. [Overview of the Initiative]

[0005] The enterprise architecture of the related technologies used to manage email presents several problems. The first problem is that as a company grows and hires more employees, the volume of email received by the company can increase exponentially. Even a company with only a few hundred users could receive or send a massive amount of email (e.g., billions) in just a few years. Therefore, the cost of archiving such email, even for a limited time, can increase exponentially as the required storage increases.

[0006] Another related technical issue is that enterprise architectures used for email management often lack inter-company compatibility in terms of access or operation due to vendor lock-in and other problems. Such enterprise architectures can be highly siloed, potentially causing problems associated with the ability to perform email analysis without using the company's enterprise architecture, or with facilitating the acquisition of emails by third parties. In situations where emails need to be quickly retrieved for regulatory compliance, companies typically have no choice but to use crawling tools within their enterprise architecture to search and retrieve emails from archives. However, because the volume of emails managed by companies can be enormous (e.g., billions), such tools require significant time and computation to crawl archives and retrieve requested emails from archives or storage systems that facilitate user-client interfaces or software.

[0007] To address related technical issues, the exemplary implementation described herein focuses on an in-place email acquisition and archiving system. Here, “in-situ” may be used as a substitute for the term “in-place.” In the exemplary implementation, this system utilizes both journal copies received by the enterprise architecture before processing and information generated at each processing point of the enterprise architecture before delivery to end users to generate a full-text index of all emails received by the enterprise architecture implemented by the enterprise, eliminating the need to duplicate all emails received by each end user, thereby significantly reducing storage costs as emails sent to end users can be stored in their original location instead of requiring clone copies. The full-text index of emails is also stored together with information generated at each processing point of the enterprise architecture between the receipt of journal copies and the final delivery of emails to end users, facilitating the ability to reconstruct any email from the end user's perspective, thereby facilitating email archiving while enabling enterprises to manage emails in their original location without requiring clone copies of each email received by end users. Such exemplary implementations eliminate the need to crawl all emails managed by the enterprise system, thus reducing the time and computation required to obtain emails for regulatory compliance.

[0008] Furthermore, because a full-text index is maintained within the archiving system, data analysis can be performed on text managed by the archive from inter-enterprise solutions, thereby avoiding the need to utilize the same enterprise architecture implemented by the enterprise to perform analysis, search, or retrieval, essentially bypassing the enterprise architecture altogether. Since the archive is a full-text index, analysis can be performed on emails received by the enterprise significantly faster than analysis by using analytical tools to traverse emails stored in the enterprise architecture.

[0009] Aspects of this disclosure may include an archiving system that receives journal copies of emails directed to an enterprise architecture and manages a full-text index of the journal copies, and information associated with processing points in the enterprise architecture that process the journal copies and generate emails directed to end users.

[0010] Aspects of this disclosure may include methods for an archiving system for managing an archive of emails that may be referred to as “in-place” emails within an enterprise architecture and for facilitating the retrieval of in-place emails (which, according to embodiments described herein, can be retrieved even if deleted from in-place storage), the method for receiving journal copies of emails directed to an enterprise architecture (each email may have one or more journal copies, and one or more emails may be sent to such enterprise architecture), preferably for managing journal copies in a full-text index, extracting message identifiers (IDs) from the (received) journal copies of emails, and for organizing the enterprise architecture associated with one message ID from a plurality of message IDs This may include providing a message ID to an application programming interface (API) associated with the enterprise architecture in order to retrieve one or more processing points used by the enterprise architecture to process journal copies, in response to a request to retrieve one or more in-place emails from the architecture (i.e., in response to a request to retrieve one or more emails that have already been processed (e.g., processing to receive journal copies, processing to retrieve message IDs, etc.)), and providing the API with one or more retrieved processing points associated with the requested one or more in-place emails in order to retrieve one or more of the requested in-place emails from one or more devices storing one or more of the in-place emails.

[0011] Aspects of the Disclosure may include an archiving system configured to manage an archive of email as in-place email within an enterprise architecture, and which facilitates the retrieval of in-place email, the archiving system may include a storage system and a server connected to the storage system by a network, the server including a processor, the processor configured to receive journal copies of email directed to the enterprise architecture, retrieve message identifiers (IDs) from the journal copies of email for management in a full-text index managed by the storage system, and provide the message IDs to an application programming interface (API) associated with the enterprise architecture in order to retrieve one or more processing points used by the enterprise architecture to process the journal copies in response to a request to retrieve one or more in-place emails from the enterprise architecture associated with the message IDs, and provide the retrieved one or more processing points associated with the requested one or more in-place emails to the API in order to retrieve one or more of the requested in-place emails from one or more devices storing one or more of the in-place emails.

[0012] Aspects of this disclosure may include a computer program for an archiving system that manages an archive of emails as in-place emails within an enterprise architecture and facilitates the retrieval of in-place emails, the computer program including instructions that include receiving journal copies of emails directed to the enterprise architecture, retrieving message identifiers (IDs) from the journal copies of emails to manage the journal copies in a full-text index, providing the message IDs to an application programming interface (API) associated with the enterprise architecture to retrieve one or more processing points used by the enterprise architecture to process the journal copies in response to a request to retrieve one or more in-place emails from the enterprise architecture associated with the message IDs, and providing the API with one or more retrieved processing points associated with the requested one or more in-place emails to retrieve one or more of the requested in-place emails from one or more devices storing one or more of the in-place emails. The computer program and instructions may be stored in a non-transient computer-readable medium and executed by one or more processors.

[0013] Aspects of the present disclosure may include an archiving system for managing an archive of emails as in-place emails within an enterprise architecture and for facilitating the retrieval of in-place emails, the archiving system may include means for receiving journal copies of emails directed to the enterprise architecture, preferably means for retrieving message identifiers (IDs) from the journal copies of emails to manage the journal copies in a full-text index, and means for providing the message IDs to an application programming interface (API) associated with the enterprise architecture in order to retrieve one or more processing points used by the enterprise architecture to process the journal copies in response to a request to retrieve one or more in-place emails from the enterprise architecture associated with the message IDs, and means for providing the API with one or more retrieved processing points associated with the requested one or more in-place emails in order to retrieve one or more of the requested in-place emails from one or more devices storing one or more of the in-place emails. [Brief explanation of the drawing]

[0014] [Figure 1] This figure shows an exemplary enterprise architecture configured to manage user emails, with an exemplary implementation. [Figure 2] This figure shows an example of an in-place email acquisition and archiving system with an exemplary implementation. [Figure 3(a)] This diagram shows an exemplary flow for creating an in-place email acquisition and archiving system with an exemplary implementation. [Figure 3(b)] This diagram shows an exemplary flow for retrieving in-place emails using an exemplary implementation. [Figure 4(a)] This figure illustrates exemplary management information managed by an archiving system for archiving journal copies, based on an exemplary implementation. [Figure 4(b)] This figure illustrates exemplary management information managed by an archiving system for archiving journal copies, based on an exemplary implementation. [Figure 4(c)] This figure illustrates exemplary management information managed by an archiving system for archiving journal copies, based on an exemplary implementation. [Figure 4(d)] This figure shows an example implementation of an in-place email archiving system and a user interface for facilitating the retrieval of in-place emails. [Figure 4(e)] This figure shows an example implementation of an in-place email archiving system and a user interface for facilitating the retrieval of in-place emails. [Figure 4(f)] This figure shows an example implementation of an in-place email archiving system and a user interface for facilitating the retrieval of in-place emails. [Figure 4(g)] This figure shows an example implementation of an in-place email archiving system and a user interface for facilitating the retrieval of in-place emails. [Figure 4(h)] This figure shows an example implementation of an in-place email archiving system and a user interface for facilitating the retrieval of in-place emails. [Figure 4(i)] This figure shows an example implementation of an in-place email archiving system and a user interface for facilitating the retrieval of in-place emails. [Figure 4(j)]A diagram showing an example of an in-place email archive system and a user interface for facilitating the retrieval of in-place emails according to an exemplary implementation. [Figure 4(k)] A diagram showing an example of an in-place email archive system and a user interface for facilitating the retrieval of in-place emails according to an exemplary implementation. [Figure 4(l)] A diagram showing an example of an in-place email archive system and a user interface for facilitating the retrieval of in-place emails according to an exemplary implementation. [Figure 4(m)] A diagram showing an example of an in-place email archive system and a user interface for facilitating the retrieval of in-place emails according to an exemplary implementation. [Figure 5] A diagram showing an exemplary system to which the archive system can be applied.

Best Mode for Carrying Out the Invention

[0015] The following detailed description provides details of the figures and exemplary implementations of the present application. Reference numerals and descriptions of redundant elements between the figures are omitted for clarity. The terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatically" may include fully automatic or semi-automatic implementations with user or administrator control for certain aspects of the implementation, depending on the desired implementation of those skilled in the art practicing the implementation of the present application. The selection can be made by the user via a user interface or other input means, or can be implemented by a desired algorithm. The exemplary implementations described herein can be used alone or in combination, and the functions of the exemplary implementations can be implemented by any means according to the desired implementation.

[0016] FIG. 1 shows an exemplary enterprise architecture configured to manage a user's electronic mail according to an exemplary implementation from the prior art. In an exemplary implementation, electronic mail may be sent from the Internet to an enterprise architecture implemented by an enterprise. An enterprise architecture, which may also be described or referred to as an "electronic mail system" or an "electronic mail architecture", may be a combination of hardware and / or software to facilitate the sending and / or receiving of electronic mail. The enterprise architecture may include one or more servers for receiving and processing electronic mail. The first electronic mail received by the enterprise architecture is known as a journal copy, and the journal copy is sent and received using the MIME protocol as a standard to facilitate transmission between the sender and the recipient and between the Internet.

[0017] The enterprise architecture receives the journal copy and performs processing to determine the destination end user. Depending on the underlying client used by the enterprise architecture, the journal copy determines the end user, generates an electronic mail to be delivered to the end user in a format compliant with the underlying electronic mail client interface, and is processed to send the electronic mail to the end user. After the processing is completed, the journal copy is discarded.

[0018] In the example shown in Figure 1, the journal copy received by the enterprise architecture includes three types of end-user recipients: direct recipients (indicated in the To: field), carbon copy recipients (indicated in the CC: field), and blind carbon copy recipients (indicated in the BCC: field). The email generated for each end-user may differ depending on the enterprise architecture. For example, direct recipients and carbon copy recipients are unaware of the existence of blind carbon copy recipients, and therefore this information is removed when generating emails directed to them. Furthermore, blind carbon copy recipients also receive emails generated for them, but typically there is nothing in the generated email to indicate that it is a blind carbon copy. In the example in Figure 1, multiple processing points may be configured for, or include, at least one of the following tasks: generating emails for each user, sending the emails to the appropriate server (if necessary) to trigger delivery of the emails to end users, and sending the emails to the appropriate virtual storage space that facilitates the user's email client interface or software, or to the user device. Multiple processing points may be provided by hardware and / or software.

[0019] Depending on the implementation of the enterprise architecture, emails may be stored locally on a user device that facilitates the user's email client interface or software, or they may be stored in a storage system that facilitates a dedicated virtual storage space for each end user within the enterprise for user access. These emails are referred to herein as folder copies, and folder copies are managed by the user in their original location, either on the end-user device or in a dedicated virtual storage space.

[0020] To facilitate analysis or regulatory compliance, relevant technologies may replicate folder copies to a storage system for archiving purposes. When the volume of email is excessive, a database containing email metadata may be required or used in relevant technologies as an index for indexing emails replicated to the archive.

[0021] Figure 2 shows an example of an in-place email retrieval and archiving system with an exemplary implementation. In the exemplary implementation described herein, journal copies received in the enterprise architecture are also transferred to the proposed in-place email retrieval and archiving system. The journal copies are then processed to generate a full-text index of all content within the journal copies, thereby enabling management of the journal copies in the full-text index. Each text string within the journal copy, e.g., each paragraph / word / etc., is associated with the index for later retrieval, as described herein. To trace the history from the receipt of the journal copy to the generation of emails for end-user recipients and the delivery of emails to end-user recipients, information that may be metadata about the execution of the processing point, such as the processing point ID and execution time, is extracted at each processing point and used for processing the journal copies. Processing points may be managed by an application programming interface (API) in the enterprise architecture.

[0022] Figure 3(a) shows an exemplary flow for creating an in-place email retrieval and archiving system with an exemplary implementation. In 300, the archiving system receives a journal copy. In 301, the archiving system generates a unique identifier for the journal copy for indexing in a full-text index and associates this unique identifier with each text string in the journal copy, e.g., each paragraph, each word, etc. Preferably, the text string may have a predetermined number of characters, and more preferably, the text string may correspond to “words”. In the exemplary implementation described herein, the unique identifier can be generated based on the message identifier (ID) of the journal copy, or the message ID can be extracted to the server from the journal ID as a unique identifier in more detail. In 302, the archiving system generates information used to reconstruct the journal copy and associates it with the unique identifier. The information used to reconstruct the journal copy may include, for example, any information indicating the location of text strings in the journal copy and / or any information indicating how to organize the text strings. In response to a 303 error, the journal copy is subsequently deleted by the archiving system. In most implementations of enterprise architectures, due to the burden of storing large volumes of email, the enterprise architecture may also delete the journal copy after it has been processed, which can significantly reduce the size of the archive (data).

[0023] Figure 3(b) shows an exemplary flow for retrieving in-place email with an exemplary implementation. To facilitate this functionality, the enterprise architecture's API is configured to associate the message ID of a journal copy with the processing point used to generate and deliver the email to the underlying user, such associations are shown as possible in Figures 4(a)–4(c), and in particular in Figure 4(b). In 311, the message ID is provided to the API by a request to retrieve the processing point. Each enterprise architecture has its own version of processing point, and different architectures may have different terminology. For example, graph ID is a term used by several such enterprise architectures, and some enterprise architectures may have a built-in or configurable API known as a graph API configured to retrieve such processing points. Tracking processing points can be done in various ways depending on any desired implementation. For example, in an exemplary implementation that includes a graph API, the graph API can generate a record (e.g., in the form of metadata or other information) for each processing point used to generate and deliver the email to the end user, and associate such record with the message ID for future retrieval. In another exemplary implementation, a custom-built API or other record (e.g., a stack trace) may also be used to track each processing point used and generate an appropriate record (e.g., in the form of metadata or other information) to be associated with the message ID for future retrieval. In yet another exemplary implementation, depending on the configuration of the enterprise architecture, each processing point may be configured to generate a record (e.g., in the form of metadata or other information) to be collected by the API or other function to be associated with the message ID for future retrieval.

[0024] In step 312, the API returns the processing point to the archive system. Depending on the desired implementation, the archive system may then provide a user interface to facilitate the selection of relevant underlying emails for selection. After such selections have been made, in step 313, the archive system provides the API with the corresponding processing point, along with a request to retrieve the underlying email associated with the corresponding processing point. In step 314, the API retrieves the underlying email from the user device across the provided processing points and provides this email to the archive system.

[0025] Figures 4(a) to 4(c) illustrate exemplary management information managed by an archiving system for archiving journal copies, in an exemplary implementation. While Figures 4(a) to 4(c) show examples of tables for organizing information, it should be noted that other forms of data organization, such as arrays, metadata with vectors of information, etc., may also be used. Specifically, Figure 4(a) shows an exemplary full-text index in an exemplary implementation. The full-text index is an index of all text strings, such as words, processed by the archiving system, and the unique identifier of the processed journal copy that contained the words. Figure 4(b) shows an exemplary table in an exemplary implementation for managing the association of information associated with each processing point to the unique identifier. Figure 4(c) shows an exemplary table for managing the association of generated information used to reconstruct a journal copy from the full-text index, which may be used by one or more algorithms to reconstruct the journal copy.

[0026] Figures 4(d) to 4(m) show examples of an in-place email archiving system and user interfaces for facilitating in-place email retrieval, according to a desired implementation. Here, as shown in the images below, there are many options incorporated for the purpose of efficient searching. A user interface configured to perform in-place email searching is provided, as shown in Figure 4(d). Searches can be performed using various fields such as keywords, from / to fields / carbon copy fields / blind carbon copy fields, dates, or departments. Figure 4(e) shows an exemplary user interface, including the expansion of the drop-down boxes in Figure 4(d), according to an exemplary implementation. Keyword searching offers multiple options for searching based on all and word proximity, as well as on the exact phrases present in the email content.

[0027] Figures 4(f) and 4(g) show examples of user interfaces for searching by keyword or flag, and for filtering emails by specifying sender, recipient, or both. In exemplary implementations, users can also filter emails based on date, date range, or department. Further options may include, but are not limited to, attachments, metadata, etc., to facilitate enhanced search and filtering options that may be used in complex e-discovery requirements.

[0028] Figure 4(h) shows an example of a user interface for displaying in-place email search results. More specifically, Figure 4(h) shows the search results in response to a search request made according to the provided search criteria. In this exemplary implementation, the search results provide a preview of creating a workspace for retrieving the email, but depending on the desired implementation, it may also provide part or all of the full text of the email.

[0029] Figures 4(i) and 4(j) show an example user interface for creating an in-place email workspace, based on an exemplary implementation. In the exemplary implementation described herein, the user can provide details for creating a workspace from which to retrieve in-place emails, such as a name or description, or the retrieved in-place emails may also be provided to an existing workspace. Other options, such as create and save options, are also available.

[0030] Figure 4(k) shows an example of a user interface for facilitating permission to access in-place email, using an exemplary implementation. Because in-place email is stored either directly on the user's device or in a virtual space created by an enterprise architecture email application to maintain the user's email and address, sufficient authorization credentials must be provided to retrieve email from the source.

[0031] Figures 4(l) and 4(m) illustrate an example user interface for performing a global task of selectively archiving in-place emails from search results, using an exemplary implementation. In this example, after a workspace is created, the workspace may be opened for selecting a summary of save options to indicate the progress of the emails regarding whether they were successfully archived, staged, saved, deleted, or if an error occurred during archiving. In the image above, 1000 emails from the search results have been successfully archived. In-place emails can be searched by leveraging a full-text index and then retrieving them when requested with respect to selective archiving, via the user interface described herein. Thus, such exemplary implementations enable enterprise architecture emails to be maintained in their original location, searchable, and retrieved only when requested, thereby saving storage and processing resources compared to creating duplicate archives of emails and attempting to search for emails through the enterprise architecture system.

[0032] Because all text within the journal copy is fully indexed, searching and retrieving emails can be significantly faster than crawling all emails stored in the enterprise architecture using the enterprise architecture's internal search capabilities. This allows users to bypass the enterprise architecture in response to requests for email retrieval from regulatory bodies or e-discovery compliance. Furthermore, the full-text index can be traversed for data analysis purposes as needed.

[0033] Furthermore, because all text within the journal copy is fully indexed, the actual emails delivered to end users can be maintained in their original location, in contrast to storing cloned copies within the enterprise architecture for regulatory purposes. Therefore, such exemplary implementations can significantly reduce enterprise storage costs, as a backup storage system is not required.

[0034] To reconstruct a journal copy in response to a query, the archiving system is configured to extract all words associated with a specific unique identifier and then reconstruct the journal copy using the information generated for this purpose. According to a preferred implementation, one or more algorithms configured to reconstruct the journal copy based on the generated information may be used, and these algorithms may be any type of text recovery algorithm known in the art. For example, if the generated information indicates the position of each text string in the original message, the text strings are assembled to their respective corresponding positions. In another exemplary implementation, the generated information may not be necessary for certain text recovery algorithms that do not require such information, such as machine learning-based algorithms. For example, a machine learning-based algorithm, such as LLM, may be used, which may be configured to predict the original message from a corpus of text strings such as words, based on learning from a database of emails.

[0035] Furthermore, information associated with the processing points of the journal copy is also indexed and retained, so such information can be used to generate mock copies of the email as they would be received by each end user. To generate mock copies of the email as they would be received by each end user, the reconstructed journal copy is then processed by a simulated execution of the processing points based on the information associated with the processing points, generating mock copies of how the email would appear to each end user recipient. The mock copies are then provided for regulatory compliance purposes. If the original email is required, such emails can be readily provided by the enterprise through the enterprise architecture, as the underlying end user and email content are known. In situations such as when the underlying in-place email has been deleted by the end user, mock copy generation can also be used to restore the email content. This is because tracking the underlying in-place email through the processing points fails to retrieve the in-place email. In this example, a notification or other alert (e.g., via the interface described herein) indicating that the underlying in-place email has been deleted may be provided, and a mock copy may be generated in response to an instruction to retrieve the email. Thus, even if the in-place email is deleted, the email content of the underlying delivered in-place email can be restored.

[0036] Figure 5 shows an exemplary system to which an archiving system may be applied. The exemplary system may include one or more servers 500 connected to one or more storage systems 502 via a network 501. One or more servers 500 are configured to receive journal copies and information associated with each processing point used to process the journal copies, by executing the flowchart shown in Figure 3, and to process the journal copies for storage in the management information shown in Figures 4(a) to 4(c). One or more servers 500 may be configured to receive queries for retrieving emails (e.g., by word content, by user, by timestamp, etc.), and then process the queries to retrieve such information from the storage systems.

[0037] Each of the one or more servers may include one or more processors 510, memory 511, input / output (I / O) interfaces 512, and local storage 513. According to a preferred implementation, the one or more processors 510 may be implemented using any hardware processor or any combination of hardware and software processors, such as a central processing unit (CPU), graphics processing unit (GPU), or tensor unit. The memory 511 may include local access memory, such as read-only memory (ROM) or random access memory (RAM), to facilitate the preferred functionality of the one or more servers. The input / output (I / O) interfaces 512 are used to interface one or more servers 500 to the Internet or other networks connecting the archive system to an enterprise architecture, and to interface one or more servers 500 to one or more storage systems 502 via network 501. The local storage 513 may include flash memory, hard disk drives, or other types of non-transient storage to facilitate various software functions to one or more servers 500. In one example, software stored in the local storage 513 to facilitate the function of performing the function outlined in Figure 3 may be loaded into memory 511 and executed by one or more processors 510. In the exemplary implementation described herein, some of the management information described in Figures 4(a) to 4(c) is initially stored in the local storage 513 and then destaged to one or more storage systems 502 at a later time.

[0038] Network 501 can be any form of network used to facilitate connectivity, such as a storage area network (SAN), local area network (LAN), or wide area network (WAN), depending on the desired implementation.

[0039] Each of the one or more storage systems may include one or more processors 520, memory 521, I / O interface 522, and storage 523. According to a preferred implementation, the one or more processors 520 may be implemented using any hardware processor or any combination of hardware and software processors, such as a central processing unit (CPU), graphics processing unit (GPU), or tensor unit. The memory 521 may include local access memory, such as read-only memory (ROM) or random access memory (RAM), to facilitate the desired functions of the one or more storage systems. The input / output (I / O) interface 522 is used to interface the one or more storage systems 502 with one or more servers 500 via a network 501. The storage 523 may include any storage architecture to facilitate the storage system's storage, such as solid-state drives (SSDs) or hard disk drives, according to a preferred implementation. Storage 523 may be configured to store some or all of the management information shown in Figures 4(a) to 4(c) in order to facilitate the functions described herein.

[0040] Processor 520 is configured to manage mail archives as in-place mail within an enterprise architecture, and can be configured to facilitate the functionality of an archiving system that facilitates the retrieval of in-place mail, and can be configured to execute methods or computer instructions which perform: receiving journal copies of mail directed to the enterprise architecture; retrieving message identifiers (IDs) from the journal copies of mail for management in a full-text index managed by a storage system; providing the message IDs to an application programming interface (API) associated with the enterprise architecture in order to retrieve one or more processing points used by the enterprise architecture to process one journal copy from multiple journal copies corresponding to a message ID in response to a request to retrieve one or more in-place mail from the enterprise architecture associated with one message ID from multiple journal copies; and providing the retrieved one or more processing points associated with the requested one or more in-place mail to the API in order to retrieve the requested one or more in-place mail from one or more devices storing one or more of the in-place mail.

[0041] As shown in Figure 2, one or more devices may include one or more user devices that manage one or more in-place emails. Depending on the desired implementation, one or more user devices may further include a mail server or other enterprise server that facilitates email functionality and storage for one or more users in the virtualized system.

[0042] The processor 520 can be configured to perform methods or computer instructions as described herein, and may be further configured to generate a full-text index of journal copies using message IDs in a database managed by the storage system, and to perform methods or instructions for deleting journal copies.

[0043] Depending on the desired implementation, one or more of the requested in-place emails may include blind carbon copy emails.

[0044] The processor 520 can be configured to perform the methods or instructions described above, and can be further configured to perform methods or instructions for providing a user interface configured to facilitate email searching, and in response to a search request performed through the user interface, the processor can be configured to perform methods or instructions for retrieving message IDs associated with the search request, and a request to retrieve one or more in-place emails from the enterprise architecture is made in the user interface from message IDs among multiple retrieved message IDs associated with the selection of emails among multiple emails.

[0045] Depending on the desired implementation, the user interface can be configured to perform text-based email searches, where this text is searched against a full-text index of in-place emails managed within the archive system's database, and the full-text index of in-place emails is associated with the corresponding message ID.

[0046] Depending on the desired implementation, this text may be one or more of the following: text in the email body, sender, direct recipient, carbon copy recipient, or blind carbon copy recipient.

[0047] Depending on the desired implementation, the user interface can be configured to search emails by attachment, which are then searched against a full-text index of in-place emails managed within the archiving system's database, and the full-text index of in-place emails is associated with the corresponding message ID.

[0048] The archiving systems described herein allow emails to be stored in their original location (i.e., in a virtual space assigned to the user or on an end-user device) without the need for clone copies. Furthermore, queries can be directed to the archiving system instead of the enterprise architecture, and these queries can trace the location where the emails are stored without the need to perform analysis, retrieve email content based on search parameters, reconstruct emails by generating simulated copies of emails received by the user for compliance purposes, or go through the enterprise architecture. In addition, because a full-text index of journal copies exists, such archiving systems can handle broader search queries than those available through the enterprise architecture. For example, a search query such as "Show all emails about 'Project X' sent to user Y by blind carbon copy between dates A and B" can be processed by the archiving system much faster than the enterprise architecture due to the full-text index, unique identifiers, and retrievable processing points.

[0049] Part of the detailed explanation is presented with respect to algorithms and symbolic representations of computer operations. These algorithmic descriptions and symbolic representations are means used by those skilled in data processing technology to communicate the essence of innovative technologies to others skilled in the art. An algorithm is a set of defined steps that lead to a desired final state or final result. In exemplary implementations, the steps performed require the physical manipulation of tangible quantities to achieve a tangible result.

[0050] As is evident from the description, unless otherwise explicitly stated, descriptions using terms such as “processing,” “calculating,” “calculating,” “determining,” and “displaying” throughout the description are understood to include the operations and processes of a computer system or other information processing device that manipulate data represented as physical (electronic) quantities in the registers and memory of a computer system to convert it into other data similarly represented as physical quantities in the memory or registers or other information storage devices, transmission devices, or display devices of a computer system.

[0051] Exemplary implementations may also relate to apparatus for performing the operations described herein. This apparatus may be specifically constructed for a required purpose, or may include one or more general-purpose computers that are selectively operated or reconfigured by one or more computer programs. Such computer programs may be stored on computer-readable media, such as computer-readable storage media or computer-readable signal media. Computer-readable storage media may include, but are not limited to, tangible media such as optical disks, magnetic disks, read-only memory, random-access memory, semiconductor devices and drives, or any other type of tangible or non-transient media suitable for storing electronic information. Computer-readable signal media may include media such as carrier waves. The algorithms and representations presented herein are not inherently related to any particular computer or other apparatus. Computer programs may include pure software implementations containing instructions for performing the operations of the desired implementation.

[0052] Various general-purpose systems may be used with programs and modules according to the examples herein, or it may be convenient to construct more specialized devices to perform steps of a desired method. In addition, the exemplary implementations are not described with reference to any particular programming language. It will be understood that various programming languages ​​may be used to implement the techniques of the exemplary implementations described herein. Instructions in a programming language may be executed by one or more processing devices (e.g., a central processing unit (CPU), a processor, or a controller).

[0053] As known in the prior art, the aforementioned operations can be performed by hardware, software, or any combination of software and hardware. Various embodiments of the exemplary implementations may be implemented using circuits and logic devices (hardware), while other embodiments may be implemented using instructions stored on a machine-readable medium (software), which, when executed by a processor, cause the processor to execute a method for performing the implementation of the present application. Furthermore, some exemplary implementations of the present application may be performed solely in hardware, while other exemplary implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit or distributed across multiple components in any number of ways. When executed by software, the method may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer-readable medium. If necessary, the instructions may be stored on the medium in a compressed and / or encrypted form.

[0054] Furthermore, other implementations of the Application will become apparent to those skilled in the art from the examination herein and the practical application of the Art of this Application. Various aspects and / or components of the exemplary implementations described herein may be used individually or in any combination. This Specification and the exemplary implementations are intended to be considered merely examples, and the true scope and idea of ​​the Application are shown by the following claims.

[0055] Based on the above disclosures, for example, Figures 3(a), 3(b), 4(a), 4(b), 4(c) and their descriptions, it can be understood that: Journal ID and message ID may be substantially synonymous. With respect to journal ID (message ID), one or more processing points may be associated with the journal ID.

[0056] The reorganization information identified from the reorganization index shown in Figure 4(c) (e.g., R1) may include information corresponding to each processing point (e.g., D1, D4, D8, etc.) associated with the journal (e.g., the journal with journal ID "J1"). The journal copy may be reorganized using the information associated with each processing point contained in the reorganization information. Such reorganization can be performed when the underlying in-place email is deleted. The functionality for such reorganization may allow the user to generate a simulated copy of the email.

[0057] The full-text index may have a list of journal IDs for each word (an example of a text string). The following processes may be performed: The enterprise architecture may receive a word as an email search keyword entered by the user. The enterprise architecture may identify the journal ID corresponding to the received (entered) word from the full-text index shown in Figure 3(a). The enterprise architecture may provide the identified journal ID (message ID) to the API shown in 311 of Figure 3(b).

[0058] The API that receives the message ID (journal ID) via 311 and the API that receives the processing point via 313 may be the same. The purpose of returning the processing point to the user may be to generate a simulated execution of the processing point to generate a simulated email when the email cannot be retrieved, or to selectively use the processing point in situations where multiple emails have been delivered but only one is needed. It is sufficient that the API is associated with the enterprise architecture.

[0059] The enterprise architecture may receive a processing point corresponding to the message ID (sent journal ID) in 312. Returning the processing point is optional. Alternatively, it may retrieve all emails associated with the message ID and processing point. Furthermore, it may be possible to generate a mock email using the processing point. (Addendum 1) A method for an archiving system that manages email archives as in-place email within an enterprise architecture and facilitates the retrieval of said in-place email, The recipient receives one or more journal copies of emails addressed to the aforementioned enterprise architecture. In particular, to manage the journal copies in a full-text index, one or more message identifiers (IDs) are extracted from one or more journal copies of the email. In response to a request to retrieve one or more of the in-place emails from the enterprise architecture associated with one message ID from the plurality of message IDs, The steps include providing the message ID to an application programming interface (API) associated with the enterprise architecture in order to retrieve one or more processing points used by the enterprise architecture to process one journal copy from the plurality of journal copies corresponding to the message ID, and The steps of providing the API with the retrieved processing points associated with the requested in-place emails, in order to retrieve the requested in-place emails from one or more devices storing the requested in-place emails, method. (Addendum 2) The method according to Appendix 1, wherein the one or more devices include one or more user devices that manage one or more of the in-place emails. (Addendum 3) The method according to Addendum 1, further comprising the steps of generating the full-text index of the journal copy using the message ID in the database and deleting the journal copy. (Addendum 4) The method according to Appendix 1, wherein the requested one or more of the in-place emails include a blind carbon copy email. (Addendum 5) The steps include providing a user interface configured to facilitate searching the aforementioned emails, and further including, in response to a search request made through the user interface, retrieving a message ID from among the plurality of message IDs associated with the search request, The method according to Appendix 1, wherein the request to retrieve one or more of the in-place emails from the enterprise architecture is made in the user interface from the message IDs of the retrieved multiple message IDs associated with the selection of the emails among the multiple emails. (Addendum 6) The method according to Addendum 1, wherein the user interface is configured to perform a text search of the email, the text is searched against the full-text index of the in-place email managed in the database of the archiving system, and the full-text index of the in-place email is associated with a corresponding message ID. (Addendum 7) The method according to Appendix 6, wherein the text is one or more of the text in the body of the email, the sender, the direct recipient, the carbon copy recipient, or the blind carbon copy recipient. (Addendum 8) The method according to Addendum 1, wherein the user interface is configured to search for the email by attachment, the attachment is searched against a full-text index of the in-place email managed in the database of the archiving system, and the full-text index of the in-place email is associated with a corresponding message ID. (Addendum 9) An archiving system configured to manage email archives as in-place email within an enterprise architecture, and which facilitates the retrieval of said in-place email, Storage systems, and Servers connected to the storage system via the network The server is equipped with, A processor configured to perform the following: Receiving one or more journal copies of emails directed to the aforementioned enterprise architecture, For management in a full-text index managed by the storage system, one or more message identifiers (IDs) are retrieved from one or more journal copies of the email. In response to a request to retrieve one or more of the in-place emails from the enterprise architecture associated with one of the multiple message IDs, To provide the message ID to an application programming interface (API) associated with the enterprise architecture in order to retrieve one or more processing points used by the enterprise architecture to process one journal copy from the multiple journal copies corresponding to the message ID, and To retrieve the requested one or more in-place emails from one or more devices storing the one or more of the in-place emails, provide the API with the retrieved one or more processing points associated with the requested one or more of the in-place emails. Archive system. (Addendum 10) The archiving system described in Appendix 9 includes one or more user devices that manage one or more of the in-place emails. (Addendum 11) The archive system according to Appendix 9, wherein the processor is configured to generate the full-text index of the journal copy using the message ID in a database managed by the storage system, and to delete the journal copy. (Addendum 12) One or more of the requested in-place emails, including blind carbon copy emails, are archived in the archiving system described in Appendix 9. (Addendum 13) The processor is further configured to provide a user interface configured to facilitate searching the email, and in response to a search request made through the user interface, the processor is further configured to retrieve a message ID associated with the search request. The archive system described in Appendix 9, wherein the request to retrieve one or more of the in-place emails from the enterprise architecture is made in the user interface from the message IDs of the retrieved message IDs associated with the selection of the emails among the multiple emails. (Addendum 14) The archive system as described in Appendix 9, wherein the user interface is configured to perform a text search of the emails, the text being searched against the full-text index of the in-place emails managed in the database of the archive system, and the full-text index of the in-place emails is associated with a corresponding message ID. (Addendum 15) The aforementioned text is one or more of the text in the body of the email, the sender, the direct recipient, the carbon copy recipient, or the blind carbon copy recipient, as described in Appendix 14 of the archiving system. (Addendum 16) The archiving system described in Appendix 9, wherein the user interface is configured to search for the email by attachment, the attachment is searched against a full-text index of the in-place email managed in the database of the archiving system, and the full-text index of the in-place email is associated with a corresponding message ID.

Claims

1. A method for an archiving system that manages email archives as in-place email, which are emails maintained in their original location within an enterprise architecture, and facilitates the retrieval of said in-place email, The step of receiving one or more journal copies of emails directed to the enterprise architecture, In order to manage the journal copies in a full-text index, the steps include: for each of the one or more journal copies of the email, retrieving from the journal copy the message identifier (ID) which is the journal ID that the journal copy has; In response to a request to retrieve in-place email associated with one of multiple message IDs from the enterprise architecture, The steps include providing the message ID to the application programming interface (API) of the enterprise architecture in order to extract one or more processing points in the process from receiving a journal copy corresponding to the message ID to delivering the email to an end-user recipient, The steps of providing the API with the retrieved one or more processing points associated with the requested in-place email in order to retrieve the requested in-place email from one or more devices, and The steps include receiving the requested in-place email from the API that has received one or more processing points retrieved, How to do it.

2. The method according to claim 1, wherein the one or more devices include one or more user devices that store one or more in-place emails.

3. The method according to claim 1, further comprising the steps of generating the full-text index of the journal copy using the message ID in the database, and deleting the journal copy.

4. The method according to claim 1, wherein the requested in-place email includes a blind carbon copy email.

5. The steps include providing a user interface configured to facilitate searching the aforementioned emails, and further including retrieving a message ID from among the plurality of message IDs associated with the search request in response to a search request made through the user interface, The method according to claim 1, wherein the request to retrieve the in-place email from the enterprise architecture is made in the user interface from a message ID among the retrieved message IDs associated with the selection of an email among the multiple emails.

6. The method according to claim 5, wherein the user interface is configured to perform a text search of the email, the text is searched against the full-text index of the in-place email managed in the database of the archiving system, and the full-text index of the in-place email is associated with a corresponding message ID.

7. The method according to claim 6, wherein the text is one or more of the text in the body of the email, the sender, the direct recipient, the carbon copy recipient, or the blind carbon copy recipient.

8. The method according to claim 5, wherein the user interface is configured to search the email by attachment, the attachment is searched against a full-text index of the in-place email managed in a database of the archiving system, and the full-text index of the in-place email is associated with a corresponding message ID.

9. An archiving system configured to manage email archives as in-place emails, which are emails maintained in their original location within an enterprise architecture, and which facilitates the retrieval of such in-place emails, Storage systems, and Servers connected to the storage system via the network The server is equipped with, A processor configured to perform the following: Receiving one or more journal copies of emails addressed to the enterprise architecture, For management in a full-text index managed by the aforementioned storage system, for each of the one or more journal copies of the email, the message identifier (ID), which is the journal ID of the journal copy, is retrieved from the journal copy. In response to a request to retrieve in-place email associated with one of multiple message IDs from the enterprise architecture, To extract one or more processing points in the process from receiving a journal copy corresponding to the message ID to delivering the email to an end-user recipient, the message ID is provided to the application programming interface (API) of the enterprise architecture. To retrieve the requested in-place email from one or more devices, provide the API with the retrieved one or more processing points associated with the requested in-place email, and Receiving the requested in-place email from the API that has received one or more processing points retrieved, Archive system.

10. The archiving system according to claim 9, wherein the one or more devices include one or more user devices for storing one or more in-place emails.

11. The archiving system according to claim 9, wherein the processor is configured to generate the full-text index of the journal copy using the message ID in a database managed by the storage system, and to delete the journal copy.

12. The archiving system according to claim 9, wherein the requested in-place email includes a blind carbon copy email.

13. The processor is further configured to provide a user interface configured to facilitate searching the email, and in response to a search request made through the user interface, the processor is further configured to retrieve a message ID associated with the search request. The archiving system according to claim 9, wherein the request to retrieve the in-place email from the enterprise architecture is made in the user interface from a message ID among the retrieved message IDs associated with the selection of an email among a plurality of emails.

14. The archiving system according to claim 13, wherein the user interface is configured to perform a text search of the emails, the text being searched against the full-text index of the in-place emails managed in the database of the archiving system, and the full-text index of the in-place emails being associated with a corresponding message ID.

15. The archiving system according to claim 14, wherein the text is one or more of the text in the body of the email, the sender, the direct recipient, the carbon copy recipient, or the blind carbon copy recipient.

16. The archiving system according to claim 13, wherein the user interface is configured to search for the email by attachment, the attachment is searched against a full-text index of the in-place email managed in a database of the archiving system, and the full-text index of the in-place email is associated with a corresponding message ID.

Images