CN102143126B - The access method of CPM meeting history record and message storage server - Google Patents

Abstract

The invention discloses a method for accessing CPM conversation history records and a message storage server. In the above method, the message storage server receives the access instruction from the client, wherein the access instruction carries a tag classification identifier; the message storage server executes the access operation corresponding to the access instruction according to the tag classification identifier. According to the technical solution provided by the present invention, it is further possible to reduce overhead and improve user experience when providing users with multiple conversation logic views.

Description

CPM meeting history access method and message storage server

technical field

The present invention relates to the communication field, in particular, to a method for accessing a Converged IP Messaging (CPM for short) conversation history record and a message storage server.

Background technique

The Converged IP Messaging (CPM for short) enabler proposed by the OMA organization can span different access networks and is built on a unified IP core network to support end-user one-to-one, one-to-one Communication of various media types (eg, text, pictures, audio/video clips, binary files, audio/video streams) between multiple and multiple applications.

In a converged message communication environment, the CPM enabler provides CPM services to users in units of CPM talks to enable them to exchange information. Record and store on the side, so that when needed, you can send a request to the server on the network side to access the historical interaction record information of the CPM talks you have participated in, and truly reproduce the entire process of the talks that the user has participated in. The user's own conversation history information stored on the server on the network side is managed.

The CPM message storage server provides CPM users with the above-mentioned function of storing CPM meeting history records, and the CPM message storage client accesses and manages the CPM meeting history records and related contents belonging to the CPM user by accessing the message storage server, and through The meeting history information acquired by the network side is analyzed, and the view and content of the meeting are displayed to the CPM user.

A CPM session describes the operation of information interaction between communicating parties using the CPM enabler functional entity. A CPM session consists of any number of CPM messages, CPM files, and CPM sessions that are exchanged outside the session. Wherein, a CPM message is an information body that may contain multiple discrete (discontinuous) media (for example, text, pictures, audio clips, video clips, etc.). A CPM file is one or more files carrying multimedia content exchanged between participants. The file transfer process can only begin after the recipient user agrees to receive the file. A CPM session refers to a logical connection between two or more participants for a period of time, which can be used for participants to exchange continuous media in real time, and can also be used to exchange discrete media and files. CPM message exchange and CPM file transfer can be performed within the CPM session or outside the CPM session. It is generally believed that each CPM session contains only one CPM session in a specific time, but users can participate in multiple CPM sessions in parallel.

A CPM meeting history is a stored representation of a CPM meeting. Authorized responsible persons can obtain and store the information they exchanged during the CPM conversation, and store the above information as a CPM conversation history record in the message storage server provided by the CPM service provider. At this time, a CPM message exchanged outside the CPM session is stored as a CPM message record, and a CPM file transfer performed outside the CPM session is stored as a CPM file transfer history record. A CPM session is stored as a CPM session history record (including data such as intra-session CPM messages, intra-session CPM file transfers, and intra-session interactive continuous media segments). Therefore, in terms of storage representation, the CPM conversation history can be described as a collection of CPM message records, CPM file transfer history and CPM session history. Please refer to Figure 1 for details.

Figure 1 is a schematic diagram of the relationship between the CPM talks and the historical records of the CPM talks and the contents contained therein. The CPM meeting history recording function is actually to record the CPM messages exchanged during the CPM meeting, the CPM file transfer and the CPM session conducted. In order to realize the meeting history recording function, there needs to be a CPM functional entity on the network side that can be located on the signaling plane and the media plane at the same time during the communication process, as a B2BUA to receive all signaling messages and media messages during the communication process, and extract them through analysis Record the information that needs to be recorded according to a certain format: record a CPM message interacted outside the CPM session as a CPM message record file, record a CPM file transmitted outside the CPM session as a CPM file transmission history file , to record a CPM session as a CPM session history file. The CPM participation function server completes the above-mentioned meeting history record function, and submits the above-mentioned record file to the CPM message storage server for permanent storage.

What are actually stored as physical files on the message storage server are CPM message records, CPM file transfer history records and CPM conversation history records included in the CPM conversation history records. The message storage server shall manage the resources related to the stored meeting history records, and support the following functions:

(1) store CPM message records, CPM file transfer history records, CPM session history records, CPM conversation history records, including any media objects that are part of CPM message records and CPM session history records;

(2) According to the CPM user preference or the service provider's strategy, synchronize the locally stored resources with the locally stored resources of the message storage client, including synchronous management in a multi-device scenario;

(3) Management (for example, copy, delete, etc.) and access to stored resources; query stored resources; based on service provider policies and user preferences, record the operations performed by the responsible person on network storage (for example, upload/download/ modify/delete CPM messages, CPM file transfer history, CPM session history, CPM conversation history, and specific entries such as media objects that are part of the CPM message and CPM session history), etc.

In the related art, in order to store messages, a storage model scheme based on a traditional electronic mailbox structure can be referred to in FIG. 2 . Each user has a storage area pre-allocated by the service provider. Under this directory, there are a series of independent folders (such as inbox, trash box, outbox, etc.) and user folders predefined by the system. Self-created independent folders (such as Folder1, Folder2, etc.). Using this storage model, message records and session history records can be stored in any directory, and users can manually move the stored content between folders.

However, the above scheme has the following disadvantages:

(1) CPM message records and CPM session history records can be distributed in any folder. In order to provide users with a view of the CPM conversation, it is necessary to use additional metadata to separate the CPM message records and CPM records scattered in each directory. Session history records are associated with the CPM session they belong to.

(2) Since CPM message records and CPM session history records can be distributed in arbitrary folders, the server cannot support message storage. The client requests the server to build a linear view for the conversation history records through the IMAP/THREAD command ([RFC5256]), however For mobile devices with limited computing and storage resources, completing the operation of building a linear view will bring a large overhead and burden, which may cause slow response speed and other adverse effects on user experience.

(3) Since the CPM message records and CPM session history records belonging to a CPM meeting may be distributed in different folders, the message storage client needs to continuously pass the IMAP/SELECT command when obtaining the content related to a CPM meeting history record Select a folder, and then use the IMAP/FETCH command to obtain the record files stored in this folder, and then re-SELECT another folder to obtain the record files stored in this folder, and repeat until all the CPM talks are obtained. Content, the operation of constantly using the SELECT command to open the folder increases the number of command interactions between the message storage client and the server, and there is additional overhead, especially for mobile devices, frequent redundant command interactions will increase the data on the wireless interface traffic, increase the cost of using the service for users, and reduce the experience of using the service for users.

(4) Some management operations of the user may destroy the linear view of the CPM meeting. Under the above storage model, users can perform arbitrary management operations on the resources stored on the message storage server, for example, delete a certain message record file, but the result is to destroy the reply relationship between messages, thereby destroying the CPM session linear view.

In the related art, there is also a storage model solution based on the CPM session structure, as shown in FIG. 3 for details. As shown in Figure 3, this scheme designs the message storage model of CPM based on the structural characteristics of CPM talks: that is, according to the containment relationship among CPM talk history records, CPM message records and CPM session history records, each CPM talk history record The included recording resource files are stored in separate talks subfolders.

In this storage model solution, the message storage server allocates a dedicated storage area for each CPM user, and establishes a corresponding subfolder for each CPM session under the storage area, and each session included in the CPM session The CPM message outside the session is stored as an independent message record file, and each CPM session is stored in the session subfolder as an independent CPM session history record. The creation of the meeting folder is completed by the system, and the user's management authority is limited, and he can only view the resources on the message storage server to prevent the user's operation from destroying the CPM meeting view.

Based on the message storage model of the CPM conversation structure, the record resources belonging to the same CPM conversation are stored in the same conversation folder, which saves metadata and maintenance for recording the relationship between the history of the CPM conversation and the record resources it contains The management operation overhead for this relationship. Moreover, the creation of the meeting folder is performed by the CPM enabler, and the user's operation authority is limited, thus ensuring that the view of the CPM meeting will not be destroyed by the user's operation.

However, the above scheme has the following disadvantages. Since the meeting folder is managed by the message storage server, the user has no operation authority, so the user cannot manage the resources stored on the message storage server, cannot create custom folders, and cannot move/copy Message records and session history files can only be viewed in the chat view, which has a poor user experience.

Contents of the invention

