CN102143125B - Access method of converged internet protocol messaging (CPM) session 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; the message storage server parses the access instruction to obtain the file directory identifier to be accessed, and obtains the link metadata information corresponding to the file directory identifier; the message storage server according to the link metadata information Execute the access operation corresponding to the access instruction. According to the above technical solution provided by the present invention, in addition to satisfying user-defined management operations on record resources stored on the message storage server, it can also provide users with multiple views, and on the premise of reducing the management overhead of the message storage server as much as possible , can provide users with a good business experience.

Description

CPM meeting history access method and message storage server

technical field

The present invention relates to the field of communications, 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 one-to-one, One-to-many and communication of various media types (eg, text, pictures, audio/video clips, binary files, audio/video streams) between 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 CPM conversation view, 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 extra overhead brought by the operation of constructing a linear view in the related art and the problems that the CPM meeting record will be destroyed when the user manages the resources stored on the message storage server. Therefore, the main purpose of the present invention is to An improved method for accessing CPM conversation history records and a message storage server are provided to solve at least one of the above-mentioned problems.

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

The method for accessing the CPM conversation history record according to the present invention includes: the message storage server receives the access instruction from the client; the message storage server parses the access instruction to obtain the file directory identifier that needs to be accessed, and obtains the link metadata information corresponding to the file directory identifier; The message storage server performs an access operation corresponding to the access instruction according to the link metadata information.

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 first receiving unit for receiving an access instruction from a client; a parsing and obtaining unit for parsing the access instruction to obtain the file directory identifier to be accessed, and obtaining the link element corresponding to the file directory identifier data information; an execution unit, configured to execute an access operation corresponding to the access instruction according to the link metadata information.

According to the present invention, a message storage model suitable for its own characteristics is defined for the meeting history records in the integrated message service communication environment, and a complete solution is formed by defining related metadata and related storage management operations, which can meet the needs of CPM talks In addition to satisfying user-defined management operations on record resources stored on the message storage server, it can also provide users with a variety of views. On the premise of minimizing the management overhead of the message storage server, it can provide users with a good business experience.

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 in the related art;

FIG. 3 is a schematic diagram of a message storage model based on a conversation structure in the related art;

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 a schematic diagram of command transmission for a user to obtain an access control list operation according to an embodiment of the present invention;

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

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

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

FIG. 10 is a schematic diagram of instruction transmission according to an embodiment of the present invention in which a user requests to set an active folder operation;

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

Fig. 12 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. 13 is a flow chart of command transmission for user request to create a folder operation according to an embodiment of the present invention;

FIG. 14 is a flow chart of instruction transmission for the user to add a record object to a user-defined folder according to an embodiment of the present invention;

Fig. 15 is a flow chart of instruction transmission for obtaining record object identifier information when the user checks the content in the user-defined folder according to an embodiment of the present invention;

Fig. 16 is a flow chart of instruction transmission for obtaining the content of the conversation history record stored in the message server when the user checks the content in the user-defined folder according to an embodiment of the present invention;

Fig. 17 is a flow chart of instruction transmission for the user to delete the conversation history record operation according to the embodiment of the present invention;

FIG. 18 is a flow chart of MSS processing when the user deletes the session history record operation according to an embodiment of the present invention;

FIG. 19 is a flow chart of command transmission for the operation of deleting a link object in a user-defined folder according to an embodiment of the present invention;

FIG. 20 is a flow chart of instruction transmission for the user to move the link object operation in the user-defined folder according to an embodiment of the present invention;

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

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

Detailed ways

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 S406):

Step S402: the message storage server receives an access instruction from the client;

Step S404: The message storage server parses the access instruction to obtain the file directory identifier to be accessed, and obtains the link metadata information corresponding to the file directory identifier;

Step S406: The message storage server performs an access operation corresponding to the access instruction according to the link metadata information.

Using the above method, by storing the link metadata information in the storage area of the message storage server, the access operation to the user management area is associated with the CPM meeting history records stored in the system management area, which solves the problem of constructing a linear view in the related technology The additional overhead caused by the operation and the problem that the CPM meeting record will be destroyed when the user manages the resources stored on the message storage server can satisfy the user's custom management operation on the record resources stored on the message storage server. It is also possible to provide users with multiple views.

Preferably, before the message storage server receives the access instruction from the client, 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 record information, and a second storage unit for storing system predefined file information;

(2) Create a user management area in the message storage server, wherein the user management area includes a third storage unit for storing user-defined information.

Preferably, the above meeting history record information includes: meeting metadata information and record information, wherein the record information includes: at least one piece of CPM message record information, at least one piece of CPM file transfer history record information, and at least one piece of CPM session history record information;

Preferably, the above system predefined file information includes: system predefined file directory, link metadata information under the system predefined file directory;

Preferably, the user-defined information includes: a user-defined file directory, and link metadata information under the user-defined file directory.

Wherein, the above-mentioned user-defined information may also include: local record file information uploaded by the client.

Preferably, the above meeting metadata information includes but not limited to the following three types: meeting information metadata information, message/transmission file history record information, and session history record metadata information.

Refer to FIG. 5 for an example of the storage model architecture created in the above message storage server. As shown in Figure 5, on the message storage server, assign an exclusive storage space (such as "Root-User" folder, i.e. the root directory) for each legal user on the message storage server, which is used to store information related to the conversation history records owned by the user. Resource records, and provide management capabilities to users. The user-specific storage space (corresponding to the "Root-User" directory) is divided into two parts: the system management area and the user-defined management area.

Among them, the system management area is composed of MSS predefined folders, such as "Conversation-History" (conversation history folder), "ReceivedBox" (inbox), "SendBox" (outbox) as shown in Figure 4 etc. are folders predefined by MSS. Among them, the meeting history record folder is dedicated to storing record resources related to the meeting history record, and maintains a unique backup on the MSS to provide the user with a view of the meeting. Other system folders associate the content stored in the conversation history folder through "link metadata", thereby providing users with some system-predefined views, such as outbox view, inbox view, and so on.

Wherein, the user-defined management area is composed of user folders, such as "Folder1" and "Folder2" shown in FIG. 4 are folders created by users themselves. Users can "add" the CPM message records, CPM file transfer records, CPM session history records or a part thereof, or CPM meeting history records that they are interested in or think important to a custom folder for personalized management. Provide user-defined dynamic views. User folders provide user-defined dynamic views by associating content stored in the "Conversation-History" folder through "Link Metadata". 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 this storage model scheme, in order to avoid the MSC requesting the record files (such as message records, file transfer records or meeting history records) contained in the CPM meeting history records from the MSS, it is necessary to continuously pass IMAP4/SELECT ([RFC 3501]) Command to select the target folder to obtain the disadvantages of additional overhead caused by the file, this solution uses all the files related to the CPM conversation history (that is, all message records, file transfer history records, session history records) are directly stored Under the "Conversation-History" folder, and by employing "Conversation Metadata" to record information about CPM conversations, maintain CPM conversation history and records of CPM messages belonging to the conversation, CPM file transfer history, and CPM conversation history relationship between.

Among them, the system management area is managed by MSS, which is mainly used to store and maintain the CPM meeting view, and the user's access management operation is limited; in the user management area, the user has full management rights, and can realize the meeting history through custom folders Categorical management of recorded content to provide a variety of user-defined views.

Among them, the storage objects involved in the message storage model include the following five categories:

The first category: CPM message record object: it is used to store a CPM message record outside the session (including all media objects carried by the message);

The second category: CPM file transfer history object: it is used to store the file transfer history outside a session;

The third category: CPM session history record object: it is used to store the history record information of a CPM session (including the session state information of the CPM session, and all CPM messages interacted in the session, the transmitted CPM files and the continuity of the interaction media stream object);

The fourth category: metadata record object (metadata information): it is used to provide flexible management capabilities by using metadata information. In general, it can include two types of metadata:

Meeting metadata (that is, the above-mentioned meeting metadata information): record the description information of CPM meeting history records, and maintain the association between CPM message records, CPM file transmission history records, and CPM session history records and the CPM meetings to which they belong, so as to provide view;

Link metadata (that is, the above-mentioned link metadata information): maintain the relationship between the content of the CPM meeting and the folder to which it is linked (it can be a system folder or a user folder), so that it can flexibly provide a variety of system default views and user-defined views.

The present invention adopts a framework for establishing a metadata model, which can provide flexible management capabilities, wherein the metadata includes: session metadata and link metadata. The metadata model is described in detail below.

For example, as shown in FIG. 5 , the conversation metadata is stored under the conversation history record folder. Store link metadata in inbox, outbox, and user-defined folders.

Wherein, for the meeting metadata, the meeting history record folder needs to maintain three types of metadata, so as to respectively record information related to the CPM meeting, CPM message (CPM file transfer) and CPM session. The meeting metadata can be extracted from each record object file related to the meeting and stored as metadata. When the MSC requests to present the meeting view, it needs to first request the meeting metadata from the MSS, and then obtain the storage on the MSS through these metadata. The descriptive information of the CPM meeting, so as to provide the user with a meeting view. CPM messages (file transfers) and CPM session metadata are mainly used to record messages (file transfers) and summary information of CPM session objects and which user folders are associated, providing useful information for content management and query operations on MSS .

Preferably, each time MSS receives a CPM message record, CPM file transfer history record or CPM session history record, it needs to parse it, extract relevant information, and update the three types of metadata tables.

