JP4376830B2 - E-mail delivery system - Google Patents

Description

The present invention stores the e-mail sent from the sending terminal apparatus in the mailbox, relates to an electronic mail delivery system adapted to deliver e-mail stored in the mailbox to the receiving terminal apparatus.

  In recent years, mobile communication terminals (transmission-side terminal devices or reception-side terminal devices) such as mobile phones, PHS, and PDAs equipped with an e-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 is performed as follows. First, when an e-mail sender sends an e-mail from a transmitting terminal device to a receiving terminal device, the e-mail is stored in a mail box of a mail distribution server installed in the mobile phone network. The user of the receiving terminal device makes an inquiry to the mail receiving server as needed to check whether a new e-mail is stored in the mailbox, and if the new e-mail is stored in the mailbox, the e-mail Is downloaded to the terminal device on the receiving side to receive the e-mail. In the case of an Internet connection service for a mobile phone, the short message service center (SMSC) notifies the terminal device receiving the e-mail that the e-mail has been received. The electronic mail stored in the mailbox is downloaded to the receiving terminal device through the mail receiving server, and the electronic mail is received.

  By the way, there are various types of mobile communication terminals, the services that can be used differ depending on the model, and the format (contents) of the corresponding multimedia data (image, video, audio, music, office document, etc.) And the size is also different. For this reason, if the sender sends an e-mail with an attached file without knowing the model of the receiving terminal device, the corresponding format (content), size, etc., the receiving terminal device attaches to the e-mail. The problem was that the attached file could not be received. In addition, even when an attached file is received, the receiving terminal device does not support the format (content), and thus there is a problem that it cannot be displayed or used on the receiving terminal device.

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

  An example of such an e-mail receiving system is illustrated in FIG. 20, this e-mail receiving system includes a network 70 including the Internet, a mobile communication network, or a network in which these networks are connected to each other, and a mail distribution server (in this case, a transmission-side mail distribution server 71a). And a receiving mail distribution server 71b), a mail box 72, a mail receiving server 73, a directory server 74, a web space 75, a web server 76, a conversion function unit 77, and a receiving terminal profile 78. A short message service center (SMSC) 79. Note that 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 such an e-mail receiving system will be described as follows. First, when the transmitting terminal device (MS-1) transmits an e-mail containing only text data of a predetermined number of characters, the transmitting mail distribution server 71a installed in the mobile phone network receives the e-mail. Since the transmission side mail distribution server 71a transmits the electronic mail received via the network 70 to the reception side mail distribution server 71b, the reception side mail distribution server 71b that has received the e-mail receives the account of the reception side terminal device (MS-2). Is inquired of the directory server 74 whether the user directory 74a exists.

  As a result, if the account is managed by the receiving terminal device (MS-2), the receiving mail distribution server 71b stores the received e-mail in the mail box 72 and notifies the short message service center (SMSC) 79. To do. Then, the short message service center (SMSC) 79 transmits a notification that the electronic mail has been received to the terminal device (MS-2) that receives the electronic mail. As a result, the receiving terminal device (MS-2) can access (delivery request) the mail receiving server 73 and receive the e-mail stored in the mail box 72.

  On the other hand, if the sending terminal device (MS-1) transmits an e-mail having an attached file (content) such as a photograph and is managed by the receiving terminal device (MS-2) of the e-mail, the receiving is received. The side mail delivery server 71b receives the e-mail, stores the e-mail having the received attached file (content) in the web space 75, and sends the URL and e-mail for accessing the web server 76 to the mail box 72. save. Then, the short message service center (SMSC) 79 transmits a notification that the electronic mail has been received to the receiving terminal device (MS-2) that is the destination of the electronic mail. Thereby, the receiving terminal device (MS-2) accesses (delivery request) the mail receiving server 73 and acquires the URL and the electronic mail stored in the mail box 72.

  When the receiving terminal device (MS-2) accesses the web server 76 based on the acquired URL, the web server 76 attaches to the receiving terminal device (MS-2) stored in the web space 75. The electronic mail having the file (content) is distributed to the receiving terminal device (MS-2). Thereby, the receiving side terminal device (MS-2) can receive the electronic mail. In this case, when the receiving terminal device (MS-2) accesses the web server 76, the receiving terminal device (MS-2) notifies the web server 76 of user agent information for identifying this terminal. As a result, the web server 76 acquires an electronic mail from the web space 75 and transmits it to the conversion function unit 77 to make a conversion request.

  In response to the conversion request, the conversion function unit 77 determines the format (content) and size that can be received by the receiving terminal device (MS-2) from the receiving terminal profile 78 and the received user agent information, and converts the conversion engine 77a. Thus, a conversion process is performed so as to obtain a receivable format (content) and size. After the conversion process, the web server 76 delivers the converted electronic mail to the receiving terminal device (MS-2). As a result, the receiving terminal device (MS-2) can receive the electronic mail, and the attached file (content) can be seen.

  By the way, the reception of an e-mail is normally performed only once. However, in the system as shown in FIG. 20 described above, the web server 76 is accessed after receiving the hosted URL. There is a need. For this reason, the problem that the reception operation | movement of an email was inconvenient occurred. Further, it is necessary to access the web server 76 every time a notification that an e-mail has been received is received. For this reason, the problem that the operation | movement for receiving an email was troublesome occurred. Further, since the web browser software on the receiving terminal device (MS-2) is used for accessing the web server 76, the attached file cannot be saved in the save folder of the software for managing the received e-mail. There was also a restriction that the body and attachments of e-mails created by the sender were stored separately by each software.

  Further, since the e-mail addressed to the receiving terminal device (MS-2) may not necessarily be a message required by the recipient, the web server 76 may not be accessed. In this case, since the attached file (content) addressed to the receiving terminal device (MS-2) stored in the web space 75 is not deleted, it is expected that the capacity of the web space 75 will be compressed. It will be. For this reason, the problem that it is necessary to secure a larger-capacity web space 75 occurs, and the cost for increasing the capacity of the web space 75 also increases.

Therefore, the applicant of the present application (Japanese Patent Application No. 2004-252184), even if the receiving side terminal device has restrictions on the usable format (format), communication speed, memory capacity, data transfer amount, etc. We proposed an e-mail storage system that can receive attached files such as multimedia data such as image files, moving image files, and midi (registered trademark) files, regardless of the restrictions.
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> Kyoko Arata, “E-mail Send / Receive 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> OMA (Open Mobile Alliance) Release Program and Specifications [online] [searched on June 17, 2005], Internet <URL: http://www.openmobilealliance.org/release_program/> W3C (The World Wide Web Consortium) Content Adaptation and Generation Principles for Heterogeneous Clients [online] [searched on June 17, 2005], Internet <URL: http://www.w3.org/2002/07/DIAT/ posn / inria / DIAT-PositionPaper.html>

  By the way, when changing the model of a mobile phone (in this case, a receiving terminal device), a 2G (Second Generation) terminal or PDC terminal, or a 2.5G (2.5 Generation) terminal or PDC packet terminal usually At the shop when the model is changed, the model change system process is performed so that the automatically changed model information is reflected in the user directory storing the account information. For this reason, the model information of the receiving terminal device can be obtained from the account information. However, if it is a 3G (Third Generation) terminal or W-CDMA terminal (method decided by IMT2000) compatible with USIM (Universal Subscriber Identity Module), the model can be changed by simply replacing USIM. Become. For this reason, the directory server storing the model information cannot determine which model the user directory is currently using. As a result, it becomes difficult for the USIM-compatible mobile communication terminal (3G terminal, W-CDMA terminal) to obtain the model information of the receiving terminal device from the account information.

  For this reason, in the system proposed in the above-mentioned Japanese Patent Application No. 2004-252184, information such as the format (contents) and size that can be received by the receiving terminal device is unknown, and when stored in the mailbox This means that the e-mail conversion process cannot be performed. As a result, there arises a problem that an attached file (content) such as multimedia data such as an image file, a moving image file, and a midi file (midi is a registered trademark) corresponding to the receiving terminal device cannot be received.

  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 device (MS-2) at this time are required. However, until the receiving terminal device (MS-2) accesses, information such as the format (content) and size that can be received by the receiving terminal device (MS-2) is unknown. 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.

  In this case, as shown in FIG. 21, a distribution system in which the conversion proxy 85 performs conversion in accordance with the receiving terminal device (MS-2) when taking out an e-mail from the mailbox 82 is an OMA (Open Mobile Alliance: Non-Patent Document 3) and W3C (The World Wide Web Consortium: Non-Patent Document 4). However, in these distribution systems, the user of the receiving terminal device (MS-2) selects and registers a conversion scenario in advance, and converts the e-mail based on the registered conversion scenario. That is, it is impossible to perform conversion according to the user's preference.

  Therefore, the present invention has been made to solve the above problems, and the receiving side terminal device is a USIM compatible mobile communication terminal (3G terminal, W-CDMA terminal), PDA (Personal Digital Assistant) or PC. (Personal Computer) etc., regardless of restrictions on usable formats (formats), communication speed, memory capacity, data transfer amount, etc., multimedia files such as image files, video files, midi (registered trademark) files, etc. It is an object of the present invention to be able to receive an attached file (content) such as data according to the user's preference of the receiving terminal device.

