MXPA98005278A - Method and system for sending message from llamadapor collect automatize - Google Patents

Abstract

A method and apparatus allow a calling party to contact a called party with a collect call, whether or not the called station answers or is busy. When the calling party dials a collect-call access code, the call goes to a message sending platform, which collects the call information and tries to complete the call. If there is no answer or if the called station is busy, the message sending platform retains control of the call and automatically suggests the calling party to enter a name and a message to be sent to the called party. After the name and message have been entered, the calling party is given a confirmation number, if desired, which allows the calling party to determine whether the called party has received the message. The message sending platform repeatedly tries to send the message when calling the called party. Once the call has been answered, the message sending platform identifies the calling party and tries to get the called party to accept or reject the collect message. If the called party accepts the message, the message platform transmits it and it is loaded to the called party by the message.

Description

*. METHOD AND SYSTEM. FOR SENDING AUTOMATED CALLING MESSAGE FOR RECEIVING BACKGROUND OF THE INVENTION Field of the Invention 5 The invention relates in general to the service of sending telephone messages and in particular to systems for sending automated collect calls. A portion of the exposition of this patent document contains material which is subject to the copyright protection. The owner of the copyright has no objection to the facsimile reproduction by any person, of the patent document or of the patent exposition, as it appears in the records or archives of the Patent and Trademark Office, but otherwise reserves all copyright of any kind.1 Background Information Calls collect allow the caller to transfer charges for a call to the account. the telephone station receiving the call, at the option of the called party. Currently, the called party must answer the call and accept the charges, in order to complete a collect call. If the called station does not answer or is busy, the call does not can be completed. There is a need to allow the calling party to complete a collect call by leaving a message to be transmitted to a called party at the option of the called party, if the called station does not answer or is busy when the call is placed. U.S. Patent No. 4,932,042 to Baral et al. Describes an apparatus and method for sending spontaneous voice and data messages. Baral y cois exhibits an interurban switch that has a dual tone multi-frequency receiver (DTMF) and a voice message operations center (VMOC), which has voice message sending equipment. When the interurban switch receives a call, it interconnects the DTMF receiver to the pending call of receiving a reply, in order to detect the signals typed by the calling customer. A message informing the calling customer of the availability of the voice message sending service may be transmitted during the call signal period, or during or instead of a busy signal. If the calling customer wants to leave a voice message, he must dial a key sequence, such as * 867, which is detected by the DTMF receiver of the interurban switch. Upon reception of such a sequence of keys, the interurban switch connects the call to the VMOC, which registers and transmits the voice message. Such installation requires that DTMF receivers be installed in each interurban switch, in which the voice message delivery service is available. In order to offer a comprehensive service, all interurban switches would have to be modified as well. It is likely that the expense of such modifications is large. In addition, the installation requires the calling party to enter a sequence of keys, in order to connect to the VMOC; The interurban switch does not detect that the called station does not answer or is busy. Finally, the installation does not handle the transmission of messages billed to the called party. U.S. Patent No. 4,972,461 to Brown and Cois, describes a system and method of transmitting call messages. Brown and Cois discloses a method and apparatus for call transmission service, which allow parties who call non-subscribers to a common carrier network to bill a transmission of voice messages to their billing code (e.g., credit card number. ) and verify the transmission status of the message from the network during a subsequent call. A calling party, who would like to leave a message to be transmitted to a specific telephone number, gains access to the system by dialing an 800 number associated with the system. The system then suggests the calling party, enter the billing code and the destination telephone number for the message. This system does not provide the sending of a spontaneous message in the detection of a non-response or busy condition of a called station. In addition, it does not handle the transmission of messages billed to the called party. In accordance with the foregoing, there is a need to provide automated voice call collect messages. SUMMARY OF THE INVENTION An object of the present invention is an automated voice message delivery system for collect calls. Another object is an automated collect call system, to complete calls without considering whether the called station does not answer or is busy. Another object is an automated collect call system, to transmit calls receivable by voice mail. Another object is a method to complete a collect call without answering by voice mail. These and other objects, features and advantages are provided by the method and system for sending automated collect calls. When the calling party dials a collect-call access code, the call goes to a message-sending platform, which collects the call information and tries to complete the call. If there is no answer, or if the call is busy, the message sending platform retains control of the call and automatically suggests the calling party to enter a name, if the name has not already been registered and a mail message vocal to be transmitted to the called party. After the voicemail message and the name have been entered, the calling party is given a confirmation number, if desired, which allows the calling party to determine whether the called party has received the message. The message sending platform repeatedly tries to transmit the voicemail message when calling the called party. Once the call has been answered, the message sending platform identifies the calling party and suggests to the called party to accept or reject the voice mail message receivable. If the called party accepts the message, the message sending platform transmits it and the called party is loaded by the message. It is noted that the present invention does not require any equipment to be added to the existing switches since the switches do not need to detect the key sequences. In addition, the message sending platform connects from the beginning of the call and by itself monitors the call and detects that the called station does not answer or is busy. Therefore, the calling party does not need to do anything to connect to the messaging platform. Finally, the messaging platform handles the initiation of collect calls in an automated manner. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of a platform for sending call collect messages 100, according to the present invention. Figure lb is a block diagram of a computer system, which is representative of AP 126, ISNAP 136, ACP 142, MCP 144 and the billing system 140 shown in Figure la. The figure is a block diagram of an audio server, which is representative of ARU-AS 134 and MP-AS 146 shown in FIG. Figure 2a is a summary flow chart of the processes of the present invention implemented in the message sending platform 100. Figure 2b is a flowchart of the call collect service process 200 of Figure 2a, implemented for the 100 system.

Figure 3a is a flow chart of a message sending process 300 of Figure 2a, implemented by the system 100. Figure 3b is a flow diagram of a subprocess of step 308 of Figure 3a of the sending process of messages 300 of figure 3a. Figure 3c is a flow diagram of a subprocess of the registration message menu of step 308-2 of Figure 3b. Figure 3d is a flow diagram of a subprocess of the offer options menu of step 308-3 of Figure 3b. Figure 3e is a flowchart of a sub-process of the options menu of step 308-5 of Figure 3b. Figure 3f is a flow diagram of a sub-process of the attached message of step 308-7 of Figure 3b. Figure 3g is a flow chart of a confirmation number subprocess of step 308-6 of Figure 3b. Figure 4 is a flow chart of a message transmission process 400 of Figure 2a, implemented by the system 100.