The present invention is proposed in view of the problems in the related art that the operation of constructing a linear view will bring relatively large overhead and burden, and that the user cannot manage the resources stored on the message storage server. Therefore, the main purpose of the present invention is to A method for accessing CPM conversation history records and a message storage server are provided to solve at least one of the above problems.

According to one aspect of the present invention, a method for accessing CPM session history records is provided.

The method for accessing CPM conversation history records according to the present invention includes: the message storage server receives an access instruction from a client, wherein the access instruction carries a tag classification identifier; the message storage server executes an access operation corresponding to the access instruction according to the tag classification identifier.

According to another aspect of the present invention, a message storage server is provided.

The message storage server according to the present invention includes: a receiving unit, configured to receive an access instruction from a client, wherein the access instruction carries a tag classification identifier; an execution unit, configured to execute an access operation corresponding to the access instruction according to the tag classification identifier.

Through the present invention, the tags are classified and managed in the message storage server, and the access operations corresponding to the access instructions are executed according to the tag classification identification, which solves the problem that the operation of constructing a linear view in the related art will bring relatively large overhead and burden, and further It can reduce overhead and improve user experience while providing users with multiple logical views of the conversation.

Description of drawings

The accompanying drawings described here are used to provide a further understanding of the present invention and constitute a part of the application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations to the present invention. In the attached picture:

Figure 1 is a schematic diagram of the relationship between the CPM talks and the historical records of the CPM talks and their contents;

FIG. 2 is a schematic diagram of a message storage model based on a traditional electronic mailbox structure;

Fig. 3 is a schematic diagram of a message storage model based on a conversation structure;

FIG. 4 is a flow chart of a method for accessing CPM conversation history records according to an embodiment of the present invention;

5 is a schematic structural diagram of a message storage model solution according to an embodiment of the present invention;

FIG. 6 is an architecture diagram of a message storage framework according to an embodiment of the present invention;

Fig. 7 is a schematic structural diagram of meeting metadata XML document organization according to an embodiment of the present invention;

FIG. 8 is a schematic structural diagram of tag metadata XML document organization according to an embodiment of the present invention;

FIG. 9 is a schematic diagram of instruction transmission for the user to obtain an access control list operation according to an embodiment of the present invention;

FIG. 10 is a schematic diagram of instruction transmission for user setting access control list operations according to an embodiment of the present invention;

FIG. 11 is a schematic diagram of instruction transmission for user deletion of an access control list operation according to an embodiment of the present invention;

Fig. 12 is a schematic diagram of instruction transmission for the operation of obtaining access rights by a user according to an embodiment of the present invention;

Fig. 13 is a schematic diagram of instruction transmission for a user to select a folder to view according to an embodiment of the present invention;

FIG. 14 is a schematic diagram of command transmission for a user to select a conversation history record folder and view a CPM conversation record list according to an embodiment of the present invention;

Fig. 15 is a schematic diagram of instruction transmission according to an embodiment of the present invention in which the user selects a conversation history record and checks the detailed content of the CPM conversation history record;

FIG. 16 is a schematic diagram of instruction transmission for a user to view a tag classification view according to an embodiment of the present invention;

FIG. 17 is a schematic diagram of instruction transmission for creating a user-defined label according to an embodiment of the present invention;

FIG. 18 is a schematic diagram of instruction transmission for MSC to tag content according to an embodiment of the present invention;

Fig. 19 is a schematic diagram of instruction transmission for MSC to unlabel the record file stored in the meeting history record folder according to an embodiment of the present invention;

FIG. 20 is a schematic diagram of command transmission for MSC requesting to release all marked objects under a certain label classification and the label according to an embodiment of the present invention;

Fig. 21 is a schematic diagram of command transmission for MSC requesting to release all marked objects under a certain label classification and the label according to an embodiment of the present invention;

Fig. 22 is a schematic diagram of instruction transmission of a user's request to delete a conversation history record according to an embodiment of the present invention;

Fig. 23 is a schematic diagram of instruction transmission of a user's request to create a folder according to an embodiment of the present invention;

FIG. 24 is a flow chart of instruction transmission for the operation of moving/renaming a folder by a user according to an embodiment of the present invention;

Fig. 25 is a structural block diagram of a message storage server according to an embodiment of the present invention;

Fig. 26 is a structural block diagram of a message storage server according to a preferred embodiment of the present invention.

detailed description

Hereinafter, the present invention will be described in detail with reference to the drawings and examples. It should be noted that, in the case of no conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

According to an embodiment of the present invention, a method for accessing a history record of a fused IP message CPM conversation is provided.

FIG. 4 is a flowchart of a method for accessing CPM session history records according to an embodiment of the present invention. As shown in Figure 4, the access method of the CPM interview history record according to the embodiment of the present invention includes the following processing (step S402-step S404):

Step S402: the message storage server receives an access instruction from the client, wherein the access instruction carries a tag classification identifier;

Step S404: The message storage server executes the access operation corresponding to the access instruction according to the tag classification identifier.

Using the above method, the tags are classified and managed in the message storage server, and the access operations corresponding to the access instructions are executed according to the tag classification identification, which solves the problem that the operation of constructing a linear view in the related technology will bring relatively large overhead and burden, and then This can reduce overhead and improve user experience while providing users with multiple logical views of the conversation.

Preferably, before performing the above step S401, the following processing may also be included:

(1) The message storage server receives a tag metadata request message from the client;

(2) The message storage server sends part or all of the label classification identifiers to the client.

The user accesses the message storage server according to his own needs according to obtaining part or all of the tag classifications from the message storage server, which improves the user experience.

Preferably, before performing step S401, the following processing may also be included:

(1) Create a system management area in the message storage server, wherein the system management area includes a first storage unit for storing conversation history records and conversation metadata, wherein the conversation metadata is used to indicate the relationship between the conversation history records and the file directory to which they belong Descriptive information of association relationship and interview history;

(2) Create a user management area in the message storage server, wherein the user management area includes a second storage unit for storing user-defined information created by the user, and a third storage unit for storing label metadata, wherein the label metadata is used for Indicates the association relationship between the meeting history record and the tag classification identifier, and the association relationship between the custom information and the tag classification identifier.

Wherein, creating the user management area in the message storage server in the above step (1) may include the following processing:

(1) The message storage server receives the copy instruction from the client, wherein the copy instruction carries the information of the conversation history record that needs to be stored in the user management area;

(2) The message storage server copies the conversation history information that needs to be stored in the user management area from the system management area to the user-defined information in the user management area.

Wherein, creating the user management area in the message storage server in the above step (2) may also include the following processing:

(1) The message storage server receives the information from the local record file uploaded by the client;

(2) The message storage server stores the information of the local record file in the user-defined information in the user management area.

Through the above processing, it can be seen that the custom information mainly comes from two aspects, one is from the conversation history stored in the system management area, and the other is from the local record file uploaded by the user. The overall storage model architecture (including the user management area and the system management area) created above can be specifically referred to in FIG. 5 .

By creating the above storage model architecture, the user's message storage area on the message storage server is divided into a system management area and a user management area, which can satisfy users' custom management operations on record resources stored on the message storage server.

First, the message storage structure is described in conjunction with FIG. 6 . As shown in FIG. 6 , the storage framework of the message storage function is logically divided into three subsystems: client subsystem, storage subsystem, and application subsystem.

(1) The client subsystem (ClientSubsystem) includes: the message storage client, which can access and manage the data in the message storage server, and provide the user with the meeting history display function.

(2) Application Subsystem (ApplicationSubsystem) includes: CPM functional components related to the message storage function in the CPM network, for example, the CPM participation function meeting server.

(3) Storage Subsystem (StorageSubsystem): Realize the message storage function on the network side. This subsystem is divided into two layers: the adaptation layer and the physical layer. Among them, the physical layer is used to store actual data, that is, objects such as messages, session history, and file transfer history are stored on the disk according to a certain organizational structure. The organizational structure of the physical storage view is designed by the service provider and remains fixed; The adaptation layer is responsible for organizing the actual data stored in the physical layer into different logical views according to the different needs of the client. The client can define and change the logical view by itself (note that the physical storage view will not change), so that the network storage data can be stored according to Classification management is carried out in a user-defined way to meet the individual needs of users.