To achieve the above object, in the electronic mail distribution system of the present invention, a mail distribution server for receiving an electronic mail transmitted from a transmission side terminal apparatus and storing the electronic mail in a mailbox, and a reception side terminal apparatus The electronic mail stored in the mailbox is distributed to the receiving terminal device based on the distribution request from the user terminal, and the user identification information and user agent information of the receiving terminal device are acquired at the time of the distribution request from the receiving terminal device Receivable mail server and user account information including user account information and user identification information including conversion scenarios or conversion conditions pre-registered for the receiving terminal device and mailbox location and user identification information the first Prof, including the format list and a convertible content category list such A user directory for storing and yl information, received for storing second profile information concerning the receiving terminal apparatus which a database of information including at least one of receivable size and receivable format and conversion components of the receiving terminal apparatus and terminal profile, so that and at least one or more conversion engine for converting the formats and codecs for multimedia data.

The mail receiving server acquires the user account information and the first profile information from the user directory based on the user identification information acquired at the time of the distribution request from the receiving side terminal device, and the user agent information acquired at the time of the distribution request. Whether or not it is necessary to acquire second profile information related to the receiving terminal device from the receiving terminal profile and to convert the e-mail stored in the mailbox based on the acquired second profile information If the conversion process is determined to be necessary as a result of the determination by the determination means, the conversion engine is used to convert the e-mail based on a conversion scenario that defines a conversion method or conversion condition for user account information. That can be received by the receiving terminal device By converting the size and conversion element, may be converted email to deliver to the receiving terminal.

  Next, an embodiment of the present invention will be described with reference to FIGS. 1 to 19. However, the present invention is not limited to this embodiment, and may be modified as appropriate without departing from the scope of the present invention. Can be implemented. FIG. 1 is a block diagram schematically showing a schematic configuration of the e-mail delivery system of the present invention. FIG. 2 is a flowchart showing an example of the processing operation in the mail receiving server shown in FIG. 3 to 6 are flowcharts showing examples of processing operations in the conversion function unit shown in FIG. FIG. 7 is a diagram showing an example of the outgoing mail. FIG. 8 is a diagram showing an example of a user directory.

  FIG. 9 is a diagram showing an example of a content list. FIG. 10 shows a convertible content category list. FIG. 11 is a diagram showing an example of a receiving terminal profile, FIG. 11 (a) is an example of a profile indicating the model type and receivable size based on the received user agent information, and FIG. 11 (b) is a still image. FIG. 11C shows an example of a profile indicating conversion elements corresponding to a moving image. 12 to 19 are diagrams schematically illustrating content conversion examples.

As shown in FIG. 1, an electronic mail distribution system of the present invention includes a network 10 and a mail distribution server (in this case, a transmission mail distribution server 11a) that receives an electronic mail from a transmission side terminal device (MS-1). The receiving side mail distribution server 11b), the mail box 12 for storing the electronic mail received by the receiving side mail distribution server 11b, and the mail box 12 in response to a distribution request from the receiving side terminal device (MS-2). A mail receiving server 13 for delivering the e-mail stored in the receiving terminal device (MS-2), the mail box location, user identification information (in this case, telephone number, mail address, etc.), and mail transmission / reception A directory server 14 for managing user account information such as necessary information (in this case, conversion scenario: see FIG. 8), A conversion function unit 15 that performs a predetermined conversion process on an attached file (content) attached to an email, a content list corresponding to the receiving terminal device (MS-2), a receivable size, and a conversion element (display size and display color) a receiving terminal profile 17 for storing the second profile information etc.), and a short message service center (SMSC) 18.
In this case, the network 10 includes the Internet, a mobile communication network, or a network in which these networks are connected to each other. In addition, the transmitting terminal device (MS-1) and the receiving terminal device (MS-2) are connected to a terminal device having an Internet connection function or an Internet gateway provided by a mobile communication carrier, and a terminal capable of transmitting and receiving e-mails. A device.

  Here, the transmission side mail distribution server 11a and the reception side mail distribution server 11b are not shown in the figure, but on hardware such as a CPU, RAM, ROM, a storage device such as a hard disk drive (HDD) or an optical disk drive, or a system bus. By executing a predetermined program, a function of receiving an e-mail addressed to an e-mail address assigned to the user of the receiving terminal device (MS-2) or transferring the e-mail is realized. . As such a program, software such as MTA (Message Transfer Agent) is used. A program for operating the transmission side mail distribution server 11a and the reception side mail distribution server 11b according to a predetermined procedure is stored in a ROM or a storage device, and is stored in a work area on the CPU or RAM as necessary. Called and executed. The transmission side mail distribution server 11a and the reception side mail distribution server 11b may be configured by one computer system, or may be configured by connecting a plurality of computers each having a plurality of server functions via a network. Also good.

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

  The mail receiving server 13 is a storage device such as a CPU, a RAM, a ROM, a hard disk drive (HDD) or an optical disk drive (not shown), a system bus, etc. By executing a predetermined program on the hardware consisting of: e-mail stored in the mailbox 12 based on a distribution request from the receiving terminal device (MS-2), the receiving terminal device (MS-2) ) Is delivered. As such a program, software such as MRA (Mail Retrieval Agent) is used. A program for operating the mail receiving server 13 according to a predetermined procedure is stored in a ROM or a storage device, and is called up and executed in a work area on the CPU or RAM as necessary. The mail receiving server 13 may also be configured by a single computer system, like the transmitting mail distribution server 11a and the receiving mail distribution server 11b, or a plurality of computers each having a plurality of server functions may be connected to the network. You may make it comprise by connecting with.

  The directory server 14 is configured by hardware substantially similar to the above-described transmission side mail distribution server 11a, reception side mail distribution server 11b, and mail reception server 13, and the location of the mailbox and user identification information (in this case, A user directory 14a storing user account information such as a telephone number, a mail address, etc. and information necessary for sending and receiving mail (in this case, conversion scenario: see FIG. 8) is connected. In response to a request from the mail receiving server 13, it has a function of transmitting user account information such as user identification information stored in the user directory 14 a in advance to the mail receiving server 13.

In this case, an account (MS-2) of the receiving terminal device (MS-2) is registered in the user directory 14a in advance by a registration request from the owner of the receiving terminal device (MS-2), for example, as illustrated in FIG. Stores user account information in a database of conversion scenarios corresponding to telephone numbers and email addresses. Further, the user directory 14a includes a receiving terminal device (a content list (in this case, content lists from A to I)) corresponding to the receivable format (content) list shown in FIG. MS-2) can be received (content: content type corresponding to still image, content type corresponding to moving image, content type corresponding to incoming melody (midi file), content type corresponding to markup language first profile information etc.) and database are also stored. Also, the convertible content category list shown in FIG. 10, that is, the first profile information in which the convertible format (contents: still image, moving image, incoming melody (midi file), markup language, etc.) category is databased. Stored.

The conversion function unit 15 is composed of substantially the same hardware as the transmission side mail distribution server 11a, the reception side mail distribution server 11b, and the mail reception server 13, and the conversion engine unit 16 is connected to the conversion function unit 15. An optimal conversion engine is selected for each (content). In response to a request from the mail receiving server 13 , the conversion engine unit 16 prepares the received e-mail based on the first and second profile information stored in advance in the user directory 14a and the receiving terminal profile 17 described later. The conversion engine is used to perform a conversion process so as to have a predetermined format, a predetermined codec, and a predetermined size, and to transmit the converted e-mail to the mail receiving server 13.

  In this case, a plurality of conversion engines are prepared in the conversion engine unit 16, and the format (content) of multimedia data is converted, and even in the same data format, different codecs (compression / decompression methods) exist. The codec can be converted. For example, an image conversion engine for converting an image (still image), a video conversion engine for converting video (moving image), a midi conversion engine for converting midi (registered trademark), a document conversion engine for converting a document, HTML A number of conversion engines corresponding to a plurality of multimedia data formats (contents) such as a markup language conversion engine for converting markup languages such as SMIL and SMIL are prepared.