DETAILED DESCRIPTION OF THE INVENTION Figure la is a block diagram of a system for sending call receivable messages 100, according to the present invention. A public, conventional, switched telephone network 102 is also shown. As an example, the internal details of the network 102 are represented by conventional switches 104 and 108, conventional link lines 110 and 112 and conventional telephone devices 114 and 116. The system 100 includes a bypass switch 106, connected to the network 102 by connecting lines 110 and 112. The bypass switch 106 allows a call to be simultaneously connected between three parties. In addition to the connections through the junction lines 110 and 112, the bypass switch 106 can make connections on the line 118, which is connected to the automatic call distributor (ACD) 124 and line 122, which is connected to the audio server of the message sending platform (MP-AS) 146. The ACD 124 directs the calls for operation by either the manual telephone operator console (MTOC) 132, or the automated audio response unit / server Audio (ARU-AS) 134. The ACD 124 transmits the signaling information of each call to the application processor of the intelligent services network (ISNAP) 136 through the data connection 130. The ISNAP 136 selects the type of device, to which the call is directed and sends the control commands to the ACD 124 through the data connection 130. The ACD 124 transmits the audio portion of the call to either the MTOC 132 through the audio connection 128, or to the ARU-AS 134 through of the audio connection 129. The MTOC 132 is a conventional equipment, with which the human operators manually answer the calls, and manually enter the information obtained from the calling party. The ARU-AS 134 is a conventional device that automatically answers calls and obtains information from the calling party. The ARU-AS 134 does this for example by transmitting pre-recorded suggestion messages to the calling party and detecting the touch tone keys pressed by the calling party. The ARU-AS 134 includes a conventional audio server, which registers, stores and transmits vocal messages again digitally. The application call processor (ACP) 142 and the message control processor (MPC) 144 are standard processors, which control the different portions of the message sending and collect receivable processes. The ACP 142 and the MCP 144 implement the portions of the processes that execute the standard call collect service and the message collect service. The ACP 142 receives the status information from the ARU-AS 134 and issues the orders to control the ARU-AS 134 in the collection of the information required to perform the standard call-collect service. The ACP 142 also receives status information from the ARU-AS 134 and MP-AS 146 and issues the orders to control both the ARU-AS 134, as to the MP-AS 146 in the performance of the service of sending messages receivable. The ARU-AS 134 connects to the ACD 124 and handles incoming calls to the system. The MP-AS 146 is an audio server similar to that of the ARU-AS 134, except that it is connected to the branch switch 106 and has been installed in order to be able to initiate calls. Although only "single blocks" are shown, the system 100 and each block within represent multiple equipment located in various geographic locations, but all communicating through the local / extended area network (LWAN) 138. The L AN 138 is a network standard comprising, for example, Ethernet, interconnected, multiple local area networks The ARU-AS 134, the ACP 142, the -MCP 144 and the MP-AS 146 also communicate through a local area network (LAN) 148. LAN 148 is a standard network, such as the To-Ring (Ring signal) Typically, although not required, each group of the ARU-AS 134, the ACP 142, the MCP 144, and the MP -AS 146 are located in the same place, so LAN 148 is used to interconnect them.The use of LAN 148 allows most of the message sending traffic to be interconnected without the use of LWAN 138. Shipping traffic of messages comprises mainly digitized voice messages, which tend to include large s data quantities compared to normal signaling traffic in LWAN 138. Message sending traffic that is intercommunicated through LWAN 138 would consume too many network resources. The use of LAN 148 avoids the consumption of those resources and avoids any interference with signaling traffic. The bypass switch 106 also communicates with the attached processor (AP) 126, which extracts the billing information from the switch 106 through the data connection 120. The AP 126 processes the extracted billing information and sends it to the system 140. Figure lb is a block diagram of a computer system 150 that is representative of AP 126, ISNAP 136, ACP 142, MCP 144 and billing system 140. Each of these blocks comprises at least one of such a computer system. Although only one of each AP 126, ISNAP 136, ACP 142, MCP 144 and billing system 140 is shown in FIG. 1, it is well known in the art that a distributed architecture, in which more than one computer system executes each function, is completely equivalent. The system 150 includes a CPU 150-1, to execute the instructions of the program and process the data, a memory 150-4, to store the program instructions executed and the data processed by the CPU 150-1, a disk storage 150 -5, to store the data to be transferred to and from the memory and at least one 1/0 150-2 adapter, to communicate with other devices and transfer data inside and outside the computer system, through connection 150-12. The system 150 may also include a 150-3 operator interface, to provide the status information to and accept the commands of a system operator. All these elements are interconnected by means of a bus 150-6, which allows the data to intercommunicate between the elements. The 150-2 I / O adapter represents one or more I / O adapters, or network interfaces that can be connected to local or extended area networks, such as, for example, LWAN 138 or LAN 148, or directly to other components. Therefore, connection 150-12 represents a LAN or WNA, or a direct connection to another computer. Memory 150-4 is accessible via CPU 150-1 via bus 150-6, and includes operating system 150-9, program division 150-7 and data division 150-8. The division of the program 150-7 stores and allows the execution, by means of the CPU 150-1, of the instructions of the program that implements the functions of each respective system, AP 126, ISNAP 136, ACP 142, MCP 144 and the billing system 140. Data division 150-8 is accessible via CPU 150-1 and stores the data used during the execution of program instructions. On the AP 126, the division of the program 150-7 contains the program instructions that implement the extraction and processing of the billing information from the switch 106. In the ISNAP 136, the program division 150-7 contains the instructions of the program that selects a group operator, either MTOC 132 or ARU-AS 134, to which calls are routed through ACD 124. In ACP 142, the division of program 150-7 contains instructions for the program that implements a call-by-call process. charge 200, shown in figure 2a, which controls the standard collect call service. In MCP-144, the program division 150-7 contains program instructions that implement portions of the collect-call service process 200, the message sending process 300, and the message transmission process 400, all shown in Figure 2a. In the billing system 140, the division of the program 150-7 contains the instructions of the program that implements the processing of the billing information. The figure is an exemplary block diagram of an audio server 160, which is representative of a 7? RU-AS 134 and an MP-AS 146. Each of these blocks comprises at least one of such audio server. Although only one of each ARU-AS 134 and one MP-AS 146, shown in FIG. 1, it is well known in the art that a distributed architecture, in which more than one audio server performs each function, is completely equivalent . The audio server 160 includes a CPU 160-1, to execute the instructions of the program and process the data, a memory 160-4, to store the program instructions executed and the data processed by the CPU 160-1, a storage by discs 160-5, for storing data to be transferred to and from memory, at least one 160-2 I / O adapter, for communicating with other devices and transferring data in and out of the audio server, through connection 160 -15 and at least one 160-12 audio interface, to communicate audio signals. The audio server 160 may also include a 160-3 operator interface, to provide the status information to and accept the commands of a server operator. All these elements are interconnected by means of a 160-6 bus, which allows the data to intercommunicate between the elements. Adapter 1/0 160-2 represents one or more adapters 1/0, or network interfaces that can be connected to local or extended area networks, such as, for example, LWAN 138 or LAN 148, or directly to other components. Therefore, connection 160-15 represents a LAN or WNA, or a direct connection to another computer. Audio interface 160-12 cascades audio server 160 to interurban audio lines, typically at least one IT line. Each IT line is capable of carrying 24 calls. Typically, the audio server 160 has the necessary output to handle 72 calls simultaneously, therefore, three Ti lines can be connected to each 160-12 audio interface. The memory is accessible by means of the CPU 160-1 through the bus 160-6, and includes the operating system 160-9, the division of the program 160-7 and the data division 160-8. The division of program 160-7 stores and allows the execution, by means of CPU 160-1, of the instructions of the program that implements the functions of each respective system, ARU-AS 134 and MP-AS 146. The division of data 160- 8 is accessible via the CPU 160-1 and stores the data used during the execution of the program instructions. In ARU-AS 134, the program division 160-7 contains program instructions that implement the portions of processes 200, 300 and 400, as described below. In MP-AS 146, the program division 160-7 contains program instructions that implement the portions of processes 300 and 400, as described below. Disk 160-5 contains the 160-10 data files. These files are used to store the vocal message. The 160-10 files include the files of the calling party name 160-13 and the message files 160-14. These files contain the digital registers of the names of the parties that call and the vocal messages, respectively. Figure 2a is a flowchart in summary of the processes implemented in the message sending platform 100, showing the interaction of the process of the call collect service 200, the process of sending messages 300 and the process of transmission of messages. messages 400. Process 200 includes steps 202-214, in which a calling party places a collect call, the message sending platform -100 collects the necessary information and the call is connected to the called station. In step 216, the message sending platform 100 determines whether the called station answers. If so, process 200 then completes the collect call normally in steps 218-224. If the called station does not answer or is busy, the process of sending messages 300 is invoked. Process 300 includes steps 302-304 and 308-322, in which the message sending platform 100 attempts to obtain a registered voice name if necessary and a registered message from the calling party. If this attempt is not successful, the process follows step 306, in which the call to send messages is canceled, with the appropriate treatment. If the attempt is successful, the message transmission process 400 is invoked. Process 400 includes steps 402-412, in which the message sending platform 100 originates a call to the called station, in an attempt to send the message. If there is no answer, or the terminal number is busy, the process follows step 413, in which the message sending platform 100 examines the number of sending attempts that have been made. If there have been too many transmission attempts, the process follows step 415, in which the transmission of the message is canceled. If there have not been too many transmission attempts, the process cycles return to step 402. If in step 412, the call is answered, the process follows steps 416-422, in which the message sending platform 100 identifies the calling party by transmitting again the file of the registered name and suggests the called party to accept the message.

