JP4261441B2 - E-mail storage method, storage system, and e-mail server - Google Patents

Description

The present invention stores an e-mail having an attached file transmitted from a transmission side terminal in a mailbox, and allows an e-mail having an attachment file stored in the mailbox to be received by a receiving side terminal. storage method relates to the storage system and an electronic mail server.

  In recent years, mobile communication terminals (MS: Mobile Station) such as mobile phones, PHS, and PDAs equipped with an electronic mail function have been put into practical use, and have established their status as communication means. Transmission / reception of electronic mail in such a mobile communication terminal (MS) is performed as follows. First, when an e-mail sender sends an e-mail to a recipient, the e-mail is stored in a mailbox of a mail server installed in the mobile phone network. Then, the short message service center (SMSC) sends a notification that the mail has been received to the recipient of the mail, so that the mail recipient carries the email stored in the mailbox of the mail server. It is downloaded to the communication terminal to receive e-mail.

  By the way, there are various types of mobile communication terminals, and the services that can be used differ depending on the models, and the corresponding formats (contents) and sizes are also different. For this reason, if the sender sends an e-mail with an attached file without knowing the model of the mobile communication terminal on the receiving side and the corresponding format (content) or size, the receiving mobile communication terminal There was a problem that attachments attached to e-mails could not be received. In addition, even when an attached file is received, there is a problem that the receiving side mobile communication terminal does not support files (contents) and cannot be used for display.

  Therefore, web hosting (uploading to the web space) is performed in advance in the process of sending mail, and the attached file attached to this e-mail is converted so as to correspond to the receiving terminal of the e-mail, so Non-Patent Documents 1 and 2 or Patent Document 1 have proposed an electronic mail storage system that can be received by a communication terminal (MS). In the e-mail storage system proposed in these Non-Patent Documents 1 and 2, or Patent Document 1, based on the terminal information (user agent) of the mobile communication terminal (MS) on the receiving side when accessing the web, The conversion process is performed so that the attached file attached to the electronic mail can be received by the terminal.

  An example of such an e-mail storage system is shown in FIG. In FIG. 19, this e-mail storage system 70 includes a mail server 71, a mail box 72, an IMAP (Internet Message Access Protocol) / POP (Post Office Protocol) server 73, a directory server 74, and a web space 75. , A web server 76, a conversion function unit 77, and a receiving terminal profile 78. A user directory 74 a is connected to the directory server 74, and a conversion engine 77 a is connected to the conversion function unit 77.

  The operation of the electronic mail storage system 70 will be described as follows. First, when the transmitting terminal (MS-1) transmits an e-mail containing only text data having a predetermined number of characters, the mail server 71 installed in the mobile phone network receives the e-mail. Then, the mail server 71 inquires of the directory server 74 whether or not the account of the receiving terminal (MS-2) exists in the user directory 74a.

  As a result, if the account is managed by the receiving terminal (MS-2), the received electronic mail is stored in the mailbox 72. Then, a notification that the short message service center (SMSC) (not shown) has received the mail is transmitted to the mail receiving terminal (MS-2). As a result, the receiving terminal (MS-2) can access the IMAP / POP server 73 and receive the electronic mail stored in the mail box 72.

  On the other hand, if the sending terminal (MS-1) sends an e-mail having an attached file (content) such as a photograph and is managed by the receiving terminal (MS-2) of the e-mail, the mail server 71 Receive email. Then, the mail server 71 stores the received e-mail having the attached file (content) in the web space 75 and stores a URL for accessing the web server 76 in the mail box 72. Then, a notification that the short message service center (SMSC) has received the mail is transmitted to the receiving terminal (MS-2) that is the destination of the mail. Thereby, the receiving terminal (MS-2) accesses the IMAP / POP server 73 and acquires the URL stored in the mail box 72.

  When the receiving terminal (MS-2) accesses the web server 76 based on the acquired URL, the web server 76 attaches the attached file (content) addressed to the receiving terminal (MS-2) stored in the web space 75. Is sent to the receiving terminal (MS-2). As a result, the receiving terminal (MS-2) can receive the mail. In this case, when the receiving terminal (MS-2) accesses the web server 76, the receiving terminal (MS-2) notifies the web server 76 of a user agent for identifying this terminal. As a result, the web server 76 acquires mail from the web space 75 and transmits it to the conversion function unit 77 to make a conversion request.

In response to this conversion request, the conversion function unit 77 determines the format (content) and size that can be received by the receiving terminal (MS-2) from the receiving terminal profile 78 and the received user agent, and can be received by the conversion engine 77a. The conversion process is performed so that the format (content) and size are appropriate. After the conversion process, the web server 76 downloads the converted e-mail to the receiving terminal (MS-2). As a result, the receiving terminal (MS-2) can receive the electronic mail and the attached file can be seen.
Satoshi Yamato, “Basic Knowledge of Mobile Phone Terms”, 95th: What is i-shot? [Online], 2002/06/11, [searched July 23, 2004], Internet <URL: http: // k -tai.impress.co.jp/cda/article/keyword/9754.html> Atsuko Arata, “E-mail Sending / Receiving Strategy with Photos”, edited by J-phone, [online], 2002/09/12, [searched July 23, 2004], Internet <URL: http: // k- tai.impress.co.jp/cda/article/review/10949.html> Japanese Patent Laid-Open No. 2004-56662

  By the way, the reception of electronic mail is normally performed only once, but in the system as shown in FIG. 19 described above, the web server 76 is accessed after receiving the hosted URL. There is a need. For this reason, the problem of inconvenience in receiving mail has occurred. Further, it is necessary to access the web server 76 every time a notification that mail has been received is received. For this reason, the problem that the operation | movement for receiving an email is troublesome arises.

  Furthermore, in order to convert an e-mail when stored in a mailbox, a format (content) and size information that can be received by the receiving terminal at this point are required. However, information such as the format (content) and size that can be received by the receiving terminal is unknown until the receiving terminal accesses. For this reason, there has been a problem that it is not possible to perform an e-mail conversion process when storing in a mailbox.

  Therefore, the present invention has been made to solve the above-described problems, and even if the communication terminal has restrictions on the usable format (format), communication speed, memory capacity, data transfer amount, etc., these It is an object of the present invention to be able to receive attached files such as digital contents such as an image file, a moving image file, a MIDI file (MIDI is a registered trademark), regardless of restrictions.

To achieve the above object, according to the present invention, an e-mail having an attached file transmitted from a sending terminal or an external mail server is received by a mail server , stored in a mailbox, and stored in the mailbox. An e-mail storage method that enables a receiving side terminal to receive an e-mail, wherein the mail server is a receiving side terminal corresponding to an account corresponding to the destination of the e-mail received from the sending side terminal or an external mail server Profile information including conversion elements, receivable sizes, and receivable formats pre-registered in the receiving terminal profile based on user directory information including the model information, content list, and conversion scenario registered in advance for the receiving terminal to get the, based on the mail server, acquired profile information It determined whether it is necessary to perform conversion processing to the received e-mail Te, the mail server, if the e-mail it is necessary to perform conversion processing based on conversion scenarios registered in advance with respect to the receiving terminal, and based on the acquired profile information is converted to the reception side terminal is receivable format and size, characterized in that the converted electronic mail to be stored in the mailbox.

  In this way, if the received terminal is converted to a format (content) and size that can be received by the receiving terminal, and the converted e-mail is stored in the mailbox, the usable format (format) ), Even a communication terminal with restrictions on communication speed, memory capacity, data transfer amount, etc., can receive attached files regardless of these restrictions.