Among them, for the link metadata, preferably, a "link metadata" information table can be created for system predefined folders such as "SendBox" and "ReceivedBox", as well as each user-defined user folder, for the current The system adds CPM conversation history records to system predefined folders such as "SendBox" and "ReceivedBox", or the user adds a CPM message record object, CPM file transfer history record object, CPM session history record object, CPM conversation history record object When "adding" a user-defined user folder or a part of it, the corresponding "link metadata" is created for these objects under the target folder, that is, in the "link metadata information table" of the corresponding folder Add the corresponding entry record, record the "Conversation-ID" of the associated CPM conversation history record, or the associated CPM message record, CPM file transfer history record, unique storage identifier (UID) of the CPM session history record, and The associated part number.

Specifically, the purpose of recording the above metadata information is to save the storage path information of related record objects under the folder, which is equivalent to establishing a "link" for them, without repeatedly storing related record objects, so as to save storage space. In addition, the use of link metadata can be associated with a certain part of the content (such as a media attachment, etc.) in the record object actually stored in the meeting folder, which is the traditional file management operation of copying/moving in units of files unattainable.

The following describes the session metadata and link metadata in detail.

1. Session metadata

Three types of metadata need to be maintained in the meeting history folder to record information related to CPM talks, CPM messages (CPM file transfers) and CPM sessions, respectively. Among them, the CPM meeting metadata is particularly important, because the CPM meeting history record is a logical concept, and it does not correspond to the actual physical storage file, so the description information of each CPM meeting must be provided through metadata. The meeting metadata can be extracted from each record object file related to the meeting and stored as metadata. When MSC requests to present the meeting view (such as what meeting information the user owns, etc.), it needs to first request the meeting metadata from MSS , and then obtain the description information of the CPM talks stored on the MSS through these metadata, so as to provide the user with a view of the talks. CPM messages (file transfers) and CPM session metadata are mainly used to record the summary information of messages (file transfers) and CPM session objects and which user folders are associated, providing useful information for content management and query operations on MSS .

Every time MSS receives a CPM message record, CPM file transfer history record or CPM session history record, it must analyze it, extract relevant information, and update the following three metadata tables. Three metadata tables are described below.

(1) CPM meeting information metadata table

The structure definition of CPM meeting information metadata is shown in Table 1 below. The first column "Field Name" indicates the fields that should be in the meeting information metadata table, the second column "Description" gives the explanation of the corresponding field, and the third column "Example" gives an example of the content that should be filled in this table item.

When MSS receives the CPM message records, CPM file transmission 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 "CPM meeting information metadata table" In the "Conversation-ID" field, if no corresponding conversation metadata record is found, it means that this is a new CPM conversation. It is necessary to add a row of metadata information for this CPM conversation in the CPM conversation information metadata table, and receive Extract relevant information from the obtained history record object to fill in the corresponding fields of the metadata record corresponding to the meeting history record.

Table 1 CPM meeting information metadata table (Conversation)

field name illustrate Example Conversation-ID Session identifier, which uniquely identifies a CPM session Conversation1 Start-Time Talk start time 2008/3/27 7:30 End-Time The end time of the meeting 2008/3/27 8:30 Subject Talk topic Meeting for CPM Initiator The address of the initiator of the talk bobexample.com _

Participants Address of meeting participants bobexample.com ; tinaexample.com ; Content-UID The unique storage identifier (UID) of the CPM message record, CPM file transfer history record or CPM session history record file included in the CPM conversation history record 1, 5, 6.. Thread-Result Store the result of linearly sorting this talk (2)(3 6 (423)(44 7 96)) Tag The association mark of the chat history record, that is, the name of the user folder to which the chat history record is associated. working, Important Deleted Whether the delete operation has been performed by the user, Boolean True or False

As shown in Table 1, the "metadata table of meeting information" uses the meeting identifier as the primary key, and each row of records stores description information related to a CPM meeting.

Talk start time (Start-Time), end time (End-Time), talk subject (Subject), talk initiator (Initiator) information, participants (Participants) information;

Content-UID: UID of the record file included in the meeting (UID is assigned by MSS, folder scope);

Thread-Result: the result string of linearly sorting the history of the conversation. 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, so that the message storage client can obtain the linear sorting result of the specified conversation through the GETMETADATA command.

Tag : The "Tag" information of the conversation history record, which identifies which user folders the conversation history record is associated with. For example, the user "adds" the meeting history record to his customized "working" folder and "Important" folder, then in the corresponding Tag record item in the meeting information table, add the names of these two folders ( working and Important, separated by commas), so that you can easily find out which user folders this meeting history is associated with through the meeting information table;

Deleted : The "Deleted" field that marks whether the chat history has been deleted by the user, and the default setting is "False". If the user chooses to delete the conversation history record when browsing the conversation view under the conversation folder, but the conversation history record is associated with other user folders, set this field to "True", indicating that the user executes Disabled the deletion of meeting history records under the meeting folder. Then when the MSC requests the "conversation view" from the MSS, the MSS will not return the information of the conversation history records whose "Deleted" field is set to "True" to the MSC.

(2) CPM message/transmission file history record information metadata table

Each time MSS receives a CPM message record file or CPM file transmission history submitted by CPM PF, it parses it and extracts relevant information (such as contribution identifier, session identifier of the session to which it belongs, whether it is transmitted within the session or not) message or file, time stamp, sender, receiver, etc.) to update the CPM message/transmission file information table and add corresponding records.

The structure of the CPM message/file transfer history information metadata table is shown in Table 2 below:

Table 2 CPM message/file transfer history metadata table

(Message_File)

field illustrate Example Contribution-ID A contribution identifier for a CPM message or file transfer, uniquely identifying the object. Message2 orFile1 Belong-to-Conv-ID The session identifier of the CPM session to which this message or file transfer belongs. Conversation1 Belong-to-Session-ID Whether the message or file transfer belongs to a CPM session. If it belongs to a session, record the contribution identifier of the CPM session it belongs to. If it does not belong to a CPM session, leave it blank (NULL). Session1 UID A unique identifier for a CPM message or file transfer object. If this is an object outside the CPM session, record the UID of the object; if this is an object within the CPM session, record the UID of the CPM session history object to which the message or file transfer belongs. twenty three TimeStamp The timestamp of the message or file transfer. 2008/3/27

8:30 Sender The sender of this message or file transfer. aliceexample.com _ Receiver The recipient of this message or file transfer. bobexample.com _ Subject The subject of this message or file transfer. Tag The associated tag of the message (or a part thereof) or the file transfer, which is to record the name of the user folder associated with the message (or a part thereof) or the file transfer. InterestMessage/2, Working/3

As shown in Table 2, the structure of the "CPM message/file transfer record information metadata table" uses the contribution identifier of the record object as the primary key, and each row of records stores a CPM message or a CPM file transfer-related description information. For example,

The contribution identifier (Contribution-ID) of the CPM message or file transfer, the conversation identifier (Belonged-Conv-ID) of the CPM conversation to which it belongs, the contribution identifier (Belonged-to-Session-ID) of the CPM session to which it belongs, if it is outside the session object, then leave this field empty), the unique storage identifier (UID) assigned by MSS, the timestamp (TimeStamp), the sender (Sender), the receiver (Receiver), and the subject (Subject);

"Tag" field: the associated tag of the record object, that is, the names of those user folders associated with the CPM message or CPM file transmission, for example, the user associates Part 2 (Appendix 1) of the CPM message with the user's own Defined "InterestMessage" folder, record the name of the destination folder and the associated part number (separated by "/") in this field, such as "Interest Message/2"; if the user sends Part3 of this CPM message (Appendix 2) To link to the user-defined "Working" folder, record the name of the destination folder and the associated part number in this field, such as "Working/3".

(3) CPM session history information metadata table

Every time MSS receives a CPM session history record submitted by CPM PF, it will analyze it and extract the relevant information in the session history record object (such as the contribution identifier of the session, the session identifier belonging to the CPM session, Establishment time, end time, session initiator, participant, etc.), update the CPM session information table, add corresponding records, and store relevant metadata for subsequent search and search operations. The specific content is shown in Table 3 below:

Table 3 CPM session history metadata table (Session)

field illustrate Example Contribution-ID The contribution identifier of the CPM session, which uniquely identifies the CPM session Session1 Belong-to-Conversation-ID The session identifier of the CPM session to which the CPM session belongs Conversation1 Start Time The time when this CPM session started 2008/3/27 8:30 End Time The time when this CPM session ended 2008/3/27 8:38 Initiator Initiator of this CPM session alicecpm.com Participants Participants of this CPM session bob

cpm.com UID A unique storage identifier for this CPM session history on the server Tag The associated tag of the CPM session history file, that is, the name of the user folder associated with the CPM session history (or a part thereof). Working/2，Important/3

As shown in Table 3, the structure of the "CPM session history record information metadata table" uses the contribution identifier of the session history record as the primary key, and each row of records stores a descriptive information related to a CPM session history record, for example,

Contribution ID (Contribution-ID) of the CPM session history record, session identifier (Belonged-Conv-ID) of the CPM session to which it belongs, unique storage identifier (UID) assigned by MSS, session start time (StartTime), session end Time (End-Time), Initiator (Initiator), Participants (Participants).

"Tag" field: the associated tag of the CPM session history record, that is, the names of those user folders associated with the CPM session history record (or a part thereof), for example, the audio clip ( part2), associated to the user-defined folder named "Working", then record the name of the destination folder and the associated Part number in this field, such as "Working/2"; Part3 (Appendix 2) of the historical record is associated with the user-defined "Important" folder, then record the name of the destination folder and the associated part number in this field, such as "Important/3".

2. Link metadata