The receiving terminal profile 17 includes a receiving terminal device (User Agent) information (this information is acquired when the receiving terminal device (MS-2) accesses the mail receiving server 13). Database of MS-2) model name, a plurality of display capability information including the receivable size and display color of the receiving terminal device (MS-2), and a plurality of playback capability information including reproduction time and sampling rate Stored second profile information is stored.

For example, as shown in FIG. 11 (a), profile information in which a model name, a content list, and a receivable size of a mobile device corresponding to a user agent are stored in a database is stored. Further, as shown in FIG. 11B, for a still image, a second profile in which display capability information such as display size (vertical and horizontal sizes) and display colors including conversion elements 1, 2, and 3 is made into a database. Information is stored. Furthermore, as shown in FIG. 11 (c), with regard to moving images, display capabilities such as display size (vertical x horizontal size), number of frames (fps), bit rate (kbps), and the like composed of conversion elements 1, 2 and 3 are provided. Stores profile information that is a database of information.

In the case receiving side terminal device (MS-2) other than the mobile station PDA (Personal Digital Assistant) or PC (Personal Computer), user agent (User Agent) information, not the model name of PDA or PC, It is defined for each e-mail software used.

  When the receiving terminal device (MS-2) is a mobile phone that provides Internet connection service, the receivable size is determined in advance for the following reason. Taking a cellular phone network as an example, in a communication network of a generation called PDC (Personal Digital Cellular) or 2G (Second Generation), the data communication speed of the air interface is 9600 bps. The number of bytes is 1200 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 actual data and generally has about 20% of the total information amount, so that the total amount of information that can be transferred as a result (that is, the size that can be received by the receiving terminal device) Is 6 Kbytes.

  Further, in a 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 best effort error rate tolerance is improved, and the receivable size is guaranteed up to 30K bytes. In addition, in the communication network of the generation called W-CDMA system or 3G (Third Generation), the data communication speed is set to 384 Kbps, but the total of actual data derived by the same calculation procedure as that of the 2.5 G network. The amount of bytes is 200 Kbytes. Legacy PDAs have a very small memory capacity of several megabytes, and the e-mail storage capacity per mail is specified to be small.

Next, in the e-mail delivery system configured as described above, the sending side terminal device (MS-1) receives the e-mail having the attached file (content) while referring to the flowcharts of FIGS. A procedure for delivering an e-mail from the mail receiving server 13 when it is transmitted to the apparatus (MS-2) and a procedure for the conversion function unit 15 to convert an attached file (content) will be described below. In this case, the conversion scenario (see FIG. 8) corresponding to the account (telephone number or mail address) of the receiving terminal device (MS-2) is previously requested by the user who owns the receiving terminal device (MS-2). It is assumed that it is registered in the directory 14a. Further, it is assumed that first profile information such as a receivable format (content) list (see FIG. 9) and a convertible content category list (see FIG. 10) is stored in the user directory 14a. In addition, the mobile device model name, content list, receivable size, element information such as conversion elements 1, 2 and 3 for still images and conversion elements 1, 2 and 3 for moving images and reception of mobile devices compatible with user agents It is assumed that second profile information (see FIG. 11) including a database such as possible size information is stored in advance in the receiving terminal profile 17.

  In the present embodiment, the conversion scenarios described above are prepared as conversion scenario 1, conversion scenario 2, conversion scenario 3, and conversion scenario 4, and electronic scenarios are selected based on the conversion scenario selected by the user on the receiving side. Conversion processing of an attached file (content) attached to an email is performed. In this case, in the conversion scenario 1, the conversion process is performed so that all the attached files (contents) can be seen as much as possible without changing the attachment order of the main 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 processing is performed so that all the attached files (contents) can be seen as much as possible without changing the attachment order of the main text and the attached files (contents). However, the data exceeding the receivable size is deleted, and a conversion process is performed so that it can be seen as cleanly as possible (with high resolution) within the empty receivable size. For this reason, the process of the conversion scenario 2 shown to the flowchart of FIG. 4 mentioned later will be performed. Also, in the conversion scenario 3, the conversion process is performed so that the first attached file (content) can be viewed as cleanly as possible (with high quality and high resolution) without changing the attachment order of the body text and the attached file (content). Do. For this reason, the process of the conversion scenario 3 shown in the flowchart of FIG. 5 described later is performed.

  Further, in the conversion scenario 4, the format (content) that can be received by the receiving terminal device (MS-2) is moved to the top, and the format (content) that cannot be received (not supported) is moved backward. The attachment order of attached files (contents) is changed, and conversion processing is performed so that all attached files (contents) 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 according to conversion scenario 1, processing according to conversion scenario 2, processing according to conversion scenario 3, and processing according to conversion scenario 4.

1. Normal Processing Here, the transmission side terminal device (MS-1) transmits an electronic mail as shown in FIG. In the outgoing mail shown in FIG. 7, the header part (A part surrounded by a dotted line), the body part (E-mail body consisting of B part surrounded by a dotted line), and the attached file consisting of C part and D part ( Content), C part is an image file (gif), and D part is a moving image file (mpg). Here, when the transmission side mail distribution server 11a receives the electronic mail from the transmission side terminal device (MS-1), the electronic mail received via the transmission side mail distribution server 11a network 10 is sent to the reception side mail distribution server 11b. Send.

  Then, the receiving side mail distribution server 11b that has received the message inquires the directory server 14 whether or not the account of the receiving side terminal device (MS-2) exists in the user directory 14a. As a result, if the account is managed by the receiving terminal device (MS-2), the receiving mail distribution server 11b stores the received electronic mail in the mail box 12. At the same time, the receiving mail distribution server 11b notifies the short message service center (SMSC) 18 that the e-mail has been received for the receiving terminal device (MS-2), so that the short message service center (SMSC) 18 transmits a notification to the effect that the electronic mail has been received to the receiving terminal device (MS-2).

  As a result, the receiving side terminal device (MS-2) uses a predetermined protocol (in this case, IMAP (Internet Message Access Protocol) / POP (Post Office Protocol) / OMA MMS (OMA Multimedia Messaging Service), etc.) The receiving server 13 is accessed (distribution request). Thereby, in step S21 shown in FIG. 2, the mail receiving server 13 accepts an access (distribution request) from the receiving terminal device (MS-2) by a predetermined protocol (IMAP / POP / OMA MMS or the like). Then, the mail receiving server 13 determines the account (phone number and mail address) and user agent of the receiving terminal device (MS-2) based on the access (delivery request) from the receiving terminal device (MS-2). get.

In step S22, the model name of the mobile device currently in use of the receiving terminal device (MS-2) is acquired based on the acquired user agent (see FIG. 11A). Then, from the acquired model name, the second profile information such as the content list, the receivable size, the receivable format, and the conversion element is stored in the database (see FIGS. 11A, 11B, and 11C) stored in the receiving terminal profile 17. ) Through the conversion function unit 15, and the second profile information such as the acquired receivable size, receivable format, and conversion element is transferred to the conversion function unit 15.

Next, in step S23, user account information such as a conversion scenario corresponding to the user identification information including the acquired account (phone number) and mail address is stored in a directory from the database (for example, see FIG. 8) stored in the user directory 14a. The first profile information such as a receivable format (content) list (see FIG. 9) and a convertible content category list (see FIG. 10) is acquired from the database from the database stored in the user directory 14a. Obtained via the server 14. Then, the acquired user account information and first profile information are transferred to the conversion function unit 15.