In this case, the conversion scenario does not change the attachment order of the e-mail body and attachments, but performs conversion processing so that all attachments can be seen as much as possible, and does not change the attachment order of the body and attachments. , Delete all attachments that exceed the receivable size so that they can be seen as much as possible, and perform conversion processing so that they can be seen as cleanly as possible within the free receivable size, and attachment of the text and attachments The order of the attached file is changed so that the first attached file is converted so that it can be viewed as cleanly as possible without changing the order, and the receivable format is moved to the top and the unreceivable format is moved backward. change the accompanying order, and consists of a performs conversion processing such as seen as possible all attachments It is desirable

In order to realize such an e-mail storage method, a mail server that receives an e-mail with an attached file and a user account corresponding to an account received from a sending terminal or an external mail server are registered in advance. A user directory storing user directory information including at least one of model information of the receiving terminal, content list, and conversion scenario registered in advance with respect to the receiving terminal, conversion elements of the receiving terminal, receivable size, and reception And a receiving terminal profile that stores profile information including possible formats . The mail server obtains user directory information corresponding to a user account stored in the user directory and profile information stored in the receiving terminal profile. , Receive So as to comprise a determination unit that determines whether it is necessary to e-mail subjected to conversion treatment. As a result of determination by the determination means, if the e-mail does not need to be converted, it is stored in the mailbox as it is. If the e-mail needs to be converted, the acquired profile is based on the conversion scenario. Based on the information, conversion is performed so that the receiving terminal has a format and size that can be received, and the converted electronic mail is stored in the mailbox.

Next, an embodiment of the present invention will be described with reference to FIGS. 1 to 18. However, the present invention is not limited to this embodiment, and may be modified as appropriate without changing the object of the present invention. Can be implemented. FIG. 1 is a block diagram schematically showing a schematic configuration of the electronic mail storage system of the present invention. FIG. 2 is a flowchart showing an example of processing operation of the mail server shown in FIG. 3 to 6 are flowcharts showing examples of processing operations of the conversion function unit shown in FIG. FIG. 7 is a diagram showing an example of a user directory. FIG. 8 is a diagram showing an example of a content list. FIG. 8A shows a content list corresponding to a still image, FIG. 8B shows a content list corresponding to a moving image, and FIG. A content list corresponding to the incoming melody (MIDI file) is shown. FIG. 9 shows a content category list. FIG. 10 is a diagram illustrating an example of a receiving terminal profile. 11 to 18 are diagrams schematically showing conversion examples.

As shown in FIG. 1, an e-mail storage system 10 of the present invention includes a sending terminal (hereinafter simply referred to as a sending terminal) (MS-1) or a mail server 11 that receives an e-mail from an external mail server, IMAP (Internet Message) for sending a mail box 12 for storing an electronic mail received by the mail server 11 and an electronic mail stored in the mail box 12 to a receiving terminal (hereinafter simply referred to as a receiving terminal) (MS-2) An Access Protocol (POP) / POP (Post Office Protocol) server 13 and a directory server 14 for managing accounts are provided.

  Further, the electronic mail storage system 10 of the present invention preliminarily stores the received electronic mail for each model of the receiving terminal (MS-2) and the conversion function unit 15 that performs conversion processing so as to have a predetermined format and a predetermined size. A receiving terminal profile 17 for storing the registered profile. The directory server 14 is connected to a user directory 14a that stores information such as model information, content list, conversion scenario, etc. of the receiving terminal (MS-2) corresponding to the recipient's account (for example, telephone number). A conversion engine 16 is connected to the conversion function unit 15.

  Here, the mail server 11 receives by executing a predetermined program on a storage device (not shown) such as a CPU, RAM, ROM, a hard disk drive (HDD) or an optical disk drive, or hardware such as a system bus. Various functions for receiving an e-mail addressed to the e-mail address assigned to the user of the terminal (MS-2), transferring the e-mail, and sending the e-mail are realized. As such a program, software such as MTA (Message Transfer Agent) and MRA (Mail Retrieval Agent) is used.

  A program for operating the mail server 11 according to a predetermined procedure is stored in a ROM or a storage device, and is called and executed in a work area on the CPU or RAM as necessary. The mail server 11 may be configured by a single computer system, or may be configured by connecting a plurality of computers each having a plurality of server functions via a network.

  The mailbox 12 is a database that stores electronic mail received by the mail server 11 for a certain period (for example, 30 days). In this case, when a distribution request from the IMAP / POP server 13 based on the distribution request from the receiving terminal (MS-2) is received, the stored electronic mail is transmitted to the IMAP / POP server 13. If there is no deletion instruction by the user by the mailbox operation, the stored electronic mail data is automatically deleted after a certain period (for example, 30 days).

  The IMAP / POP server 13 is composed of almost the same hardware as the mail server 11 described above, and the e-mail stored in the mail box 12 based on the e-mail delivery request from the receiving terminal (MS-2). Is received from the mailbox 12 and transferred to the receiving terminal (MS-2).

  The directory server 14 is composed of almost the same hardware as the mail server 11 described above. In response to a request from the mail server 11, the account of the receiving terminal (MS-2) stored in advance in the user directory 14a. It has a function of transmitting information such as model information, content list, conversion scenario, etc. corresponding to (for example, a telephone number) to the mail server 11. In this case, in the user directory 14a, as shown in FIG. 7, for example, model information corresponding to the account (in this case, the telephone number) of the receiving terminal (MS-2), content list, conversion scenario, etc. Information is stored. In addition, as shown in FIG. 8, the user directory 14a includes a content type corresponding to a content list (a) corresponding to a still image, a content type corresponding to a moving image (b), and a ringing melody (MIDI file). Information such as the type (c) of the content corresponding to is stored. The user directory 14a also stores a content category list as shown in FIG.

  The conversion function unit 15 is configured by hardware similar to that of the mail server 11 described above, and receives a reception based on various information stored in advance in the receiving terminal profile 17 in response to a request from the mail server 11. The electronic mail is converted to a predetermined format and size using the conversion engine 16 and the converted file is transmitted to the mail server 11. In this case, in the receiving terminal profile 17, for example, as illustrated in FIG. 10, profiles registered in advance for each model of the receiving terminal (MS-2) (conversion elements 1, 2, 3 for still images and moving images) Element information such as conversion elements 1, 2 and 3 and receivable size information) are stored.

  The receivable size is determined in advance for the following reason. Taking a cellular phone network as an example, in a generation communication network called PDC (Personal Digital Cellular) or 2G (Second Generation), the data communication speed of the air interface is 9,600 bps. The number of transfer bytes in is 1,200 bytes / second. At this time, since the allowable continuous communication time generally derived from maintaining the quality of the call connection is about 6 seconds, the total amount of bytes that can be guaranteed in 6 seconds is derived from 1200 bytes × 6 seconds, 7.2K It becomes a byte. At the time of data transfer, header information is added together with the actual data, and generally has about 20% of the total information amount. As a result, the total amount of information that can be transferred (that is, the size that can be received by the receiving terminal) is It is assumed to be 6K bytes.

  In the generation network called PDC packet system or 2.5G (2.5 Generation), the data communication speed is 28.8 Kbps. However, since this system is a best-effort communication system, Specifically, it is guaranteed at about 20 Kbps. Therefore, the total byte amount of the actual data derived by the above calculation procedure is set to 12 Kbytes. Furthermore, in today's 2.5G network, the error rate tolerance of the best effort method is improved and the receivable size is guaranteed up to 30K bytes. In the communication network of the generation called W-CDMA system or 3G (Third Generation), the data communication speed is 384 Kbps, but the total of the actual data derived by the same calculation procedure as the 2.5G network. The amount of bytes is 200 Kbytes. Legacy PDAs have a very small memory capacity of several megabytes, and the mail capacity per mail is specified to be small.

  Next, in the electronic mail storage system configured as described above, the transmission terminal (MS-1) sends an electronic mail having an attached file to the reception terminal (MS-2) with reference to the flowcharts of FIGS. The e-mail storage processing procedure of the mail server 11 when it is transmitted to will be described below. In this case, depending on the setting by the operator, the type and content list of the model corresponding to the account (phone number) of the receiving terminal (MS-2), and the offer of the user who owns this receiving terminal (MS-2) It is assumed that conversion scenarios to be adopted are registered in the user directory 14a.

  In the present embodiment, the above-described conversion scenarios are prepared as conversion scenario 1, conversion scenario 2, conversion scenario 3, and conversion scenario 4, and an e-mail is stored based on the conversion scenario selected by the user. The conversion process for is done. In this case, in the conversion scenario 1, the conversion process is performed so that all the attached files can be seen as much as possible without changing the attachment order of the text and the attached files (contents). For this reason, the process of the conversion scenario 1 shown in the flowchart of FIG. 3 to be described later is performed.

  Also, in the conversion scenario 2, the conversion process is performed so that all the attached files can be seen as much as possible without changing the attachment order of the text and attached files (contents). However, data exceeding the receivable size is deleted, and conversion processing is performed so that it can be viewed as cleanly as possible (with high resolution) within the empty receivable size. For this reason, the process of the conversion scenario 2 shown in the flowchart of FIG. 4 to be described later is performed. Also, in the conversion scenario 3, the conversion processing is performed so that the first attached file (content) can be viewed as cleanly (with high resolution) as possible without changing the attachment order of the main text and the attached file (content). For this reason, the process of the conversion scenario 3 shown in the flowchart of FIG. 5 described later is performed.

  Furthermore, in the conversion scenario 4, the format (content) that can be received by the receiving terminal is moved to the top, and the format (content) that cannot be received (not supported) is moved backward. The attachment order is changed, and conversion processing is performed so that all attached files can be seen as much as possible. For this reason, the process of the conversion scenario 4 shown in the flowchart of FIG. 6 described later is performed. The following describes in detail the order of normal processing, processing by conversion scenario 1, processing by conversion scenario 2, processing by conversion scenario 3, and processing by conversion scenario 4.