If the called party does not accept the message, the process follows steps 424-426, in which the message is canceled, with the appropriate treatment. If the called party accepts the message, the process follows steps 428-430, in which the message sending platform 100 transmits the message to the called party. In step 432, the called party is loaded by the transmission of the message. Figure 2b is a flowchart of the process of the call collect service 200, implemented by the system 100 in conjunction with the network 102, as shown in Figure la, according to the present invention. Process 200 begins with step 202, in which a calling party dials the access number for the collect call service, for example, the calling party can dial an access number "800", or the party that Flame can dial "0 + terminal number". In step 204, the network 102 recognizes the access number and directs the call to the diversion switch 106. In step 206, the diversion switch 106 directs the call to the ACD 124. In step 208, the ACD 124 sends the signaling information, including the terminal number, associated with the call to ISNAP 136, which selects an operator group, either MTOC 132 or ARU-AS 134, to which the call is to be addressed. The ISNAP 136 sends the routing command to the ACD 124, which then directs the call according to the above. In step 210, a member of the operator group to which the call was directed collects the information necessary to complete the call-collect service. This information includes the terminal number if an access number "800" is set and always includes the name of the calling party. If the operator group is the ARU-AS 134, the name of the calling party is recorded. In step 212, the calling party is held while the call is complete. In step 214, the call is completed between the operator group and the terminal number, allowing the message sending system 100 to monitor the call. In step 216, the system 100 determines whether the terminal number answered the call. If the terminal did not answer the call, due to a no-answer or a busy signal, the system 100 invokes the message sending process 300. If the terminal number answers, the process follows the step 218, in the which the operator group suggests to the called party to accept the collect call. In step 220, it is determined whether the called party accepts the collect call. If the called party accepts the call, the process follows step 222, in which the bypass switch connects the calling party to the called party and releases the connection to the operator group. Then the process ends. If the called party does not accept the call, the process continues to step 224, in which the operator group releases the called party and informs the calling party of the rejection of the call. Then the process ends. Figure 3a is a flow chart of the message sending process 300, implemented by the system 100 in conjunction with the network 102, as shown in Figure la, according to the present invention. The process 300 begins with step 302, in which the call is connected to the ARU-AS 134, which suggests to the calling party to use the message sending service. In step 304, it is determined whether the calling party accepts the message sending service. If not, the process follows step 306, in which the call is terminated and the name of the calling party is deleted, if it was recorded in step 210 of figure 2. If the calling party accepts the service of sending messages, the process continues with step 308, in which the ARU-AS 134 attempts to register the message and if necessary, the name of the calling party. If the attempt to register the message is unsuccessful, the process follows step 309, in which the process is canceled. If the attempt to register the message is successful, the process follows step 310, in which the ACP 142 generates the names of the file that identify the registered message and name. In step 312, the ACP 142 informs the MCP 144 that the message has been recorded by sending a record of the message information to the MCP 144. The recording of the message information includes the called number, other attributes of the call such as For example, a promotional offer number or coupon, the address of the ARU-AS that registered the name and the message (in a typical modality, there are several ARU-ASs), the names of the file identify the name of the part that call and the voice message files in the ARU-AS 134 and an access number to use it in the transmission of the message. In response to this message, in step 314, an MCP 144 generates a confirmation number with which the calling party can obtain the status of the transmission of the message and sends the confirmation number to the MCP 144. In step 316, an ACP 142 gives commands to the ARU-AS 134 to first transmit a final message to the calling party, including the confirmation number, to then end the call. In step 318, the bypass switch 106 generates the billing information in the form of an operator service record (OSR) and sends it through the AP 126 to the billing system 140. Similarly, the ACP 142 generates the billing information in the form of a billing detail record (BDR), which is sent to the billing system 140. Both the OSR and the BDR are marked as uncharged, indicating that none is, to be charged for the call during which the message was recorded. In step 320, the MCP 144 retrieves the registered voice message and the name files from the ARU-AS 134, using the information in the message information register and stores the name and voice message locally in MP-AS 146. In step 322, MCP 144 schedules the message for transmission. In step 324, the files of the voice message and the name of the calling party are deleted from the ARU-AS 134 and the record of the message information is stored in the MCP 144. Figure 3b is a flow diagram of a subprocess of step 308 of the message sending process 300 of -figure 3a. Subprocess 308 is introduced from step 304 of figure 3a and begins with step 308-1, in which the configuration and availability of the message delivery platform are verified. If the necessary subsystems of the message delivery platform are not configured properly or are not available, the process of sending messages follows step 308-10, in which the message is canceled. If the message sending platform is configured appropriately and is available, the process follows step 308-2, in which the registration message menu is executed. This menu allows the calling party to register a voice message and, if necessary, a name. If a message is not properly recorded by the registration message menu, the message sending process follows step 308-10, in which the message is canceled. If a message is properly recorded and the registration message menu is entered from step 308-1, the process proceeds to step 308-3. If a message is properly recorded and the registration message menu is entered from step 308-9, the process proceeds to step 308-5. In step 308-3, the offer of the options menu is executed. This menu allows the calling party to select whether or not to enter the options. If the option entered is not selected, the process continues to step 308-6. If the option entered is selected, the process continues to step 308-5. In step 308-5, the options menu is executed. This menu allows the calling party to select whether to execute various optional functions. These functions include: transmitting the message back to the calling party, send the message, add the message, delete and re-register the message and cancel the message. If the transmission option is selected, the process follows step 308-4, in which the message is transmitted back to the calling party. The process then returns to the options menu, step 308-5. If the add option is selected, the process follows step 308-7, in which the attached message routine is executed. The process then returns to the options menu, step 308-5. If the delete / register option is selected again, the process follows step 308-9, in which the registered message is deleted. The process then follows step 308-2, in which the registration message menu is executed again. If the cancel option is selected, the process continues to step 309, in which the message is deleted and canceled. If the transmission option is selected, the process follows step 308-6. If the calling party hangs up, the process proceeds to step 309 if a valid message has not been recorded and to step 310 if a valid message has been registered. In step 308-6, the routine of the confirmation number is executed. This routine supplies the calling party with a confirmation number that can be used later to verify the transmission status of the message. Figure 3c is a flow diagram of a subprocess of the registration message menu of step 308-2 of Figure 3b. The registration message menu 308-2 is input from either step 308-1 or step 308-9. In any case, menu 308-2 begins with step 308-2-1, in which it is determined whether menu 308-2 is reintroduced from step 308-9, or is entered for the first time from stage 308-1. If menu 308-2 is not reintroduced, the process follows step 308-2-3. If menu 308-2 is reintroduced, the process proceeds to step 308-2-2, in which it is determined whether the maximum number of attempts allowed in the menu has been exceeded. If the allowed menu attempts have been exceeded, the process follows step 309, in which the process is canceled. If the allowed menu attempts have not been exceeded, the process follows step 308-2-6. In step 308-2-3, the initial suggestion is transmitted to the calling party. In step 308-2-6, the process checks whether the name of the calling party was recorded in step 210. If not, the process attempts to register the name of the calling party. If after the number of attempts allowed, the name of the calling party has not been successfully registered, step 308-2-6 fails and the process follows step 309, in which the process is canceled. If the name of the calling party has been successfully registered, the process follows step 308-2-8, in which the process attempts to register the calling party's message. If after the number of attempts allowed, the calling party's message has not been successfully registered, step 308-2-8 fails and the process follows step 309, in which the process is canceled. If the calling party's message has been successfully registered, the process follows step 308-2-9, in which it is determined whether the calling party hung up. If the calling party hung up, the process follows step 308-2-10, in which the message queues for the message transmission routine 400. The process is then prepared for the message transmission routine 400, starting with in step 310 of figure 3a. If the calling party did not hang up, the process follows step 308-2-11, in which it is determined whether menu 308-2 was entered from the Delete / Re-register routine 308-9. If the menu 308-2 was introduced from the Delete / Re-register routine 308-9, the process follows the options menu 308-5 of figure 3b. If menu 308-2 was introduced from step 308-1, the process follows the offer options menu 308-3 of figure 3b. Additional description of the registration message menu of the present invention can be found., in Listing A of the Pseudocode Program of the Exemplary Registration Message Menu in the appendix. Figure 3d is a flow diagram of a subprocess of the offer options menu of step 308-3 of Figure 3b. Menu 308-3 is entered from step 308-2. Menu 308-3 begins with step 308-3-1, in which it is determined whether the permissible number of attempts has been exceeded. If so, the process follows step 309, in which the process is canceled. If not, the process follows stage 308-3-3, in which the calling party is suggested to select more options. In step 308-3-4, it is determined whether the calling party selected more options. If so, the process follows step 308-5. If not, the process follows step 308-3-5, in which it is determined whether the calling party selected the connection to an operator. If so, the calling party connects to an operator. If not, the process is linked back to step 308-3-1. Additional description of the registration message menu of the present invention can be found in Listing B of the Pseudocode Program of the Exemplary Offer Options Menu in the appendix. Figure 3e is a flowchart of a sub-process of the options menu of step 308-5 of Figure 3b. Menu 308-5 is input from either step 308-2, step 308-3, or step 308-4 of FIG. 3b. Menu 308-5 begins with step 308-5-1, in which the calling party is suggested to introduce an option. In step 308-5-2, the process receives the option selection entered by the calling party. In step 308-5-3, it is determined whether the calling party hung or not. If the calling party did not hang up, the process follows step 308-5-6. If the calling party hung up, the process follows step 308-5-4, in which it is determined whether the message was recorded or not. If the message was not recorded, the process follows step 309, in which the process is canceled. If a message was recorded, the process follows step 308-5-5, in which the message queues for the message transmission routine 400. The process then prepares for the transmission routine of message 400, beginning at step 310 of figure 3a. In step 308-5-6, it is determined whether the calling party entered a selection, or was delayed without entering a selection. If the calling party was delayed, the process follows step 308-5-13. If the calling party entered a selection, the process follows step 308-5-7, in which it is determined whether the message transmission option was selected. If so, the process follows step 308-6, the routine of the confirmation number. If not, the process follows step 308-5-8, in which it is determined whether the transmission message option was selected. If so, the process follows step 308-4, in which the message is transmitted. If not, the process follows step 308-5-9, in which it is determined whether the option to add to the message was selected. If so, the process follows step 308-7, the attached message routine. If not, the process follows step 308-5-10, in which it is determined whether the delete / re-register option was selected. If so, the process follows step 308-9 in which the recorded message is canceled. If not, the process continues to stages 308-5-11, in which it is determined whether the cancellation was selected. If so, the process follows step 309, in which the message is canceled. If not, the process follows step 308-5-12, in which it is determined whether the option to connect to an operator was selected. If so, the calling party connects to an operator. If not, all valid selections have been verified, so the selection entered by the calling party is invalid and the process follows step 308-5-13. In step 308-5-13, it is determined if the maximum allowed number of attempts to select the option has been exceeded. If so, the process follows step 308-6, the routine of the confirmation number. If not, the process follows stage 308-5-1 and the options menu is repeated. Additional description of the registration message menu of the present invention can be found in Listing C of the Pseudocode Program of the Options Menu and in the appendix. Figure 3f is a flow diagram of a sub-process of the attached message of step 308-7 of Figure 3b. Process 308-7 is introduced from step 308-5 of Figure 3b. Process 308-7 begins with step 308-7-1, in which the calling party is advised to record an additional message. In step 308-7-2, the calling party records the additional message. In step 308-7-3, it is determined whether the registration of the additional message was successful. If not, the process follows step 308-5, the options menu. If so, the process follows step 308-7-4, in which it is determined whether the registration of the additional message is valid. If the record is valid, the process follows step 308-7-9, in which the newly registered message is appended to the original message. The process then follows step 308-5, the options menu. If not, the process follows step 308-7-5, in which it is determined whether the calling party selected to be connected to an operator. If so, the calling party connects to an operator. If not, the process follows step 308-7-6, in which it is determined whether the calling party hung up. If not, the process follows step 308-7-1 and the routine of the attached message is repeated. If so, the process follows step 308-7-7, in which it is determined whether the calling party registers an original, valid message. If not, the process is canceled. If so, the process proceeds to step 308-7-8, in which the message queues for the message transmission routine 400. The process is then prepared for the message transmission routine 400, beginning at the stage 310 of figure 3a.