Create a "Link Metadata" information table for system predefined folders such as "SendBox", "ReceivedBox" and each user-defined user folder, which is used when the system adds CPM meeting history records to "SendBox" , "ReceivedBox" and other system predefined folders, or the user "adds" a CPM message record object, CPM file transfer history record object, CPM session history record object, CPM conversation history record object or a part of them to these When in a custom user folder, create corresponding "link metadata" for these objects under the target folder, that is, add corresponding entry records in the "link metadata information table" of the corresponding folder, and the records are associated The "Conversation-ID" of the CPM conversation history record, or the associated CPM message record, CPM file transfer history record, CPM session history record's unique storage identifier (UID), and the associated part number.

The purpose of recording such metadata information is to save the storage path information of related record objects under this folder, which is equivalent to establishing a "link" for them, instead of repeatedly storing related record objects, so as to save storage space. In addition, the use of link metadata can be associated with a certain part of the content (such as a media attachment, etc.) in the record object actually stored in the meeting folder, which is the traditional file management operation of copying/moving in units of files unattainable.

The specific content of the link metadata information table is shown in Table 4 below:

Table 4 Link Information Metadata Table (Relevance)

field name illustrate Example Seq The serial number of the link information metadata record is allocated incrementally by the client according to the latest link metadata record information obtained on the server, which can uniquely identify a piece of link information. 1, 2, 3...

link Used to indicate the type of record object being associated and the object's identifier. Message/11/2 or File/12 or Session/22/3 or Conversation/conv3

As shown in Table 4, the structure of the "Link Metadata Information Table" contains two fields, namely the "Seq" field and the "Link" field, where the "Seq" field is the primary key and is used to uniquely identify a Link information, and the "Link" field is used to record the relevant information of the associated object, which is a string type. The value of this field has different formats for different types of associated objects:

If the type of the associated object is a CPM message record object (or a part of it), or a CPM file transfer record object, or a CPM session history record object (or a part of it), then according to "Type/UID/Part-Number" format, where "Type" indicates the type of the associated object, "UID" indicates the unique storage identifier of the associated object record file, and "Part-Number" indicates which part of the associated object. If it is associated with Attachment 1 (ie Part2) of the CPM message with UID 11, add a record item "Message/11/2" under this field; it is associated with Attachment 4 of the session history record object with UID 22 (Part3), add a record item with the value of "Link" as "Session/22/3" in the table;

If the connection is the entire CPM conversation history record, record it in the format of "Conversation/Conversation-ID", where "Conversation" indicates that the associated object is a CPM conversation history record, and "Conversation-ID" indicates the conversation ID of the conversation history record symbol. If the association is the conversation history record with the conversation identifier "conv3", add a record item with the "Link" value "Conversation/conv3" in the table.

After the above metadata model is created, when access is required, the following processing can be taken:

Processing 1: Obtain metadata related to the specified folder

MSC can request to MSS to obtain the metadata related to the specified folder through the IMAP4/GETMETADATA command ([RFC 5464]). If the specified folder is the "Conversation-History" folder, it can be obtained from the "CPM Conversation Information Metadata Table" Relevant metadata can be obtained from three types of metadata tables: , "CPM message/transmission file history record information metadata table", and "CPM session history record metadata table". If the specified folder is another system folder (such as "SendBox" or "ReceivedBox" folder) or a user folder, you can get related link metadata from the "Link Information Metadata Table". The format of the command is as follows (with three parameters):

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

The <specified folder name> parameter specifies the name of the target folder that MSC wants to obtain metadata. For example, when MSC wants to get the description information of the conversation, it will specify the folder as "Conversation-History". Define the content in the "Working" file, and the folder will be designated as "Working";