1. Normal Processing First, in step S21, the mail server 11 uses a predetermined protocol (in this case, SMTP (Simple Mail Transfer Protocol)) from the sending terminal (MS-1) or an external mail server to send an e-mail (From , To, mail text, and attached file (content)). Then, in step S22, the mail server 11 receives various information (model information, content list, conversion scenario, etc.) of the receiving terminal (MS-2) corresponding to the account (phone number) corresponding to the destination (To) of this mail. The user directory information (see FIG. 7) is acquired from the database stored in the user directory 14a via the directory server 14.

In step S23, the mail server 11 sets the profile corresponding to the model of the receiving terminal (MS-2) acquired in step S22 (conversion elements 1, 2, 3 for still images, conversion elements 1, 2 for moving images). , 3, profile information such as receivable size: see FIG. 10) from the database stored in the receiving terminal profile 17 through the conversion function unit 15. Next, the process proceeds to step S24, and analysis is performed in accordance with the Internet mail protocol based on RFC (Request For Comment) specifications. As a result, information such as the size of the e-mail, the attached file format and its size is acquired.

  Thereafter, in step S25, based on the result of analyzing the email in the previous step, it is determined whether the received email needs to be converted. In this case, if an attached file in a format (content) that is not supported (not receivable) by the receiving terminal (MS-2) is not attached, and the total size of the received e-mail is less than the receivable size In step S25, “No” is determined, and the e-mail received in the next step S27 is stored in the mail box 12 as it is.

On the other hand, if an attachment file in a format (content) that is not supported (not receivable) by the receiving terminal (MS-2) is attached, or if the total size of the received e-mail exceeds the receivable size, step In S25, “Yes” is determined, and in the next step S26, the received electronic mail is transmitted to the conversion function unit 15 (conversion processing request). Then, the conversion function unit 15 performs mail conversion processing using a predetermined conversion engine prepared by the conversion engine 16 based on the conversion scenario acquired in step S22, and then converts the converted mail to a mail server. 11 (response of the result). Thereby, the mail server 11 stores the converted mail in the mail box 12 in the next step S27. In this case, the conversion function unit 15 performs the process of the conversion scenario 1 based on the flowchart of FIG. 3 when the conversion scenario acquired in step S22 is the conversion scenario 1. Similarly, if the acquired conversion scenario is conversion scenario 2, the processing of conversion scenario 2 is performed based on the flowchart of FIG. 4, and if the acquired conversion scenario is conversion scenario 3, the processing of conversion scenario 3 is performed based on the flowchart of FIG. In the case of the conversion scenario 4, the conversion scenario 4 is processed based on the flowchart of FIG.

  When the received electronic mail is stored in the mail box 12, the mail server 11 transmits a notification to the reception terminal (MS-2) that the mail has been received via the short message service center (SMSC). Thereby, the receiving terminal (MS-2) accesses the IMAP / POP server 13 by a predetermined protocol (in this case, IMAP / POP). Then, the IMAP / POP server 13 receives the mail corresponding to the account (phone number) of the receiving terminal (MS-2) accessed from the mail stored in the mail box 12. As a result, the receiving terminal (MS-2) can receive an e-mail having an attached file (content) that has been converted or not converted to the receiving terminal (MS-2).