Additional description of the registration message menu of the present invention can be found in Listing D of the Pseudocode Program of the Exemplary Message Menu Annex in the appendix. Figure 3g is a flow diagram of a subprocess of the confirmation number of step 308-6 of Figure 3b. Process 308-6 is introduced from step 308-5 of Figure 3b. Process 308-6 begins with step 308-6-1, in which a registered message queues for the message transmission routine 400. In step 308-6-2, it is determined whether the queue was successful. Otherwise, the process follows step 309, in which the message is canceled. If so, the process follows step 308-6-3, in which a confirmation number is generated. In step 308-6-4, a final informational message, including the confirmation message, is transmitted to the calling party. The process is then prepared for the transmission routine of message 400, beginning at step 310 of figure 3a. Additional description of the registration message menu of the present invention can be found in Listing E of the Pseudocode Program of the Exemplary Confirmation Number Routine in the appendix. Figure 4 is a flow chart of a message transmission process 400, implemented in system 100 in conjunction with network 102, according to the present invention. The process 400 begins with step 402, in which the MCP 144 determines that the time programmed in step 320 of FIG. 3 has arrived for the transmission of a message. In step 404, the MCP 144 transmits an order to the MP-AS 146, which causes the MP-AS 146 to originate a call to the message sending system 100 through the bypass switch 106. The command includes a key for recording the information of the message stored in the MCP 144, which contains the reference number of the message file and the reference number of the file of the name of the calling party, which identify the message to be transmitted. The MP-AS originates the call using a special access number, which causes the desired routing to occur. The automatic number identification (AN) message associated with the call contains the key for recording the message information stored in the MCP 144. In step 406, the audio portion of the call from the MP- AS 146 connects and directs to the ARU-AS 134. The data portion of the call, including the ANI, is extracted by the ACD 124 and sent to the ACP 142 through the ISNAP 136. In step 408, the ACP 142 uses the key contained in the ANI message, to access the record of the message information stored in the MCP 144. In step 410, the ACP 142 transmits an order to the ARU-AS 134, which causes the ARU-AS originates a call to the terminal number and connects the call from the MP-AS to the call originated recently in a conference call. In step 412, the ACP 142 determines whether the call to the terminal number was answered, or whether there was a non-response (RNA) or busy call. If there was an RNA or busy, the process continues with step 414, in which the MCP 144 schedules another attempt to transmit call messages for a later time. The process is then linked to step 402. If the terminal number answers the call, the process continues with step 416, in which the ACP 142 instructs the ARU-AS 134 to transmit a suggestion informing the called party of the message. In step 418, the ACP 142 transmits an order to the MCP 144, which in turn orders the MP-AS 146 to transmit the registered name of the calling party, which identifies the sender of the message to the called party. In step 420, the ACP 142 instructs the ARU-AS 134 to suggest that the called party accept the message. In step 422, the ACP 142 determines whether the called party accepts the message. If the called party does not accept the message, the process continues with step 424, in which the call is terminated and step 426, in which the billing information is created without loading. This billing information causes the billing system 140 to charge nothing for the call. Then the process ends. If the called party accepts the message, the process continues with step 428, in which the ACP 142 commands the MCP 144, which in turn orders the MP-AS 146 to transmit the message to the called party. In step 430, the ACP 142 instructs the ACD 124, through the ISNAP 136, to release the call while the MP-AS 146 transmits the message. In step 432, the loaded billing information is created. This billing information causes the billing system 140 to bill the call to the called party. Then the process ends. Although specific embodiments of the present invention have been described, it will be appreciated by those skilled in the art that other modalities that are equivalent are possible.