Next, the process proceeds to step S24, where an e-mail addressed to the account (phone number and e-mail address) of the receiving terminal device (MS-2) is read from the mailbox 12 and the Internet based on the RFC (Request For Comment) specification is read. Perform email analysis according to email rules. For example, in the case of the e-mail shown in FIG. 7, for each part of a plurality of MIMEs (Multipurpose Internet Mail Extensions), that is, the e-mail body of B part, the attachment file (gif file) of C part, and the attachment of D part E-mail is decomposed for each file (mpg file). Then, the size of the attached file (content) and the type of the attached file (content) are determined from the headers of each decomposed MIME. Thereafter, in step S25, based on the result of analyzing the e-mail in the previous step S24, that is, based on the second profile information such as the acquired receivable size, receivable format, and conversion element. It is determined whether the converted e-mail needs to be converted.

  In this case, an attached file (content) in a format (content) that is not supported (not receivable) by the receiving terminal device (MS-2) is not attached, and the total size of the received e-mail can be received. If it is less than the size, it is determined as “No” in step S25. Then, in the next step S28, the electronic mail stored in the mail box 12 is delivered as it is to the receiving terminal device (MS-2). On the other hand, an attached file (content) in a format (content) that is not supported (not receivable) by the receiving terminal device (MS-2) is attached, or the total size of the received e-mail exceeds the receivable size If so, “Yes” is determined in step S25.

  Then, in the next step S26, the electronic mail read from the mailbox 12 is transferred to the conversion function unit 15, and based on the conversion scenario transferred in step S22 and acquired by the conversion function unit 15. 15 performs the conversion process of the electronic mail based on the conversion scenario. Thereafter, the mail receiving server 13 receives the converted e-mail converted by the conversion function unit 15 from the conversion function unit 15 in step S27, and receives the converted e-mail in the next step S28. Delivered to the terminal device (MS-2).

  If the acquired conversion scenario is conversion scenario 1, the conversion function unit 15 executes the processing of conversion scenario 1 based on the flowchart of FIG. Similarly, if the acquired conversion scenario is conversion scenario 2, the conversion function unit 15 executes processing of conversion scenario 2 based on the flowchart of FIG. 4, and if it is conversion scenario 3, conversion is performed based on the flowchart of FIG. The process of scenario 3 is executed, and if it is conversion scenario 4, the process of conversion scenario 4 is executed based on the flowchart of FIG.

2. Processing of Conversion Scenario 1 If the conversion scenario transferred in step S23 and received by the conversion function unit 15 is conversion scenario 1, the conversion function unit 15 converts the conversion scenario 1 in step S30 of FIG. Start processing. Then, in step S31, it is determined whether the file (attached to the received e-mail) needs to be converted in format (content). Here, if the file attached to the received e-mail is listed in the receivable format (content) list (see FIG. 9) corresponding to the content list acquired from the user directory 14a in step S23 described above. Since there is no need to convert the format (content), “No” is determined in step S31, and the process proceeds to step S31b.

  On the other hand, if the file attached to the received e-mail does not exist in the receivable format (content) list (see FIG. 9), “Yes” is determined in step S31, and the process proceeds to step S31a. If it is listed in the convertible content category list (see FIG. 10) acquired from the user directory 14a in step S23, it can be converted to the content 1 in the receivable format (content) list (see FIG. 9). The conversion engine unit 16 is selected to select a conversion engine, and the conversion engine unit 16 requests conversion of the format (content) of the attached file of the e-mail received by the conversion engine.

  In this case, the conversion engine unit 16 includes the content 1 in the format (content) list (see FIG. 9) that can be received from the prepared image conversion engine, video conversion engine, midi conversion engine, document conversion engine, markup language conversion engine, and the like. The conversion engine corresponding to is selected, and the format (content) conversion process is executed using the selected conversion engine. Thereafter, the conversion function unit 15 acquires the format (content) converted by the conversion engine unit 16, attaches the file of the format (content) to the e-mail, and re-converts it into an e-mail form.

  For example, the phone number is “090-0000-0001” (in the case of this account, as shown in FIG. 11, the model name of the mobile device in use is specified as V802SH from the user agent (Vodafone / 1.0 / V802SH), The content list is G. Then, as shown in FIG. 8, when an e-mail having an attached file whose format (content) is bmp is received for a conversion scenario (conversion scenario 1), it corresponds to a still image. The formats (contents) to be performed are jpg and png from the receivable format (content) list (see FIG. 9). In this case, since bmp is listed in the still image category of the convertible content category list (see FIG. 10), it is converted into jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9). Need to be done. Therefore, the conversion function unit 15 uses the image conversion engine prepared in the conversion engine unit 16 for the attached file whose format (content) is bmp, and converts the bmp format (content) to the jpg format (content). Convert it. Thereby, the conversion function part 15 transmits the converted e-mail to the mail receiving server 13, and the mail receiving server 13 distributes the converted e-mail to the receiving terminal device (MS-2).

  Here, when the format (content) conversion of the attached file is performed, the size may be reduced due to the characteristics of the format (content). For example, in the case of jpg, parameters such as an image sampling rate and a quality value are determined in a range where normal quality is not deteriorated as compared with bmp, and an image is compressed by format (content) conversion. In this case, in the next step S31b, it is determined whether or not the total mail size is equal to or smaller than the receivable size of the receiving terminal device (MS-2).

  If it is equal to or smaller than the receivable size, the conversion function unit 15 determines “Yes” in step S31b, and transmits an e-mail having the converted format (content) to the mail receiving server 13 in step S37. To do. Then, the mail receiving server 13 receives the email having the format (content) after the conversion in step S27 (see FIG. 2) described above, and proceeds to the next step S28 to receive the converted email. This is distributed to the terminal device (MS-2).

On the other hand, if the size is larger than the receivable size, the conversion function unit 15 determines “No” in step S31b, and proceeds to the next step S32. Next, the conversion element 1 is designated from the second profile information acquired in step S32. Thereafter, in step S33, the format (content) of all attached files is 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 sizes after conversion is equal to or smaller than the receivable size (see FIG. 11) of the receiving terminal device (MS-2). Here, if it is less than the receivable size, “Yes” is determined in step S 34, and an e-mail having the converted format (content) is transmitted to the mail receiving server 13.

  On the other hand, if it is larger than the receivable size, it is determined as “No” in step S34, and in the next step S35, whether or not it is the last conversion element, that is, whether or not there is the next conversion element. Make a decision. Here, when there is no next conversion element, it determines with "Yes" in step S35, and transmits the email which consists of a format (content) after conversion to the mail receiving server 13. FIG. As a result, the mail receiving server 13 proceeds to the above-described step S28 (see FIG. 2), and distributes the electronic mail having the converted format (content) to the receiving terminal device (MS-2).

On the other hand, if there is a next conversion element, “No” is determined in step S35, and the next conversion element (in this case, conversion element 2) is determined from the second profile information acquired in next step S36. After the designation, 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 format (content) of the attached file is converted by the designated conversion element, it is not necessary for the receiving terminal device (MS-2) to increase the receivable size as much as possible. It is desirable to delete information (for example, additional information such as jpg Exif information and thumbnails).

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

(1) First Conversion Example First, a first 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 first conversion example). In this case, the size of the body + header is 1K, the display size is 640 × 480, the image size is 30K, the display color is 240,000 colors, the display size is 640 × 480, and the image size is 30K. Assume that an e-mail having an attached file composed of an image 2 having a display color of 240,000 colors is received. In FIG. 12, the format (content) of the attached file (images 1 and 2) is jpg. In the case of this account (090-0000-0001), as shown in FIG. 11, the user agent (Vodafone / 1.0 / V802SH) The model name of the mobile device in use is specified as V802SH, the content list is G, and the conversion scenario is conversion scenario 1 as shown in FIG.

  Then, from the receivable format (content) list corresponding to the content list G shown in FIG. 9, it can be seen that the model of the mobile device in use is a receivable format (content) (jpg). Will not be converted. In this case, since the received e-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, the total size of the e-mail is 61K. Therefore, the first conversion is performed based on the conversion element 1.

  With the conversion element 1 (V802SH still image conversion element 1 in FIG. 11B) corresponding to this model (V802SH), the conversion function unit 15 uses the image conversion engine prepared in the conversion engine unit 16, Both image 1 and image 2 have a display size of 320 × 240, an image size of 15K, and a display color of 240,000 colors. As a result, the total size of the e-mail is 31K, which exceeds 30K, which is the receivable size of this model, and the second size conversion is performed based on the still image conversion element 2. As a result of the second size conversion, the total size of the e-mail becomes 21K. Therefore, the conversion function unit 15 adopts this and transmits the converted e-mail to the mail receiving server 13. As a result, the mail receiving server 13 delivers the e-mail attached with the converted format (content) to the receiving terminal device (MS-2).