2. Processing of Conversion Scenario 1 If “Yes” is determined in step S25 of FIG. 2 and the conversion scenario acquired in step S22 is conversion scenario 1, the conversion function unit 15 determines in step S30 of FIG. The conversion process of conversion scenario 1 is started. In step S31, if the format (content) of the attached file of the received e-mail does not correspond to the content list acquired from the user directory 14a (see FIGS. 7, 8, and 9), the conversion engine 16 Conversion to a corresponding format is performed using a predetermined conversion engine prepared . For example, in FIG. 7, the formats corresponding to the still images of the receiving terminal (MS-2) whose account is “090-0000-0001” are “JPG” and “PNG” (see FIG. 8A). Therefore, the receiving terminal (MS-2) are receiving the attachment format is "BMP" (content), the conversion function 15 a predetermined conversion engine that is prepared by the conversion engine 16 (in this case Performs conversion processing using BMP → JPG conversion). As a result, the BMP file is converted into a JPG file.

  Here, when the format of the file (content) is converted, the size may be reduced depending on the format characteristics. For example, in the case of JPG, parameters such as an image sampling rate and a quality value are determined within a range in which normal quality is not deteriorated as compared with BMP, and an image is compressed by format conversion. In this case, in the next step S31a, it is determined whether or not the total mail size is equal to or smaller than the receivable size of the receiving terminal (MS-2). Here, if it is less than the receivable size, “Yes” is determined in step S31a, the process proceeds to step S27 (see FIG. 2), and the converted mail is stored in the mailbox 12. On the other hand, if the size is larger than the receivable size, “No” is determined in step S31a, and the process proceeds to the next step S32.

Next, the conversion element 1 acquired from the receiving terminal profile 17 (step S23) is specified in step S32. Thereafter, in step S33, all attached files (contents) attached are converted based on the conversion element 1. Next, the process proceeds to step S34, and it is determined whether or not the total of all the converted sizes is equal to or smaller than the receivable size (see FIG. 10) of the receiving terminal (MS-2). If the size is less than the receivable size, it is determined as “Yes” in step S34, and the converted mail is transmitted to the mail server 11 (result response). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. On the other hand, if the size is larger than the receivable size, “No” is determined in step S34, and whether or not it is the last conversion element, that is, whether or not there is the next conversion element in the next step S35. Make a decision. Here, when there is no next conversion element, it determines with "Yes" in step S35, and transmits the mail after conversion to the mail server 11 (response of a result). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12.

  On the other hand, if there is a next conversion element, “No” is determined in step S35, and the next conversion element acquired in step S36 from the receiving terminal profile 17 (S23) (in this case, conversion element 2 and After that, the process returns to step S33. Then, the above-described processing from step S33 to step S36 is repeated until there is no next conversion element. In the process of the conversion scenario 1, when the attached file is converted by a specified conversion element, unnecessary information (for example, JPG Exif) is used in the receiving terminal (MS-2) to increase the receivable size as much as possible. It is desirable to delete additional information) such as information and thumbnails.

  Here, a mail conversion example based on the conversion scenario 1 will be described with reference to FIGS. In this case, an example of receiving an e-mail having an attached file addressed to the receiving terminal (MS-2) of an account adopting conversion scenario 1 (phone number is 090-0000-0001 and model type is SHAJ01) This will be described below.

(1) First Conversion Example First, a first conversion example based on the conversion scenario 1 will be described based on FIG. 11 (note that FIG. 11 is a diagram schematically showing the first conversion example). In this case, the body + header is 1K, and an e-mail having an attached file consisting of image 1 of 640 × 480, 30K, 240,000 colors and image 2 of 640 × 480, 30K, 240,000 colors is received. To do. In this case, 640 × 480 represents 640 dots × 480 dots, and 30K represents 30K bytes, but in the following description, the display of dots and bytes is omitted and simplified. In FIG. 11, the format (contents) of the attached files (images 1 and 2) is JPG, and the content list of this account (090-0000-0001) is G (see FIG. 7). It turns out that it is a content (JPG). Therefore, the format (content) conversion in step S31 is not performed. On the other hand, the received mail size is 1K for the body + header, the size of the image 1 is 30K, and the size of the image 2 is 30K, so the total size of the mail is 61K. Therefore, the first conversion is performed based on the conversion element 1.

  With the conversion element 1 (SHAJ01 still image conversion element 1 in FIG. 10A) corresponding to this model, both the image 1 and the image 2 are converted into 320 × 240, 15K, 240,000 colors. As a result, the total size of the mail is 31K, which exceeds 30K, which is the receivable size of this model, and the second conversion is performed based on the still image conversion element 2. By the second conversion, the total size of the mail becomes 21K, and this is adopted, and the converted file (content) is stored in the mail box 12.

(2) Second Conversion Example Next, a second conversion example based on the conversion scenario 1 will be described based on FIG. 12 (note that FIG. 12 is a diagram schematically showing the second conversion example). In this case, the body + header is 1K, the format (content) is BMP, 640 × 480, 60K, 240,000 colors of image 1, and the format (content) is BMP, 640 × 480, 60K, 240,000 colors. It is assumed that an e-mail having an attached file consisting of the image 2 is received. Since the content list of this account (090-0000-0001) is G (see FIG. 7), it can be seen from FIG. 8 that it is not the corresponding content (JPG, PNG). Accordingly, the format (content) is converted in step S31, and the image 1 is converted into a 640 × 480, 30K, 240,000 color JPG format (content), and the image 2 is converted into a 640 × 480, 30K, It is converted into a JPG format (content) of 240,000 colors.

  On the other hand, the file size converted into the JPG format (contents) is 1K for the body + header, 30 for image 1 and 30K for image 2, so the total file size after conversion is 61K. Therefore, the size is determined in step S31a. Since the receivable size of this terminal is 30K (see FIG. 10), the first conversion is performed based on the conversion element 1. With the conversion element 1 (SHAJ01 still image conversion element 1 in FIG. 10A) corresponding to this model, both the image 1 and the image 2 are converted into 320 × 240, 15K, 240,000 colors. As a result, the total size of the mail is 31K, which exceeds 30K, which is the receivable size of this model. Therefore, the second conversion is performed based on the still image conversion element 2. By the second conversion, the total size of the mail becomes 21K, and this is adopted, and the converted file (content) is stored in the mail box 12.