As shown in Figure 6, the CPM functional component (for example, the CPM participation function) in the application subsystem is responsible for storing the message class objects related to the CPM conversation into the network storage during the communication process of the message session, and organizing them according to the physical storage view, Stored in the specified directory; the storage subsystem manages and maintains the data stored in the physical layer, and provides a logical view to the outside through the adaptation layer. The CPM functional components in the client subsystem (for example, the message storage client) construct a custom logical view through the custom label behavior, and classify and manage the physically stored message objects, thereby realizing a variety of different user-defined dynamic views .

Among them, the physical storage locations of various resource contents on the physical layer are fixed and do not need to be changed. The folders created by the CPM service provider and the storage locations of various contents are fixed. With the function of applying labels on the message storage client, users can customize personalized labels, add these "labels" to various content stored on the server (equivalent to classifying them), and then store them on the server according to different labels. The content is organized into a logical view and presented to the user. The above operation of "adding" tags does not change the actual storage location of these contents on the server, which actually implements a layer of logical view superimposed on the physical storage view, and the user operates the logical view by managing "tags", making the physical storage The data can be provided in the way that suits you best, with great flexibility and scalability.

Below in conjunction with Fig. 5, describe the architecture of the message storage model of the physical layer, as shown in Fig. 5, assign a dedicated storage space (for example, create "Root-User" folder) for each legal user on the message storage server, It is used to store the resource records related to the conversation history owned by the user and provide management functions to the user.

Divide the user-specific storage space (corresponding to the "Root-User" directory) into two parts: the system management area and the user management area.

Among them, create a folder predefined by MSS in the system management area, as shown in Figure 5, "Conversation-History" (conversation history folder) is a folder predefined by MSS, which is dedicated to storing information related to the history of conversations. Record resources and maintain a unique backup on MSS to provide users with a view of the conversation.

Wherein, in the user management area, user-defined folders are created, such as "Folder1" and "Folder2" shown in FIG. 5 are folders created by users themselves. Users can "copy" the important CPM message records, CPM file transfer history records, and CPM session history records to a custom folder for separate storage in units of record files. In addition, the user can also upload local record files to a user-defined folder on the message storage server, and move the uploaded record files between different user folders.

In the "Conversation-History" folder it is possible to provide a logical view by manipulating tag metadata. Tag metadata is stored under the top-level folder (for example, "Root-User").

In the specific implementation process, a supporting metadata model (talk metadata and tag metadata) is defined for the message storage model. Wherein, the meeting metadata record provides summary description information of the CPM meeting history record. The label metadata is used to record the relationship between the "label" and the marked record object. The system can provide predefined labels to realize the system's predefined label classification view, and users can also define custom labels to realize user-defined labels. Customize the tabbed taxonomy view.

The two types of metadata stored in FIG. 5 are described below.

(1) Session metadata

Meeting metadata, used to record the description information of CPM meeting history records, and maintain the relationship between CPM message records, CPM file transfer history records, and CPM session history records and the CPM talks to which they belong, so as to provide a meeting view; meeting metadata and The "Conversation-History" folder is associated;

Since all CPM message records, CPM file transfer history records, and CPM conversation history records recorded by the CPM participation function during the conversation are directly stored in the "Conversation-History" folder on the MSS, in fact, the CPM conversation history records There is no actual physical storage structure corresponding to it, so the descriptive information of each CPM session must be provided through metadata. Preferably, the conversation metadata is stored under the "Conversation-History" folder.

Meeting metadata can be extracted from each record object file related to the meeting and stored as metadata. When presenting the meeting view to MSC (such as what meeting information the user owns, etc.), MSC needs to first request the meeting metadata from MSS Data, and then use these metadata to obtain the description information of the CPM talks stored on the MSS, so as to provide the user with a view of the talks.

The conversation metadata is associated with the "Conversation-History" folder, and is used to provide the association between the record files stored in the folder and the CPM conversations it belongs to, and to provide description information for the CPM conversation history records. Preferably, the conversation metadata (Conversation.xml) can be stored in the form of an XML document to record the description information of the CPM conversation. The organizational structure of the conversation metadata XML document is shown in FIG. 7 below.

As shown in Figure 7, the XML document of the conversation metadata takes the <Conversation> element as the root element, under which there are multiple <ConvID> sub-elements named after the conversation identifier, and each such sub-element represents a conversation history Description of the record.

Among them, the <ConvID> sub-element can be divided into multiple sub-elements, which are used to describe the history of the CPM conversation: <Start-Time> sub-element: record the start time of the CPM conversation; <End-Time> sub-element Element: record the end time of the CPM meeting; <Subject> sub-element: record the subject information of the CPM meeting; <Initiator> sub-element: record the initiator address information of the CPM meeting; <Participants> sub-element: record the CPM meeting The address information of the participants, under this element, the address of each participant is recorded separately through multiple <entry> elements; <Content-UID> sub-element: record the UID of each record file contained in the CPM meeting (UID is determined by MSS allocation, folder scope); <Thread-Result> sub-element: records the result string of the linear sorting of the session history by MSS. Due to the scheme of storing all conversation history records under "Conversation-History", the client cannot use the THREAD command to request linear sorting results from the server. In order to solve this problem, add this record item in the conversation metadata information table , store the result of the linear sorting of the conversation by the server as metadata, and the message storage client can obtain the linear sorting result of the specified conversation through the GETMETADATA command.

Preferably, when the MSS receives the CPM message records, CPM file transfer history records, and CPM session history records submitted by the CPM participation function, it should first analyze them, obtain the meeting identifiers of these record objects, and query the "metadata XML of the meeting" Does the corresponding <ConvID> sub-element already exist in , if no corresponding <ConvID> sub-element is found, it means that this is a new CPM meeting, and a new <ConvID> needs to be added for the CPM meeting in the meeting metadata XML document > sub-element, and extract relevant information from the received record object to fill in each sub-element under the <ConvID> element.

The conversation metadata XML document is described below in conjunction with an example. In the conversation metadata XML document, description information of two conversation history records whose conversation identifiers are ConvID1 and ConvID2 are recorded.

The following describes the access operation of the conversation metadata (for example, acquiring the conversation metadata associated with the "Conversation-History" folder).

Preferably, obtaining the conversation metadata associated with the "Conversation-History" folder includes but is not limited to the following processing: MSC can request the MSS to obtain the conversation metadata of the "Conversation-History" folder through the IMAP4/GETMETADATA command ([RFC5464]) data. Among them, the command format is as follows:

GETMETADATA <"name of the specified folder"><(option)><(specified metadata table or field name in the table)>

Among them, <the name of the specified folder> parameter, gives the name of the target folder that MSC wants to obtain metadata, here should be set to the "Conversation-History" folder;

<(option)> parameter: Use the DEPTH option to expand the range of returned metadata. When the DEPTH option is set to "Infinity", it means to return the values of all fields in the specified metadata table.

<(specified metadata table or field name in the table)> parameter: the format is "/shared/XML document name/XML element name", which is used to specify the name of the target metadata XML document that MSC wants to obtain metadata and the Which XML element in the XML document.

For example, when the MSC requests all metadata of the CPM conversation history from the MSS, the following command is used: GETMETADATA "Conversation-History" (DEPTHInfinity) (/shared/conversation/).

For example, if the MSC only wants to obtain the metadata information of a certain field of a specific record item, such as the conversation subject information of the conversation history record with the conversation identifier "ConvID3", the MSC can use the following command: GETMETADATA "Conversation-History "(/shared/conversation/convID3/Subject).

Among them, the conversation metadata associated with the "Conversation-History" folder is managed by MSS, and MSC cannot modify it, but can only be accessed in a read-only state.

(2) Tag metadata

Preferably, the label classification identification includes at least one of the following: a system predefined label classification identification and a user-defined label classification identification.

In the specific implementation process, the tag metadata is associated with the root folder "Root-User", providing the association between "user-defined tags" or "system predefined tags" and the tagged content, so that the message can be The record objects stored on the memory are classified according to the user's needs, and a dynamic logical view is provided for the user.

In the embodiment of the present invention, the tag metadata (Tag.xml) is stored as an example in the form of an XML document. Preferably, the tag metadata can also be organized in other forms (for example, a database) to record "tags" and marked records Relationships between objects. For example, see FIG. 8 for an organization chart of a tag metadata XML document.

As shown in Figure 8, the tag metadata XML document takes the <TagList> element as the root element, under which there are multiple <TagName> sub-elements named after "tag name", and each such sub-element represents a tag Classification, this element can be divided into multiple <FileFolderName> sub-elements named after the folder where the marked record object is located, and each such sub-element represents a folder (it can be a "Conversation-History" system folder, or a user-defined folder), each marked record object under this element is a <Seq> sub-element.