Appendix Copyright 1994, 1995 MCI Corporation RECORD MESSAGE MENU - PSEUDOCODE PROGRAM LISTING A if global recollection counter exceeded Play, "We regret we are unable to complete your cali ..." Flush caller. Return MENU_CALL_COMPLETED. if this was not the re-entry menu Clear enú attempts for this men. Bump pegcount for number of times messenger is offered to callers: broken out by RNA / BUSY / MACHINE answer detection. Play "Welcome to Collect Message Service." Play "You have asked to record a message to be delivered later." Play "We will make up to 8 attempts to deliver your collect message" else Clear menu re-entry flag. if menu attempts have been exceeded for this menu Play "We did not record a message." Play "Please hang up and try your cali again." Play "Thank you for using 1-800-Collect Message Service, Cleanup menu, Flush caller, Write BDR with term method, MT_FLUSH, term status BDR_STAT_RECORD_FAIL, Return MENU_CALL_C0MPLETED, Increment menu for this menu.

Loop MAX_NAME_RECORD_RETRIES times: if caller has not recorded their yam Clear File Path. Get File Path out of configuration file. Clear Yam File Yam. Generate unique Ñame File Ñame. Record ñame with parameters: DEFAULT LANGUAGE, STOP ON KEY PRESS MAX RECORD TIME = 4 seconds MAX LEADING SILENCE = 2 seconds MAX TRAILING SILENCE = 2 seconds BEEP = Yes instructions PMODE_CLEAR_DTMF, Do not append. File Path. Yam File Yam. Play "Please say your name at the tone." if Ñame was recorded Set flag to indicate Ñame was recorded. Break out of loop, else Play "We did not record a yam." if caller still has not recorded their ñame Play "Please hang up and try your cali again." Play "Thank you for using Collect --- Calling Service." Write BDR with term method MT_ORIG_DISC, term status BDR_STAT_RECORD_FAIL. Cleanup menu.

Flush caller. Return MENU_CALL_COMPLETED. if caller hungup Write BDR with term method MT_ORIG_DISC, term status BDR_STAT_MESSENGER Cleanup menu. Flush caller. Return MENU_CALL_COMPLETED. Play "Please record your message after the tone." Clear File Path. Get File Path out of configuration file. Clear Message File Yam. Generate Message File Ñame based on unique filename of Ñame File Ñame. Record message with parameters: DEFAULT LANGUAGE STOP ON KEY PRESS MAX RECORD TIME = 240 seconds MAX LEADING SILENCE = 2 seconds MAX TRAILING SILENCE = 2 seconds BEEP = Yes; beep after instructions PMODE_CLEAR_DTMF, Do not append. File Path. Yam File Yam. Play 'Press' * 'when you are finished. "If Voice' recorder failed Cleanup menu. Prepare to retry this menu. Do not count this as a try menu.

Goto start of this menu (return). if message recording was maximum Set flag to indicate message was recorded. Play "Your message is four minutes long." Tie Time stamp. zone, and Daylight savings indicator to the message. Bump pegcount for C18_MESSAGE_ATTEMPT_BY_CALLER. else if message recording was invalid Set flag to indicate message was not recorded. Play "We did not record a message." Bump pegcount for C18_MESSAGE_ATTEMPT_BY_CALLER. Cleanup this menu. Prepare to retry this menu. Goto start of this menu (return). else if operator was selected Set TTC value (TTC_XFERPOINT, TTC_XFER_INIT_PROMPT). Bump pegcount C18_XFER_REQUESTED. Transfer to manual (SCRP_H0LD_XFER, SCRP_HOLD_XFER) Cleanup this menu. Return MENU_CALL_COMPLETED. if caller hungup if a message has been recorded Queue message to Message Platform. Cleanup this menu. Write BDR, tern method MT_ORIG_DISC. term status BDR_STAT_DISCONNECT. Return MENU_CALL_COMPLETED. Write BDR with term method MT_NEW_CALL, term status BDR STAT NORMAL. if this enú was entered from Erase / Rerecord option Cleanup this menu. Cali Messenger Options Menu (return). Cleanup this menu. Prepare to reenter Options menu. Cali Messenger Offer Options Menu (return).