(3) Third Conversion Example Next, a third conversion example based on the conversion scenario 1 will be described based on FIG. 13 (note that FIG. 13 is a diagram schematically showing the third conversion example). In this case, the body + header is 1K, the format (content) is BMP, 640 × 480, 60K, 240,000 color images 1, and the format (content) is 3 gp, 176 × 144, 30 fps, 64 kbps, 60 K. It is assumed that an e-mail having an attached file consisting of the moving image 1 is received. Since the content list of this account (090-0000-0001) is G (see FIG. 7), it can be seen from FIG. 8 that the still image is not the corresponding content (JPG, PNG), and the corresponding content is the moving image. It turns out that it is (3gp, noa). Accordingly, in step S31, the format (content) is converted for the image 1, and the format (content) is not converted for the moving image 1. Then, the image 1 is converted into a 640 × 480, 30K, 240,000 color JPG format (content).

  On the other hand, the file size is 1K for the body + header, the size of the image 1 converted to the JPG format (content) is 30K, and the size of the moving image 1 is 60K, so the total file size is 91K. . Therefore, the size is determined in step S31a. Since the receivable size of this terminal is 30K (see FIG. 10), the first conversion is performed based on the conversion element 1. By the conversion element 1 (the SHAJ01 still image conversion element 1 in FIG. 10A and the SHAJ01 moving image conversion element 1 in FIG. 10B) corresponding to this model, the image 1 is 320 × 240, 15K, 24 Converted to all colors, moving image 1 is converted to 176 × 144, 15 fps, 64 kbps, 30K.

  As a result, the total size of the mail is 46K, which exceeds 30K which is the receivable size of this model. Therefore, the second conversion is performed based on the still image and moving image conversion element 2 as shown in FIG. Even in the second conversion, the total size of the mail does not become 30K or less at 35K, so the third conversion is performed based on the still image and moving image conversion element 3. As a result, the total size of the mail is 21K as shown in FIG. 13, and this is adopted, and the converted file (content) is stored in the mail box 12.

(4) Fourth Conversion Example Next, a fourth conversion example based on the conversion scenario 1 will be described based on FIG. 14 (note that FIG. 14 is a diagram schematically showing a fourth conversion example). In this case, the body + header is 1K, the format (content) is BMP, 640 × 480, 60K, 240,000 colors of image 1, the format (content) is mid, the 5K ringtone and the format (content) ) Is 3 gp, and it is assumed that an e-mail having an attached file consisting of a moving picture 1 of 176 × 144, 30 fps, 64 kbps, 60 K is received.

  Since the content list of this account (090-0000-0001) is G (see FIG. 7), it can be seen from FIG. 8A that the still image is not the corresponding content (JPG, PNG). Further, from FIG. 8B, it can be seen that the corresponding content (3gp, noa) is present in the moving image. Also, from FIG. 8C, it can be seen that the incoming melody is not the corresponding content (mmf, smd). Therefore, the format (content) is converted for the image 1 and the incoming melody (MIDI file) (step S31), and the format (content) is not converted for the moving image 1. The format (content) of the image 1 is JPG and converted to 640 × 480, 30K, 240,000 colors, and the incoming melody (MIDI file) is converted to mmf.

  On the other hand, the file size is 1K for the text + header, the size of the image 1 converted to JPG is 30K, the size of the incoming melody converted to mmf is 5K, and the size of the movie 1 is 60K. The size is 96K. Therefore, as described above, after determining whether or not the size is receivable, the first time based on the conversion element 1 is set so that the receivable size of this model is 30K or less as shown in FIG. Thus, the second conversion is performed based on the conversion element 2, and the third conversion is performed based on the conversion element 3. As a result, as shown in FIG. 14, the total size of the mail becomes 26K by the third conversion, and this is adopted, and the converted file (content) is stored in the mail box 12.

(5) Fifth Conversion Example Next, a fifth conversion example based on the conversion scenario 1 will be described based on FIG. 15 (note that FIG. 15 is a diagram schematically showing the fifth conversion example). In this case, the text + header is 1K, the format (content) is BMP, the image 1 of 640 × 480, 60K, 240,000 colors, the format (content) is zip, and an electronic file having other attached files of 30K Assume that an email has been received. Since the content list of this account (090-0000-0001) is G (see FIG. 7), it can be seen from FIG. 8A that the still image is not the corresponding content (JPG, PNG). Further, it can be seen that the other zips are contents not shown in FIG. Therefore, the image 1 is converted into a 640 × 480, 30K, 240,000 color JPG, and the zip remains unconverted.

  On the other hand, the file size is 1K for the text + header, the size of the image 1 converted to JPG is 30K, and the size of the unconverted zip is 30K, so the total size is 61K. Therefore, after determining whether the size is receivable, as shown in FIG. 15, the first conversion is performed based on the conversion element 1, the second conversion is performed based on the conversion element 2, and the conversion element is converted. Based on 3, the third conversion is performed. In this case, the total size becomes 39K by the third conversion, and does not become 30K or less, which is the receivable size of this model. For this reason, the image 1 converted to JPG is 160 × 120, 240,000 colors, the size is converted to 8K, and the zip file is stored in the mailbox 12 without conversion (still 30K). . In this case, since the total size of the text + header and image 1 is 9K, the IMAP / POP server 13 can selectively receive only this portion. Further, the server mail transfer function of the IMAP / POP server 13 makes it possible to transfer to another mail.

3. Processing of Conversion Scenario 2 If “Yes” is determined in step S25 of FIG. 2 and the conversion scenario acquired in step S22 is conversion scenario 2, the conversion function unit 15 determines in step S40 of FIG. The conversion process of conversion scenario 2 is started. Then, in step S41, if the attached file (content) of the received e-mail does not correspond to the content list acquired from the user directory 14a (see FIGS. 7, 8, and 9), the conversion engine 16 prepares it. The data is converted into a corresponding format using a predetermined conversion engine .

Next, in step S41a, it is determined whether or not the sum of all sizes after format conversion is equal to or smaller than the receivable size (see FIG. 10) of the receiving terminal (MS-2). Here, if it is less than the receivable size, it is determined as “Yes” in step S41a, and the converted mail is transmitted to the mail server 11 (response to the result). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. On the other hand, if the size exceeds the receivable size, “No” is determined in step S41a, and the process proceeds to the next step S42. Next, the conversion element 1 acquired from the receiving terminal profile 17 (S23) is specified in step S42. Thereafter, in step S43, all attached files (contents) attached are converted based on the conversion element 1.

Next, the process proceeds to step S44, where it is determined whether or not the total of all converted mail sizes is equal to or smaller than the receivable size (see FIG. 10) of the receiving terminal (MS-2). Here, if it is less than the receivable size, it is determined as “Yes” in step S44, and the converted mail is transmitted to the mail server 11 (result response). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. On the other hand, if the size exceeds the receivable size, “No” is determined in step S44, and whether or not it is the last conversion element in the next step S45, that is, whether or not there is the next conversion element. Judgment is made.

  Here, if there is the next conversion element, “No” is determined in step S45, and the next conversion element (in this case conversion element 2) acquired from the receiving terminal profile 17 (S23) in next step S46. Then, the process returns to step S43, and the above-described conversion processing from step S43 to step S46 is repeated until there is no next conversion element. Also in the processing of this conversion scenario 2, as in the case of the conversion scenario 1, when the attached file is converted by the specified conversion element, the receiving terminal (MS-2) is used to increase the receivable size as much as possible. It is desirable to delete unnecessary information (for example, additional information such as JPG Exif information and thumbnails).

  On the other hand, if the conversion process from step S43 to step S46 is repeated and there are no conversion elements for the next conversion, “Yes” is determined in step S45, and the next Proceed to step S47. In this step S47, a file (single file) that does not fall below the receivable size even after conversion by the last conversion element is deleted. By deleting a file that did not become smaller than the receivable size even after conversion, a free space is created in the receivable size. Therefore, in step S48, it is determined whether or not the total mail size after conversion by the previous or previous conversion element is equal to or smaller than the receivable size.

