reference will now be made in detail to the embodiments , examples of which are illustrated in the accompanying drawings , wherein like reference numerals refer to the like elements throughout . the embodiments are described below to explain the present invention by referring to the figures . fig1 shows a functional block diagram of a text messaging system according to the first embodiment . the text messaging system according to the first embodiment consists of server 1 connected to internet 2 and mobile communication network 4 , multiple pc clients 3 , and multiple mobile phones 5 a , 5 b , . . . on the mobile communication network 4 . incidentally , to simplify the drawing , only one pc client 3 is shown . the mobile phone can send and receive a text message . the server 1 is notified of a detected self status of each mobile phone such as “ busy ” or “ out of radio area .” the server 1 has text message send part 6 , text message receive part 7 , status administration part 8 , status storage part 9 , decision part 10 , notification management part 11 , message storage part 12 , receive part 13 , send part 14 , and radio status detection part 15 . the text message send part 6 and text message receive part 7 send and receive a text message with the pc client 3 connected to the internet 2 , and send and receive send result notification of a text message or already - read notification of a text message with the pc client 3 . the status administration part 8 receives operational status of the pc client from the pc client 3 and stores it in the status storage part 9 for each user . the operational status of the pc client is , for example , activation and completion of internet applications , connection and disconnection of the internet 2 , activation status of a screen saver , or pc in operation . the status administration part 8 receives stores prescribed information from the pc client 3 and stores it in the status storage part 9 for each user . the prescribed information is , for example , an e - mail address of each user , a nickname in irc , a server and a channel , the phone number of a mobile phone , or present phone number . fig2 shows an example of an operational status and a phone number of each pc client retained for each user by the status storage part 9 . as shown in fig2 , the status storage part 9 retains only one active status for each user . for example , even if one user has multiple pc clients , a pc for which an up - to - date status is set according to the user &# 39 ; s operation is valid . in fig2 , if data are blank , it is determined that the status is null . for example , a status of each pc client in fig2 means the following : user a : pc does not operate because there is not an ip address . user b : pc is in operation and is connected to a network . user c : pc is in operation and is connected to a network . e - mail is currently in use . user d : pc is in operation . chatting by irc . pc is in operation . there is a phone number of a destination . user e : pc is in operation . a screensaver is active . there is a phone number of a destination . when the server 1 receives a text message addressed to any of the users , the decision part 10 operates as follows . the decision part 10 refers to the operational status of a pc client of the relevant user and determines a send mode which can receive the text message in real time . at this time , if an internet application is active on the pc client of the relevant user , the decision part 10 determines that the text message is sent with the internet application . if a pc client of the relevant user does not exist , is not connected to the internet , or is not used , the mobile phone of the relevant user is determined as the destination of the text message . if necessary , the text message is converted after the determination of a send mode , and the send request of the text message is done to the message send part 6 or send part 14 . the decision part 10 notifies the text message to be sent to the notification management part 11 to monitor the send result of the text message . the notification management part 11 retains the text message sent in response to the notification from the decision part 10 in a message table . the notification management part 11 also sends send notification to the sender if the status of the text message corresponds to a prescribed case . the prescribed case is such that the other party did not read the text message within a prescribed time , the text message was not read while the network application is active , the text message is not read while the pc is connected to the internet 2 . fig3 shows a conceptual diagram of the message table . in the message table shown in the figure , the name of a sender , the name of a receiver , the type of receiver , the timer id , and the contents of the text message are retained . the message storage part 12 temporally stores the text message if the text message is not immediately sent to the mobile terminal 5 a , 5 b , etc . the receive part 13 and send part 14 are for sending and receiving the text message among mobile phones 5 a and 5 b . radio status detection part 15 detects notification from the mobile phone 5 a or 5 b and stores the status of the mobile phone such as within radio area or busy . the pc client 3 has text message send / receive 21 , network service detection part 22 , pc operation detection part 23 , and status setting part 24 . the text message send / receive part 21 sends and receives the text message with the server 1 , notifies the user of the send result of the text message sent from the server 1 , and further notifies the server 1 that the received text message was read according to the input of the user . incidentally , the text message send / receive part 21 may be an independent application or another internet application for sending and receiving text messages can be substituted . an e - mail application or an irc application is cited as an example of an application for sending and receiving text messages . the network service detection part 22 detects the activation and completion of a network application . specifically , it detects the connection and disconnection of an webpage or the activation and completion of an e - mail or irc application , and notifies the status setting part 24 of it each time the status changes . at the same time , it detects an e - mail address , a nickname used for irc , a server , and a channel and notifies of them . the pc operation detection part 23 monitors a user status and notifies the status setting part 24 of it each time the status changes . specifically , it monitors whether or not there is input by keyboard or mouse , the pc client 3 connects to or disconnects from a network by lan or dial up , the screensaver is active , input by keyboard or mouse is done on the top window in multiwindow . the pc operation detection part 23 also sends “ connection message ” to the status administration part 8 of the server 1 at every definite period of time . if “ connection message ” does not come within a period of time , the status administration part 8 determines that the pc client 3 is disconnected from the internet 2 . the status setting part 24 notifies the status administration part 8 of the server of the status of the pc client detected by the above - mentioned service detection part 22 and the pc operation detection part 23 . the status setting part 24 receives the mobile phone number of the user and the present phone number and notifies the status administration part 8 of the server 1 of them . furthermore , the status setting part 24 obtains the operational status of the pc client of another user , destination , contact address , etc . from the server 1 and outputs them . next gives a specific explanation of the process done by the pc client according to the embodiment ( process done by the application ) showing screen examples and flowcharts . fig4 shows an example of a window for setting whereabouts of the user . the right side of the screen shown in the figure is a presence status setting window . this window is for writing presence status of the user ( present , absent , away from seat , in council , in laboratory , etc . ), his / her destination , phone number , brief schedule , etc . input in the window by the user notifies the status administration part of the server 1 of a presence status . the presence status of another user obtained from the server 1 by the status setting part is displayed on a window on the left side in the figure . fig5 shows an example of a message send window in the pc client 3 . selecting the receiver of a text message on the above - mentioned left window in the figure opens the text message send window . with this , a brief message such as “ hey , come on ” or “ call me ” can be notified substantially in real time if the other party connects to the internet 2 with a pc client . furthermore , by checking the send result notification box , the result notification of a sent message can be asked for . fig6 shows the receive window of text messages . the receive window is displayed in the corner of the screen without being displayed in front of the window being used . on the right side of the window , there is a button for replying by call or text message . this button is for immediately replying to a received text message . the button on the right edge is for abandoning the text message without replying to it . by pressing any of the buttons or closing the window , the already - read message showing the text message was read is sent to the server 1 from the pc client 3 . the text message receive part 6 of the server 1 that received notification notifies the notification management part 11 of an already - read notification . if the pc client 3 where an internet application is in operation received a text message , the receive window is displayed with the application window . fig7 is a screen example when a text message is received while an e - mail application is being used . a message from user b indicated as to - be - read in fig7 is a message send by the present invention . fig8 is a screen example when a text message is received while the irc application is being used . if these internet application are being used , the mail becoming already - read or reply input to a chat is detected with the service detection part 22 of the pc client 3 and is notified the server 1 . once a pc is powered and connected to the server via the internet , the operative status notification process shown in fig9 and the connection status notification process shown in fig1 are commenced . at first in step s 1 , the above - mentioned network service detection part 22 and the pc operation detection part 23 monitor the operational status of the pc client 3 . in step s 2 , the service detection part 22 and the pc operation detection part 23 determine whether or not there is a change in the operational status . if there is a change , a new status is notified the status setting part 24 and step s 3 ensues . if there is no changes in the operational status , the process returns to step s 1 . in step s 3 , the status setting part 24 received the notification notifies the server 1 of a new operational status . at the moment , information for identifying the user such as a user name or an ip address is added and notified , and the process returns to step s 1 to monitor occurrence of a new status change . in other words , in steps s 1 to s 3 , a process that the change of the operational status of the pc client is notified the server 1 is performed . meanwhile , the pc operation detection part 23 performs the connection status notification process shown in fig1 in addition to the monitor and detection of the pc operation in the above - mentioned steps s 1 and s 2 and notifies the server 1 of the connection status . at first , in step s 21 , the pc operation detection part 23 determines whether or not the pc client 3 is connected to the internet 2 . if the result is “ yes ”, step s 22 ensues . if the result is “ no ”, the process returns to step s 21 again and repeat the above - mentioned determination . in step s 22 , the pc operation detection part 23 sends the connection notification to the server 1 via the status setting part 24 . in step s 23 , the pc operation detection part 23 waits for the elapse of predetermined time t and if the time elapsed , the process returns to step s 21 and repeats the above - mentioned determination and connection notification . namely , in steps s 21 to s 23 , while the pc client 3 is connecting to the internet 2 , a process that the connection notification to the server 1 is performed every time the predetermined time t elapses . when the pc is powered and connected to the server via the internet , the send process as shown in fig1 are commenced along with the above - mentioned operation status notification process and the connection status notification process . in step s 31 , the text message send / receive part 21 determines whether or not the other party a text message is sent to was selected . if the result is “ yes ”, step s 32 ensues . otherwise the process repeats the step and waits for the other party to be selected . in step 32 , the text message send / receive part 21 opens the text message send window in fig5 and accepts the input of a text message to be sent . in step s 33 , the text message send / receive part 21 waits for the “ send ” button to be pressed . when the button is pressed , the input message is sent to the serve with the sender &# 39 ; s name and the process returns to step s 31 . when the pc is powered , a receive process as shown in fig1 is commenced in parallel with the above - mentioned process . at first , in step s 41 , the text message send / receive part 21 waits for a reception from the server 1 and if there is a reception , step s 42 ensues . in step s 42 , the text message send / receive part 21 determines whether or not the reception is a text message from another user . if the result is “ yes ”, step s 43 ensues . otherwise step s 50 , which will be descried below , ensues . in step s 43 , the text message send / receive part 21 opens the receive window exemplified in fig6 , 7 , or 8 , notifies the user of the received text message part , and obtains a sender number included in the sent text message such as an ip address . in step s 44 , the text message send / receive part 21 determines whether or not the reply button was pressed . if the above - mentioned read - and - abandon button was pressed or the window was closed , step s 45 ensues . if the reply button was pressed , step s 46 ensues . in step s 45 , the text message send / receive part 21 sends a already - read notification that notifies the server that the text message was read . in step s 46 , the text message send / receive part 21 determines whether the pressed reply button is the button for call . if the button for call was pressed , the step s 47 ensues . if the reply button by text message was pressed , step s 48 ensues . in step s 47 , the text message send / receive part 21 dials the mobile - phone number of the other party or the phone number of current whereabouts that is notified with the text message . the receive wait state in step s 41 returns . in step s 48 , the text message send / receive part 21 opens the text message send window as shown in the above - mentioned fig5 and accepts the input of a text message . by the text message being input and the “ send ” button being pressed in step s 49 , the inputted text message is sent . the destination of the text message to be sent is set to the sender of the text message that is previously obtained . if it is determined that the reception is not a text message in step s 42 , step s 50 ensues . in step s 50 , the text message send / receive part 21 determines whether or not the send result of the text message is received . if the reception is the send result , then step s 51 ensues , the send result notified from the server 1 is notified the user , and the receive wait state in step s 41 returns . for example , a send result “ the message addressed to 020 - 222 - 222 was not read and forwarded to the mobile phone .” is displayed on the screen . if the reception is not the send result , step s 52 ensues . in step s 52 , the text message send / receive part 21 determines whether or not the reception is an already - read notification . if the reception is the already - read notification , step s 53 ensues and it is notified the user that the sent text message is read by the other party . for example , as the result display of the mail in fig7 , the text message is displayed in catalogue and the relevant message part is displayed with half - tone dot meshing or a color . after that the receive wait state of step s 41 returns . the flow of the process performed by the server 1 is explained with a flowchart . in the following description , the operational status of each pc client is shown in the above - mentioned fig2 . the server 1 can support an e - mail or irc application used by the pc client . to simplify the description , a case that a text message is sent from the mobile phone 5 a of user a to the mobile phone of another user c is described as a example . at first , flow of the process performed by the decision part 10 based on fig1 is explained . in step s 61 , by the decision part 10 receiving from the receive part 13 of the server 1 a text message sent from the mobile phone 5 a of user a , the process is commenced . the text message includes the mobile phone number , contents of the text message , sender information , and the presence of the notification of the send result . now assume that the mobile phone number of user c is “ 020 - 444 - 4444 ”, contents of the text message is “ returns to the office at 3 p . m .”, and the sender information is the mobile phone number of user a i . e . “ 020 - 444 - 4444 .” incidentally , when a text message is sent with each application from the pc client 3 , the message receive part 7 of the server 1 receives the text message and notifies the decision part 10 of it . in this case , information for identifying the sender and receiver is a user &# 39 ; s name or an ip address . if the text message is sent by e - mail , the information is an e - mail address ; if the text message is sent by irc , the information is a nickname . in step s 62 , the decision part 10 searches in the status storage part 9 with the received mobile phone number “ 020 - 444 - 4444 ” as a search key and obtains the status of user c . similarly , the decision part 10 also obtains the status of the sender . in step s 64 , the decision part 10 determines whether or not the pc client of user b is connected to the internet 2 . in this example , since the ip address of user c is not empty , it is determined that the pc client is connected and step s 65 ensues . if it is not connected , the text message is sent to the send part 14 and step s 74 , which is described below , ensues . in step s 65 , it is determined whether or not the pc client 3 of user c is in operation . namely , if a screensaver is active on the pc client of user c , it is assumed that user c is not in front of the pc and a mobile phone is selected as a destination . the received text message is stored in the message storage part 12 . conversely , a screensaver is not active on the user c &# 39 ; s pc in this example . therefore the other party is assumed to be in front of the pc , the pc client of user c is selected as a destination , and step s 66 ensues . in step s 66 , the decision part 10 determines whether or not an internet application of the pc client is active on the pc client 3 of user c . specifically , by referring to fig2 , it is understand that the e - mail address of user c is written and the e - mail is being used . in this case , step s 67 ensues . conversely , if the internet application is not active , step s 68 , which is described later , ensues . in step s 67 , the decision part 10 obtains a necessary parameter for sending the text message with an e - mail application such as an e - mail address from the status storage part 9 . at this moment the decision part 10 also obtains the name of user a . in step s 68 , the decision part 10 obtains a necessary parameter for directly sending the text message such as an ip address from the status storage part 9 . at this moment the decision part 10 also obtains the name of user a . in step s 69 , the decision part 10 notifies the text message send part 6 of the text message and the information obtained in step s 67 or s 68 and requests send . in this example , the text message is configured to an e - mail message by text message send part 6 and sent to the e - mail address of user c . in the pc client 3 of user c which received the e - mail message , the text message is displayed on an window shown in fig7 . the e - mail message sent from the server is usually sent to a client via an e - mail server . in above - mentioned step s 63 , if it is determined that the pc client of user c is not active , step s 70 ensues . in step s 70 , the decision part 10 obtains a parameter which is necessary to send the text message to the mobile phone of user c such as a mobile phone number from the status storage part 9 . at the same time , the decision part 10 also obtains the name of user a , which is a sender , the mobile phone number of user a , and the number of whereabouts . if it is determined there is no statuses and step s 70 ensues , the parameter of user c is not obtained . consequently , the other party &# 39 ; s phone number that were sent when the previous message was received “ 020 - 444 - 4444 ” is set to the other party &# 39 ; s phone number and next step s 71 proceeds . in step s 71 , the decision part 10 passes the information obtained in the above - mentioned step s 70 to the send part 14 and requests radio transmission . in step s 72 , the decision part 10 determines whether or not the mobile phone of user c can notify the server 1 that the text message was read and the sender requests notification . if both is possible , step s 73 ensues . if the notification from the mobile phone is impossible , the process returns to step s 61 and waits for the reception of the text message . in step s 73 , the decision part 10 sends the sent text message , the sender &# 39 ; s name , and send notification including a send terminal and a receive terminal to the notification management part 11 . and step s 61 returns . as described later , the notification part 11 writes contents of the received send notification in the message table . in the above - mentioned step s 64 or s 65 , if it is determined that the pc client of user c is not connected to the internet or the pc is not currently used , step s 47 ensues . in step s 74 , the decision part 10 determines whether or not sender a requests notification of a send result . if sender a requests the notification , then the above - mentioned step s 70 ensues and the notification to the mobile phone is sent . in step s 75 , the decision part 10 creates result notification addressed to the sender indicating that the text message is temporally stored in the message storage part 12 . in step s 76 , the decision part 10 determines send mode according to the status of sender a sends the result notification created in step s 74 . namely , the decision part 10 sends the text message to the mobile phone because the pc client of receiver c is not connected to the internet and notifies user a that a text message indicating it . the message is sent to the decision part 10 and transmitted to sender a in an appropriate way . flow of status administration process managing the operational status of the pc client in the server 1 is described next with a flowchart shown in fig1 . at first , it is notified the status administration part 8 of the server 1 from the status setting part 24 that the operational status in the pc client 3 of the user changed in step s 81 and the process is commenced . in step s 82 , the status administration part 8 updates the contents of the status storage part 9 for each user based on the received contents . in step s 83 , the status administration part 8 further notifies the notification management part 11 of the change of the operational status . reporting administration process performing notification to the sender from the server 1 is described below with a flowchart shown in fig1 . in this embodiment , the following four processes are performed : ( i ) main process , ( ii ) timeout process of stored text message , ( iii ) process of stored text message according to a receiver status , and ( iv ) process other than above . at first , in step s 91 in fig1 , receiving events such as message , timeout process , and status notification of user &# 39 ; s activities commences the following process . in step s 92 , the notification management part 11 determines whether or not the received event is a text message . if the event is a text message , step s 93 ensues . otherwise step s 100 , which will be described later , ensues . in step s 93 , the notification management part 11 determines whether or not the received text message is send notification notified from the decision part 10 in step s 37 in fig1 . if the received text message is the send notification , step s 94 ensues . if the received text message is not the send notification , no process is performed and step s 91 returns . in step s 94 , the notification management part 11 activates a timer counting a prescribed time and manages the message table with timer id . in step s 95 , the notification management part 11 writes timer id in addition to contents of the text message included in the send notification , sender and receiver , and send / receive type . then step s 95 ensues . if it is determined in step s 92 that the text message is not send notification or is not an usual text message , then step s 100 ensues . in step s 100 , the notification management part 11 determines whether or not the received event is timeout notification . if the event is timeout notification , message timeout handling routine in step s 300 ensues . in the timeout handling routine , stored text messages that timed out are deleted . timeout process is described later . if the received event is not timeout notification , step s 200 ensues . in step s 200 , the notification management part 11 determines whether or not the received event is notification of the operational status of a pc client . if the event is the notification of the operational status , step s 500 ensues and another handling routine is performed . the operational status handling routine in step s 400 and another operational routine in step s 500 are described later . if it is determined in step s 100 that the event is timeout notification , the timeout handling routine in step s 300 ensues . fig1 is a flowchart showing flow of the timeout handling routine . at first in step s 301 , the notification management part 11 determines whether or not the timed - out text message is left in the message table . if the text message is left , it is assumed that already - read notification from the receiver in a predetermined time and step s 302 ensues . if the text message is not left , the main routine in above - mentioned fig1 returns . in step s 302 , the notification management part 11 determines whether or not the type of the receiver of the timed - out text message is a mobile phone . if the type is a mobile phone , step s 303 ensues ; if the type is a pc client , step s 307 ensues . in step s 303 , the notification management part 11 determines whether or not the sender hopes for notification of send result of the text message . if the sender hopes for the notification , step s 304 ensues . if the sender does not hope for the notification , step s 306 ensues . in step s 304 , the notification management part 11 creates to - be - read result notification that indicates the sent text message was not read and step s 305 ensues . in step s 305 , the notification management part 11 notifies the decision part 10 of created to - be - read result notification . the decision part 10 selects appropriate send means and send method from the sender status and sends the to - be - read result notification to the sender . in step s 306 , the notification management part 11 deletes an entry of relevant text messages from the message table and the main routine in above - mentioned fig1 returns . that is to say , in steps s 303 to s 305 , result notification indicating “ the text message is sent to the mobile phone , but it was not read .” is sent to the sender . in step s 302 , if the receiver is determined as a pc client , step s 307 ensues . in step s 307 , as is the case with the above - mentioned s 303 , the status administration part 11 determines whether or not the sender hopes for notification of send result . if the sender hopes for the notification , step s 308 ensues . if the sender does not hope for the notification , step s 315 ensues . in step s 308 , the notification management part 11 creates radio send result notification indicating the text message is sent to the mobile phone . in step s 309 , the notification management part 11 notifies the decision part 10 of the created radio send result notification . the decision part 10 that received the notification notifies the sender of the above - mentioned result notification in a send mode according to the operational status of the sender &# 39 ; s pc client . in step s 310 , the notification management part 11 passes the text message to the send part 14 and deletes the entry of the relevant text message from the message table . in step s 311 , the notification management part 11 obtains necessary information such as the receiver &# 39 ; s mobile phone number to send the text message to the mobile phone from the status storage part 9 . in step s 312 , the notification management part 11 notifies the send part 14 of send information and requests the transmission of text message . in step s 313 , the notification management part 11 determines whether or not it can be notified that the receiver &# 39 ; s mobile phone read the text message . if it can be notified , the step s 314 ensues . otherwise the main routine in above - mentioned fig1 returns . in step s 314 , the notification management part 11 issues send notification including sender / receiver , send / receive type , etc . this send notification is written in the message table in the above - described step s 94 . in step s 200 , if the received event is determined as the change notification of the operational status of the pc client , step s 400 operational status handling routine shown in fig1 ensues . fig1 is a flowchart showing flow of the operational status handling routine . at first in step s 401 , the notification management part 11 determines whether or not the text message addressed to the pc client with the operational status changed is in the message table . if it is in the message table , step s 402 ensues . if not , the main routine returns . in step s 402 , the notification management part 11 determines whether or not the change of the status corresponds to “ disconnection from the internet ” or “ screensaver active .” if it corresponds to either of the above two statuses , step s 403 ensues . if it is not corresponds to any of the above two statuses , step s 410 ensues . in step s 403 , the notification management part 11 determines whether or not the sender hopes for the send notification sent to the sender , and if the sender for it step s 404 ensues . if the sender does not hope for it step s 416 ensues . in step s 404 , the notification management part 11 creates radio send result notification and notifies the decision part of it , assuming that the a text message that was previously sent to the pc client . for example , radio send result notification with a message “ the message addressed to 020 - 222 - 222 was not read in the pc and was sent to the mobile phone .” is created . the decision part determines a send mode according to the status of the sender and requests it to be sent from the text message send part 6 or the send part 14 . in step s 405 , the notification management part 11 passes the text message to the send part 14 and deletes the entry of the relevant text message from the message table . in step s 406 , the notification management part 11 obtains necessary information such as a mobile phone number to send it to the mobile phone from the status storage part 9 . in step s 407 , the notification management part 11 sends the obtained send information to the send part 14 and requests sending . in step s 408 , the notification management part 11 determines whether or not that the receiver &# 39 ; s mobile phone read can be notified . if it is possible , step s 409 ensues . otherwise the main routine in fig1 returns . in step s 409 , the notification management part 11 creates send notification including the sent text message , sender / receiver , and send / receive type , etc . this send notification is written in the message table in step s 94 of the above - mentioned main routine . if it is determined that the status change notified in above - mentioned s 402 is not disconnection or activation , step s 410 ensues . in step s 410 , the notification management part 11 determines whether or not the notified status change is completion notification of an internet application that is already sent . if it is completion notification , step s 411 ensues ; otherwise the main routine in fig1 ensues . in step s 411 , the notification management part 11 obtains send information necessary to send to pc client such as an ip address by referring to the status storage part 9 . in step s 412 , the notification management part 11 passes the send part 14 an obtained send message or text message and requests sending . in step s 413 , the notification management part 11 deletes the relevant text message from the message table . in step s 414 , the notification management part 11 determines whether or not the sender hopes for the notification of the send result . if the user hopes for the notification , step s 415 ensues . if not , the main routine indicated in fig1 ensues . in step s 415 , the notification management part 11 creates a pc send result notification and notifies the decision part 10 of it , assuming that a text message previously sent to an internet application of the pc client was not read . for example , a pc send result notification with a content “ a text message addressed to channel # ca was not read and was sent to pc ” is created . the decision part 10 selects a send means and send method according to the sender &# 39 ; s status and requests sending from the text message send part 6 . in step s 416 , the notification management part 11 obtains information necessary to send to the mobile phone such as the mobile phone number from the status storage part 9 . in step s 417 , the notification management part 11 passes the obtained information to the send part 14 and requests sending . in step s 200 , if it is determined that the received event is not a change notification of the operational status , another handling routine in step s 500 ensues . fig1 is a flowchart showing flow of another handling routine . at first in step s 501 , the notification management part 11 determines whether or not the received event is text message acquisition notification from the receiver . for example , if acquisition notification from a pc client or mobile terminal that received a text message is received by the text message receive part 7 or the receive part 13 , the acquisition notification is sent to the notification management part 11 . there may also be the case in which reply to an e - mail message or a confirmation command sent in the same channel of irc may be detected by the text message receive part 7 and the acquisition notification 11 is sent to the notification management part 11 . if the received event is acquisition notification , step s 502 ensues ; otherwise a below - described step s 503 ensues . in step s 502 , the notification management part 11 deletes the entry of the relevant text message from the message table and the main routine in fig1 returns . in step s 503 , the notification management part 11 determines whether or not the received event is notification indicating a text message to the mobile phone is stored . if it is the notification , step s 504 ensues . otherwise the main routine in fig1 returns . that is to say , if a text message is stored in the message storage part 12 , storage notification is sent to the notification management part 11 from the send part 14 . in step s 504 , the notification management part 11 determines whether or not the sender hopes for the notification of a send result . if the sender hopes for the notification , step s 505 ensues . if not , the main routine in fig1 ensues . in step s 505 , the notification management part 11 creates storage result notification indicating a text message is stored . the decision part 10 determines a send mode according to a sender &# 39 ; s status and requests sending of storage result notification from the send part 6 or the send part 14 . in the above process , time to be timed out or notification setting when a text message is not read immediately may be set for the server from a mobile phone or a pc client via the internet . the setting can also be performed with a text message in a prescribed format . a mobile terminal can obtain arbitrary information by sending a text message in a prescribed format from the mobile terminal with the text messaging system shown in the above - mentioned first embodiment . for example , fig1 shows a configuration diagram of a text messaging system that changes or refers to the operational status of a pc client managed by the server 1 . in fig1 , information server 30 is used as a pc client . the mobile terminal 5 sends a text message in a format for sending the text message to the pc client . the information server 30 pretends to be the pc client and sets an operational status form the server 1 . for example , a destination or schedule information is sent from a mobile terminal 5 to a phone number of the information server 30 as a text message in a prescribed format . as described , the server 1 sends the text message to the information server 30 . the information setting part 26 of the information server 30 that received the text message analyzes the received text message , and notifies the status administration part 8 of information that changes the operational status of the sender . the information setting part 26 sends a text message indicating that the destination of another user needs to be known with a phone number of the other user . then the server 1 sends the text message to the information server 30 . the information acquisition part 25 of the information server 30 analyzes the received text message and obtains the operational status of the other pc client with the phone number as a search key . the obtained information is sent as a text message from the information server to the number of the sender mobile terminal . accordingly , for example , current whereabouts of another user can be identified and a call can be made to him / her . as shown in fig2 , the radio server 1 b may be made to have the message storage part 12 and radio status detection part 15 by installing a radio sever 1 b independent of a text message server 1 a . in this case , the receive part 13 a and 13 b and the send part 14 a and 14 b are respectively installed in the text message server 1 a and the radio server 1 b . the status administration server 1 c may also be made to have the status administration part 8 and decision part 9 by further installing an independent status administration server 1 . a where - to - call number may be sent with a text message so that the other party can immediately call back when the text message is sent from a pc client or a mobile phone . a receiver can call the number and talk to the other party as soon as he receives the text message . for example , the decision part 10 refers to the sender &# 39 ; s status as well as the receiver &# 39 ; s status . if the number of current whereabouts is set in the status storage part 12 , the decision part 10 sends the phone number as a callback number with the text message . if the number of current whereabouts is not set , the mobile phone number may be sent with the text message as a callback number . in addition to the above - mentioned embodiment , it is conceivable that a schedule in a particular condition is obtained or a function such as acquisition of e - mail is added to the server 1 . services can easily be added without changing server configuration . in the above - mentioned embodiment , a single mobile communication network and a single internet are respectively shown . however , they may be multiple . since the status administration part of the server 1 holds only one active status per user , if the number of networks increases , it can be supported . use of this invention allows a text message to be sent in a send mode according to the other party &# 39 ; s status and to be sent and received substantially in real time . by notifying the sender of send result such as the text message not being checked by the other party , the text message can be notified in another send mode . furthermore , the sender can know which send mode is used in which the text message was sent and thus communications with texts can be smoothly performed in real time . while only selected embodiments have been chosen to illustrate the present invention , to those skilled in the art it will be apparent from this disclosure that various changes and modifications can be made herein without departing from the scope of the invention as defined in the appended claims . furthermore , the foregoing description of the embodiments according to the present invention is provided for illustration only , and not for the purpose of limiting the invention as defined by the appended claims and their equivalents .