<(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/table name/primary key value/specific field", which is used to specify the name of the target metadata table that MSC wants to obtain metadata and Which field in this table. Relevant metadata tables and corresponding table names (see Tables 1, 2, 3, and 4 for specific field names):

CPM conversation information metadata table: Conversation

CPM message/transfer file record information metadata table: Message_File

CPM session history information metadata table: Session

Link information metadata: Relevance

The following description is combined with an example. In example (1), when the MSC requests all the metadata of the CPM interview history from the MSS, the following command is used:

GETMETADATA "Conversation-History" (DEPTH Infinity) (/shared/conversation/)

Example (2), if MSC only wants to obtain the metadata information of a certain field of a specific record item, such as the topic information of the conversation history record with the conversation identifier "Conv3", MSC can use the following command:

GETMETADATA "Conversation-History" (/shared/conversation/conv3/Subject)

Example (3), when MSC requests the link metadata in the "SendBox" folder from MSS, use the following command:

GETMETADATA "SendBox" (DEPTH Infinity) (/shared/Relevance/)

Example (4), when MSC requests MSS for all link metadata in user-defined folders (such as "Working" folder), use the following command:

GETMETADATA "Working" (DEPTH Infinity) (/shared/Relecance/)

Processing 1: Set the metadata related to the specified folder

The MSC can also request the MSS to modify the metadata related to the specified folder through the IMAP4/SETMETADATA command ([RFC 5464]). Since the metadata tables associated with system folders are managed by MSS, and MSC has no right to request modification operations, the three metadata tables related to the "Conversation-History" folder, and the system folders such as "SendBox" and "ReceivedBox" The content of the "link metadata information table" shall be managed by MSS, and MSC cannot modify it, but can only be accessed in a read-only state.

Therefore, MSC can only set the link metadata in the "Link Information Metadata Table" of the user folder. The format of the command is as follows:

SETMETADATA <"name of the specified folder"><(value of the specified metadata table or field name setting in the table)>

<name of the specified folder> parameter, giving the name of the user folder that MSC wants to set metadata;

<(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 (entry value), where "entry" specifies the table where the metadata that MSC wants to modify is located and the corresponding The field name, and "value" indicates the value you want to set. The specific format of the "entry" part is "/shared/table name/field name/field value".

Example (1), MSC wants to delete an associated object under the user folder ("Working"), the link information sequence number of this associated object is 12, that is, the value of the "Seq" field in the "Link Metadata Table" is "12" To link records, MSC uses the following command:

SETMETADATA "Working" (/shared/Relevance/12/LinkNIL)

The fifth category: folder object (namely file directory): the combined storage container of the above objects, and the contents stored in different folders are different.

Among them, the CPM message object records, CPM file transfer history records, and CPM session history record objects exist as "leaf nodes" and cannot be nested. In folder objects, user folders can be nested to provide different grouping layers.

In the specific implementation process, creating the above message storage model mainly includes the following processing:

(1) In the system management area, the folders predefined by the system are generated by MSS and stored in the top-level directory.

For example, MSS generates a conversation history box, an inbox, and an outbox.

Among them, the "Conversation-History" folder (conversation history box) is specially used to store content related to CPM conversations, that is, all CPM conversations and related message record objects, file transfer history record objects, and session history record objects. stored directly under this folder;

The "SendBox" folder (outbox) is used to provide the "outbox view" in units of CPM session history records. That is, MSS should include the CPM meeting history records initiated by the CPM user into the "Outbox View", where the outbox contains "Link Metadata", which needs to be added in the "Link Metadata" of the "SendBox" folder A record that establishes the association between the CPM conversation history stored in the "Conversation-History" folder and the "SendBox" folder, and provides users with a system-predefined sendbox view;

"ReceivedBox" folder (inbox): Provides "inbox view" in units of CPM conversation history. That is to say, MSS should include the CPM meeting history records of the CPM user (not the originator) in the "inbox view", where the inbox contains "link metadata", that is, the "link metadata" in the "ReceivedBox" folder Add a record in "Metadata" to establish the association between the CPM conversation history stored in the "Conversation-History" folder and the "ReceivedBox" folder, and provide users with a predefined view of the inbox.

Therefore, the above system-predefined folders are actually three system-predefined views provided by MSS, namely "conversation view", "outbox view" and "inbox view". These three views are all Taking the CPM meeting history record as the unit, it provides users with the organizational relationship of the storage content predefined by the system.

Preferably, the user's management operations on system folders (eg, "Conversation-History" folder, "SendBox" folder, and "ReceivedBox" folder) are limited. For example, users are not allowed to create subfolders under system folders; users are not allowed to delete, copy, move, and rename system folders; users are not allowed to upload files to system folders; only users are allowed to view the contents of system folders , only allow users to delete meeting history records in units of meetings.

(2) The above-mentioned meeting history record box is a folder specially used to store the content related to the CPM meeting history record on the MSS, that is to say, all message record objects, file transfer history record objects and session history record objects are directly Stored under the "Conversation-History" folder.

Preferably, the chat view is maintained through "chat metadata" information. That is, the relationship between the recorded objects in the meeting history box and their respective CPM talks is maintained through the "metadata of the meeting".

Preferably, since the CPM meeting itself is a logical concept, and there is no actual physical entity corresponding to it, the description information about each CPM meeting needs to be provided through metadata, so the "metadata of the meeting" needs to provide the CPM meeting Description.

(3) The user's actual needs Create one or more custom folders (can be nested) in the user management area, and create the actual meeting content and user files stored in the meeting history folder by using "link metadata" The relationship between folders, thus providing a user-defined view.

Preferably, the user can upload the locally stored message record file, file transfer history record file or session history record file (or some content of the record file) to a user-defined folder on the message storage server, and can upload these Files are moved between different user-defined folders. That is to say, for user-defined folders, users have full administrative rights, and can create subfolders, rename, move, delete, and copy user folders and files.

Preferably, the user can also upload the local record file to a custom folder on the message storage server, and can move the file between different user folders. That is to say, for user-defined folders, users have full administrative rights, and can create subfolders, rename, move, delete, and copy user folders and files.

Preferably, after step S402 is performed, the above method may further include the following processing:

(1) The message storage server checks the authority of the client to request access to the file information;

(2) The message storage server determines that the client has access control authority to the requested file information.

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 [RFC 4314 ACL extension], the above access control rights can refer to the access control list (ACL), where ACL is a set of <Access Identifiers, rights> value pairs, "Access Identifiers" identifies the responsible person, and "rights ”Identifies which access control permissions the corresponding responsible person has. An ACL applies to a "mailbox" (ie folder).

[RFC 4314] 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: create mailboxes, 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: delete mailboxes, indicating that the folder can be deleted by the DELETE command, or the source folder can be deleted by the RENAME command;

t: delete Messages, 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 [RFC 4314], Through SETACL, DELETEACL, GETACL, LISTRIGHTS and other commands to manage various access control permissions of user-defined folders, that is, to give other CPM users the ability to access relevant 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 6.

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 [RFC 4314], and request the MSS to specify Add the access control permission to a certain user to the target folder, see Figure 7 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 to a certain user folder, the MSC should follow the procedure specified in [RFC 4314] to construct an "IMAP4/DELETEACL" command, requesting the MSS to specify the user's access to the target folder Control permission list deletion, see Figure 8 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 authority a specific user has for the user folder he created, he can follow the regulations in [RFC 4314], and the MSC constructs the "IMAP4/LISTRIGHTS" command to request the MSS to return the specified user's access control authority. For the access control permission list of the target folder, see Figure 9 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 10):

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 [RFC 3501]. Only when the authentication is successful, MSC can access the resources on MSS. Unable to 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 [RFC 3501], and use a specific authentication mechanism in the <authentication mechanism name> 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 a valid LOGIN command according to the regulations and procedures in [RFC 3501], use the MSC user name in the <user name> 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 folder (it can be a system folder or a user folder) to view, then MSC first carries the folder by constructing an IMAP4/SELECT command ([RFC 3501]) name, request MSS to select the folder. MSS sets the target folder as the active folder after receiving the command.

As shown in Figure 10, 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 meeting history box to view the CPM meeting history list;

After the user logs in to MSS through MSC, the user will first obtain a list of available folders on the server, and the user will see the "Conversation-History" folder (conversation history box) on the interface. When the interview history is recorded, the MSC will request information about the interview history from the MSS.

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.

Specifically, MSC can use the IMAP4/GETMETADATA command ([RFC5464]), specify the name of the target folder as "Conversation-History", and request to obtain all the conversation history records of the "Conversation Information Metadata Table" from the conversation history folder of MSS metadata information. After MSC obtains the description information related to the meeting, it analyzes and displays the meeting view on the client. (Note: Those CPM talks with "Deleted Field" set to "True" will not be presented to MSC through the system-provided talk view.)

Describe below in conjunction with example.

If the user selects the CPM conversation folder (that is, "Conversation-History") and wants to view the CPM conversation record information, the MSC should send the IMAP4/GETMETADATA command ([RFC 5464]) to the MSS to obtain the information associated with the "Conversation-History" folder. The metadata information of the CPM session is displayed on the client as the description information of the CPM session.

Because the CPM talk is a logical concept, there is no actual physical storage entity corresponding to it, that is to say, the summary information of the CPM talk (such as start time, end time, talk topic, participants, etc.) comes from the information of the talk Included CPM messages or CPM file transfer history or CPM session history. When the MSC requests the meeting summary information from the MSS, it is impossible for the MSS to parse the CPM message record file or the CPM file transmission history record file or the CPM session history record file every time, so as to obtain the relevant information of the CPM meeting, and the metadata can be compared Record this information well. Therefore, use the extended GETMETADATA command of [RFC 5264] to obtain the meeting information metadata, see Figure 11 for details.

As shown in Figure 11, after the GETMETADATA request command, the following steps are performed:

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

Step 2: According to the name of the metadata table "Conversation", MSS queries the "CPM Conversation Information Metadata Table" in the conversation history folder, and obtains all the record rows in the table whose "Deleted" field is set to "False" (indicating All fields and corresponding values of those records for which the user has not performed the operation of deleting interview records (that is, the effective interview history record information) are returned to the MSC through the response command of GETMETADATA.

It can be seen from the figure that all information of the effective CPM meeting information metadata table stored on the MSS is obtained from the response message of the GETMETADATA command returned by the MSS. The GETMETADATA command shown in Figure 6 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/22 18: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 conversation history record to view the specific content of the conversation 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.

In the specific implementation process, after the user obtains the meeting list, he has obtained the relevant metadata information of the meeting through commands, where the information includes the value of the <Content-UID> field, which records exactly the The UIDs (unique storage identifiers on the MSS) of all CPM message records, CPM file transfer history records, and CPM session history files contained in the CPM conversation, using these UIDs, the MSC can obtain the information related to the CPM conversation from the MSS through corresponding commands. The header information or content information of all recorded files is presented locally.

Describe below in conjunction with example.

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 12 for details.

As shown in Figure 12, after the MSC selects the corresponding session history subfolder through the IMAP4/SELECT command ([RFC 3501]), it can request the MSS to obtain the session history record subfolder through the IMAP4/FETCH command ([RFC 3501]) After receiving the command, the MSS obtains relevant information and returns it to the MSC through the 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.

In the specific implementation process, the above-mentioned user-defined folder (user-defined file directory) is created by the user in the user management area of MSS. Due to the limitation of operation rights, users do not have the right to create folders in the system management area, but 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 ([RFC 3501]), and carries the name of the folder to be created by the user in the <mailbox name> parameter in the CREATE command, and the name of the folder Comply with the standard path naming rules, use slash (/) as the layer separator.

As shown in Figure 13, 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 3. Add part or all of the interview history information to the custom file directory under the access instruction instruction (that is, the user adds CPM message records (or a part of them), CPM file transfer history records, CPM session history records (or a part of them) ) or the history of CPM talks into a custom folder), the above step S406 may further include the following processing:

(1) The message storage server adds the record item that needs to be associated to the link metadata information, so that part or all of the information of the record item is associated with the user-defined file directory;

(2) The message storage server updates the associated field of the meeting metadata information according to the type of the record item.

In the specific implementation process, when the user browses the CPM conversation history record, he may record a certain CPM message record/CPM file transmission history record/CPM session history record, or record a certain part of the file (such as a certain picture, audio, video), or are interested in this entire CPM interview history, and hope to add them to a custom folder for category management, and then perform category management to build a personalized view. Then perform the following processing:

Step 1: The user executes the "add operation", and MSC modifies the "link metadata information table" of the target user folder by constructing an IMAP4/SETMETADATA command ([RFC 5464]), and adds a record item associated with the record object.

Step 2: After MSS receives the request command, it first analyzes and obtains the name of the target folder, then queries the link metadata information table of the folder, adds corresponding record items in the table, and stores the actual information in the meeting history A specified record or a part of a record in a folder is associated with the folder.

Step 3: MSS correspondingly updates the "Tag" field in the meeting information metadata table, message/transfer file history metadata table, and session history metadata table according to the category of the associated object, and adds the name of the target user folder and /or the associated Part number to add an association relationship.

Describe below in conjunction with example.

When users browse the content of CPM meeting history records, they may have a certain CPM message record, CPM file transmission history record or a certain CPM meeting history record or a certain part of these records (such as a picture, audio, video) or the entire If you are interested in the history of CPM talks and want to add them to a custom folder for classified management, the user performs the "Add Link Object Operation".

In traditional messaging services (such as Email), the IMAP4/COPY command is used to copy the source file to the target folder in units of files. If this command is used, the user can only record a whole message, session history as the unit. In the inventive solution of this technology, MSC modifies the "link metadata information table" of the target folder by constructing the IMAP4/SETMETADATA command, and increases the record items related to the associated record object, which can flexibly realize the association of a CPM conversation history record or a Record a file or a certain part of a record file (such as a picture, audio, video, etc.).

As shown in Figure 14, before MSC initiates the "add link object operation", it must first obtain the latest "link metadata" associated with the target user folder on the server through the IMAP4/GETMETADATA command, and then it can correctly update the MSS. "Link metadata" to modify the operation.

As shown in Figure 14, MSC already knows that there are already 9 link objects under the user folder "Working" on MSS, then when MSC requests to record Part 2 (attachment) of a CPM message with UID 2 stored in the talk folder 1) When adding to the user-defined "Working" folder, the link metadata serial number increment should be set to 10.

MSS performs the following operations after receiving the command:

Step 1, analyze and obtain the name of the target user folder;

Step 2. Find the link metadata table "Relevance" of the "Working" folder, and search for the record with the value "10" in the "Seq" field in the table. If found, it means that the serial number already exists in this folder If the link record is 10, MSS returns an error response; if the record does not exist, MSS will add a record with the serial number "10" to the metadata table, and set the <Link> field to "Message/ 2/2";

Step 3. If the operation is successful, the MSS returns a success response to the MSC.

Step 4. MSS updates the "CPM Message/File Transfer History Metadata Table" in the "Conversation-History" folder, finds the record with UID 2, and then adds "Working/2" to the "Tag" field of the record. " string, indicating that the Part 2 part of the message record is associated with the Working folder.

Similarly, if MSC wants to add a CPM session history record with UID 13 stored under the talk folder to the user-defined "My Favorite" folder, MSC should first request the user folder "My Favorite" from MSS According to the latest "link metadata" information, there are currently 10 link objects under this folder, then MSC will increment the serial number of the link metadata to 11, and use the following command:

SETMETADATA "My Favorite" (/shared/Relevance/11/Link "Session/13")