(2) Second Conversion Example Next, a second 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 second conversion example). In this case, the size of the body + header is 1K, the format (content) is bmp, the display size is 640 × 480, the image size is 60K, the display color is 240,000 colors, and the format (content). It is assumed that an e-mail having an attached file composed of an image 2 of bmp, a display size of 640 × 480, an image size of 60K, and a display color of 240,000 colors is received. In the case of this account (090-0000-0001), as shown in FIG. 11, the model name of the mobile device in use is specified as V802SH from the user agent (Vodafone / 1.0 / V802SH), and the content list is G. As shown in FIG. 8, the conversion scenario is conversion scenario 1.

  Then, from the receivable format (content) list corresponding to the content list G shown in FIG. 9, it can be seen that bmp is not a jpg or png that is a receivable format (content) for the mobile device in use. In this case, since bmp is listed in the still image category of the convertible content category shown in FIG. 10, conversion to jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9) is performed. Will be performed. Then, the image 1 is converted into a jpg format (content) having a display size of 640 × 480, an image size of 30K, and a display color of 240,000 colors, and the image 2 has a display size of 640 × 480 and an image size of At 30K, the display color is converted to 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 size of the converted file size is 61K. Therefore, the size is determined in step S31b. Since the receivable size of this terminal is 30K (see FIG. 11), the first size conversion is performed based on the conversion element 1. With the conversion element 1 (V802SH still image conversion element 1 in FIG. 11B) corresponding to this model (V802SH), the display size of both the image 1 and the image 2 is 320 × 240, the image size is 15K, The display color is converted to 240,000 colors.

  As a result, the total size of the e-mail is 31K, which exceeds the receivable size of this model (V802SH), which is 30K. Therefore, the second size conversion is performed based on the still image conversion element 2. As a result of the second size conversion, the total size of the e-mail becomes 21K. Therefore, the conversion function unit 15 adopts this and transmits the converted e-mail to the mail receiving server 13. As a result, the mail receiving server 13 delivers the e-mail attached with the converted format (content) to the receiving terminal device (MS-2).

(3) Third Conversion Example Next, a third conversion example based on the conversion scenario 1 will be described based on FIG. 14 (note that FIG. 14 is a diagram schematically showing the third conversion example). In this case, the size of the body + header is 1K, the format (content) is bmp, the display size is 640 × 480, the image size is 60K, the display color is 240,000 colors, and the format (content). Assume that an e-mail having an attached file consisting of a moving image 1 having a size of 3 gp, a display size of 176 × 144, a frame number of 30 fps, a bit rate of 64 kbps, and a size of 60K is received. In the case of this account (090-0000-0001), as shown in FIG. 11, the model name of the mobile device in use is specified as V802SH from the user agent (Vodafone / 1.0 / V802SH), and the content list is G. As shown in FIG. 8, the conversion scenario is conversion scenario 1.

  Then, from the receivable format (content) list corresponding to the content list G shown in FIG. 9, it can be seen that bmp is not a jpg or png that is a receivable format (content) for the mobile device in use. In this case, since bmp is listed in the still image category of the convertible content category shown in FIG. 10, conversion to jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9) is performed. Will be performed. On the other hand, in 3GP, since the model of the mobile device in use is listed in the receivable format (content), the format (content) is not converted. The image 1 is converted into a jpg format (content) having a display size of 640 × 480, an image size of 30K, and a display color of 240,000 colors.

  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. Therefore, the total file size is 91K. It becomes. Therefore, the size is determined in step S31b. Since the receivable size of this model (V802SH) is 30K (see FIG. 11), the first size conversion is performed based on the conversion element 1. Become. With the conversion element 1 (the still image conversion element 1 in FIG. 11B and the moving image conversion element 1 in FIG. 11C) corresponding to this model (V802SH), the display size of the image 1 is 320 × 240. The image size is 15K, the display color is converted to 240,000 colors, and the moving image 1 is converted to a display size of 176 × 144, the number of frames is 15 fps, the bit rate is 64 kbps, and the size is 30K.

  As a result, the total size of the e-mail becomes 46K, which exceeds 30K, which is the receivable size of this model (V802SH). Therefore, the second size conversion is performed based on the still image and moving image conversion element 2 as shown in FIG. Even in the second size conversion, the total size of the e-mail does not become 30K or less at 35K, so the third size conversion is performed based on the still image and moving image conversion element 3. As a result, the total size of the e-mail is 21K as shown in FIG. 14, and the conversion function unit 15 adopts this to transmit the converted e-mail to the mail receiving server 13. As a result, the mail receiving server 13 delivers an electronic mail having an attached file having the converted format (content) to the receiving terminal device (MS-2).

(4) Fourth Conversion Example Next, a fourth 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 fourth conversion example). In this case, the size of the body + header is 1K, the format (content) is bmp, the display size is 640 × 480, the image size is 60K, the display color is 240,000 colors, and the format (content). Is a mid-size 5K incoming melody (midi), format (content) is 3gp, display size is 176x144, number of frames is 30fps, bit rate is 64kbps, and from video 1 with size 60K Assume that an e-mail having an attached file is received.

  In the case of this account (090-0000-0001), as shown in FIG. 11, the model name of the mobile device in use is specified as V802SH from the user agent (Vodafone / 1.0 / V802SH), and the content list is G. As shown in FIG. 8, the conversion scenario is conversion scenario 1. Then, from the receivable format (content) list corresponding to the content list G shown in FIG. 9, it can be seen that bmp is not a jpg or png that is a receivable format (content) for the mobile device in use. In this case, since bmp is listed in the still image category of the convertible content category shown in FIG. 10, conversion to jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9) is performed. Will be performed. In addition, it can be seen that the type of mobile device being used is not mmf or smd which is a receivable format (content). In this case, mid is listed in the ringtone melody (midi) category of the convertible content category shown in FIG. 10, so that the ringtone melody (midi) in the receivable format (content) list (see FIG. 9) is displayed. Conversion to mmf corresponding to the content 1 is performed.

  On the other hand, the file size is the body + header size is 1K, 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 moving image 1 is 60K. The total size is 96K. Therefore, as described above, after determining whether or not the size is receivable in step 31b, the conversion is performed so that the receivable size of this model (V802SH) is 30K or less as shown in FIG. The first size conversion is performed based on the element 1, the second size conversion is performed based on the conversion element 2, and the third size conversion is performed based on the conversion element 3. As a result, as shown in FIG. 15, the total size of the e-mail becomes 26K by the third size conversion, and the conversion function unit 15 adopts this and transmits the converted e-mail to the mail receiving server 13. As a result, the mail receiving server 13 delivers an electronic mail having an attached file having the converted format (content) to the receiving terminal device (MS-2).

(5) Fifth Conversion Example Next, a fifth conversion example based on the conversion scenario 1 will be described based on FIG. 16 (note that FIG. 16 is a diagram schematically showing the fifth conversion example). In this case, the size of the body + header is 1K, the format (content) is bmp, the display size is 640 × 480, the image size is 60K, the display color is 240,000 colors, and the format (content) is Assume that an e-mail having other attached files of the size image 30K is received by zip. In the case of this account (090-0000-0001), as shown in FIG. 11, the model name of the mobile device in use is specified as V802SH from the user agent (Vodafone / 1.0 / V802SH), and the content list is G. As shown in FIG. 8, the conversion scenario is conversion scenario 1.

  Then, from the receivable format (content) list corresponding to the content list G shown in FIG. 9, it can be seen that bmp is not a jpg or png that is a receivable format (content) for the mobile device in use. In this case, since bmp is listed in the still image category of the convertible content category shown in FIG. 10, conversion to jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9) is performed. Will be performed. In addition, it can be seen that the type of mobile device in use is not a receivable format (content). In this case, the zip is listed in the other of the convertible content categories shown in FIG. 10, but is not present in the other items of the receivable format (content) list (see FIG. 9). Will remain.

  On the other hand, since the size of the body + header is 1K, the size of the image 1 converted to jpg is 30K, and the size of the unconverted zip is 30K, the total size is 61K. Therefore, after determining whether or not the size is receivable in step S31b, the first size conversion is performed based on the conversion element 1 and the second time based on the conversion element 2 as shown in FIG. Size conversion is performed, and the third size conversion is performed based on the conversion element 3. In this case, the total size becomes 39K by the third size conversion, and does not become 30K or less, which is the receivable size of this model (V802SH). Therefore, the image 1 converted to jpg has a display size of 160 × 120, a display color of 240,000 colors, an image size of 8K, a zip file with no conversion (still 30K), and mail reception Transmit to the server 13. As a result, the mail receiving server 13 delivers the e-mail attached with the converted image 1 and the non-converted zip file to the receiving terminal device (MS-2).