OFFER OPTIONS MENU - PSEUDOCODE PROGRAM LISTING B if this was not the re-entry menu Clear menu attempts for this menu, else Clear menu re-entry flag. Increment menu attempts for this menu. if Options desired per otto. cfg (PARAM_MESSENGER_OPTIONS_MENU ACTIVE Y) Loop (PARAM_MESSENGER_OFFER_OPTIONS_MENU MAX_MENU_ATTEMPTS) times: if Configuration number desired per otto. cfg (MESSENGER_CONFIRM_NUMBER_ACTIVE Y) Play "Please hold for your confirmation number." if Options menu can not be retried Break out of loop. Play "Press" 1"now for more options. Play" Or you may hangup and your message will be delivered. "if caller entered" 1"DTMF is valid Messenger Options have been selected else if caller did not answer '1' DTMF is valid. else if caller selected operator Set TTC value (TTC_XFERPOINT, TTC_XFER_INIT_PROMPT). Bump pegcount C18_XFER_REQUESTED. Transfer to manual (SCRP_HOLD_XFER, SCRP_HOLD_XFER) Cleanup this menu. Return .MENU_CALL_COMPLETED. else Continued looping, if DTMF is valid Break out of loop. if more attempts for Options remain and DTMF menu is valid if user entered '1' (selected Options) Cleanup this menu. Cali Messenger Options Menu (return). if user hungup if a message was recorded Queue message to Message Platform. Write BDR with term method MT_ORIG_DISC, term status BDR_STAT_DISCONNECT. Cleanup this menu. Return MENU_CALL_COMPLETED. Cali Message Confirmation Number routine. if Message Confirmation Number routine failed to queue the message Play "Your message has not been accepted." Play "Please hangup and try your cali again." Play "Thank you for using Collect Message Service." Write BDR with term method MT_FLUSH. term status BDR STAT NORMAL.

Flush the caller Cleanup this menu. Return MENU CALL COMPLETED.

OPTIONS MENU - PSEUDOCODE PROGRAM LISTING C if this was not the re-entry menu Clear menu attempts for this menu. Set Menu reentry flap, to true for next invocation of this menu. if menu attempts have been exceeded for this menu Cleanup menu. Cali .messenger Confirmation number routine. Return MENU_CALL_COMPLETED. Increment menu attempts for this menu. Play "To deliver your message, press '1' now." Play "Tolisten to this message, press '2' now." if current message has at least thirty seconds before maximizing out Play "To add to this message, press '3' now." Play "To erase and rerecord your message, press '4' now." Play "To cancel this message and exit the system, press '5' now." if user hungup if a message was recorded Queue message to Message Platform. Write BDR with term method MT_ORIG_DISC. term status BDR_STAT_DISCONNECT. Cleanup this menu. Return MENU_CALL_COMPLETED. if user selected '1' (DELIVER) Cali Messenger Confirmation Number routine.

Play "Thank you for using 1-800-Collect Message Service." Write BDR with term method MT_FLUSH, term status BDR_STAT_NORMAL. Cleanup menu. Return MENU_CALL_COMPLETED. else if user selected '2' (PLAY) Play recorded message to user. if user hungup if a message was recorded What message to Message Platform. Write BDR with term method MT_ORIG_DISC. term status BDR_STAT_DISCONNECT. Cleanup menu. Return MENU_CALL_COMPLETED. else Prepare to reentrv to this menu. Cali Messenger Options Menu (return). else if user selected '3' (ADD) if current message has at least thirty seconds before maximizing out Cali Messenger Append Message routine. if Messenger Append Message routine indicates DONE Cleanup this menu. Return MENU_CALL_COMPLE ED_. else Play "Your message length is the maximum allowed." You may not add to this message. " Cleanup menu. Prepare to reenter this menu.

Cali Messenger Options Menu (return). else if user selected '4' (ERASE / RERECORD) while (No more available attempts for RecordMessageMenu) Decrement total menu attempts for RecordMessageMenu. Cleanup menu. Set flag indicating erase / rerecord was selected. Get audio server yam (node). Delete recorded message file from local ÑAS. Set flag to indicate message is not recorded. Play "Your message has been erased." Prepare to retry message creation. Cali Record Message Menu (return). else if user selected '5' (CANCEL) Ensure at least one more attempt can be made to Record a message: Get audio server ñame (node). Delete recorded ñame file from local ÑAS. Set flag to indicate ñame is not recorded. Delete recorded message file from local ÑAS. Set flag to indicate message is not recorded. Play "Your message has been erased." Play "Thank you for using Collect Message Service." Flush caller. Write BDR with term method MT_FLUSH, term status BDR_STAT_MESSAGE_ERASE. Return MENU_CALL_COMPLETED. else if user selected operator Set TTC value (TTC_XFERPOINT, TTC_XFER_INIT_PROMPT). Bump pegcount C18_XFER_REQUESTED. Transfer to manual (SCRP HOLD XFER, SCRP HOLD XFER) Cleanup this menu. Return MENU_CALL_COMPLETED. else if invalid selection if attempts for this menu have been exceeded Invoke Confirmation number routine. else (attempts remain) Play "We can not process your response." Prepare for reentering this menu. Cali Messenger Options Menu (return). else (input timeout) if attempts for this menu have been exceeded Invoke Confirmation number routine. else (attempts remain) Play "I do not understand your response." Prepare for reentering this enú. Cali Messenger Options Menu (return). Cleanup menu. Return MENU CALL COMPLETED.

APPEND MESSAGE MENU - PSEUDOCODE PROGRAM LISTING D Loop for (PARAM_MESSENGER_OPTIONS_MENU MAX_MENU_ATTEMPTS) times: Play "Please be speaking after the tone." Record message: DFLT LANGUAGE, ON_KEY_STOP, (PARAM_RECORD_MESSAGE_MENU MAX_RECORD_TIME) - length already recorded, PARAM_RECORD_MESSAGE_MENU MAX_LEADING_SILENCE 20; in tenths of a second PARAM_RECORD_MESSAGE_MENU MAX_TRAILING_SILENCE 20; in tenths of a second PARAM_RECORD_MESSAGE_MENU BEEP Y: beep after instructions PMODE_CLEAR_DTMF, Append, File Path. Message File Yam. Play "Press '*' when you are finished." If Voice recorder succeeded Break out of loop, else Play "We did not record a message." if Voice recorder failed (PARAM_MESSENGER_OPTIONS_MENU MAX_MENU_ATTEMPTS) times Cleanup menu. Set flag to indicate message was not recorded Prepare Options menu for reentry. Cali Messenger Options Menu. else if recording is valid Set flag to indicate message was recorded if recording length was maximized Play "Your message is four minutes long." Write BDR with term method MT_NEW_CALL, term status BDR_STAT_NORMAL. Cleanup menu. Prepare Options menu for reentrv. Cali Messenger Options Menu, else if user selected operator Set flag to -indicate message was not recorded Set TTC value (TTC_XFERPOINT, TTC_XFER_INIT_PROMPT) _. Bump pegcount C18_XFER_REQUESTED. Transfer to manual (SCRP_HOLD_XFER, SCRP_HOLD_XFER) Cleanup this menu. Return DONE, else Set flag to indicate message was not recorded if user hungup if a message was recorded message to Message Platform Write BDR with term method MT_ORIG_DISC, term status BDR_STAT_DISCONNECT. Cleanup this menu. Return DONE Return NOT DONE.