The following description is combined with an example. An example of a tag metadata XML document is as follows:

In the label metadata XML document shown in the above example, four types of labels are recorded: "SendBox", "ReceivedBox", "Important", and "CPM", among which "SendBox" and "ReceivedBox" are predefined labels of the system. The content under the two label elements is automatically written by MSS. MSS takes the meeting as a unit, and puts the history records of the CPM talks initiated by the user into the "SendBox" label, and the CPM talks that the user accepts the invitation to participate in The history is grouped in the "ReceivedBox" tab. That is to say, even if the user does not create any label classification, the system can also provide the user with the predefined "inbox" and "outbox" label classification views by default.

The "Important" and "CPM" tags are custom tags created by users. When users browse the contents of the user folder or the "Conversation-History" folder, they can record a CPM message or a CPM file stored in the target folder. Transfer history records and CPM session history records are marked with custom tags, and they are classified into user-defined tag categories. When MSS receives the user's tag request, it will modify the tag metadata XML document and add related XML elements to Record the association between the label and the marked record object.

As shown in the above example: the "Important" tag marks two record files with UIDs 11 and 3 in the "Conversation-History" folder, and a conversation history record with the conversation identifier ConvID1. In addition, it also marks Two record files with UIDs 11 and 5 in the user folder "Working". And the "CPM" label only marks a record file with UID 11 in the user folder "Study".

The following describes the access operations of tag metadata:

Preferably, obtaining the label metadata associated with the "Root-User" folder includes the following processing: MSC can request the MSS to obtain the label metadata associated with the "Root-User" folder through the IMAP4/GETMETADATA command ([RFC5464]) . Among them, the format of the command is as follows: GETMETADATA <"name of the specified folder"><(option)><(specified metadata table or field name in the table)>

The <name of the specified folder> parameter gives the name of the target folder that MSC wants to obtain metadata, here it should be set to "/", indicating that the CPM user logs in to the root directory "Root-User" folder;

<(option)> parameter: Use the DEPTH option to expand the range of returned metadata. When the DEPTH option is set to "Infinity", it means to return the values of all fields in the specified metadata table.

<(specified metadata table or field name in the table)> parameter: the format is "/shared/XML document name/XML element name", which is used to specify the name of the target metadata XML document that MSC wants to obtain metadata and the Which XML element in the XML document. For example, set the CPM tag metadata XML document as TagList.xml.

For example, when MSC requests all tag metadata from MSS, use the following command: GETMETADATA“/”(DEPTHInfinity)(/shared/TagList/);

For example, if MSC only wants to get all the record objects associated with a certain tag (such as "Important" tag), MSC can use the following command: GETMETADATA "/" (DEPTHInfinity) (/shared/TagList/Important/).

Preferably, since MSC is able to modify the tag metadata associated with the "Root-User" folder, the tag metadata associated with the "Root-User" folder can be set, for example, user "Create Tag", "Delete Label", "Add label to record object", "Unlabel record object" and other operations. The MSC is required to request modification of tag metadata from the MSS using the IMAP4/SETMETADATA command ([RFC5464]). The format of the command is as follows: SETMETADATA <"name of the specified folder"><(specified metadata table or the value set by the field name in the table)>

<name of the specified folder> parameter, give the name of the user folder that MSC wants to set metadata, here should be set to "/", which means that the CPM login root directory "Root-User" folder;

<(the specified metadata table or the value set by the field name in the table)> parameter: it is a value pair in the form of (entryvalue), where "entry" specifies the table where the metadata that MSC wants to modify is located and the corresponding field name, and "value" indicates the value you wish to set. The specific format of the "entry" part is "/shared/XML document name/XML element".

For example, when MSC requests to create a new tag category "Important", use the following command: SETMETADATA "/" (/shared/TagList/Important/"")

For example, if MSC requests to mark the record file with UID 11 stored in the folder "Conversation-History" with the "Important" tag, use the following command: SETMETADATA "/"(/shared/TagList/Important/Conversation-History/s1 "11");

For example, when MSC requests to remove the "Important" tag for the record file with UID 11 stored in the "Conversation-History" folder, use the following command: SETMETADATA "/"(/shared/TagList/Important/Conversation-History/ s1NIL);