3. Processing of Conversion Scenario 2 If the conversion scenario transferred in step S23 and received by the conversion function unit 15 is conversion scenario 2, the conversion function unit 15 converts the conversion scenario 2 in step S40 of FIG. Start processing. Then, in step S41, it is determined whether the file attached to the received e-mail needs to be converted in format (content). Here, if the file attached to the received e-mail is listed in the receivable format (content) list (see FIG. 9) corresponding to the content list acquired from the user directory 14a in step S23 described above. Since there is no need to convert the format (content), “No” is determined in step S41, and the process proceeds to step S41b.

  On the other hand, if the file attached to the received e-mail does not exist in the receivable format (content) list (see FIG. 9), “Yes” is determined in step S41, and the process proceeds to step S41a. If it is listed in the convertible content category list (see FIG. 10) acquired from the user directory 14a in step S23, it can be converted to the content 1 in the receivable format (content) list (see FIG. 9). The conversion engine unit 16 is selected to select a conversion engine, and the conversion engine unit 16 requests conversion of the format (content) of the attached file of the e-mail received by the conversion engine.

  In this case, the conversion engine unit 16 includes the content 1 in the format (content) list (see FIG. 9) that can be received from the prepared image conversion engine, video conversion engine, midi conversion engine, document conversion engine, markup language conversion engine, and the like. The conversion engine corresponding to is selected, and the format (content) conversion process is executed using the selected conversion engine. Thereafter, the conversion function unit 15 acquires the format (content) converted by the conversion engine unit 16, attaches the file of the format (content) to the e-mail, and re-converts it into an e-mail form.

  Next, in step S41b, it is determined whether or not the total size of all e-mails is equal to or smaller than the receivable size (see FIG. 11) of the receiving terminal device (MS-2). If the size is less than the receivable size, the conversion function unit 15 determines “Yes” in step S41b, and transmits an e-mail to the mail receiving server 13 in step S49a. Then, the mail receiving server 13 receives the converted e-mail from the conversion function unit 15 in step S27 (see FIG. 2) described above, and proceeds to the next step S28. The electronic mail is distributed to the receiving terminal device (MS-2).

On the other hand, if the size exceeds the receivable size, “No” is determined in step S41b, and the process proceeds to the next step S42. In step S42, the conversion element 1 is designated from the acquired second profile information (see FIG. 11). Thereafter, in step S43, all attached files are converted based on the conversion element 1. Next, the process proceeds to step S44, and it is determined whether or not the total of all the converted e-mail sizes is equal to or smaller than the receivable size (see FIG. 11) of the receiving terminal device (MS-2).

If the size is less than the receivable size, “Yes” is determined in step S44, and the converted e-mail is transmitted to the mail receiving server 13 in step S49a. 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. If there is a next conversion element, “No” is determined in step S45, and the next conversion element (in this case, conversion element 2 is obtained) from the acquired second profile information 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 conversion scenario 1, when the format (contents) is converted by a specified conversion element, in order to increase the receivable size as much as possible, the receiving side terminal device ( It is desirable to delete information unnecessary for MS-2) (for example, additional information such as jpg Exif information and thumbnails).

  If the conversion element from the step S43 to the step S46 is repeatedly executed and there is no conversion element for the next conversion, it is determined as “Yes” in the step S45, and the next Proceed to step S47. In 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 the conversion, the receivable size becomes empty. Therefore, in step S48, it is determined whether or not the size of all e-mails after conversion by the previous or previous conversion element is equal to or less than the receivable size.

  If the total e-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 format (contents) is converted in step S49a. The e-mail attached with the file is sent to the mail receiving server 13. If the total e-mail size after conversion by the previous or previous conversion element is less than the receivable size, “Yes” is determined in step S48, and the conversion function unit 15 converts in step S49. As a file having a later format (content), a conversion file by a conversion element of the previous time or the previous time is adopted and transmitted to the mail receiving server 13.

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

  Here, an example of e-mail conversion based on the conversion scenario 2 will be described based on FIG. 17 (note that FIG. 17 is a diagram schematically showing the conversion example). In this case, an e-mail having an attached file addressed to the receiving terminal device (MS-2) of the account (phone number is 090-0000-0002 and model type is V802SE) adopting the conversion scenario 2 is received. Examples are described below. In this case, the size of the body + header is 1K, the format (content) is bmp, the display size is 640 × 480, the image size is 60K, the display color is 240,000 colors, and the format (content) Assume that an e-mail having a file with a size of 30K is received. In the case of this account (090-0000-0002), as shown in FIG. 11, the model name of the mobile device in use is specified as V802SE from the user agent (Vodafone / 1.0 / V802SE), and its content list is H. As shown in FIG. 8, the conversion scenario is conversion scenario 2.

  Then, from the receivable format (content) list corresponding to the content list H shown in FIG. 9, it can be seen that bmp is a receivable format (content) jpg or png for the type of mobile device in use. In this case, since bmp is listed in the still image category of the convertible content category shown in FIG. 10, conversion to jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9) is performed. Will be performed. On the other hand, other zips remain unconverted. The size of the received email 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. Therefore, the total size of the email is 61K. Become. Therefore, the size is determined in step S41b. Since the receivable size of this mobile device model (V802SE) is 30K (see FIG. 11), the first size conversion is performed based on the conversion element 1. It becomes.

With conversion element 1 (V802SE still image conversion element 1 in FIG. 11B) corresponding to this model (V802SE), image 1 has a display size of 320 × 240, an image size of 15K, and a display color of 24. It is converted to become all colors. As a result, the total size of the e-mail becomes 46K, which exceeds the receivable size of this model, which is 30K. Therefore, the second size conversion is performed based on the still image conversion element 2. As a result of the second size conversion, the total size of the e-mail becomes 41K. Therefore, the third size conversion is performed based on the still image conversion element 3. As a result, the total size of the e-mail becomes 39K, and thus a file (zip) having another format (content) exceeding the receivable size of 30K is deleted.
In this case, a file composed of a format (content) after the previous conversion with a size of 15K converted based on the conversion element 1 is adopted (see step S48), and a file composed of a format (content) of a total of 16K is adopted. The attached e-mail is distributed to the receiving terminal device (MS-2).

4). Processing of Conversion Scenario 3 If the conversion scenario transferred in step S22 and received by the conversion function unit 15 is conversion scenario 3, the conversion function unit 15 converts the conversion scenario 3 in step S50 of FIG. Start the conversion process. Then, in step S51, it is determined whether the file (attached to the received e-mail) needs to be converted in format (content). Here, if the file attached to the received e-mail is listed in the receivable format (content) list (see FIG. 9) corresponding to the content list acquired from the user directory 14a in step S23 described above. Since there is no need to convert the format (content), “No” is determined in step S51, and the process proceeds to step S51b.

  On the other hand, if the file attached to the received e-mail does not exist in the receivable format (content) list (see FIG. 9), “Yes” is determined in step S51, and the process proceeds to step S51a. If it is listed in the convertible content category list (see FIG. 10) acquired from the user directory 14a in step S23, it can be converted to the content 1 in the receivable format (content) list (see FIG. 9). The conversion engine unit 16 is selected to select a conversion engine, and the conversion engine unit 16 requests conversion of the format (content) of the attached file of the e-mail received by the conversion engine.

  In this case, the conversion engine unit 16 includes the content 1 in the format (content) list (see FIG. 9) that can be received from the prepared image conversion engine, video conversion engine, midi conversion engine, document conversion engine, markup language conversion engine, and the like. The conversion engine corresponding to is selected, and the format (content) conversion process is executed using the selected conversion engine. Thereafter, the conversion function unit 15 acquires the format (content) converted by the conversion engine unit 16, attaches the file of the format (content) to the e-mail, and re-converts it into an e-mail form.

  Next, in step S51b, it is determined whether or not the total of all e-mail sizes is less than or equal to the receivable size (see FIG. 11) of the receiving terminal device (MS-2). If the size is less than the receivable size, “Yes” is determined in step S51b, and an e-mail is transmitted to the mail receiving server 13 in step S59. Then, the mail receiving server 13 receives the e-mail attached with the file having the converted format (content) from the conversion function unit 15 in the above-described step S27 (see FIG. 2), and proceeds to the next step S28. Thus, the electronic mail is delivered to the receiving terminal device (MS-2).