After receiving the command and analyzing it, MSS first adds (11, Session/13) record lines to the "Link Metadata Information Table" (Relevance) of the "My Favorite" folder, and then needs to update the "Conversation-History" file Folder "Session History Metadata Table", find the record with UID 13, and then add the name of the "My Favorite" folder in the "Tag" field of the record item, indicating that the session history file and "My Favorite" folder Favorite" folder.

Preferably, if MSC wants to add a CPM interview history to the user-defined "Working" folder, use the following command:

SETMETADATA "working" (/shared/Relevance/12/Link "Conversation/convID1")

After receiving the command and analyzing it, MSS first adds (12, Conversation/conID1) record line to the "Link Metadata Information Table" (Relevance) of the "Working" folder, and then needs to update the "Conversation-History" folder "CPM meeting information metadata table", find the record with the meeting identifier convID1, and then add the name of the "Working" folder in the "Tag" field of the record item, indicating that the meeting history file and "Working " folder.

Operation 4. When the access instruction indicates to present the information corresponding to the system's predefined file directory (that is, the user views the content in the system preset folders such as "SendBox" and "ReceivedBox"), the message storage server executes according to the link metadata information Access operations corresponding to access instructions include:

(1) The message storage server sends the identification information of the first conversation history record associated with the system predefined file directory to the client;

(2) When the client locally stores the first identification information of all record files corresponding to the first meeting history record identification information, the message storage server receives all or part of the first identification information from the client;

Preferably, when the identification information of all record files corresponding to the meeting history record identification information is not saved locally at the client, the method may further include:

(2.1) The message storage server receives the identification request instruction from the client;

(2.2) The message storage server sends the identification information of all record files corresponding to the session history identification information to the client;

(2.3) The message storage server receives identification information of all or part of all record files from the client, and sends record information corresponding to the identification information of all or part of all record files to the client for presentation.

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

In the specific implementation process, MSC obtains the user's request, and requests the "link metadata" of the target folder from MSS through the IMAP4/GETMETADATA command, so as to obtain the meeting identifier information of all meeting history records associated with the folder.

Among them, after the MSC obtains the meeting identifier of the meeting history record associated with the "SendBox" or "ReceivedBox" folder, it includes the following two processing methods:

Method 1: If the description information of the conversation is stored locally, that is, the UID information of all record files contained in the conversation (such as obtained when viewing the contents of the "Conversation-History" folder), the MSC first selects "Conversation-History" through the SELECT command -History" folder, and then use these UIDs to request the specific content of relevant record files to MSS through the IMAP4/FETCH command;

Method 2: If the MSC does not store the description information of the meeting locally, the MSC first requests the content of the "Content-UID" field of the meeting metadata from the MSS through the IMAP4/GETMETADATA command to obtain the UID information of all the record files included in the meeting , and then select the "Conversation-History" folder through the SELECT command, and finally use the above UID to request the specific content of the relevant record file from MSS through the IMAP4/FETCH command.

Operation 5. When the access instruction indicates to present the information corresponding to the user-defined file directory (that is, the user views the content in the user-defined folder), the message storage server performs the access operation corresponding to the access instruction according to the link metadata information. include:

(1) The message storage server sends the second conversation history identification information associated with the user-defined file directory to the client;

(2) When the client locally stores the second identification information of all record files corresponding to the second meeting history record identification information, the message storage server receives all or part of the second identification information from the client;

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

In the specific implementation process, when the user selects a custom folder to view, in addition to the link object, the above-mentioned folder may also store record files uploaded by the user locally. Therefore, MSC first selects the user folder through the SELECT command, obtains the UID of the actual record file stored under the folder, and then retrieves the content of the above-mentioned user uploaded record file locally through the FETCH command. Then, the MSC requests the "link metadata" of the user folder from the MSS through the IMAP4/GETMETADATA command, so as to obtain the UID information of all link objects associated with the folder. Specific processing includes the following three situations:

Case 1: If the association is the entire history of the meeting, the MSC will obtain the meeting identifier of the meeting history, and use the meeting identifier to query the meeting in the locally stored meeting information (obtained when viewing the meeting list operation) The UIDs of the relevant recording files included, and then use these UIDs to request the specific content of the meeting from the meeting history folder of MSS through the IMAP4/FETCH command;

Situation 2: If the association is a complete message record, file transfer history record or session history record file, MSC will obtain the UID of the record file, and then MSC will use this UID to send the session history record file of MSS through the IMAP4/FETCH command The folder requests the specific content of the record file;

Case 3: If the association is a certain part of a message record file or a session history record file (such as a certain media object carried), the MSC will obtain the UID of the corresponding record file and the <Part-Number> indicating this part, and then The MSC uses the UID and <Part-Number> to request the specific content of this part from the conversation history folder of the MSS through the IMAP/FETCH command.

Then, MSC selects the "Conversation-History" folder through the SELECT command, and uses the obtained UID information of the associated record object to fetch the content of the associated object back to the local through the FETCH operation, so the user can view the custom folder in the content.

Describe below in conjunction with example.

When the user selects a user-defined folder (such as "Working") to browse, MSC first needs MSS to send a SELECT command to select the target folder "Working", and obtains the files stored under this folder in the response command returned by MSS. The UID of the record file uploaded by the user. Then MSC retrieves these recorded contents locally through the FETCH UID command. Then MSC uses the GETMETADATA command to request the "Link Metadata" information of the "Working" folder to be able to obtain all the CPM message records, CPM file transfer history records, CPM session history records or CPM conversation history record objects associated with this folder identifier information.

As shown in Figure 15, MSC constructs the GETMETADATA command according to [RFC 5464], sets the target folder name to the user-defined folder name "Working" that you want to view, and sets the <option> parameter to "DEPTH infinity", which means to obtain metadata For all the records in the table, set the <entry> parameter to "/shared/Relevance", indicating that you want to get the records in the "Link Metadata Information Table".

After MSS receives the command, it obtains the parameter value carried by the GETMETADATA command, and then obtains all records from the "Link Metadata Information Table" of the target folder, and returns to MSC through the response message of the GETMETADATA command. The MSC can obtain the UID or UID+<Part-Number> of all CPM session history records, CPM message records, CPM file transfer history records, or the meeting identifiers of the CPM meeting history records associated with the folder by parsing the response command.

Then MSC executes the SELECT command, selects the meeting folder, and then uses the obtained UID and related <Par-Number> to use the FETCH command to obtain the actual stored record content on the MSS. As shown in Figure 16, the MSC requests the MSS to obtain the UID For Part 2 of the record file with UID 2, request Part 3 of the record file with UID 12, and request the header and body part of the record file with UID 1, 2, 4, 5, and 6. After the MSC obtains these recorded contents, it presents them locally to the user for viewing.

Operation 6. User deletes meeting history

When the user needs to delete a whole piece of conversation history record information in the system management area, the method may also include the following processing:

(1) The message storage server obtains the identification information of all record files corresponding to a whole piece of conversation history record information;

(2) When the associated field of the meeting information metadata information is empty, the message storage server deletes the record item corresponding to a whole piece of meeting history record information;

(3) When the associated field of message/transmission file history record information or session history record metadata information is empty, the message storage server deletes all records corresponding to the identification information of a whole conversation history record information. record item.

In the specific implementation process, MSC receives the user's deletion request, and MSC uses the "IMAP4/STORE[UID-List]+FLAG(\Deleted)" command (UID-List indicates the UID list of the record files that you want to delete, separated by commas ) request MSS to delete the interview history record and all the record files contained in the interview history record.

MSS shall perform the following processing after receiving this command.

Step 1: MSS uses the UID list obtained from the STORE command to query the "Conversation-History" folder's "Conversation Information Metadata Table" "Content-UID" field, find the corresponding conversation history record item, and then check the record item Whether the "Tag" field of "Tag" is empty, if it is empty, go to step 2; if it is not empty, go to step 3;

Step 2: If the CPM meeting history record is not associated with other user folders, perform the following steps:

Step 2.1: Delete the corresponding record line of the meeting history record from the "metadata table of meeting information";

Step 2.2: Use the UID list to query the "UID" fields of the "CPM Message/File Transfer History Metadata Table" and "CPM Session History Metadata Table" to find the corresponding records;

Step 2.3: Check whether the "Tag" field of the record is empty. If it is empty, it means that the record is not associated with any other user-defined folder and can be deleted. Perform the following steps: the record file represented by the UID Set the FLAG tag ([RFC3501]) to (\DELETE) state; delete the record information line of the message object from the corresponding metadata table; update the "link metadata table" of "ReceivedBox" or "SendBox", and set the The link information represented by the UID is removed to update the "Inbox" and "Outbox" views.

Step 2.4: If the "Tag" field is not empty, it means that the record object is also associated with other user-defined folders, then set the "Belonged-to-Conv-ID" field of the record object to empty, indicating that the The conversation history record to which the record object belongs has been deleted, and the record object is no longer associated with the conversation, but exists as an independent record object.

Repeat steps 2.3 and 2.4 until all UID items in the UID list have been checked.

Step 3: If the CPM meeting history record is associated with other user folders, all the record files contained in the CPM meeting cannot be actually deleted, and then delete the record corresponding to the CPM meeting in the CPM meeting information table If the "Deleted field" is set to "True", it means that the user has performed a delete operation.

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

Describe below in conjunction with example.

When the user checks the meeting history list information, as shown in Figure 17, if he wants to delete a certain CPM meeting history record, he must first select the CPM meeting history record, because MSC has already obtained it through the GETMETADATA command when viewing the CPM meeting record list To obtain the UIDs (through the "Content-UID" field) of all record files included in the CPM meeting, MSC uses the STORE[UID-List]+FLAG(\Deleted) command to delete (UID-List indicates those record files that you want to delete list of UIDs, separated by commas).