CONFIRMATION NUMBER ROUTINE - PSEUDOCODE PROGRAM LISTING E message to Message Platform. if message queue failed Play "Your message has not been accepted." Play "Please hangup and try your cali again." Play "Thank you for using, Collect Message Service." Write BDR with term method MT_FLUSH. term status BDR_STAT_NORMA. Return. Play "Your message has been recorded." if Confirmation number configured (MESSENGER_CONFIRM_NUMBER_ACTIVE = Y) if user hungup Write BDR with term method MT_ORIG_DISC, term status BDR_STAT_DISCONNECT. Return Play "Your confirmation number is the phone number you dialed plus three more digits." Play "The complete number is ..." Play "string (concatenated called number + confirmation number). Play" Again, the last three digits of your confirmation number Play string (3 digit Confirmation number) if Delivery status number configured (MESSENGER_DELIVERY_STATUS_NUMBER_ACTIVE Y) Play "To check on the delivery status of your message cali" Play "< < 18C Collect Status Number > >". Play "within 36 hours." Play "Again, that number is ..." Play "< < 18C Collect Status Number > >" Play "Thank you for using Collect Message Service." Write BDR with term method MT_FLUSH, term status BDR_STAT_NORMAL. Return.

Claims (42)

1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and therefore the property described in the following claims is claimed as property. 1. In a telecommunications network comprising a public switched telephone network and a message sending platform, a method for transmitting voice mail messages from a calling party placing a collect call from a calling station to a party call to a call station, comprising the steps of: A) connecting the call receivable from the calling station to the message sending platform; B) collect, in the message sending platform, the information that identifies the called station of the collect call from the calling party; C) originating a termination call from the platform for sending messages to the called station, using the public switched telephone network; D) detect on the message sending platform if the termination call was answered by the called station; E) obtain on the message sending platform, a voice message from the calling party if the termination call was not answered; and F) attempting to transmit the message to the called party from the message sending platform. The method according to claim 1, characterized in that the step of trying to transmit the message to the called party from the message sending platform comprises the steps of: G) originating a call to transmit the message from the message sending platform towards the station called; H) suggest to the called party to accept the transmission of the vocal message, if the called party answers the message transmission call; and I) transmit the voice message, if the called party accepts the transmission of the voice message. 3. The method according to claim 2, characterized in that it further comprises the step of: billing the called party by the message, if the called party accepts the message. The method according to claim 1, characterized in that the step of suggesting the transmission of the message to the called party from the message sending platform comprises the steps of: G) scheduling a time in which the transmission call of the message will be made message; H) originate a call to transmit the message to the called station at the scheduled time; I) detect if the message transmission call was answered; J) repeating steps G, H, and I until the message transmission call is answered, or the message transmission call continues without a predetermined number of times; K) suggest to the called party to accept the transmission of the vocal message, if the call to transmit the message was answered; and L) transmit the voice message, if the called party accepts the transmission of the voice message. The method according to claim 4, characterized in that it also comprises the step of: billing the party-called by the voice message, if the called party accepts the voice message. The method according to claim 1, characterized in that it further comprises the step of: assigning to the calling party a confirmation number to obtain the state of the transmission of the voice message from the message sending platform. The method according to claim 1, characterized in that the step of obtaining the voice message comprises the steps of: G) recording the voice message with the audio server on the message sending platform; H) suggest to the calling party to select at least one optional function, considering the handling of the vocal message; and I) execute the optional function selected. The method according to claim 7, characterized in that at least one optional function is selected from a list of optional functions consisting of: transmitting the voice message back to the calling party, attaching an additional voice message to the voice message, deleting and re-register the vocal message, cancel the vocal message and transmit the vocal message. The method according to claim 7, characterized in that the step of recording the vocal message comprises the steps of: J) suggesting to the calling party to record the vocal message; K) record the name of the calling party; and L) record the voice message of the calling party. The method according to claim 7, characterized in that the optional function selected attaches an additional voice message to the voice message and the step of executing the optional function selected comprises the steps of: J) suggesting the calling party to record an additional voice mail; K) record the additional voice message; and L) append the additional vocal message to the vocal message. 11. In a telecommunications network comprising a public switched telephone network and a message sending platform, a method for transmitting voice mail messages from a calling party placing a collect call from a calling station to a party call at a call station, comprising the steps of: A) receiving a collect call on the message sending platform; B) determine if the called station answers the collect call; C) normally complete the collect call, if the called station answers; D) try to obtain a voice message from the calling party, if the called station does not answer; E) delete and cancel any registered message, if the attempt to obtain a voice message from the calling party is unsuccessful; F) try to call the called station to transmit the vocal message, if a vocal message was successfully obtained; G) suggest to the called party to accept the vocal message, if the called station answers; H) transmit the voice message to the called party, if the called party accepts the voice message; and I) load the called station by the voice message, if the called party accepts the voice message. The method according to claim 11, characterized in that the message sending platform comprises a bypass switch and the step of receiving a call in the message sending platform comprises the steps of: J) recognizing in the public switched telephone network an access number of the call-collect service; and K) directing the collect call from the public switched telephone network to the referral switch of the message delivery platform based on the access number. The method according to claim 11, characterized in that the message sending platform further comprises an automatic call distributor, a bypass switch, an application processor and a plurality of operator groups including, an automated response unit / server of audio and a manual telephone operator console and the step of determining whether the called station answers the collect call comprises the steps of: J) directing the collect call from the bypass switch to the automatic call distributor; K) select, in the application processor, the operator group to which the call is directed based on the called number; L) direct the collect call from the automatic call distributor to the selected operator group; M) collect, in the selected operator group, the information that identifies the called station of the collect call from the calling party; N) retain the collect call on the bypass switch; OR) originate a termination call from the operator group to the called station; and P) detect whether the called station answers the termination call. The method according to claim 11, characterized in that the step of completing the collect call normally, if the called station answers, comprises the steps of: J) suggesting, in the audio response unit / audio server, to the part called accept the collect call; K) detect if the called party accepts the collect call; L) authorize the termination call from the derivation switch and extend the collect call to the called station, if the called party accepts the collect call; and M) release the called station, and inform the calling party, if the called party does not accept the collect call. The method according to claim 11, characterized in that the message sending platform further comprises a message control processor and an audio server of the message sending platform, including an audio response unit / audio server and the stage of trying to obtain a voice message from the calling party, if the called station does not answer comprises the steps of: J) in the audio response unit / audio server, execute the steps of: 1) suggesting the calling party accept the voice message sending service, 2) detect if the calling party accepts the voice message sending service, 3) terminate the call, if the calling party does not accept the voice message sending service , 4) record a voice message from the calling party, if the calling party accepts the voice message sending service, 5) generate an indicator that identifies the registered voice message, when the voice message registration complete, 6) assign a confirmation number to the registered voice message, 7) inform the calling party of the confirmation number, 8) terminate the calling station's call, 9) generate the billing information that indicates no there is a charge to be made for the collect call and 10) to transmit a message indicating that a voice message has been registered; K) retrieving the registered voice message from the audio response unit / audio server to the audio server of the message sending platform; L) programming a transmission time for the voice message recorded in the message control processor; and M) storing the flag identifying the voice message recorded in the audio response unit / audio server. The method according to claim 11, characterized in that the step of trying to call the called station to transmit the voice message, if a voice message was successfully obtained, comprises the steps of: J) determining, in the message control processor , if the scheduled transmission time for the registered voice message arrived; K) transmitting an order from the message control processor to the audio server of the message sending platform, causing the order that the audio server of the message sending platform originates a call to the message sending platform; L) directing the call originated by the audio server of the message sending platform to the audio response unit / audio server; M) originating a transmission call from the audio response unit / audio server to the called number specified in the indicator identifying the recorded voice message, stored in the audio response unit / audio server; and N) detect, in the audio response unit / audio server, whether the called station answers the transmission call. The method according to claim 11, characterized in that the step of suggesting to the called party to accept the voice message, comprises the steps of: J) informing the called party that a vocal message is available from the response unit audio / audio server; K) transmit the name of the calling party 'from the audio server of the message sending platform; L) suggest to the called party to accept the vocal message from the audio response unit / audio server; and M) detect whether the called party accepts the voice message. 18. A method for transmitting a receivable voice mail message, comprising the steps of: A) detecting an unanswered collect call from a calling telephone station to a called telephone station; B) obtain a voice message from a calling party at the calling telephone station and record the voice message at an audio response unit / audio server; C) originate a notification call to the called telephone station; D) notify the called party at the telephone call station of the voice message, when the called party answers the notification call; and E) transmitting the voice message to the called party at the called telephone station, when the called party accepts the voice message. The method according to claim 18, characterized in that: a plurality of notification calls are originated to the called telephone station until the called telephone station answers. The method according to claim 18, characterized in that: a plurality of notification calls are originated to the called telephone station until the called telephone station answers or the number of calls exceeds a predetermined number. The method according to claim 18, characterized in that it further comprises: charging the called party by the transmission of the message, if the message is transmitted to the called party. The method according to claim 18, characterized in that it further comprises: generating a confirmation number, with which the calling party can obtain the state of the transmission of the voice message and transmit it to the calling party. The method according to claim 18, characterized in that the step of obtaining a voice message from the calling party at the calling telephone station comprises the steps of: F) recording the voice message of the calling party; G) suggest to the calling party to select at least one optional function; H) receive the selection of the calling party; and I) execute the optional function selected. The method according to claim 23, characterized in that the optional function is selected from a list of optional functions comprising, transmitting the message back to the calling party, recording an additional message from the calling party and attaching it to the message, delete and re-register the message, cancel the message and transmit the message to the called party. The method according to claim 23, characterized in that the step of recording the voice message of the calling party comprises the steps of: J) suggesting to the calling party to record the voice message; K) try to register the name of the calling party; and L) try to record the vocal message of the calling party. The method according to claim 23, characterized in that the step of registering an additional message comprises the steps of: J) suggesting to the calling party to record an additional message; and K) try to record the additional message. 27. A system for transmitting voice mail messages from a calling party, which places a collect call from a calling station to a called party at a call station using a public switched telephone network, comprising: A) a collector, coupled to the public switched telephone network, which collects the information that identifies the called station from the collect call from the calling party; B) a generator of the termination call, which originates a termination call to the called station using the public switched telephone network; C) a response detector, detect if the termination call is answered by the called station; D) a voice message recorder, which obtains a voice message from the calling party, if the termination call is not answered; and E) a message transmission system, which attempts to transmit the message to the called party. The system according to claim 27, characterized in that the message transmission system comprises: E-l) a generator of the message call, which originates a call to transmit the message to the calling station; E-2) an audio suggestion, which suggests to the called party to accept the transmission of the voice message, if the called party answers the message transmission call; and E-3) a message transmission device, which transmits the voice message, if the called party accepts the transmission of the voice message. 29. The system according to claim 28, characterized in that the message transmission system further comprises: a device that programs the transmission, which schedules a time in which a message transmission call must be made. 30. The system according to claim 27, characterized in that it further comprises: a billing system, which invoices the party called by the message, if the called party accepts the message. 31. The system according to claim 27, characterized in that it further comprises: a generator of the confirmation number, which generates a confirmation number to obtain the state of the transmission of the voice message from the message sending platform. 32. The system according to claim 27, characterized in that the voice message recorder comprises: D-1) an audio recorder, which registers the voice message; D-2) a first audio suggestion, which suggests to the calling party to select at least one optional function, considering the handling of the vocal message; and D-3) an optional function execution device, which executes the optional function selected. The system according to claim 32, characterized in that at least one optional function is selected from a list of optional functions consisting of: transmitting the voice message back to the calling party, attaching an additional voice message to the voice message, deleting and re-register the vocal message, cancel the vocal message and transmit the vocal message. 34. A system for sending voice mail messages receivable for a public switched telephone network, comprising: A) a detector coupled to the public switched telephone network for detecting an unanswered collect call from a telephone station calling to a station telephone call; B) an audio server of the voice message coupled to the public switched telephone network to suggest and receive a voice message from a calling party at the calling telephone station; C) a generator of the message call coupled to the public switched telephone network to originate a call to the telephone station called subsequent to the audio server of the voice message, having received the voice message from the calling party; D) a voice notification unit coupled to the generator of the message call to generate a second voice message informing the called party at the called telephone station of the first voice message, when the called party answers the call of the call generator of the call message; and E) a voice message unit for transmitting the first voice message to the called party at the called telephone station, when the called party accepts the first voice message. 35. The system for sending call receivable voice mail messages according to claim 34, characterized in that the generator of the message call originates a plurality of calls to the called telephone station until the called telephone station answers. 36. The system for sending call receivable voice mail messages according to claim 34, characterized in that the generator of the message call originates a plurality of calls to the called telephone station until the called telephone station answers or the number of calls exceed a predetermined number. 37. The system for sending call receivable voice mail messages according to claim 34, characterized in that it further comprises: a billing system for generating billing information, so that the called party is charged by the transmission of the message, if the message is transmitted to the called party. 38. The system for sending call receivable voice mail messages according to claim 34, characterized in that it further comprises: a unit of the confirmation number for generating a confirmation number and transmitting it to the calling party, the calling party obtaining the status of the transmission of the vocal message from the confirmation number. 39. The system for sending call receivable voice mail messages according to claim 34, characterized in that the audio server of the voice message comprises: B-1) a voice message recorder, which records the voice message of the calling party; B-2) a message generator, which suggests to the calling party to select at least one optional function; B-3) a receiver for the selection of the optional function, which receives the selection of the calling party; and B-4) an optional function unit, which executes the optional function selected. 40. The system for sending call receivable voice mail messages according to claim 39, characterized in that the optional function unit comprises: B-4-1) a reproduction unit, which reproduces the message to the calling party; B-4-2) a message attachment unit, which records an additional message from the calling party and attaches it to the message; B-4-3) a message deletion unit, which erases the message; B-4-4) a cancellation unit, which cancels the message; and B-4-5) a message transmission unit, which transmits the message to the called party. 41. The system for sending call receivable voice mail messages according to claim 39, characterized in that the voice message recorder comprises: B-l-1) a message generator, which suggests to the calling party to record the voice message; B-l-2) a voice name recorder, which attempts to register the name of the calling party; and B-1-3) a voice message recorder that attempts to record the voice message of the calling party. 42. The system for sending call receivable voice mail messages according to claim 40, characterized in that the message attachment unit comprises, a message generator that suggests to the calling party to record an additional message and a voice message recorder Trying to register the additional message.