If the total mail size after the conversion by the conversion element of the previous time or the previous time is not less than the receivable size, “No” is determined in step S48, and the last converted mail is sent to the mail server 11 (result) Response). As a result, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail converted last in the mail box 12. If the total mail size after the conversion by the previous or previous conversion element is less than the receivable size, “Yes” is determined in step S48, and in the next step S49, the previous or A conversion file based on the conversion element of the previous time is adopted, and the converted mail is transmitted to the mail server 11 (result response). As a result, the mail server 11 stores the converted mail in the mail box 12.

  As described above, in the conversion based on this conversion scenario 2, files that are not smaller than the receivable size (single file) even if converted with the lowest level conversion element are deleted, and the receivable size is made free. For the remaining file, a file whose level is converted by the upper conversion element is adopted, and for example, a high-resolution image file is obtained for the image file.

  Here, an example of mail conversion based on the conversion scenario 2 will be described with reference to FIG. 16 (note that FIG. 16 is a diagram schematically showing the conversion example). In this case, an example of receiving an e-mail having an attached file addressed to the receiving terminal (MS-2) of the account (phone number is 090-0000-0002 and model type is SHAS01) adopting the conversion scenario 2 This will be described below. In this case, the body + header is 1K, the format (content) is BMP, the image 1 of 640 × 480, 60K, 240,000 colors, the format (content) is zip, and there is an attached file consisting of 30K and others. Assume that an e-mail has been received.

  In FIG. 16, since the format (content) of image 1 is BMP, it is not a corresponding content as shown in FIG. 8, so the format (content) is converted to JPG. On the other hand, other zips remain unconverted. The received mail size is 1K for the body + header, the size of the image 1 converted to JPG is 30K, and the size of the other zip is 30K, so the total size of the mail is 61K. Therefore, the size is determined in step S41a. Since the receivable size of this terminal is 30K (see FIG. 10), the first conversion is performed based on the conversion element 1.

Image 1 is converted into 320 × 240, 15K, 240,000 colors by conversion element 1 corresponding to this model (SHAS01 still image conversion element 1 in FIG. 10A). As a result, the total size of the mail is 46K, which exceeds 30K, which is the receivable size of this model, and the second conversion is performed based on the still image conversion element 2. Since the total size of the mail is 41K by the second conversion, the third conversion is performed based on the still image conversion element 3. Thus, since the total size of the mail is 39K, other files (zip) exceeding the receivable size of 30K are deleted.
In this case, a file after the previous conversion with a size of 15K converted based on the conversion element 1 is adopted (see step S48), and a file (content) of 16K in total is stored in the mailbox 12. Become.

4). Processing of Conversion Scenario 3 If “Yes” is determined in step S25 of FIG. 2 and the conversion scenario acquired in step S22 is conversion scenario 3, the conversion function unit 15 determines in step S50 of FIG. The conversion process of conversion scenario 3 is started. Then, in step S51, if the attached file (content) of the received e-mail does not correspond to the content list (see FIGS. 7, 8, and 9) acquired from the user directory 14a, the conversion engine 16 prepares it. The data is converted into a corresponding format using a predetermined conversion engine .

Next, in step S51a, it is determined whether or not the sum of all sizes after format conversion is equal to or smaller than the receivable size (see FIG. 10) of the receiving terminal (MS-2). If the size is less than the receivable size, “Yes” is determined in step S51a, and the converted mail is transmitted to the mail server 11 (result response). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. On the other hand, if the size exceeds the receivable size, “No” is determined in step S51a, and the process proceeds to the next step S52. With a, of the file that is attached to the received e-mail, to specify the files of the last of the accompanying number (n). Thereafter, in step S53, the attached file (content) with the last attached number (n) is converted based on the conversion element 1.

  Next, the process proceeds to step S54, and it is determined whether or not the total mail size after conversion in the attached file (content) with the attached number (n) is less than the receivable size (see FIG. 10). If the size is less than the receivable size, “Yes” is determined in step S54, and the process proceeds to step S27 (see FIG. 2) described above, and the converted mail is stored in the mailbox 12. If the total mail size after conversion exceeds the receivable size, “No” is determined in step S54, and whether or not it is the last conversion element in the next step S55, that is, the next It is determined whether or not there is a conversion element.