When MSC requests MSS to delete a certain CPM meeting history record, MSC obtains the UIDs of all record files contained in the meeting history record, constructs a STORE command, and requests MSS for a deletion operation. The command interaction process between MSC and MSS is shown in the figure below:

After receiving the command, the MSS should execute the following processing flow, see Figure 18 for details.

Step 1: MSS uses the UID list (1, 2, 3, 5, 6) obtained from the STORE command to query the "Content-UID" field of the "CPM Conversation Information Metadata Table" in the "Conversation-History" folder, and finds Corresponding conversation history record item, and then check whether the "Tag" field of the record item is empty, if it is empty, go to step 2, if it is not empty, go to step 3;

Step 2: If the CPM meeting history record is not associated with other user folders, perform the following steps:

Step 2.1: Delete the corresponding record line of the meeting history record from the "metadata table of meeting information";

Step 2.2: Use the UID list (1, 2, 3, 5, 6) to query the "UID" fields of the "CPM message/file transfer history metadata table" and "CPM session history metadata table" respectively, and find the corresponding Record;

Step 2.3: Check the "Tag" field of the record, if the "Tag" field is empty, perform the following steps: set the FLAG tag ([RFC3501]) of the record file represented by the UID to (\DELETE) state; set The record information line of the message object is deleted from the corresponding metadata table; update the "link metadata table" of "SendBox" or "ReceivedBox", and delete the link information represented by the UID to update the "receipt" and The Outbox view. If the field is not empty, go to step 2.4;

Step 2.4: The "Tag" field is not empty, indicating that the record object is associated with other user-defined folders and cannot be deleted, then set the "Belonged-to-Conv-ID" field corresponding to the record line to If it is empty, it means that the meeting history record to which the record object belongs has been deleted, and the record object is no longer associated with the meeting, but exists as an independent record file.

Step 2.5: Repeat steps 2.3 and 2.4 until all UID items in the UID list have been checked.

Step 3: The CPM conversation history is associated with other user folders, then all the record files contained in the CPM conversation cannot be actually deleted (because the user associates the conversation history with a custom folder, he consider this important information), then in the CPM meeting information table, the "Deleted field" of the record corresponding to the CPM meeting is set to "True", indicating that the user has performed a delete operation. Note that those CPM talks with "Deleted Field" set to "True" will not be returned to MSC for presentation.

When the MSC receives the reply from the MSS that the operation of deleting the meeting history record is successful, it considers that the CPM meeting history record has been deleted successfully, and then the MSC updates the local view, and no longer displays the information related to the meeting under the meeting folder.

Operation 7. When the access instruction indicates to delete part or all of the link metadata information corresponding to the user-defined file directory (that is, the user deletes the link object in the user-defined folder), the message storage server executes the link metadata information according to the link metadata information. The access operations corresponding to the access instructions include:

(1) The message storage server deletes the record item that needs to be deleted in the link metadata information, so that part or all of the information of the record item is not associated with the user-defined file directory;

(2) The message storage server deletes the identification information of the user-defined file directory in the associated field of the meeting metadata information according to the type of the record item.

During the specific implementation process, the MSC obtains the user deletion request, and uses the IMAP4/SETMETADATA command to set the value of the link metadata of the target object to "NIL".

MSS will perform the following processing after receiving this command:

Step 1: In the "Link Metadata Table" of the target user folder, find the record of the specified link metadata, and then delete this row of records;

Step 2: Check the type of the link record object to be deleted, if it is a CPM message record (or a part of it), a CPM file transfer history record or a CPM session history record (or a part of it), go to step 3; if it is a CPM Talk history object, then perform step 4:

Step 3: Find the "CPM Message/File Transfer History Metadata Table" or "CPM Conversation History Metadata Table" in the meeting history folder, find the "Tag" field of the record requesting to disassociate, first Remove the name of the target folder from the value of the "Tag" field, then check whether the field is empty, if it is empty, go to step 3.1; otherwise, go to step 3.2;

Step 3.1: The record object is no longer associated with any user folder, check the "Belonged-to-Conv-ID field", if the field is empty, go to step a; otherwise, go to step b;

Step a: Indicate that the conversation history where the record object is located has been deleted, and it is an independent file that can be deleted, then perform the following steps: MSS actually deletes the record file from the conversation history folder (set its FLAG to \ DELETE), and delete the metadata of the record file from the corresponding metadata table; update the "Link Metadata Table" of "ReceivedBox" or "SendBox", and delete the link object information represented by the UID to update " Inbox and Outbox views;

Step b: Indicate that the conversation history record where the record object is located still exists, then the record file cannot be deleted, and then end the operation;

The record object is also associated with other user folders, which cannot be deleted, and the operation ends;

Find the "CPM Meeting Information Metadata Table" of the meeting history folder, find the "Tag" field of the record requesting to disassociate, first remove the name of the target folder from the value of the "Tag" field, and then Check whether the field is empty, if it is empty, go to step 4.1; if not, go to step 4.2.

Step 4.1: The interview record object is no longer associated with any user folder, check the "Deleted" field, if this field is set to "True", then perform step a, if this field is set to "False", then perform step b:

Step a: Indicate that the meeting history record has been deleted by the user and can be deleted, then MSS will delete the metadata record line corresponding to the meeting history record from the meeting information metadata table, and follow the "(5) User deletes CPM According to the relevant descriptions in "Conversation History", check whether the record files contained in the meeting need to be deleted at the same time;

Step b: Indicate that the conversation history record has not been deleted by the user, then the conversation history record cannot be deleted, and the operation ends;

Step 4.2: If the record object is also associated with other user folders, the record object cannot be deleted, and the operation ends;

After performing the above steps, if the operation is successful, the MSS returns an operation success response message to the MSC, and the MSC updates the local chat view, and no longer displays the content of the record through the user folder.

Describe below in conjunction with example.

When the user browses the contents of the custom folder, if he does not want to put a record object in the folder and wants to delete it, he should perform the following steps.

Note that since there may be record objects uploaded by users in the user folder, there may also be link objects, and MSC's deletion operations are also different for these two different objects. When MSC obtains the content stored in the user folder, it obtains the record object (via SELECT+FETCH command) and link object (via GETMETADATA+FETCH command) uploaded by the user through different operations, so for MSC, it can Distinguish between these two types of objects under the user folder, and use different commands when performing deletion operations, as shown in Figure 13.

If the deleted record file is uploaded by the user, use the IMAP/STORE command to set the file to (\Deleted) state;

If you delete a linked object, use the SETMETADATA command, as shown in Figure 13.

The command shown in Figure 13 will release the association between the Working folder and Part 2 of the CPM message record file with UID 2.

MSS will perform the following processing after receiving the command:

Step 1: In the "Link Metadata Information Table" (Relevance) of the Working folder, find the record whose <Link> field value is "/Message/2/2", and then delete this row of records;

Step 2: In the "CPM Message/File Transfer Record Metadata Table" in the "Conversation-History" folder, find the record whose <UID> field is 2, and then perform the following steps:

Step 2.1: Check the "Tag" field of the record, first remove the "working/2" string information from this field, if the "Tag" field is empty after removal, then perform step 2.2); After the division, the "Tag" field is not empty, then perform step 2.3);

Step 2.2: The record object is no longer associated with other user folders, then check the "Belonged-to-ConID" field:

If this field is empty, it means that the record object has been disassociated from the CPM meeting, and it is an independent file, and there is no other user folder associated with it, so it should be deleted from MSS, and MSS sets the FLAG of the record file "\DELETE"; and update the "Link Metadata Table" of "SendBox Folder" or "ReceivedBox Folder", delete the link information represented by the UID, so as to update the "Received Folder" and "Sent Folder" views;

If the field is not empty, it means that the record object is still associated with the CPM meeting and cannot be actually deleted, then end the operation;

Step 2.3: Indicate that the object is also associated with other user folders and cannot be deleted, then end the operation.