On the other hand, if the size exceeds the receivable size, “No” is determined in step S51b, and the process proceeds to the next step S52. Next, the conversion element 1 is designated from the second profile information (see FIG. 11) acquired in step S52, and the file with the last attached number (n) is designated among the files attached to the received electronic mail. Thereafter, in step S53, the attached file 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 of the converted e-mail size in the attached file with the attached number (n) is smaller than the receivable size (see FIG. 11).

Here, if the size is less than the receivable size, “Yes” is determined in step S54, and an e-mail attached with a file having the converted format (content) is sent to the mail receiving server 13 in step S59. Send. On the other hand, if the total size of the converted e-mail 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, Then, it is determined whether or not there is the next conversion element. If there is a next conversion elements, and a "No" determination at step S55, the following conversion factors (in this case from the acquired second profile information (see FIG. 11) in the next step S56 and the conversion element 2 After that, the process returns to step S53, and the processes of step S53 to step S56 are repeatedly executed 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”, the process proceeds to the next step S57, and the previous attached number ( It is determined whether or not the attachment file of (n-1) exists. If there is no attached file with the previous attached number (n−1), “No” is determined in step S57, and an e-mail with the converted format (content) attached is received in step S59. Transmit to the server 13.

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

  If the above-mentioned steps S53, S54, S55, S57, and S58 are repeatedly executed and there is no attached file with the previous attached number (n−1), “No” is returned in step S57. In step S59, an e-mail attached with the converted format (content) is transmitted to the mail receiving server 13. Then, the mail receiving server 13 receives the e-mail attached with the converted format (content) in the above-described step S27 (see FIG. 2), proceeds to the next step S28, and converts the converted format (content). ) Is attached to the receiving terminal device (MS-2).

Even in the process of the conversion scenario 3, information unnecessary for the receiving terminal device (MS-2) (for example, additional information such as jpg Exif information and thumbnails) is deleted in order to increase the receivable size as much as possible. It is desirable to do so.
As described above, in the conversion based on the conversion scenario 3, conversion is performed for each format (content) of the attached file. For this reason, for example, when the format (content) of the converted attached file is an image, a higher-resolution and higher-quality image can be obtained.

Here, an e-mail conversion example based on the conversion scenario 3 will be described with reference to FIG. 18 (note that FIG. 18 is a diagram schematically showing the conversion example). In this case, an e-mail having an attached file addressed to the receiving terminal device (MS-2) of an account that employs conversion scenario 3 (phone number is 090-0000-0003 and model type is V802SE) is received. Examples are described below. In this case, the size of the body + header is 1K, the format (content) is jpg, the display size is 320 × 240, the image size is 15K, and the display color is composed of images 1, 2, and 3 of 240,000 colors. Assume that an e-mail with an attached file is received.
In the case of this account (090-0000-0003), as shown in FIG. 11, the model name of the mobile device in use is specified as V802SE from the user agent (Vodafone / 1.0 / V802SE), and the content list is H. As shown in FIG. 8, the conversion scenario is conversion scenario 3.

  Then, from the receivable format (content) list corresponding to the content list H shown in FIG. 9, since jpg is a receivable format (content) in the mobile device model being used, the format (content) conversion is performed. No conversion. The received e-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, the size is first determined in step S61b. Since the receivable size (see FIG. 11) of this model (V802SE) is 30K, the image 3 that is the last attached file based on the conversion element 1 is used. Perform the first size conversion. Next, the second size conversion is performed based on the conversion element 2, and the third size conversion is performed based on the conversion element 3. By the third size conversion, as shown in FIG. 18, the total size of the e-mail is 39K, which exceeds the receivable size of 30K.

  For this reason, the image 2 that is the previous attached file is subjected to the fourth size conversion based on the conversion element 1, the fifth size conversion is performed based on the conversion element 2, and the sixth time conversion is performed based on the conversion element 3. Size conversion will be performed. As a result of the sixth size conversion, as shown in FIG. 18, the total size of the e-mail becomes 32K, which exceeds the receivable size of 30K. For this reason, with respect to the image 1 as the previous attached file, the seventh size conversion is performed based on the conversion element 1, and the eighth size conversion is performed based on the conversion element 2. By the eighth size conversion, as shown in FIG. 18, the total size of the e-mail is 27K, which is 30K or less of the receivable size. As a result, the third size conversion file is used for image 3, the sixth size conversion file is used for image 2, the eighth size conversion file is used for image 1, and these files are attached. The electronic mail is delivered to the receiving terminal device (MS-2).

5. Processing of Conversion Scenario 4 If the conversion scenario transferred in step S22 and received by the conversion function unit 15 is conversion scenario 4, the conversion function unit 15 converts the conversion scenario 4 in step S60 of FIG. Start the conversion process. Then, in step S61, it is determined whether the file (attached to the received e-mail) needs to be converted in format (content). Here, if the file attached to the received e-mail is listed in the receivable format (content) list (see FIG. 9) corresponding to the content list acquired from the user directory 14a in step S23 described above. Since there is no need to convert the format (content), “No” is determined in step S61, and the process proceeds to step S61b.

  On the other hand, if the file attached to the received e-mail does not exist in the receivable format (content) list (see FIG. 9), “Yes” is determined in step S61, and the process proceeds to step S61a. If it is listed in the convertible content category list (see FIG. 10) acquired from the user directory 14a in step S23, it can be converted to the content 1 in the receivable format (content) list (see FIG. 9). The conversion engine unit 16 is selected to select a conversion engine, and the conversion engine unit 16 requests conversion of the format (content) of the attached file of the e-mail received by the conversion engine.

  In this case, the conversion engine unit 16 includes the content 1 in the format (content) list (see FIG. 9) that can be received from the prepared image conversion engine, video conversion engine, midi conversion engine, document conversion engine, markup language conversion engine, and the like. The conversion engine corresponding to is selected, and the format (content) conversion process is executed using the selected conversion engine. Thereafter, the conversion function unit 15 acquires the format (content) converted by the conversion engine unit 16, attaches the file of the format (content) to the e-mail, and re-converts it into an e-mail form.

  Next, in step S61b, it is determined whether or not the total of all e-mail sizes is less than or equal to the receivable size (see FIG. 11) of the receiving terminal device (MS-2). If the size is less than the receivable size, “Yes” is determined in step S61b, and an e-mail attached with a file having the converted format (content) is sent to the mail receiving server 13 in step S69b. Send. Then, the mail receiving server 13 receives the e-mail attached with the file having the format (content) after the conversion in the above-described step S27 (see FIG. 2), proceeds to the next step S28, and after the conversion An e-mail attached with a file having a format (content) is distributed to the receiving terminal device (MS-2).

On the other hand, if the size exceeds the receivable size, “No” is determined in step S61b, and the process proceeds to the next step S62. In step S62, the order of the attached file corresponding to the receiving terminal device (MS-2) is moved to the top. Next, the conversion element 1 is designated from the second profile information (see FIG. 11) acquired in step S63. Thereafter, in step S64, all attached files are converted based on the conversion element 1, and the process proceeds to the next step S65.

  In step S65, it is determined whether or not the total of all the converted e-mail sizes is equal to or smaller than the receivable size (see FIG. 11). Here, if it is equal to or smaller than the receivable size, “Yes” is determined in step S65, and a file having the converted format (content) is transmitted to the mail receiving server 13 in step S69b. On the other hand, if the size exceeds the receivable size, “No” is determined in step S65, and whether or not it is the last conversion element in the next step S66, that is, whether or not there is the next conversion element. Judgment is made.

If there is a next conversion element, “No” is determined in step S66, and the next conversion element (in this case, conversion element 2) is determined from the second profile information acquired in 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 the specified conversion element, unnecessary information (for example, in the receiving terminal device (MS-2)) is set in order to increase the receivable size as much as possible. , Jpg Exif information and additional information such as thumbnails) are desirably deleted.

  On the other hand, when there is no next conversion element, it determines with "Yes" in step S66, progresses to step S68, and deletes the file larger than the receivable size. 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. Here, if the total size after the conversion exceeds the receivable size, “No” is determined in step S69, and the file that has exceeded the receivable size in step S69b is determined as the mail receiving server 13. Send to.

  If the total size after conversion is less than or equal to 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. In step S69b, the converted file is transmitted to the mail receiving server 13. As described above, in the conversion based on this conversion scenario 4, the attached file consisting of the format (content) supported by the receiving terminal device (MS-2) is moved to the head, and the format (content not supported) ) Is moved backward, and the conversion process is performed, so that as many attachments as possible can be seen.

  Here, an example of e-mail conversion based on the conversion scenario 4 will be described with reference to FIG. 19 (note that FIG. 19 is a diagram schematically showing an example of conversion). In this case, an example of receiving an e-mail having an attached file addressed to the receiving terminal device (MS-2) of an account (phone number is 090-0000-0004, model type V702MO) adopting conversion scenario 4 This will be described below. In this case, the size of the body + header is 1K, the format (content) is doc, the size is 20K, the format (content) is gif, the display size is 640 × 480, and the image size is 40K. The display color is the image 1 having 240,000 colors, the format (content) is jpg, the display size is 320 × 240, the image size is 15K, and the attached file is the image 2 having the display color of 240,000 colors. Assume that an e-mail has been received. In the case of this account (090-0000-0004), as shown in FIG. 11, the model name of the mobile device in use is specified as V702MO from the user agent (Vodafone / V702MO / 1.0), and its content list is D. As shown in FIG. 8, the conversion scenario is conversion scenario 4.

  Then, from the receivable format (content) list corresponding to the content list D shown in FIG. 9, since the file whose format is doc is a format (content) that is not to be converted, no conversion is performed. On the other hand, gif indicates that the mobile device model (V702MO) in use is not jpg or png which is a receivable format (content). In this case, since gif is listed in the still image category of the convertible content category shown in FIG. 10, conversion to jpg corresponding to the content 1 in the receivable format (content) list (see FIG. 9) is performed. Will be performed. Furthermore, since jpg is a receivable format (content) for the mobile device model (V702MO) in use, the format (content) is not converted.

  In FIG. 19, a file whose format is doc, which is another file, is a format (content) that is not subject to conversion, and is therefore not converted. On the other hand, since jpg of the image 2 has a corresponding format (content) (see FIG. 9), the conversion of the format (content) is not converted. On the other hand, since the format (content) of the image 1 is gif, the format (content) is not compatible (see FIG. 9), so the format (content) is converted to jpg. The received email size is 1K for the body + header, 20K for other sizes, 30K for image 1 after conversion to jpg, and 15K for image 2, so the total size is 66K. In step S61b, the size is determined. Since the receivable size of this model (V702MO) is 30K, the first conversion is performed based on the conversion element 1.

  Therefore, first, the image 1 having the format (content) (jpg) corresponding to the receiving terminal device (MS-2: V702MO) is No. 1, the image 2 is No. 2, and other formats (contents) (doc) ) Change the order so that) comes to the end. Then, by performing the first size conversion based on the conversion element 1, as shown in FIG. 19, the total size after conversion becomes 51K. Since this is a size exceeding the receivable size of 30K, the total size after conversion is 41K by performing the second size conversion based on the conversion element 2, and the third size based on the conversion element 3 By performing the conversion, the total size after conversion becomes 37K. Since this also exceeds the receivable size of 30K, other large files (doc) are deleted. Accordingly, 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 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 delivered to the receiving terminal device (MS-2) without conversion has been described. However, when the file is acquired by the receiving terminal device (MS-2), in the fifth conversion example of FIG. 16, the body, the header, and the image 1 are first acquired by the IMAP method, and the remaining files are transferred later. You may make it acquire with a receiving request. In this case, when the first e-mail is acquired, the mail receiving server notifies the receiving terminal device (MS-2) together with the first e-mail as attachment data that there is a subsequent file. On the receiving terminal device (MS-2) side, by referring to the attached data and making a subsequent reception request to the mail receiving server, the other files described above can be acquired.

  Further, when the other file exceeds the receivable size of the receiving terminal device (MS-2) (in the example of FIG. 16, the other file (zip) is 30K or more), the above-mentioned By referring to the data attached by the mail receiving server, the user of the receiving terminal device (MS-2) can know the existence of the subsequent file. However, since reception at the receiving terminal device (MS-2) is not possible, a server mail transfer procedure (for example, to a mail address such as a personal computer owned by the user of the receiving terminal device (MS-2) separately) ), The subsequent file can be acquired.

  These can be similarly performed for the deletion of excess files in the conversion scenario 2 (FIG. 17) and the conversion scenario 4 (FIG. 19) described above. In this case, the mail receiving server 13 may notify the receiving terminal device (MS-2) of the existence of the subsequent file without deleting the excess files. It goes without saying that the file can be acquired by performing a mail transfer procedure and transferring it to a mail address of a personal computer or the like.

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 a processing operation of the mail receiving server shown by FIG. It is a flowchart which shows the example of the processing operation of the conversion scenario 1 in the conversion function part in the processing operation of FIG. It is a flowchart which shows the example of the processing operation of the conversion scenario 2 in the conversion function part 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 conversion function part 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 conversion function part in the processing operation of FIG. It is a figure which shows an example of a received mail. It is a figure which shows an example of a user directory. FIG. 9A shows an example of a content list, FIG. 9A shows a content list corresponding to a still image, FIG. 9B shows a content list corresponding to a moving image, and FIG. 9C shows an incoming melody ( The content list corresponding to the midi file) is shown. It is a figure which shows the content category list | wrist which can be converted. FIG. 11A is a diagram illustrating an example of a receiving terminal profile, FIG. 11A is an example of a profile indicating a model type and a receivable size based on received user agent information, and FIG. 11B corresponds to a still image. FIG. 11C illustrates an example of a profile indicating a conversion element corresponding to a moving image. 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 email receiving system. It is a block diagram which shows typically the schematic structure of the receiving system of the email proposed by OMA and W3C.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Network, 11a ... Sending side mail delivery server, 11b ... Reception side mail delivery server, 12 ... Mailbox, 13 ... Mail receiving server, 14 ... Directory server, 14a ... User directory, 15 ... Conversion function part, 16 ... Conversion Engine unit, 17 ... receiving terminal profile, 18 ... short message service center (SMSC)