If there is a next conversion element, “No” is determined in step S55, and the next conversion element acquired from the receiving terminal profile 17 (S23) in next step S56 (in this case, conversion element 2 is used). Then, the process returns to step S53, and the processes of step S53 to step S56 are repeated until there is no next conversion element. If the next conversion element is not found while the processes in steps S53 to S56 are repeated, the determination in step S55 is “Yes”, and the process proceeds to the next step S57, where the previous attached number ( It is determined whether there is an attachment file (content) of (n-1). If there is no attached file (content) of the previous attached number (n−1), “No” is determined in step S57 , and the converted mail is transmitted to the mail server 11 (result response). As a result, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12.

On the other hand, if there is an attachment file (content) with the previous attachment number (n−1), “Yes” is determined in step S57, and the process proceeds to step S58 to attach the attachment file with the previous attachment number (n−1). After designating (content) as the file to be converted , the process returns to the above-described step S53, and the above-described steps S53, S54, S55, and S57 are repeated until the attached file (content) of the previous attachment number (n-1) is exhausted. , Step S58 is repeatedly executed.

When the above-described steps S53, S54, S55, S57, and S58 are repeatedly executed and the attached file (content) of the previous attached number (n-1) is lost, the process goes to step S57. If “Yes” is determined, the converted mail is transmitted to the mail server 11 (result response). As a result, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. In the conversion scenario 3 as well, in order to increase the receivable size as much as possible, information unnecessary for the receiving terminal (MS-2) (for example, additional information such as JPG Exif information and thumbnails) is deleted. It is desirable to make it.

  As described above, in the conversion based on this conversion scenario 3, conversion is performed for each attached file (content). For this reason, for example, when the converted attached file is an image file, an image file with higher resolution and higher image quality can be obtained.

  Here, a mail conversion example based on the conversion scenario 3 will be described based on FIG. 17 (note that FIG. 17 is a diagram schematically showing a conversion example). In this case, an example of receiving an e-mail having an attached file addressed to the receiving terminal (MS-2) of an account that employs conversion scenario 3 (phone number is 090-0000-0003 and whose model type is SHAU01) This will be described below. In this case, it is assumed that the body + header is 1K, the format (contents) is JPG, and an e-mail having an attached file composed of 320 × 240, 15K, 240,000 color images 1, 2, and 3 is received.

  In FIG. 17, since the format (content) of images 1, 2, and 3 is JPG, it is the corresponding content (see FIG. 8), so the format (content) is converted without conversion. The received mail size is 1K for the body + header, and each of the images 1, 2 and 3 is 15K, so the total size is 46K. Therefore, first, the size is determined in step S51a. Since the receivable size (see FIG. 10) of this model is 30K, the first attachment of the image 3 that is the last attached file based on the conversion element 1 is performed. Perform conversion. Next, the second conversion is performed based on the conversion element 2, and the third conversion is performed based on the conversion element 3. By the third conversion, as shown in FIG. 17, the total size of the mail is 38K, which exceeds the receivable size of 30K.

  For this reason, the image 2 that is the previous attached file is subjected to the fourth conversion based on the conversion element 1, the fifth conversion based on the conversion element 2, and the sixth conversion based on the conversion element 3. Will be done. By the sixth conversion, as shown in FIG. 17, the total size of the mail is 32K, which exceeds the receivable size of 30K. For this reason, the image 1 as the previous attached file is subjected to the seventh conversion based on the conversion element 1 and the eighth conversion based on the conversion element 2. By the eighth conversion, as shown in FIG. 17, the total size of the mail is 27K, which is 30K or less of the receivable size. As a result, the third conversion file for image 3, the sixth conversion file for image 2, and the eighth conversion file for image 1 are stored in mailbox 12.

5. Processing of Conversion Scenario 4 If “Yes” is determined in step S25 of FIG. 2 and the conversion scenario acquired in step S22 is conversion scenario 4, the conversion function unit 15 determines in step S60 of FIG. The conversion process of conversion scenario 4 is started. In step S61, if the attached file (content) of the received e-mail does not correspond to the content list (see FIGS. 7, 8, and 9) acquired from the user directory 14a, the conversion engine 16 prepares it. The data is converted into a corresponding format using a predetermined conversion engine .

Next, in step S61a, it is determined whether or not the sum of all sizes after format conversion is equal to or smaller than the receivable size (see FIG. 10) of the receiving terminal (MS-2). If the size is less than the receivable size, “Yes” is determined in step S61a, and the converted mail is transmitted to the mail server 11 (result response). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. On the other hand, if the size exceeds the receivable size, “No” is determined in step S61a, and the process proceeds to the next step S62. In step S62, the order of the attached file (content) corresponding to the receiving terminal (MS-2) is moved to the top. Next, the conversion element 1 acquired from the receiving terminal profile 17 (S23) is specified in step S63. Thereafter, in step S64, all attached files (contents) attached are converted based on the conversion element 1.

Next, in step S65, it is determined whether or not the total of all converted mail sizes is equal to or smaller than the receivable size (see FIG. 10). If the size is less than the receivable size, it is determined as “Yes” in step S65, and the converted mail is transmitted to the mail server 11 (result response). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. On the other hand, if the size exceeds the receivable size, “No” is determined in step S65, and in the next step S66, whether or not it is the last conversion element, that is, whether or not there is the next conversion element. Judgment is made.

  Here, if there is the next conversion element, it is determined as “No” in step S66, and the next conversion element (in this case conversion element 2) acquired from the receiving terminal profile 17 (S23) in the next step S67. Is specified). Thereafter, the process returns to step S64, and the processes of steps S64 to S67 are repeated until the last conversion element is eliminated. Even in the conversion process of the conversion scenario 4, when the attached file is converted by a specified conversion element, unnecessary information (for example, JPG) is used in the receiving terminal (MS-2) in order to increase the receivable size as much as possible. It is desirable to delete the Exif information and additional information such as thumbnails).

On the other hand, if there is no next conversion element, “Yes” is determined in step S66, the process proceeds to step S68, and a file larger than the receivable size is deleted. Next, in step S69, it is determined whether or not the total size after conversion by the previous or previous conversion element is equal to or smaller than the receivable size. If the total size after conversion exceeds the receivable size, “No” is determined in step S69, and the file that has exceeded the receivable size is transmitted to the mail server 11 (result of the result). respond. As a result, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the file that has exceeded the receivable size in the mail box 12.

If the total size after conversion is equal to or smaller than the receivable size, “Yes” is determined in step S69, and the file converted by the previous or previous conversion element is adopted in step S69a. , The converted mail is transmitted to the mail server 11 (result response). Thereby, the mail server 11 proceeds to the above-described step S27 (see FIG. 2), and stores the converted mail in the mail box 12. As described above, in the conversion based on this conversion scenario 4, the attached file (content) supported by the receiving terminal (MS-2) is moved to the top, and the unsupported attached file (content) is moved backward. Since the conversion process is performed after the transfer, it is possible to see as many attachments (contents) as possible.

  Here, a mail conversion example based on the conversion scenario 4 will be described based on FIG. 18 (note that FIG. 18 is a diagram schematically showing a conversion example). In this case, an example of receiving an e-mail having an attached file addressed to a receiving terminal (MS-2) of an account (phone number is 090-0000-0004 and model type is TSAQ01) adopting conversion scenario 4 This will be described below. In this case, the text + header is 1K, the format (content) is doc and the other file is 20K, the format (content) is GIF, the image is 640 × 480, 40K, 240,000 colors, and the format (content) is It is assumed that an e-mail having an attached file consisting of an image 2 of 320 × 240, 15K, 240,000 colors is received by JPG.

  In FIG. 18, a file whose format is doc, which is another file, is a file (content) that is not subject to conversion, and is therefore not converted. On the other hand, since the JPG of the image 2 is the corresponding content (see FIG. 8), the format (content) conversion is not converted. On the other hand, since the format (content) of the image 1 is GIF, it is an incompatible content (see FIG. 8), so the format is converted to JPG. The received mail size is 1K for the body + header, the other size is 20K, the size of image 1 after conversion to JPG is 30K, and the size of image 2 is 15K, so the total size is 66K. The size is determined in step S61a. Since the terminal has a receivable size of 30K, the first conversion is performed based on the conversion element 1.

  Therefore, first, in order such that the image 1 in the format (JPG) corresponding to the receiving terminal (MS-2: TSAQ01) is No. 1, the image 2 is No. 2, and the other file (doc) is the last. Replace. Then, by performing the first conversion based on the conversion element 1, the total size after conversion becomes 51K as shown in FIG. Since this is a size exceeding the receivable size of 30K, the total size after conversion is 41K by performing the second conversion based on the conversion element 2, and the third conversion is performed based on the conversion element 3. By doing so, the total size after conversion becomes 37K. Since this also exceeds the receivable size of 30K, other large files (doc) are deleted. Thus, since the total size after conversion is 16K, the file after conversion by the previous conversion element 2 in which the total size after conversion is 21K or less and 30K or less is adopted.

  In the fifth conversion example of the conversion scenario 1 described above, an example in which other files (zip) are stored in the mailbox 12 without being converted has been described. However, when the file is acquired by the receiving terminal (MS-2), in the fifth conversion example of FIG. 15, the body, the header, and the image 1 are acquired first by the IMAP method, and the remaining files are received later. You may make it acquire by a request. In this case, when the first e-mail is acquired, the receiving terminal (MS-2) is notified together with the first e-mail as attachment data that the IMAP / POP server has a subsequent file. On the receiving terminal (MS-2) side, by referring to the attached data and making a subsequent reception request to the IMAP / POP server, the other files described above can be acquired.

  If the other file exceeds the receivable size of the receiving terminal (MS-2) (in the example of FIG. 15, the other file (zip) is 30K or more), the IMAP / By referring to the data attached by the POP server, the user of the receiving terminal (MS-2) can know the existence of the subsequent file. However, since it cannot be received at the receiving terminal (MS-2), a server mail transfer procedure (for example, a transfer procedure to a mail address such as a personal computer owned separately by the user of the receiving terminal (MS-2)). By doing this, it is possible to acquire subsequent files.

  These can be similarly performed for the deletion of excess files in the conversion scenario 2 (FIG. 16) and the conversion scenario 4 (FIG. 18) described above. In this case, if the excess file is stored in the mailbox 12 together with the converted e-mail without being deleted, the IMAP server notifies the receiving terminal (MC-2) of the existence of the subsequent file. Good. Of course, it is possible to carry out a mail transfer procedure from the mail box 12 to another electronic mail server and transfer it to a mail address of a personal computer or the like to obtain a file.