If the actual deletion operation of the record file is performed in the above process (that is, the FLAG flag of the record file is set to "/Deleted", then the link metadata information tables of "Incoming Folder" and "Outbox Folder" should also be deleted. Update, delete the link metadata of the deleted record file from the table, that is, the deleted record file will not appear in the "Inbox" or "Outbox" view.

Operation 8. When the access instruction indicates to delete the user-defined file directory (that is, the user deletes the user-defined user folder), the message storage server performs the access operation corresponding to the access instruction according to the link metadata information, including:

(1) The message storage server obtains the session corresponding to the link metadata information and the identification information of all the record files included in the session;

(2) When the associated field of the meeting information metadata information is empty, delete the record item of the meeting in the message storage server;

(3) When the associated field of message/transmission file history record information or session history record metadata information is empty, the message storage server deletes all or part of record items corresponding to the identification information of all record files.

In the specific implementation process, MSC obtains the user request, and uses the IMAP4/DELETE command ([RFC 3501]) to delete the specified user folder. After receiving the DELETE command, MSS analyzes it to extract the name of the target folder to be deleted, and then performs the following steps:

Step 1: Check the "Link Metadata Information Table" related to the target user folder, and obtain the UID and Part information of all record objects associated with the user folder;

Step 2: For each link object record in the "Link Metadata Information Table", perform the corresponding operations described in "(6) Users delete link objects in custom folders", according to the different categories of these link objects ( may be conversation history, message history, file transfer history, or session history), check to see if the actual stored log file can be deleted.

Step 3: After processing the above process, delete the "link metadata table" corresponding to the target folder;

Step 4: Delete the user folder.

After the MSS executes the above operations successfully, it returns a success response message to the MSC, and the MSC updates the local view, and no longer displays the deleted custom user folder.

Describe below in conjunction with example.

When the user browses the contents of the custom folder, if he does not want to put a record object in the folder and wants to delete it, he should perform the following steps.

Note that since there may be record objects uploaded by users in the user folder, there may also be link objects, and MSC's deletion operations are also different for these two different objects. When MSC obtains the content stored in the user folder, it obtains the record object (via SELECT+FETCH command) and link object (via GETMETADATA+FETCH command) uploaded by the user through different operations, so for MSC, it can Distinguish between these two types of objects under the user folder, and use different commands when performing deletion operations, as shown in Figure 13.

If the deleted record file is uploaded by the user, use the IMAP/STORE command to set the file to (\Deleted) state;

If you delete a linked object, use the SETMETADATA command, as shown in Figure 13.

The command shown in Figure 19 will disassociate the Working folder from Part 2 of the CPM message record file with UID 2.

MSS will perform the following processing after receiving the command:

Step 1: In the "Link Metadata Information Table" (Relevance) of the Working folder, find the record whose <Link> field value is "/Message/2/2", and then delete this row of records;

Step 2: In the "CPM Message/File Transfer Record Metadata Table" in the "Conversation-History" folder, find the record whose <UID> field is 2, and then perform the following steps:

Step 2.1: Check the "Tag" field of the record, first remove the "working/2" string information from this field, if the "Tag" field is empty after removal, then perform step 2.2); After the division, the "Tag" field is not empty, then perform step 2.3);

Step 2.2: The record object is no longer associated with other user folders, then check the "Belonged-to-ConID" field:

If this field is empty, it means that the record object has been disassociated from the CPM meeting, and it is an independent file, and there is no other user folder associated with it, so it should be deleted from MSS, and MSS sets the FLAG of the record file "\DELETE"; and update the "Link Metadata Table" of "SendBox Folder" or "ReceivedBox Folder", delete the link information represented by the UID, so as to update the "Received Folder" and "Sent Folder" views;

If the field is not empty, it means that the record object is still associated with the CPM meeting and cannot be actually deleted, then end the operation;

Step 2.3: Indicate that the object is also associated with other user folders and cannot be deleted, then end the operation.

If the actual deletion operation of the record file is performed in the above process (that is, the FLAG flag of the record file is set to "/Deleted", then the link metadata information tables of "Incoming Folder" and "Outbox Folder" should also be deleted. Update, delete the link metadata of the deleted record file from the table, that is, the deleted record file will not appear in the "Inbox" or "Outbox" view.

Operation 9. When the access instruction indicates to delete the user-defined file directory (that is, the user deletes the user-defined folder), the message storage server performs the access operation corresponding to the access instruction according to the link metadata information, including the following processing:

(1) The message storage server obtains the session corresponding to the link metadata information and the identification information of all the record files included in the session;

(2) When the associated field of the meeting information metadata information is empty, delete the record item of the meeting in the message storage server;

(3) When the associated field of message/transmission file history record information or session history record metadata information is empty, the message storage server deletes all or part of record items corresponding to the identification information of all record files.

In the specific implementation process, if the user wants to copy a link object from the source folder to the destination folder, the MSC requests to add the link object to the link metadata information table of the target folder through the IMAP4/SETMETADATA command .

After receiving the SETMETADATA command, the MSS performs the update operation of the corresponding link metadata information table, and correspondingly updates the " Tag" field content.

The MSS operates successfully, and returns a success response message to the MSC.

Describe below in conjunction with example.

If the user wants to delete a custom folder, but there is an associated record file object in the folder, the client should remind the user, "This folder is not empty, do you want to empty this folder and delete it?", if If the user decides to perform the delete operation, the MSC should use the IMAP4/DELETE ([RFC 3501]) command to delete the specified folder.

If the user wishes to delete the custom folder "Working", the MSC constructs a "DELETE "\Working"" command. After receiving the DELETE command, MS S analyzes it to extract the name of the target folder to be deleted ("Working"), and then performs the following steps:

Step 1: Query the "Link Metadata Information Table" corresponding to the target folder, and obtain all the record rows in the table, each row represents an associated object;

Step 2: Check the type of the associated object in each line, if the associated object is a CPM message record (or a part thereof), a CPM file transfer history record or a CPM session history record (or a part thereof), then perform step 3; if the associated is the CPM meeting history, then go to step 4:

Step 3: Find the "CPM Message/File Transfer History Metadata Table" or "CPM Conversation History Metadata Table" in the meeting history folder, and find the "Tag" field of the record requesting to disassociate. The name of the target folder is removed from the value of the "Tag" field, then check whether the field is empty, if it is empty, go to step 3.1; if not, go to step 3.2;

Step 3.1: The record object is no longer associated with any user folder, check the "Belonged-to-Conv-ID field", if the field is empty, go to step a; if the field is not empty, go to step b;

Step a: Indicate that the conversation history record where the record object is located has been deleted and is an independent file that can be deleted, then MSS deletes the record file from the conversation history record folder (set its FLAG to \DELETE), and The metadata of the record file is deleted from the corresponding metadata table; and the "Link Metadata Table" of "SendBox" or "ReceivedBox" is updated, and the link information represented by the UID is deleted to update the "Inbox" and "Outbox" view;

Step b: Indicate that the meeting history record where the record object is located still exists, then the record file cannot be deleted, and the operation ends;

Step 3.2: The record object is also associated with other user folders and cannot be deleted, so end the operation;

Step 4: Find the "CPM meeting information metadata table" of the meeting history record folder, find the "Tag" field of the record requesting to disassociate, first move the name of the target folder from the value of the "Tag" field , and then check whether the field is empty, if it is empty, perform step 4.1); if it is not empty, perform step 4.2):

Step 4.1: The record object is no longer associated with any user folder, check the "Deleted" field, if this field is set to "True", then perform step a, if this field is set to "False", then perform step b:

Step a: Indicate that the meeting history record has been deleted by the user and can be deleted, then MSS will delete the metadata record line corresponding to the meeting history record from the meeting information metadata table, and follow the "(5) User deletes CPM According to the relevant descriptions in "Conversation History", check whether the record files contained in the meeting need to be deleted at the same time;

Step b: Indicate that the conversation history record has not been deleted by the user, then the conversation history record cannot be deleted, and the operation ends;

Step 4.2: If the record object is also associated with other user folders, the record object cannot be deleted, and the operation ends;

Repeat steps 2, 3, and 4 until all records in the "Link Metadata Information Table" of the target user folder are checked. After processing the above process, delete the "link metadata information table";

Step 6: Delete the user folder.

If the above operation is successful, MSS returns a DELETE command success response message to MSC. After receiving it, MSC thinks that the user folder and all associated contents have been deleted on the server, then updates the user interface and displays the operation result to the user.

Operation 10. When the access instruction indicates to copy the link object (that is, the user copies the link object), the message storage server performs the access operation corresponding to the access instruction according to the link metadata information, including the following processing:

(1) The message storage server copies the link object from the link metadata information corresponding to the source file directory to the link metadata information corresponding to the destination file directory;

(2) The message storage server updates the associated field of the meeting metadata information according to the type of the link object.

In the specific implementation process, if the user wants to copy a link object from the source folder to the destination folder, the MSC requests to add the link object to the link metadata information table of the target folder through the IMAP4/SETMETADATA command .

After receiving the SETMETADATA command, the MSS performs the update operation of the corresponding link metadata information table, and correspondingly updates the " Tag" field content.

The MSS operates successfully, and returns a success response message to the MSC.

Operation 11. When the access instruction indicates to move the link object, the message storage server performs the access operation corresponding to the access instruction according to the link metadata information, including:

(1) The message storage server moves the link object from the link metadata information corresponding to the source file directory to the link metadata information corresponding to the destination file directory;

(2) The message storage server updates the associated field of the meeting metadata information according to the type of the link object.

In the specific implementation process, if the user wants to move a link object from the source folder to the destination folder, the MSC first requests to add the link object to the link metadata information table of the target folder through the SETMETADATA command, and then Then use the SETMETADATA command to request to delete the metadata information of the link object in the source folder.

After receiving the SETMETADATA command, the MSS performs the update operation of the corresponding link metadata information table, and correspondingly updates the " Tag" field content.

The MSS operates successfully, and returns a success response message to the MSC.

Describe below in conjunction with example.

If the user wants to move a linked object to another user-defined folder, first add the link to the "Link Metadata Information Table" of the other folder, and then execute the metadata information of the source folder Delete operation, as shown in Figure 20.

After MSS receives the "SETMETADATA“/My Favorite”(/shared/Relevance/15/Link“Message/2/2”)”command, it performs the following steps (such as the operation of “User Add Link Record” in section 3.2.3):

First, in the metadata table of the "My Favorite" folder, add a link record with the <Seq> field as "15" (assuming that MSC has learned the latest link metadata information in the destination folder "My Favorite" through the GETMETADATA operation If there are 14 records, construct the SETMETADATA command to add the 15th link record), the value of the <Link> field of the link record is "Message/2/2";

Then, in the CPM message record metadata table of "Conversation-History", find the record item with UID 2, and add "MyFavorite/2" information in the "Tag" field of the record item.

After receiving the "SETMETADATA "/Working" (/shared/link/message/2/2 NIL)" command, MSS performs related operations according to the "user deletes the link object" described in operation 7.

According to an embodiment of the present invention, a device for accessing a Converged IP Messaging (CPM) conversation history record is also provided.