For example, if MSC requests to disassociate all marked objects under the "Important" label classification with this label, use the following command: SETMETADATA "/"(/shared/TagList/Important/*NIL);

For example, if MSC requests to delete the tag category "Important", use the following command: SETMETADATA "/" (/shared/TagList/ImportantNIL).

Preferably, before the message storage server receives the access instruction from the client, the method may further include the following processing:

(1) The message storage server receives the request message of the tag metadata from the client;

(2) The message storage server sends part or all of the label classification identifiers to the client.

Wherein, the access control authority of the client defines the ability of the user to access and manipulate the folder on the message storage server and the resources stored in the folder. Whenever a user requests to manipulate the resources stored on the message storage server (that is, when executing different operation commands), it is necessary to check the access control authority of the requester to the corresponding resource. Only when certain permissions are met, the message storage Only the server can perform related operations, otherwise the message storage server will reject the requesting party's request command and return an error response message.

According to the definition in [RFC4314ACL Extension], the above access control rights can refer to the access control list (ACL), where ACL is a set of <AccessIdentifiers, rights> value pairs, "AccessIdentifiers" identifies the responsible person, and "rights" identifies the corresponding What access control permissions does the responsible person have. An ACL applies to a "mailbox" (ie folder).

[RFC4314] defines the following access control permissions for folders on the IMAP4 server and resources under the folders, and is identified by different permission identifiers, for example:

l: lookup, indicating that the folder can be listed, that is, it can be accessed by LIST, LSUB, and SUBSCRIBE commands;

r: read, indicating that the folder is readable and can be accessed by SELECT and STATUS commands;

s: Keep the seen/unseen flag information in the session, you can set or clear the \SEEN flag through the STORE command;

w: write, indicating that the folder is writable, you can set or clear other marks except \SEEN and \DELETED through STORE, or set other marks except \SEEN and \DELETED through APPEND and COPY commands;

i: insert, indicating that the folder can be operated by APPEND and COPY commands;

k: createmailboxes, which means that you can use the CREATE command to create sub-folders of any level under this folder, or use the RENAME command to move/rename the folder;

x: deletemailboxes, indicating that the folder can be deleted by the DELETE command, or the source folder can be deleted by the RENAME command;

t: deleteMessages, the \DELETED mark can be set or cleared for the files under the folder through the STORE operation, and the \DELETED mark can be set through the APPEND/COPY command;

e: The delete operation can be performed through the EXPUNGE command;

a: administer, which can execute SETACL, DELETEACL, GETACL, LISTRIGHTS and other commands to manage the access control list;

In the specific implementation process, the folders on the message storage server can be divided into two different types: (1) folders created by the system, such as "Root-User" root directory folder, and "Conversation-History" conversation history Record folder; (2) Folders created by users, such as "Folder1", "Folder2" and so on;

When MSS creates a folder, it will first assign certain permissions to the folder, and then the user's operations on the folder should be performed according to the permissions. Of course, depending on the folder created by the system request and the folder created by the user request, the MSS assigns different permissions to it.

For example, assign user access control permissions to system-level folders. CPM users mainly view system folders, and other operations such as modification, deletion, and movement should be restricted to prevent user misoperations from affecting the integrity of CPM session history records. destruction. So for system-level folders, you can assign the following access rights: l, r, etc. System folders cannot be assigned the following access rights: x, k, etc.

When assigning access control permissions to user-defined folders, because users have full access control permissions to the folders they create, all permission identifiers can be assigned, and users can also follow the regulations and procedures of [RFC4314] through SETACL, DELETEACL, GETACL, LISTRIGHTS and other commands are used to manage various access control permissions of user-defined folders, that is, to give other CPM users the ability to access related permissions of user-defined folders.

The following describes the user's "operation of obtaining access control list", "operation of setting access control list", "operation of deleting access control list" and "operation of obtaining access authority" in combination with four embodiments, wherein the above operations are all for users For security reasons, the system folder does not assign "a" (administer) permission to the user, so the user cannot manage the access control list of the system folder.

Embodiment 1: User obtains access control list operation

If the user wants to obtain the access control list of a certain user folder, according to the regulations in [RFC4314], the MSC constructs the IMAP4/GETACL command, specifies the name of the target folder, and requests the MSS for the access control list of the target folder, specifically See Figure 9.

The user requests the MSS for the access control list of the "Working" user folder. After receiving the command, the MSS checks whether the requesting user has the "a" permission for the target folder, that is, whether the permission of the access control list can be obtained. If it has this permission, MSS returns the access control list in the response message to the GETACL command, as shown in the above figure, the access control list shows that the user "Fred" has the "rwipslxetad" permission on the target folder, and the user "Chris" Have "lrswi" permissions on the target folder.

If the requester user does not have "a" permission on the target folder, the MSS should reject the requester's GETACL command with a failure response message.

Embodiment 2: User setting access control list operation

If the user wants to set the access control list of a user folder, such as granting certain permissions to another user, the MSC should construct the IMAP4/SETACL command according to the procedure specified in [RFC4314], and request the MSS to be the specified target Folders add access control permissions to a user, see Figure 10 for details.

The user requests MSS to add the access control authority "cda" to the target folder "Working" for another user "Chris". After MSS receives this command, it should first check whether the requesting user has the "a" permission on the target folder. If the requesting user has "a" permission on the target folder, then MSS will follow the request in the SETACL command as the target folder. In the access control list of the folder "Working", add the "cda" permission of the "Chris" user; if the requester user does not have the "a" permission for the target folder, MSS should reject the requester's SETACL command with a failure response message .

Embodiment 3: User deletes the access control list operation

If a user wants to delete another user's access control list for a certain user folder, the MSC should follow the procedure specified in [RFC4314] to construct an "IMAP4/DELETEACL" command, requesting the MSS to specify the user's access control for the target folder Delete the permission list, see Figure 11 for details.

The user requests the MSS to delete the access control permission list of another user "Fred" to the target folder "Working". After MSS receives this command, it should first check whether the requesting user has "a" permission on the target folder; if the requesting user has "a" permission on the target folder, then MSS will follow the request in the DELETEACL command as the target In the access control list of the folder "Working", delete all access control permissions of the "Fred" user; if the requester user does not have the "a" permission on the target folder, MSS should reject the requester's DELETEACL command with a failure response message .

Embodiment 4: User obtains access permission operation

If the user wants to know which access control rights a specific user has for the user folder he created, he can follow the regulations in [RFC4314], and the MSC constructs the "IMAP4/LISTRIGHTS" command to request the MSS to return the specified user's access to the target Folder access control permission list, see Figure 12 for details.

The user requests the MSS to obtain the access control permission list of the user "Smith" to the target folder "Working". After MSS receives this command, it should first check whether the requesting user has the "a" permission on the target folder; if the requesting user has the "a" permission on the target folder, then MSS will follow the request in the LISTRIGHTS In the access control list of the folder "Working", find all access control permissions of the "Smith" user and return it in the reply message to the LISTRIGHTS command; if the requesting user does not have the "a" permission on the target folder, MSS The requestor's LISTRIGHTS command SHOULD be rejected with a failure response message.

The user's message storage access operation mainly includes the following processing (operation 1 to operation 11):

In the specific implementation process, when a CPM user wishes to view the content stored on the MSS, he will first log in to the MSS (ie, the message storage server) using the MSC (ie, the above-mentioned client).

Step 1. The user uses MSC to log in to MSS;

Among them, MSC will use the IMAP4/AUTHENTICATE command or IMAP4/LOGIN command to authenticate with MSS according to the regulations and procedures of [RFC3501]. Only when the authentication is successful, MSC can access the resources on MSS. Access resources on MSS.

Preferably, the AUTHENTICATE command allows the MSC to use other authentication mechanisms to log in to the MSS instead of sending the user name and password in text format. When using this command, MSC must construct a valid AUTHENTICATE command according to the regulations and procedures in [RFC3501], and use a specific authentication mechanism in the <authenticationmechanismname> parameter.

Step 2: MSS will return a prompt string after receiving the command, prompting MSC to select an appropriate authentication method, if MSS does not support the authentication method suggested by MSC, it will return a NO response message. At this time the MSC must try to use other authentication methods until the LOGIN command is used.

Among them, the LOGIN command allows MSC to use textual user name and password to log in to MSS. Although this is not a good method, it is sometimes the only method that can be used between MSC and MSS. When using this command, MSC must construct an effective LOGIN command according to the regulations and procedures in [RFC3501], use the MSC user name in the <username> parameter, and use the password in the <password> parameter.

Step 3: After MSS receives the LOGIN command, it uses the user name and password for authentication. If the authentication is successful, it returns an OK response message. If the authentication fails, it returns a NO response message. If the parameters are wrong, it returns a BAD response message.

After the user logs into the message storage, if the user selects a certain folder (it can be a system folder or a user folder) to view, then MSC first constructs an IMAP4/SELECT command ([RFC3501]) to carry the information of the folder Name, request MSS to select the folder. MSS sets the target folder as the active folder after receiving the command.

As shown in Figure 13, if the user selects the "Conversation-History" folder, the MSC constructs the following SELECT command to request the MSS to set the folder as an active folder.

Likewise, users can also check a user folder to make it the active folder.

Operation 1. The user selects the interview history folder (system folder) to view the list of CPM interview records

Preferably, when the user needs to view the conversation history record information, the method may also include the following processing:

(1) The message storage server receives the session metadata information request instruction from the client, wherein the session metadata information request instruction carries the directory identification information to which the session metadata information belongs;

(2) The message storage server sends the metadata information of the conversation to the client for parsing and presentation.

In the architecture shown in Figure 2 above, all record objects are scattered in arbitrary folders, and no corresponding mechanism is defined to display "conversation history records". In the storage architecture shown in Figure 5, the session view can be provided through session metadata.

After the user logs in to MSS with MSC, the user will first obtain the list of available folders on the server, and the user will see the "Conversation-History" folder and the user folder on the interface. When the user wants to view the "Conversation-History" folder When there are interview history records, MSC shall request relevant description information of interview history records from MSS.

Since the meeting history record on MSS is not stored as an independent physical file, but the description information of the CPM meeting is recorded through the "metadata XML document of the meeting", the MSC should use the IMAP4/GETMETADATA command ([RFC5464]) to specify the target The name of the folder is "Conversation-History", and the metadata information of all the conversation history records recorded in the "conversation metadata XML document" is requested from the conversation history folder of MSS.

After the MSC obtains the description information related to the meeting, it analyzes and displays the CPM meeting history list on the client, thereby providing a meeting view.

Because the CPM talk is a logical concept, there is no actual physical storage entity corresponding to it, that is to say, the relevant descriptive information of the CPM talk (such as initiation time, end time, talk topic, participants, etc.) needs to come from the CPM message records, CPM file transfer history records, or CPM session history records included in the conversation. When MSC requests meeting summary information from MSS, it is impossible for MSS to parse these related record objects every time to obtain relevant information of CPM meeting. It is a better solution to record this information through metadata.

Therefore, in this solution, the MSC uses the extended GETMETADATA command of [RFC5264] to request the MSS to obtain the "metadata of the meeting", so as to obtain the description information of the meeting history records stored on the MSS, as shown in Figure 14.

After MSS receives the GETMETADATA request command, perform the following steps:

Step 1: Parse the command and extract the <target folder name> parameter as "Conversation-History", the <option> parameter as "DEPTHinfinity", and the <entry> parameter as "/shared/Conversation/";

Step 2: According to the name of the metadata file "Conversation", MSS queries the "conversation metadata XML document", obtains all the <ConvID> elements in the XML document and the content of all sub-elements under this element, and submits to MSC returns.

Preferably, the MSC obtains all the information of the effective CPM meeting information metadata table stored on the MSS through the response message of the GETMETADATA command returned by the MSS. As shown in Figure 9, the GETMETADATA command returns a series of value pairs <entry, value>, where entry indicates a field in the metadata table, and value is the value corresponding to the field. For example, "/shared/conversation/convID1/StartTime"2009/05/2218:00"" indicates that the conversation start time ("StartTime") of the CPM conversation history record with the conversation identifier "ConvID1" in the conversation information table is "2009/ 05/22 18:00". In this way, the MSC can obtain which talks are stored on the MSS and the summary information of these talks, and the MSC can display them to the user through the interface. For example, after the user selects a meeting folder, the summary information of all CPM talks stored under the meeting folder will be displayed in units of one line of records in the display area on the right.

Operation 2. The user selects a meeting history record to view the details of the CPM meeting history record

Preferably, after viewing the interview history record information, the method may further include the following processing:

(1) The message storage server receives the record object identification information from the client;

(2) The message storage server sends part or all information of the record object corresponding to the record object identification information to the client for presentation.

When the user obtains the meeting information list, he has obtained the relevant metadata information of the meeting through the IMAP4/GETMETADATA command, which includes the value of the <Content-UID> field, which records all the CPMs included in the CPM meeting Message records, CPM file transfer history records, UIDs of CPM session history files (unique storage identifiers on the MSS), using these UIDs, the MSC can obtain the CPM session related information from the MSS through the IMAP4/FETCH command ([RFC3501]) The header information or content information of all recorded files are presented locally.

During the specific implementation process, when a CPM user views the meeting information list, he may select one of the CPM meeting history records to view its detailed record content. Since MSC has acquired the name of the subfolder of CPM conversation history on MSS through the LIST command, MSC can select the corresponding conversation history subfolder through the IMAP4/SELECT command, and then through the IMAP4/FETCH command Obtain all the record files related to the CPM meeting under the folder, see Figure 15 for details.

As shown in Figure 15, after the MSC selects the corresponding meeting history subfolder through the IMAP4/SELECT command ([RFC3501]), it can request the MSS to obtain the CPM contained in the meeting through the IMAP4/FETCH command ([RFC3501]) Message record file, CPM file transfer history file and CPM session history file header or body part information, after MSS receives this command, obtains relevant information and returns it to MSC through FETCH response command.

The MSC stores the above information locally, analyzes it, and presents the content of the CPM meeting history to the user.

When a user browses the content of the CPM conversation history record, if he wants to view the content of a certain CPM message or the content of the media attachment carried by the CPM session history record, the MSC uses the FETCH command to carry the information of the message record file or the CPM session history file where the desired media attachment is located. The UID and the part number of the media attachment request data from the MSS. After receiving the command, the MSS analyzes it, obtains the corresponding data according to the UID and Part number and returns it to the MSC, and the MSC stores it locally and performs analysis and presentation.

Operation 3. The user views the label classification view

Preferably, when the access instruction indicates to view the tag classification view, the above step S404 may include the following processing:

(1) The message storage server receives a request message from the client for the content of the conversation history record, wherein the request message carries the file directory identifier and part or all of the record object associated with the label classification identifier. logo;

(2) The message storage server sends part or all of the content of the record object to the client for presentation.

In the specific implementation process, MSC requests "tag metadata" from MSS by constructing IMAP4/GETMETADATA commands, so as to know which tag categories are currently available on the server, and present various tag categories to users after parsing, as shown in Figure 16 for details.

As shown in Figure 16, through the response message returned by the MSS, the MSC will learn that there are currently three label categories on the server: "SendBox", "ReceivedBox" and "Important".

When the user specifies one of the label classifications and wants to view the label classification view, for example, if the "Important" label is selected, MSC will search in the label metadata obtained from the message storage server and find all the records associated with the "Important" label The folder where the object is located and the identifier information of the record object are shown in Figure 16. The objects associated with this label are: the record files with UID 11 and 3 located in the "Conversation-History" folder, and the conversation identifier is The conversation history of ConvID1, and the record files with UID 11 and 5 located in the "Working" folder.

Then MSC uses this information to request the content of the relevant record object from the message storage server through the combination of the SELECT command and the FETCH command, and after fetching it locally for analysis, the organization is displayed under the view of the label classification.

Preferably, if the user does not set any custom label, the system will provide two predefined views of "inbox" and "outbox" by default.

Operation 4. User edit label classification view

Preferably, when the access instruction indicates to edit the tag classification view, the above step S404 may include the following processing:

(1) The message storage server receives the editing instruction of the tag metadata from the client:

(2) The message storage server executes the editing operation corresponding to the editing instruction on the tag metadata.

In the specific implementation process, the user can create a custom label, add a label to the record object, remove the label from the record object, or delete the custom label. The above operations are all requested by the MSC to the MSS by constructing the IMAP4/SETMETADATA command "Tag metadata" to achieve, so that various logical views can be dynamically constructed.

Among them, before MSC initiates tag management operations, it must first obtain the latest "tag metadata" on the server through the IMAP4/GETMETADATA command, so that it can correctly modify the "tag metadata" on the MSS.

Preferably, the editing instruction is used to indicate at least one of the following: create a custom label, add a label to a record object in the label metadata, unlabel the record object in the label metadata, and delete a custom label. Describe below in conjunction with example respectively.

1. User-created custom labels

If the user creates a custom "Important" label, see Figure 17 for details. After receiving the request, MSS modifies the tag metadata XML document (TagList.xml) associated with "Root-User" and adds the <Important> element, as shown in the gray font part in the table below. <SendBox> and <ReceivedBox> tags are system predefined tags.

2. MSC requests to label the record file with UID 11 stored in the "Conversation-History" folder with the "Important" label.

Preferably, before this operation, MSC has obtained the latest "tag metadata" information on MSS through the IMAP4/GETMETADATA command, and MSC already knows that there is no tag object under the "Important" tag, so MSC will mark the tag A content (use s1 to denote the first marked object), as shown in Figure 18.

After receiving the request, MSS modifies the tag metadata XML document (TagList.xml) associated with "Root-User", and adds related sub-elements under the <Important> element, as shown in the gray part below.

3. The MSC requests to remove the "Important" label for the record file with UID 11 stored in the "Conversation-History" folder.

Preferably, the command as described in Figure 19 can be used:

After receiving the request, MSS modifies the tag metadata XML document (TagList.xml) associated with "Root-User", and deletes the relevant sub-elements under the <Important> element, as shown in the gray part below.

4. MSC requests to disassociate all marked objects under the "Important" label classification with this label.

Preferably, a command as described in FIG. 20 may be used.

After receiving the request, MSS modifies the tag metadata XML document (TagList.xml) associated with "Root-User", and deletes the relevant sub-elements under the <Important> element, as shown in the gray part below.

5. MSC requests to delete the label category "Important".

Preferably, the commands described in FIG. 21 can be used.

After receiving the request, MSS modifies the tag metadata XML document (TagList.xml) associated with "Root-User", and deletes the <Important> element and all the content under this element, as shown in the gray part below.

Users can dynamically modify the logical view by manipulating tags, and the record objects stored on the message storage server can provide multiple logical views according to the tag classification. When the user deletes the conversation history record under the "Conversation-History" folder, or deletes the record object under the user folder, and modifies the physical view, the label logic view will also be updated accordingly.

Operation 5. User deletes meeting history

Preferably, when the message storage server deletes a conversation history record in the system management area in response to a user instruction, the method may further include the following processing:

(1) The message storage server receives a conversation history record from the client and the identifiers of all its subordinate record objects;

(2) The message storage server deletes the description information corresponding to a conversation history record and all its subordinate record objects in the conversation metadata according to the identification of a conversation history record and all its subordinate record objects;

(3) In the tag metadata, the message storage server deletes the association relationship between a conversation history record and all its subordinate record objects and tag classification identifiers according to the identifiers of a conversation history record and all its subordinate record objects.

In the specific implementation process, when the user browses the meeting history list under the meeting history folder, if he wants to delete a whole meeting history record, MSC will use "IMAP4/STORE[UID-List]+FLAG(\Deleted )" command (UID-List indicates the list of UIDs of those record files to be deleted, separated by commas) to request MSS to delete the meeting history record and all the record files contained in the meeting history record.

Since the MSC has obtained the UIDs of all record files contained in the CPM meeting through the GETMETADATA command (obtained through the "Content-UID" field) when viewing the list of CPM meeting records, these UIDs can be used as IMAP4/SOTRE commands ([RFC3501 ]) UID list parameter. Please refer to Figure 22 for details.

MSS shall perform the following processing after receiving this command:

(1) MSS uses the UID list obtained from the STORE command to query the <Content-UID> sub-element of the "Conversation Metadata XML Document" in the "Conversation-History" folder, find the corresponding conversation history record item, and obtain the conversation history Recorded session identifier;

(2) Delete the corresponding <ConvID> element and all sub-elements contained in the "conversation metadata XML document" that describe the information of the conversation history;

(3) Set the FLAGS of the record object corresponding to the UID list carried in the STORE command to the "\Deleted" state, indicating deletion.

(4) Update the "Tag Metadata XML Document", use the conversation identifier of the deleted conversation history to search in each <Converstion-History> sub-element in the "Tag Metadata XML Document", set the value of the XML element to The session identifier XML element is removed, because modifications to the physical view require synchronous updates to the logical view.

After performing the above steps, if the operation is successful, MSS returns an operation success response message to MSC, MSC updates the local conversation view, and the "Conversation-History" folder no longer displays the content of the CPM conversation history record.

Operation 6. The user deletes the record objects under the custom file directory in the custom information in the user management area

Preferably, when the message storage server deletes the record object under the custom file directory in the custom information in the user management area in response to the user instruction, the method may also include the following processing:

(1) The message storage server receives the identification of the record object under the user-defined file directory from the client;

(2) In the tag metadata information, the message storage server deletes the association relationship between the record objects under the self-defined file directory and each tag classification identifier according to the identifiers of the record objects under the self-defined file directory.

In the specific implementation process, if the user wants to delete the record object in the user-defined folder, MSC should use the IMAP4/[STORE+flags\DELETED] command ([RFC3501]) to delete the specified record file. After receiving this command, MSS sets the FLAG of the corresponding record file to the \Deleted state, and then needs to update the "label metadata XML document" synchronously to ensure that the deleted record object will no longer appear in the label classification view .

Operation 7. The user deletes the custom file directory in the custom information in the user management area

Preferably, when the message storage server deletes the custom file directory in the custom information in the user management area in response to the user instruction, the method further includes the following processing:

(1) The message storage server receives the identification of the user-defined file directory from the client;

(2) The message storage server deletes the association relationship between the custom file directory and each tag classification identifier according to the identifier of the custom file directory in the tag metadata information.

In the specific implementation process, if the user wants to delete the entire user-defined folder, MSC should use the IMAP4/DELETE command ([RFC3501]) to delete the specified user folder. After receiving this command, MSS sets the FLAG of all record objects in the corresponding user folder to the \Deleted state, and needs to update the "tag metadata XML document" synchronously to ensure that the deleted record objects will not be deleted again. Appears in tabbed category view.

Operation 8. The user requests to create a folder operation

Users can create custom folders on MSS, but due to the limitation of operation rights, users have no right to create folders in the system management area, and can only create custom folders in the user management area.

MSC requests MSS to create a user-defined folder by constructing an IMAP4/CREATE command ([RFC3501]), and carries the name of the folder to be created by the user in the parameter <mailboxname> in the CREATE command. The name of the folder conforms to the standard Path naming rules, use slash (/) as the layer separator.

As shown in Figure 23, MSC uses the CREATE command to create a folder named "working/ims/cpm", and if the path does not exist, MSS will first create the working folder and ims folder in the user's login directory. Then create a cpm folder under the working/ims path.

When the MSC receives the OK response command from the MSS, it means that the operation of creating the folder is successfully completed, and the MSC presents the newly created folder locally. If the MSC receives a NO response command or a BAD response command from the MSS, it means that the folder creation operation fails and the specified folder cannot be created, and the MSC returns an error message to the user.

Operation 9. The user performs the operation of moving/renaming the folder

Due to the setting of operation rights, CPM users can only move/rename user folders, but not system folders.

Preferably, the MSC can request the MSS to rename a certain user folder through the IMAP4/RENAME command, or move the user folder from the file directory hierarchy to another new place.

The MSC shall generate the IMAP4RENAME request command according to the procedures and rules of [RFC3501], specifically as follows:

(1) According to the rules and procedures of [RFC3501], set the name of the source folder in the <existingmailboxname> parameter in the RENAME request command;

(2) Set the name of the target folder you want to move to in the <newmailboxname> parameter in the RENAME request command;

Preferably, the naming of the above two parameters conforms to the standard path naming rules, that is, except for paths beginning with a slash (/), all paths start from the user's login directory (that is, the storage space of the CPM user on the MSS root directory), the path levels are separated by slashes (/);

(3) After constructing the RENAME command, MSC shall send the command to MSS according to the rules and procedures in [RFC3501].

See Figure 24 for a specific example. As shown in Figure 24, MSC requests to rename the user folder named "Working" to "Study".

When the MSC receives the OK response command from the MSS, it means that the operation of moving/renaming the folder is successfully completed, and prompts the user for the operation result. When the MSC receives a NO response command or a BAD response command from the MSS, it means that the operation of moving/renaming the folder fails, and the MSC returns an error message to the user.

Operation 10. User request to search record object

MSC can search for qualified CPM message records or CPM session history records from active folders on MSS through search object operations according to certain search conditions.

The MSC shall generate the IMAP4SEARCH request command according to the procedures and rules of [RFC3501], where the procedures and rules are described as follows:

(1) According to the rules and procedures of [RFC3501], specify the character set type of the string appearing in the <searchcriteria> search condition parameter in the <optionalCHARSETSpecification> character set identification parameter in the SEARCH request command, which is represented by the word "CHARSET ” at the beginning of the registered character set identifier, the default identifier is US-ASCII, so this parameter is often omitted;

(2) Set the <searchcriteria> search criteria parameter of the SEARCH command to the specified keyword and value that you want to query. There can be one or more query criteria. For specific query keywords that can be used, please refer to [RFC3501];

(3) The search extension mechanism defined in [RFC5466] can be used to enhance search capabilities: a mechanism is defined to name and store search conditions on the IMAP server, and these named search conditions can be used in future SEARCH operations or It is quoted as a search condition parameter in other commands;

(4) The search extension mechanism defined in [RFC5182] can be used to enhance the search capability: through this extension, the client can have such a pipeline mechanism that can use the result of the SEARCH command as the input of other subsequent commands, which can improve performance. optimize on

(5) The search extension mechanism defined in [RFC4731] can be used to enhance the search capability: extend the IMAPSEARCH command and UIDSEARCH command so that the client can control what information is returned. The following result set options are defined: min, max, all emails found, number of emails found;

(6) The search extension mechanism defined in [RFC5032] can be used to enhance the search capability: the IMAPSEARCH operation is extended WITHIN, allowing the IMAPSEARCH operation to return emails within or outside a specific time interval;

(7) After constructing the SEARCH command, MSC shall send the command to MSS according to the rules and procedures in [RFC3501].

When the MSC receives the OK response command from the MSS, it means that the search object operation is successfully completed, and the MSC extracts the search structure from the response message and displays it to the user. When the MSC receives a NO response command or a BAD response command from the MSS, it means that the search operation fails, and the MSC returns an error message to the user.

Operation 11. The user requests to copy the record object

Record files stored in the "Conversation-History" folder, such as CPM message records, CPM file transfers, CPM conversation history records, etc., users can copy these record files to the user folder. In addition, for those record files stored in the user folder, the user can also copy them to another user folder. However, due to the limitation of the operation authority, the user cannot copy the record object to the system folder, and the copy operation is based on the file, that is, the media object in the record file cannot be copied.

MSC constructs the IMAP4/COPY command, executes the UID of the file to be copied and the name of the target folder, and requests MSS to perform the copy operation.

According to an embodiment of the present invention, a message storage server is also provided.

Fig. 25 is a structural block diagram of a message storage server according to an embodiment of the present invention. As shown in FIG. 25 , the message storage server includes: a receiving unit 1 and an executing unit 2 .

The receiving unit 1 is configured to receive an access instruction from a client, wherein the access instruction carries a tag classification identifier;

The execution unit 2 is configured to execute the access operation corresponding to the access instruction according to the tag classification identifier.

In the above-mentioned message storage server, the tags are classified and managed, and the access operations corresponding to the access instructions are executed according to the tag classification identification, which solves the problem that the operation of building a linear view in the related technology will bring a large overhead and burden, and then it can be used for Reduce overhead and improve user experience when users are provided with multiple logical views of a conversation.

Preferably, the above message storage server may further include a first storage unit 3 , a second storage unit 4 , and a third storage unit 5 . Wherein, the first storage unit 3 is used to store the interview history record and the interview metadata, wherein the interview metadata is used to represent the association relationship between the interview history record and the file directory to which it belongs and the description information of the interview history record; the second storage unit 4. It is used to store the custom information created by the user; the third storage unit 5 is used to store the tag metadata, wherein the tag metadata is used to represent the relationship between the meeting history record and the tag classification identifier and the custom information The association relationship with the tag classification identifier.

By establishing the above storage architecture, user-defined management operations on record resources stored on the message storage server can be satisfied.

Preferably, the above-mentioned message storage server may also include: a copy unit 6, which is used to copy the information of the conversation history record that needs to be stored in the user management area from the first storage unit to the custom information of the second storage unit; the acquisition unit 7. It is used to acquire the information of the local record file uploaded by the client and store it in the custom information of the second storage unit.

Therefore, users can copy the records in the system management area to realize custom management.

Preferably, the above-mentioned message storage server may also include: an authentication unit 8, connected to the receiving unit 1, for checking the authority of the client to request access to the file information; a determination unit 9, connected to the authentication unit 8 and Between the execution unit 2, it is used to determine that the client has access control authority to the requested file information.

Therefore, the security of the access operation can be guaranteed, and the system reliability can be improved.

For the working mode of the combination of the units in the above-mentioned device, refer to the descriptions in Fig. 4 to Fig. 24 , which will not be repeated here.

To sum up, through the above-mentioned embodiments of the present invention, the technical solution provided defines a storage model suitable for the characteristics of the meeting history records in the converged message service communication environment, and at the same time satisfies the user's requirements for the record resources stored on the message storage server. In addition to custom management operations, it can also provide users with a variety of views, such as the meeting view (viewing the meeting history in units of CPM talks), the linear view of the meeting (constructed according to the reply-replied relationship), and the system Predefined views (such as views according to the relationship between sending and receiving, subject classification) and user-defined views (user-defined folders, and adding interested record files or part of the content of record files to the custom folders), in On the premise of reducing the management overhead of the message storage server as much as possible, it can provide users with a good business experience.

Obviously, those skilled in the art should understand that each module or each step of the above-mentioned present invention can be realized by a general-purpose computing device, and they can be concentrated on a single computing device, or distributed in a network formed by multiple computing devices Alternatively, they may be implemented in program code executable by a computing device so that they may be stored in a storage device to be executed by a computing device, and in some cases, in an order different from that shown here The steps shown or described are carried out, or they are separately fabricated into individual integrated circuit modules, or multiple modules or steps among them are fabricated into a single integrated circuit module for implementation. As such, the present invention is not limited to any specific combination of hardware and software.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims (18)

1. A method for accessing a fusion of IP message CPM conversation history records, characterized in that, comprising: The message storage server receives an access instruction from the client, wherein the access instruction carries a tag classification identifier; The message storage server executes an access operation corresponding to the access instruction according to the tag classification identifier; Wherein, before the message storage server receives the access instruction from the client, it also includes: A system management area is created in the message storage server, wherein the system management area includes a first storage unit storing interview history records and interview metadata, wherein the interview metadata is used to indicate that the interview history records are related to The association relationship of the file directory to which it belongs and the description information of the interview history; A user management area is created in the message storage server, wherein the user management area includes a second storage unit for storing custom information created by users, and a third storage unit for storing label metadata, wherein the label metadata It is used to indicate the association relationship between the conversation history record and the tag classification identifier, and the association relationship between the custom information and the tag classification identifier. 2 . The method according to claim 1 , wherein the label classification identification includes at least one of a system predefined label classification identification and a user-defined label classification identification. 3. The method according to claim 1, wherein creating the user management area in the message storage server comprises: The message storage server receives the copy instruction from the client, wherein the copy instruction carries the information of the conversation history record that needs to be stored in the user management area; The message storage server copies the information of the conversation history record that needs to be stored in the user management area from the system management area to the user-defined information in the user management area. 4. The method according to claim 1 or 3, wherein creating the user management area in the message storage server comprises: The message storage server receives information from the local record file uploaded by the client; The message storage server stores the information of the local record file in the user-defined information in the user management area. 5. The method according to any one of claims 1 to 2, wherein, before the message storage server receives the access instruction from the client, the method further comprises: The message storage server receives a tag metadata request message from the client, wherein the tag metadata is used to represent the association relationship between the conversation history record and the tag classification identifier and the relationship between the custom information and the tag classification identifier. connection relation; The message storage server sends part or all of the label classification identifiers to the client. 6. The method according to any one of claims 1 to 3, characterized in that, after the message storage server receives the access instruction from the client, the method further comprises: The message storage server checks the permission of the client to the requested file information; The message storage server determines that the client has access control authority to the requested file information. 7. The method according to claim 1, wherein, before the message storage server receives the access instruction from the client, when the user needs to view the conversation history, the method further comprises: The message storage server receives a request instruction for meeting metadata from the client, wherein the request instruction for meeting metadata carries a directory identifier to which the meeting metadata information belongs; The message storage server sends the session metadata to the client for parsing and presentation. 8. The method according to claim 7, characterized in that, after viewing the interview history, the method further comprises: The message storage server receives the record object identifier from the client; The message storage server sends part or all information of the record object corresponding to the record object identifier to the client for presentation. 9. The method according to claim 1, wherein the message storage server performing an access operation corresponding to the access instruction according to the tag classification identifier comprises: The message storage server receives a request message from the client for the content of the conversation history record, wherein the request message carries the file directory identifier and the file directory identifier to which some or all of the record objects associated with the tag classification identifier belong. identification of some or all of the recorded objects; The message storage server sends the content of the part or all of the record objects to the client for presentation. 10. The method according to claim 1, wherein the message storage server performing an access operation corresponding to the access instruction according to the tag classification identifier comprises: The message storage server receives an editing instruction of the tag metadata from the client; The message storage server performs an edit operation corresponding to the edit instruction on the tag metadata. 11. The method according to claim 10, wherein the editing instruction is used to indicate at least one of the following: Create a custom label, add a label to the record object in the label metadata, unlabel the record object in the label metadata, and delete the custom label. 12. The method according to claim 1, wherein when the message storage server deletes a conversation history record in the system management area in response to a user instruction, the method further comprises: The message storage server receives from the client the identifiers of the conversation history record and all its subordinate record objects; The message storage server deletes the description information corresponding to the one conversation history record and all its subordinate record objects in the conversation metadata according to the identifiers of the one conversation history record and all its subordinate record objects ; In the tag metadata, the message storage server stores the association relationship between the one conversation history record and all its subordinate record objects and tag classification identifiers according to the identifiers of the one conversation history record and all its subordinate record objects to delete. 13. The method according to claim 1, wherein when the message storage server deletes the record object under the custom file directory in the custom information in the user management area in response to a user instruction, The method also includes: The message storage server receives an identifier of a record object under the custom file directory from the client; In the tag metadata information, the message storage server deletes the association relationship between the record objects under the self-defined file directory and each tag classification identifier according to the identifiers of the record objects under the self-defined file directory. 14. The method according to claim 1, wherein when the message storage server deletes the custom file directory in the custom information in the user management area in response to a user instruction, the method further include: The message storage server receives the identifier of the custom file directory from the client; The message storage server deletes the association relationship between the self-defined file directory and each tag classification identifier according to the identifier of the self-defined file directory in the tag metadata information. 15. The method according to claim 1 or 3, wherein, before the message storage server receives the access instruction from the client, the method further comprises: The message storage server receives a tag metadata request message from the client; The message storage server sends part or all of the label classification identifiers to the client. 16. A message storage server, comprising: A receiving unit, configured to receive an access instruction from a client, wherein the access instruction carries a tag classification identifier; an executing unit, configured to execute an access operation corresponding to the access instruction according to the tag classification identifier; The first storage unit is used to store the interview history record and the interview metadata, wherein the interview metadata is used to indicate the association relationship between the interview history record and the file directory to which it belongs and the description information of the interview history record; The second storage unit is used to store user-defined information created by the user; The third storage unit is used to store label metadata, wherein the label metadata is used to indicate the association relationship between the conversation history record and the label classification identification and the relationship between the custom information and the label classification identification relationship. 17. The message storage server according to claim 16, wherein the message storage server further comprises: A copying unit, configured to copy the information of the conversation history record that needs to be stored in the user management area from the first storage unit to the custom information in the second storage unit; The obtaining unit is configured to obtain the information of the local record file uploaded by the client and store it in the self-defined information of the second storage unit. 18. The message storage server according to any one of claims 16 to 17, wherein the message storage server further comprises: An authentication unit, configured to check the authority of the client to the file information requested to be accessed; A determining unit, configured to determine that the client has access control authority to the requested file information.