Claims (2)

An e-mail delivery system for storing an e-mail transmitted from a transmission-side terminal device in a mailbox and delivering the e-mail stored in the mailbox to a reception-side terminal device,
A mail delivery server that receives the email transmitted from the transmitting terminal device and stores the email in a mailbox;
Based on a delivery request from the receiving terminal device, the electronic mail stored in the mailbox is delivered to the receiving terminal device, and at the time of delivery request from the receiving terminal device, the user identification of the receiving terminal device A mail receiving server for acquiring information and user agent information;
User account information including conversion scenarios or conversion conditions registered in advance for the location of the mailbox, user identification information, and the receiving terminal device, and a receivable format list corresponding to the user identification information; A user directory storing first profile information including a convertible content category list;
A receiving terminal profile that stores second profile information related to the receiving terminal device in which information including at least one of the receivable size, receivable format, and conversion element of the receiving terminal device is databased;
And at least one conversion engine for converting the format and codec of the multimedia data,
The mail receiving server acquires the user account information and the first profile information from the user directory based on user identification information acquired at the time of a distribution request from the receiving side terminal device, and simultaneously acquired at the time of the distribution request. Based on the user agent information, second profile information relating to the receiving terminal device is acquired from the receiving terminal profile, and based on the acquired second profile information , conversion processing to an e-mail stored in the mailbox is performed. A determination means for determining whether or not it is necessary to apply,
As a result of the determination by the determination means, when it is determined that conversion processing is necessary, the receiving terminal device receives the e-mail by the conversion engine based on a conversion scenario that defines a conversion method or conversion condition of the user account information. An e-mail delivery system characterized in that the e-mail is converted into a receivable format, size and conversion element, and the converted e-mail is delivered to the receiving terminal. 2. The electronic mail according to claim 1 , wherein the receiving terminal device is a terminal device having an Internet connection function or a terminal device capable of transmitting and receiving an electronic mail by connecting to an Internet gateway provided by a mobile communication carrier. Distribution system.

Images