Fig. 21 is a structural block diagram of a message storage server according to an embodiment of the present invention. As shown in FIG. 21 , the device for accessing CPM conversation history records according to the embodiment of the present invention includes: a first receiving unit 1 , an analysis and acquisition unit 2 , and an execution unit 3 .

The first receiving unit 1 is configured to receive an access instruction from a client;

The parsing and obtaining unit 2 is used to parse the access instruction to obtain the file directory identifier to be accessed, and obtain the link metadata information corresponding to the file directory identifier;

The execution unit 3 is configured to execute an access operation corresponding to the access instruction according to the link metadata information.

In the storage area of the above-mentioned message storage server, the link metadata information is stored, and the access operation to the user management area is associated with the CPM meeting history records stored in the system management area, which can meet the requirements of the user for the records stored on the message storage server. While customizing resource management operations, it can also provide users with multiple views.

Preferably, as shown in FIG. 22, the above-mentioned device may further include: a first creation unit 4, configured to create a system management area in the message storage server, wherein the system management area includes a first storage unit for storing conversation history record information, A second storage unit for storing system predefined file information; a second creating unit 5, configured to create a user management area in the message storage server, wherein the user management area includes a third storage unit for storing user-defined information.

Preferably, as shown in FIG. 22 , the above device may further include: a second receiving unit 6 configured to receive local record file information uploaded from the client.

Preferably, as shown in FIG. 22, the above-mentioned device may further include: an authentication unit 7, configured to check the authority of the client to the requested file information; Has access control permissions.

The working mode of the combination of the units in the above-mentioned device can refer to the description in FIG. 4 to FIG. 20 , and will not be repeated here.

To sum up, through the above-mentioned embodiments of the present invention, a storage model suitable for its characteristics is defined for the conversation history records in the converged message service communication environment, and a complete set of related metadata and related storage management operations is formed by defining related metadata and related storage management operations. The solution, in addition to meeting the characteristics of CPM talks and satisfying users' custom management operations on the record resources stored on the message storage server, can also provide users with multiple views, such as the meeting view (viewed in units of CPM talks conversation history), the linear view of the conversation (constructed according to the relationship between replies and replies), 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 add the interested record file or part of the content in the record file to the custom folder), on the premise of minimizing the management overhead of the message storage server, 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 (21)

1. an access method for the IP message CPM meeting history record merged, is characterized in that, comprising:

Message storage server receives the access instruction coming from client;

Described message storage server is resolved described access instruction and is obtained the file directory mark needing access, and obtains link metadata information corresponding to described file directory mark;

Described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information;

Wherein, described link metadata information is for maintaining the incidence relation between CPM conversation content and the file be linked to.

2. method according to claim 1, is characterized in that, before message storage server reception comes from the described access instruction of client, described method also comprises:

In described message storage server, create system management region, wherein, described system management region comprises the first memory cell of storage meeting history record information, the second memory cell of storage system predefine fileinfo;

In described message storage server, create user management region, wherein, described user management region comprises the 3rd memory cell storing customized information;

Wherein, described user management region is the region that in memory space, user has complete administration authority.

3. method according to claim 2, is characterized in that,

Described meeting history record information comprises: talks metadata information and record object information, wherein, described record object information comprises: at least one CPM Message Record information, at least one CPM file transfer history information, at least one CPM conversation history recorded information;

Described system predefine fileinfo comprises: the link metadata information of the predefined file directory subordinate of the predefined file directory of system, described system;

Described customized information comprises: the link metadata information of User Defined file directory, described user-defined file directory subordinate.

4. method according to claim 3, is characterized in that, described User Defined fileinfo also comprises:

The local record fileinfo of described client upload.

5. method according to claim 3, is characterized in that, described talks metadata information comprises:

Talks information metadata information, message/transfer file history information, conversation history record metadata information.

6. method according to any one of claim 1 to 5, is characterized in that, after described message storage server reception comes from the access instruction of client, described method also comprises:

The authority of described client to the fileinfo of request access checks by described message storage server;

Described message storage server determines that the fileinfo of described client to described request has access control right.

7. method according to claim 3, is characterized in that, before message storage server reception comes from the access instruction of client, when user needs to check described meeting history record information, described method also comprises:

Described message storage server receives the talks metadata information request instruction coming from described client, and wherein, described talks metadata information request instruction carries the catalogue identification information belonging to described talks metadata information;

Described talks metadata information is sent to described client to carry out resolving and presenting by described message storage server.

8. method according to claim 7, is characterized in that, after checking described meeting history record information, described method also comprises:

Described message storage server receives the record object id information coming from described client;

The part or all of information of record object corresponding for described record object id information is sent to described client to present by described message storage server.

9. method according to claim 5, is characterized in that, when user needs to delete a whole piece meeting history record information in described system management region, described method also comprises:

Described message storage server obtains the identification information of the whole log files corresponding to a described whole piece meeting history record information;

When the associate field of described talks information metadata information is empty, described message storage server deletes the entry corresponding to a described whole piece meeting history record information;

When the associate field of described message/transfer file history information or described conversation history record metadata information is empty, described message storage server deletes entry corresponding to the identification information of the whole log files corresponding to a described whole piece meeting history record information.

10. method according to claim 3, it is characterized in that, when described access instruction instruction adds part or all of described meeting history record information to user-defined file catalogue, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

Described message storage server is added in described link metadata information by needing the entry of association, is associated with described User Defined file directory to make the part or all of information of described entry;

Described message storage server upgrades the associate field of described talks metadata information according to the type of described entry.

11. methods according to claim 3, it is characterized in that, undertaken in current in described access instruction instruction by information corresponding for described system predefine file directory, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

The first meeting history record identification information that described system predefine file directory associates is sent to described client by described message storage server;

When the first identification information of whole log files corresponding to described first meeting history record identification information is preserved in described client this locality, described message storage server receives all or part of described first identification information coming from described client;

Recorded information corresponding for all or part of described first identification information is sent to described client to present by described message storage server.

12. methods according to claim 11, is characterized in that, when the identification information of whole log files corresponding to described meeting history record identification information is not preserved in described client this locality, described method also comprises:

Described message storage server receives the identification request instruction coming from described client;

The identification information of whole log files corresponding for described meeting history record identification information is sent to described client by described message storage server;

Described message storage server receives the identification information coming from all or part of described whole log file of described client, and recorded information corresponding for the identification information of all or part of described whole log file is sent to described client to present.

13. methods according to claim 3, it is characterized in that, undertaken in current in described access instruction instruction by information corresponding for described User Defined file directory, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

The second meeting history record identification information that described User Defined file directory associates by described message storage server is sent to described client;

When the second identification information of whole log files corresponding to described second meeting history record identification information is preserved in described client this locality, described message storage server receives all or part of described second identification information coming from described client;

Recorded information corresponding for all or part of described second identification information is sent to described client to present by described message storage server.

14. methods according to claim 3, it is characterized in that, when the instruction of described access instruction is by partly or entirely the deleting of link metadata information corresponding for described User Defined file directory, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

Described message storage server is deleted needing the entry of deleting, to make the part or all of information of described entry and described User Defined file directory onrelevant in described link metadata information;

Described message storage server deletes the identification information of described User Defined file directory according to the type of described entry in the associate field of described talks metadata information.

15. methods according to claim 3, it is characterized in that, when described User Defined file directory is deleted by described access instruction instruction, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

The identification information of whole log files that these talks comprise is referred in the meeting obtained corresponding to described link metadata information of described message storage server;

When the associate field of described talks information metadata information is empty, in described message storage server, delete the entry of described talks;

When the associate field of described message/transfer file history information or described conversation history record metadata information is empty, described message storage server deletes entry corresponding to the identification information of all or part of described whole log file.

16. methods according to claim 3, is characterized in that, when linked object copies by described access instruction instruction, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

Described linked object from link metadata information corresponding to source file catalogue, is copied in link metadata information corresponding to object file directory by described message storage server;

Described message storage server upgrades the associate field of described talks metadata information according to the type of described linked object.

17. methods according to claim 3, is characterized in that, when linked object moves by described access instruction instruction, described message storage server performs the accessing operation corresponding with described access instruction according to described link metadata information and comprises:

Described linked object from link metadata information corresponding to source file catalogue, moves in link metadata information corresponding to object file directory by described message storage server;

Described message storage server upgrades the associate field of described talks metadata information according to the type of described linked object.

18. 1 kinds of message storage server, is characterized in that, comprising:

First receiving element, for receiving the access instruction coming from client;

Resolve acquiring unit, obtain for resolving described access instruction the file directory mark needing access, and obtain link metadata information corresponding to described file directory mark;

Performance element, for performing the accessing operation corresponding with described access instruction according to described link metadata information;

Wherein, described link metadata information is for maintaining the incidence relation between CPM conversation content and the file be linked to.

19. message storage server according to claim 18, is characterized in that, described message storage server also comprises:

First creating unit, for creating system management region in described message storage server, wherein, described system management region comprises the first memory cell of storage meeting history record information, the second memory cell of storage system predefine fileinfo;

Second creating unit, for creating user management region in described message storage server, wherein, described user management region comprises the 3rd memory cell storing customized information;

Wherein, described user management region is the region that in memory space, user has complete administration authority.

20. message storage server according to claim 18, is characterized in that, described message storage server also comprises:

Second receiving element, for receiving the local record fileinfo coming from client upload.

21., according to claim 18 to the message storage server described in 20 any one, is characterized in that, described message storage server also comprises:

Authenticating unit, for checking the authority of described client to the fileinfo of request access;

Determining unit, for determining that the fileinfo of described client to described request has access control right.