It is a block diagram which shows typically schematic structure of the electronic mail storage system of this invention. It is a flowchart which shows the example of the processing operation of the mail server shown by FIG. It is a flowchart which shows the example of the processing operation of the conversion scenario 1 in the processing operation of FIG. 3 is a flowchart illustrating an example of a processing operation of a conversion scenario 2 in the processing operation of FIG. It is a flowchart which shows the example of the processing operation of the conversion scenario 3 in the processing operation of FIG. It is a flowchart which shows the example of the processing operation of the conversion scenario 4 in the processing operation of FIG. It is a figure which shows an example of a user directory. FIG. 8A shows an example of a content list, FIG. 8A shows a content list corresponding to a still image, FIG. 8B shows a content list corresponding to a moving image, and FIG. 8C shows an incoming melody ( A content list corresponding to a MIDI file) is shown. It is a figure which shows a content category list. It is a figure which shows an example of a receiving terminal profile. It is a figure which shows typically the 1st conversion example by the conversion scenario 1. FIG. It is a figure which shows typically the 2nd conversion example by the conversion scenario 1. FIG. It is a figure which shows typically the 3rd conversion example by the conversion scenario 1. FIG. It is a figure which shows typically the 4th conversion example by the conversion scenario 1. FIG. It is a figure which shows typically the 5th conversion example by the conversion scenario 1. FIG. It is a figure which shows the example of a conversion by the conversion scenario 2 typically. It is a figure which shows the example of a conversion by the conversion scenario 3 typically. It is a figure which shows the example of a conversion by the conversion scenario 4 typically. It is a block diagram which shows typically schematic structure of the conventional electronic mail storage system.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... E-mail storage system, 11 ... Mail server, 12 ... Mail box, 13 ... IMAP / POP server, 14 ... Directory server, 14a ... User directory, 15 ... Conversion function part, 16 ... Conversion engine, 17 ... Receiving terminal profile

Claims (8)

An e-mail having an attached file transmitted from a sending terminal or an external mail server is received by the mail server and stored in a mailbox so that the receiving terminal can receive the e-mail stored in the mailbox. Storage method for the received email,
The mail server, a pre-registered conversion scenarios with respect to the transmitting terminal or an external model information and content list of the receiving terminal corresponding to the account corresponding to the relevant mail received address from the mail server and the receiving terminal based on the user directory information including, it acquires the profile information including the pre receivable and registered conversion element and receivable size format to the receiving terminal profile,
The mail server determines whether it is necessary to perform a conversion process on the received e-mail based on the acquired profile information;
In the case of an e-mail that needs to be converted , the mail server is based on a conversion scenario registered in advance with respect to the receiving terminal, and a format that can be received by the receiving terminal based on the acquired profile information and An e-mail storage method, wherein the e-mail is converted to a size and the converted e-mail is stored in the mailbox. Claim wherein the conversion scenario, the e-mail text, in the accompanying order of attachment does not change, which is characterized to include those to perform the conversion process, as reproduced or seen as much as possible all attachments The e-mail storage method according to 1. In the above conversion scenario , do not change the attachment order of the main text and attachments, delete all attachments that exceed the receivable size so that they can be seen as much as possible, and clean as much as possible within the free receivable size. The e-mail storage method according to claim 1, wherein the e-mail storage method includes conversion processing that can be viewed or reproduced. Claim wherein the conversion scenario, text, attachment order of the attachment without changing, characterized in that it is included to perform first attachment conversion process as reproduced or seen cleanly as possible The e-mail storage method according to 1. In the conversion scenario , the attachment order is changed so that the receivable format is moved to the top and the unreceivable format is moved backward, and all attached files are viewed and played as much as possible. method for storing e-mail according to claim 1, characterized in that include those to perform so that conversion process. An e-mail storage system in which an e-mail having an attached file transmitted from a transmission side terminal or an external mail server is stored in a mailbox, and the e-mail stored in the mailbox can be received by the reception side terminal Because
A mail server for receiving an e-mail having the attached file;
User directory information including model information of the receiving terminal corresponding to an account corresponding to the destination of the mail received from the transmitting terminal or an external mail server, a content list, and a conversion scenario registered in advance for the receiving terminal A user directory that stores
A receiving terminal profile for storing profile information including a conversion element of the receiving terminal, a receivable size, and a receivable format;
The mail server needs to acquire user directory information corresponding to a user account stored in the user directory and profile information stored in the receiving terminal profile, and perform conversion processing on the received e-mail. A determination means for determining whether or not
As a result of determination by the determination means, in the case of an e-mail that does not need to be converted, it is stored in the mailbox as it is, and in the case of an e-mail that needs to be converted, it is registered in advance with respect to the receiving terminal An e-mail storage system that converts a received e-mail into a format and size that can be received by the receiving terminal based on a conversion scenario, and stores the converted e-mail in the mailbox. An e-mail server that stores an e-mail having an attached file transmitted from a sending terminal or an external mail server in a mailbox,
A user directory including model information of the receiving terminal corresponding to an account corresponding to the destination of the mail received from the sending terminal or an external mail server, a content list, and a conversion scenario registered in advance for the receiving terminal User directory information acquisition means for acquiring information from the user directory in which the user directory information is stored;
Profile information acquisition means for acquiring profile information including the conversion element, receivable size, and receivable format of the receiving terminal based on the acquired user directory information from the receiving terminal profile in which the profile information is stored;
Conversion judging means for judging whether or not it is necessary to perform conversion processing on the received e-mail based on the acquired profile information;
If the conversion determination means determines that it is not necessary to perform conversion processing, the received e-mail is stored in a mailbox as it is,
When it is determined that the conversion determination unit needs to perform conversion processing, the received electronic mail is transferred to a conversion processing unit, and based on a conversion scenario registered in advance with respect to the receiving terminal in the conversion processing unit. And converting the received terminal into a format and size receivable by the receiving terminal, and storing the converted e-mail in the mailbox. To email server.   8. The electronic mail server according to claim 7, wherein after the electronic mail is stored in the mailbox, a notification that the electronic mail has been received is transmitted to the receiving terminal.

Images