Patent Publication Number: US-2003236821-A1

Title: Body wearable personal network server and system

Description:
BACKGROUND OF INVENTION  
       [0001] 1. Field of the Invention  
       [0002] The present invention relates a server-client model of data collection and internetworking gate way system, typically including a hardware device and software modules providing application and database server capabilities, and gate way functionality between Personal Area Network (PAN) and Wireless Local Area Network (WLAN), wherein the system is to be worn by the system operator, and capable for storing and retrieving data for its clients under Internet based protocols over a Personal Area Network, and capable internetworking between PAN and WLAN.  
       [0003] 2. Description of the Background Art  
       [0004] Recently, it is convenient to get information from the Internet through the personal communicators, such as mobile phone, personal digital assistant (PDA), personal computer, packet personal computer, and notebook computer. Usually, this information is stored into the storage device of the personal communicators for further using, but the storage space is always not enough to keep Internet information for long term. If try to increase the storage space, need to enlarge equipment size, and need to increase the power supply also the weight will be increased.  
       [0005] The personal communicators are popular and always come out a new model frequently. A user may purchase the new model to replace the old one. Once the new model is activated, data in the old model needs to be copied to the new model then the memory device in the old model will be thrown. It is inconvenient and costly for the old memory device may be still functional, does not need to be obsolete with the old model at same time.  
       [0006] Recently, the battery usage time for the personal communicators is not long enough. A user needs to recharge the battery frequently.  
       [0007] Recently, the mobile phone devices enable the users to play Internet games or watch movie via the Internet, but it is expensive for on line usage due to the Internet payment, and at the same time the phone channel is occupied that prohibits the users from making or receiving any phone calls.  
       [0008] Recently, it is expensive for wireless Internet services through mobile phone or PAD.  
       [0009] Recently, Mobile phone or PDA can not provide both connections to PAN; such as Bluetooth, and WLAN; such as IEEE802.11b.  
       SUMMARY OF INVENTION  
       [0010] The present invention is able to store data, which is downloaded from the Internet web servers via the personal communicators. The present invention is body wearable, so the individual can retrieve data from the invention anywhere, anytime, and the access of the Internet is thus unnecessary.  
       [0011] The present invention is not anymore a server-client coexistent device. The present invention separates a conventional data communicator device into a server and a client. The server is body wearable and has its own battery and memory. The client is conventional personal communicator therefore can be redesigned to decrease its weight by decreasing its memory spaces or battery size.  
       [0012] The present invention can be set as the distributed database of its clients. The identical data does not put in all clients anymore. The data will be easy to maintain.  
       [0013] When any of old client needs to be replaced, the present invention needs not to be replaced with the client, so the data in the present invention will not be changed. The cost of replacing one of old clients is lower than to replace the server-client coexistent device.  
       [0014] The multiple users can simultaneously interactive to the present invention for playing game or watching movies. In the meantime, the phone channel is still available to allow the user to access phone calls.  
       [0015] The various kinds of applications can be installed in the present invention to provide the user convenient tools for managing his or her data.  
       [0016] The present invention is designed based on Internet protocols, so there is no need for extra conversion for the data, which is used in the Internet web server and tried to store in the present invention.  
       [0017] The present invention can be designed as an XML application server to provide the maximum coverage and is easy to maintain in the long run. The server programming gives the most control.  
       [0018] The present invention can provide gate way functionality for transmitting data between PAN and WLAN networks. 
     
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
     [0019]FIG. 1A shows a general picture of a body wearable personal network server and system according to the present invention.  
     [0020]FIG. 1B is a block diagram corresponding to the entities in FIG. 1A to illustrate the relationship of server and clients, also illustrates the blocks for representing the area of the invention that is applied. The present invention comprises the software and hardware portions in a body wearable personal network server and the software for personal communicators to enable it to work with the body wearable personal network server.  
     [0021]FIG. 1C shows a internetworking picture among the present invention, Personal Area Network, and Wireless Local Area Network.  
     [0022]FIG. 2A shows an external appearance of a body wearable personal network server (device).  
     [0023]FIG. 2B is a perspective view of the batteries location in a body wearable personal network server (device).  
     [0024]FIG. 2C is a view of bottom up aspect of a body wearable personal network server (device).  
     [0025]FIG. 2D is a view of the location of the rechargeable power supply contacts, the location of Universal Serial Bus (USB) connector, and the location of the alarm apparatus. The device also provides a vibrated gear inside the body wearable personal network server (device).  
     [0026]FIG. 3A is a block diagram illustrating the components of the hardware portion in a body wearable personal network server in FIG. 1B.  
     [0027]FIG. 3B is a block diagram illustrating the components of the communication portion in FIG. 3A.  
     [0028]FIG. 3C is a block diagram illustrating the components of the output devices in FIG. 3A.  
     [0029]FIG. 4A is a block diagram illustrating the components of the software portion in a body wearable personal network server in FIG. 1B.  
     [0030]FIG. 4B is a block diagram illustrating some of applications can be installed in the body wearable personal network server.  
     [0031]FIG. 4C is a block diagram illustrating the types of the data formats that can be provided in the body wearable person network server.  
     [0032]FIG. 5 is a block diagram illustrating the functions of the software portion in the body wearable personal network server in FIG. 4A.  
     [0033]FIGS. 6A, 6B, and  6 C is a flow chart illustrating the manner in which the operating management functions and applications are performed in the body wearable personal network server.  
     [0034]FIG. 7A is a block diagram illustrating the components of the software portion in the personal communicators in FIG. 1A.  
     [0035]FIG. 7B is a block diagram illustrating how the identical application software can be Installed in the different personal communicators based on the different platforms, which provides different APIs for the application software.  
     [0036]FIG. 8 is a block diagram illustrating the functions of the software portion in the personal communicators in FIG. 7A.  
     [0037]FIG. 9A is a flow chart illustrating the software portion in the personal communicators to perform the manner of the outgoing signal to the body wearable personal network server.  
     [0038]FIG. 9B is a block diagram illustrating the various sources that generate the outgoing signal from the personal communicators.  
     [0039]FIGS. 10A, 10B, and  10 C is a flow chart illustrating the software part in the personal communicators to perform the manner of the incoming signal from the body wearable personal network server.  
     [0040]FIG. 11 shows a picture of a body wearable personal network server and system, which provides access authorities for the multiple users. 
    
    
     DETAILED DESCRIPTION  
     [0041] Embodiments of the present invention are hereinafter described in conjunction with the drawings.  
     [0042] First Embodiment.  
     [0043] A first embodiment is discussed now.  
     [0044]FIG. 1A illustrates the general working environment of the present invention where it is applied. The device of the present invention denoted as  1  is a body wearable device, and is able to communicate with personal communicators, such as mobile phone denoted as  2 , PDA denoted as  3 , personal computer denoted as  4 , and notebook computer denoted as  5 , via a wireless connection; such as a PC card (formerly known as PCMCIA card—The Personal Computer Memory Card International Association) providing IEEE 802.11 or Bluetooth protocol in a PC card slot, or/and a wire connection through USB connector. In order to achieve the functions of the present invention, the proper software needs to be installed in the device of the present invention  1 , and in the personal communicators  2 ,  3 ,  4 , and  5 .  
     [0045] The body wearable personal network device portion is acting as a sever  1  in FIG. 1B, and the personal communicators are acting as clients  2 ,  3 ,  4 , and  5  in FIG. 1B. The relationship of server and clients for the present invention is illustrating in FIG. 1B. FIG. 1B is a schematic block diagram to illustrate the present invention, which is a body wearable personal network sever and system. The system includes a body wearable personal network server (BWPNS)  1  with its hardware portion  21  and software portion  22 , and the software portion  31  is installed in personal communicators in order to enable personal communicators to work with the BWPNS.  
     [0046] A procedure to activate the clients (personal communicators) in order to work with the server (BWPNS) is first to configure one of the clients as an administrator, which needs to be set up by the server  1 , and the rest of the clients will be configured by the administrator. After activation, all clients need to register to server to provide its resource profile; such as the size of its screen, then the server will provide unique identification for each client. The server  1  holds all resource profiles and identifications in database. As soon as a client is authorized to access the server, it can download and upload the data from and to the server. The communication protocols between server and clients adopt the standard Internet protocol stack, such as XML (extensible Markup Language), WML (Wireless Markup Language), or FTP (File Transfer Protocol) above HTTP (Hypertext Transfer Protocol), and each virtual IP address for each client can be configured by administrator and managed by the server.  
     [0047]FIG. 1C shows that the BWPNS denoted as  1  provides the gate way functionality between PAN (through protocol; such as Bluetooth), and WLAN (through protocol; such as IEEE802.11b).  
     [0048]FIG. 2A is the general outlook of the BWPNS device denoted as  1  in FIG. 1A, which comprises a body case denoted as  6 , and a removable/rechargeable battery denoted as  7 . The body case 6  comprises the wireless connection status icon denoted as  101 . When this icon appears on the liquid Crystal Display (LCD) denoted as  115 , it means that there is at least one of the registered clients communicating to the server. Another icon denoted as  102  is an indicator of the strength of the power supply. The timer denoted as  103  can be shown on LCD as the default screen. Function keys denoted as  107 ,  108 , and  109  are designed on the bottom of the LCD. The application programs can be designed to handle these function keys. An example like one of the applications use the function key  107  to choose the left item of the selection, the key  109  is used to choose the right item of the selection, and the key  108  is used to confirm and execute the selection. The power switch denoted as  110  handles to turn-on and turn-off the power. There are two LED (Light Emitting Diode) indicators denoted as  111 , and  112 , which are programmable and allow application programs to exhibit exception signs to the user. There is a lid denoted as  13 . Under the lid, there is a liquid crystal battery denoted as  131  in FIG. 2B. A removable/rechargeable battery secure lock denoted as  105  is for holding the battery. The battery charge contacts denoted as  116  are used to recharge the battery power. A bulgy object denoted as  117  is used for easily pull off the battery.  
     [0049] As illustrated in FIG. 2C, shows a bottom up view of the BWPNS device, which can be hanged on waist belt by a clip denoted as  131   
     [0050] As illustrated in FIG. 2D, the BWPNS device is designed for providing wire and wireless connections. The wire connection is the USB type of adaptor denoted as  121 , which is able to connect to a client via USB cable denoted as  122 . The wireless connection use a Bluetooth plus IEEE802.11b card build inside device  6 , which can adopt dual-mode Bluetooth and IEEE802.11b in the same device; such as Blue802 Technology unveiled by Intersil and Silicon Wave. Contact information is Silicon Wave, Inc. 6256 Greenwich Drive Suite 400, San Diego, Calif. 92122 and Intersil Corporation, 7585 Irvine Center Drive Suite 100, Irvine, Calif. 92618. A battery release button denoted as  119  to release the removable battery, which is locked through the notch denoted as  120 . The power supply contacts denoted as  118 . The speaker apparatus denoted as  124 , which is programmable and allows application programs to use it to generate basic radio alarms.  
     [0051] A block diagram FIG. 3A illustrates the primary components to comprise the BWPNS hardware portion  21  of the server  1  in FIG. 1B. The components include MPU (MicroProcessor Unit)  132 , power supply 138 , ROM and RAM memory  135 , output devices  134 , Flash Memory Chips; (Disk-on-Chips)  133 , the communication units  131 , function key entry  139 , and a timer  136 . The communication units illustrated in FIG. 3B include wireless connection  1311 , providing dual radio modes of PAN (such as Bluetooth) plus WLAN (such as IEEE 802.11b) via a PC card or build-in device, and USB wire communication port  1312 . The output devices illustrated in FIG. 3C include a LCD  1341 , indication LEDs  1342 , a speaker  1343 , and a vibrated device  1344 .  
     [0052] A block diagram FIG. 4A illustrates the software hierarchical structure for software portion  22  in FIG. 1B in the BWPNS denoted as  1  in FIG. 1B. The device drivers  241  interface with hardware devices and provide the upper level the software channels to use hardware devices, such as to access hard disk driver for retrieving or storing data files. An operating system (OS)  242  is a brain of the software portion, which handles and manages system resources, schedules application tasks, manages memory allocation, handles system exceptions, and so on. The HTTP/TCP/IP/Data Link/Physical Layer protocol handler  243  performs all protocol issues according to protocol agreements published by the standard organizations; such as ITU or IETF. Based on the customer&#39;s requirements, profiles or the incoming event type, the XML (Extensible Markup Language) handler  244  or FTP (File Transfer Protocol) handler  245  is evoked for receiving or sending the proper types of presentations. The data formatter  246  is the extension of the applications, which convert data into proper format according to users&#39; profiles. As FIG. 4C, the generated data formats that the BWPNS supports are audio data  221 , such as wav files, music data  222 , such asmp 3  files, binary data  223 , control data  224 , which is under the control command format using between server and clients, text data  225 , image data  226 , such as JEPG, web data  227 , such as WAP, XML files, game data  228 , movie data  229 , such as mpeg files, and library data  230 , such as dll files.  
     [0053] Continue in FIG. 4A, the applications  247  installed in the BWPNS provide the services to the clients. As FIG. 4B, the applications include:  
     [0054] System Manager  201 : This application is running in the background and attempt to detect any exceptions of the system (BWPNS). A warning sign or report will be generated whenever any exception is detected.  
     [0055] Personal sick or hospital historical record management system  202 : This system manages the personal healthy records for routine or emergent purposes.  
     [0056] Resource Manager  203 : This application is running in the background and attempts to manage the resources for the BWPNS. An example is when after a long run, the hard disk space contains too many fragmental spaces, so this application will be automatically executed to de-fragmentize the spaces.  
     [0057] Security Manager  204 : This application handles all security issues; such as assigns the access authorities to clients, and attempts to block hikers to break into the system.  
     [0058] Ring Music Manager  205 : This application assigns the user configured music to use for ring sound.  
     [0059] Recorder  206 : This application allows the user to use the BWPNS as a voice recorder. The voice can be put from client, and can be played to clients.  
     [0060] Email manager  207 : This application stores, retrieves, and manages the emails for the user. It also provides the ability to convert the text data format to the voice data format, and vice visa.  
     [0061] Planner  208 : The application can accept the schedule plans from user for monitoring and arrangement the schedules. It also generates an alarm or a report to the user when the schedule time is reached.  
     [0062] Personal data manager  209 : This application is designed to help user to store, retrieve, and manage his or her personal data, such as a phone list, a shopping list, and personal photos.  
     [0063] Dictionary  210 : This application can be a dictionary for the user; such as it can be an English dictionary and can travel with the user.  
     [0064] Personal Home Page  211 : The user can configure, store, and retrieve his or her home page in BWPNS through this application. The personal Home Page then can be shown on his or her personal communicators.  
     [0065] Voice Recognition  212 : This application can accept voice commands and provides proper responses to the user.  
     [0066] The database handler  248 , such as Microsoft SQL2000, which provides capabilities to manage, store and retrieve data in the databases.  
     [0067]FIG. 5 is a data flow diagram that illustrates the software portion  22  in FIG. 1B in the BWPNS denoted as  1  in FIG. 1B. The communication reception unit  151  receives an event sent from a client (a personal communicator), or from the function key touch pad on the BWPNS. The communication reception unit forwards the event to the security-checking unit  153  for the security and authorization checking. If the incoming event does not pass the security checking, a failure indication signal will be sent back to the event generator via the communication transmission unit  152 . If the incoming event passes the checking, the event is sent to the signal management unit  154  for distinguishing the type of the event in order to determine the further direction of the event. If the event is sent from the personal communicator, the signal confirmation unit  155  will be evoked to send a confirmation message back to the personal communicator via the communication transmission unit  152 , otherwise based on the event type, a proper event handler unit is evoked to handle the incoming event. The general event handlers are: System Command Handler Unit (SCHU)  157 : Some of events are for control commands, which are used to control, manage, or synchronize the in progressing communication activities between the server (BWPNS), and clients (Personal Communicators); such as hand sharking activity.  
     [0068] System Software Handler Unit (SSHU)  158 : SSHU is for installing or updating the system software. The system software is for managing, handling, and maintaining the hardware devices, and software resources.  
     [0069] Application Data Handler Unit (ADHU)  159 : ADHU is for applications to handle, store, and retrieve any format of data, as well as converting text format of data to voice format of data or voce visa.  
     [0070] Security Data Handler Unit (SDHU)  160 : SDHU is for administrator to handle security events.  
     [0071] The Command Parsing Unit  161  is evoked by the SCHU  157  to parse the system command signals. Based on applications, some of system commands will be sent to the Database Management Unit  162  to interact with database, and some of system commands directly issue results to the Output Unit  166 .  
     [0072] The Database Management Unit  162  is for storing, retrieving, controlling, and managing the database. Based on the different characters of data and programs, the resources of the data storage need to be managed, and the theory and the method to access the data storage need to be controlled by the Database Management Unit  162 .  
     [0073] If incoming command asks for or the internal application is evoked for response of the result, the result will be retrieved from the Database Management Unit  162 . The Data Response Unit 163  will be in service to handle the outgoing data. The Connector Resource Unit  164  is also put in service to evoke the proper output devices, to check the availabilities of the resources, and to obtain the resources for this event.  
     [0074] Based on the command or the application, the outgoing data may need to be reformatted by the Formatter Unit  165 .  
     [0075] Inside the BWPNS, there are some units that are automatically, periodically, or intentionally executed in the background of the system. These units are: System Management Unit (SMU)  167 : SMU is evoked to issue, report, or record the system status situations. SMU sends the results to the Output Unit  166  or to the clients (Personal Communicators) via the Communication Transmission Unit  152 .  
     [0076] System Diagnostic Unit (SDU)  168 : Usually, SDU is always executed in the background. As soon as the system detects any exceptions of the system, the SDU is evoked to attempt to fix the problem and generate the reports to the Output Unit  166  or to the clients (Personal Communicators) via the Communication Transmission Unit  152 .  
     [0077] Timer Management Unit (TMU)  169 : TMU is executed in the background and can be configured by Function Keys denoted as  107 ,  108 , and  109  in FIG. 2A. The accurate time displays on LCD denoted as  103  in FIG. 2A.  
     [0078] Power Management Unit (BMU)  170 : BMU provides the status of the power strength. If the battery strength is very weak and needs to be recharged, the signal will be sent to the Output Unit  166 , and the power strength icon denoted as  102  in FIG. 2A will show the cross mark on the icon. At the request, BMU can also display the current power strength on the LCD denoted as  103  in FIG. 2A. The BMU can be used to determine whether the server is in “sleep” or “wake up” mode. When the server is in idle for a while, BMU will leave the server in a sleep mode for power conservation, and BMU generates a “wake up” on the receiving of data.  
     [0079] The Output Unit  166  groups the different output devices, such as LCD  1341 , LEDs  1342 , speaker  1343 , and vibrated device  1344  in FIG. 3C. Applications can send the results to the proper output devices according to the users&#39; profiles.  
     [0080] A message flow chat for the software portion  22  in the BWPNS denoted as  1  in FIG. 1B is illustrating in FIGS. 6A, 6B, and  6 C. The processing at step S 1001  is to read the incoming signal from the incoming signal buffer, which accumulates and stores all incoming signals. The incoming signal was possibly sent from personal communicators through a wireless or wire connection, or sent from the function keys denoted as  107 ,  108 , and  109  in FIG. 2A by users&#39; input, or sent from the internal (inside BWPNS) application. When the incoming signal is obtained, the security checking is needed to verify the cryptogrammic information that carried by the incoming signal. From the step S 1002 , if the incoming signal can not pass the security checking (has a security error), the step S 1003  is performed to send out a failure response back to the sender, and the step S 1004  is executed to output an error from the specific output devices, which were configured by user. If the incoming signal passed the security checking, the step S 1005  is performed to assemble the fragmental signals if it is needed. If all fragmental signals for one message are not all received, the fragmental signals are stored in the buffer, and the processing is looping back to wait for the next fragmental signal. If one intact message is sent complete, the step S 1006  is performed to parse the incoming signal. According to the signal type, the signal can be distinguished.  
     [0081] On step S 1007 , it checks if the incoming signal carries the client&#39;s (personal communicator&#39;s) configuration data, such as the screen size and resolution values of output screen on the mobile phone, the step S 1008  is performed to update the client&#39;s profile, which will be used for the outgoing signal in order to send the correct format of the outgoing signal to fit the client&#39;s devices and requests.  
     [0082] The step S 1009  is to check whether the incoming signal is for asking to store the data. If the signal is for asking to store the data, which is carried within the signal, the step S 1010  will be called to update the proper database, which is according to what application is requesting for updating, such as email management application is asking for storing and updating the email database.  
     [0083] The step S 1011  is to check whether the incoming signal is for asking to retrieve the data. If the signal is for asking to retrieve the data, the step S 1012  is performed to get the proper data from the proper database, such as to get a text data from the text database. The next step S 1013  is called to process application software for the necessary adjustment of the outgoing data, such as for a big outgoing data, the fragmentation processing is performed to send fragmental data one by one. Once the outgoing data is prepared, the step S 1014  is performed to check the configuration database in order to get the receiver&#39;s resource profile, such as the receiver is a mobile phone and only can accept audio data. The step S 1015  is called when the original outgoing data does not fit receiver&#39;s requests, therefore the original data needs to be converted and reformatted to fit the receiver&#39;s requests. For an instance, the text data needs to convert and reformat to become audio data to fit the receiver&#39;s (mobile phone) request. The step S 1016  is performed to transmit the outgoing data to the output device, such as to send the outgoing data to the IEEE 802.11 protocol based wireless channel in order to send the data to the mobile phone.  
     [0084] Step S 1017  checks whether the incoming signal is sent from the function key touch pad. If the incoming signal is from the function key touch pad, the step S 1018  is performed to execute proper application to interactive with the input function keys. For an instance, the menu entry application program shows the menu on LCD. Its program asks the user to choose the proper item using the function keys  107 ,  108 , or  109  in FIG. 2A.  
     [0085] Step S 1020  is performed if the incoming signal has been checked through S 1019  that the incoming signal was sent from the internal application, such as internal diagnostic management application. The step S 1020  is performed for checking the configuration database in order to get the administrator&#39;s resource profile, such as the administrator is a mobile phone and only can accept audio data. The step S 1021  is called when the original outgoing data does not fit administrator&#39;s requests, therefore the original data needs to be converted and reformatted to fit the administrator&#39;s requests. For an instance, the text data needs to be converted and reformatted to become audio data format to fit the administrator&#39;s (mobile phone) request. The step S 1022  is performed to transmit the outgoing data to the output device, such as to send the outgoing data to the IEEE 802.11 protocol based wireless channel in order to send the data to the mobile phone. The step S 1023  is performed to send out signal from the output devices sited in server, such as the diagnostic management detects the database storage problem, so it sends out the warning signal to the speaker device, which was configured as the default warning output device by user.  
     [0086] Step S 1024  checks the in coming signal is for a security reason or not. If the signal is for a security reason, the step S 1025  is performed to process the security issues, such as the incoming signal is for a security reason to try to erase all data in database, then the security process is performed to erase all data in database.  
     [0087] After all steps have been checked or performed, the processing loops back from the beginning to read the next signal from the incoming signal buffer.  
     [0088] A block diagram FIG. 7A is illustrating the primary software units residing in Body Wearable Personal Network Client (BWPNC), personal communicator, and providing the capabilities to work with the BWPNS. The primary units include applications  540 , and Body Wearable Personal Network Client Platform  560 , which allows the identical applications  540  to port in the different BWPNS. The applications  540  in clients are the same of the applications that provide in server  201  through  212  in FIG. 4B.  
     [0089]FIG. 7B shows a concept of porting identical applications  540  to the different BWPNC based on the different platforms. One of the Body Wearable Personal Network Client Platforms  5601 ,  5602 , or  5603  is only fit the particular one of personal communicators  5801 ,  5802 , or  5803 , but the identical applications  540  can suit with all Body Wearable Personal Network Client Platforms  5601 ,  5602 , and  5603 .  
     [0090]FIG. 8 is a data flow diagram illustrating the primary functionalities of the BWPNC. A pseudo closed space covers the software portion  31  in FIG. 1B in clients denoted as  2 ,  3 ,  4 , and  5  in FIG. 1B. When the Communication Reception Unit  521  receives the incoming signal, it sends the signal to the proper signal handler unit though the platform APIs  523 . The general signal handler units in the BWPNC include: Security Data Handler Unit in Client (SDHUC)  524 : SDHUC is evoked when the incoming signal is sent for asking to handle security events.  
     [0091] Application Data Handler Unit in Client (ADHUC)  525 : ADHUC is evoked when the incoming signal is sending to application tasks. ADHUC will execute the proper tasks to perform the request in the incoming signal, or to catch the data, which is sent with signal. Then ADHUC sends the data to the Memory Management Unit  529 , or send the data to the Output Unit  528 , or send the data to the Interpreter Unit  531 . For an instance, one application in BWPNC sent out a command to BWPNS to ask for an old image data, the response signal with a request image data then is sent from the BWPNS to SDHUC and displays on the Output Unit in SDHUC.  
     [0092] Key Touch Pad Input Handler Unit in Client (KTPIHUC)  526 : KTPIHUC is evoked when the input signal is sent from the key touch pad. KTPIHUC is interactively working with the key touch pad then asks applications to work for the requests, or sends requests to the Command Construction Unit  530  to construct a new command to BWPNS.  
     [0093] The Memory Management Unit  529  is for storing, and retrieving the temporary application data in RAM (Read Access Memory). The application data in the RAM maybe retrieved by the Execution Unit  532 , which is one of the application programs to try to read the application data in order to perform the tasks according to the user&#39;s requests. The Command Construction Unit  530  may also retrieve the data from RAM, in order to build the new commands.  
     [0094] The Output Unit  528  interfaces to the device drivers, which provide from the Operating Systems of the personal communicators, such as Microsoft CE, and Symbian OS, in order to operate the output devices, such as LCD screen, and Speaker.  
     [0095] The Interpreter Unit  531  is evoked to interpreter the bytecodes, such as java programs, which are sent from BWPNS. The results of the binary codes are moved to the Execution Unit  532  for executing. The final results will send to the Output Unit  528 .  
     [0096] The command Construction Unit  530  is evoked to build new commands. The new commands may be required to include parameters that can be retrieved from the RAM through Memory Management Unit  529 .  
     [0097] The Outgoing Command Unit (OCU)  527  is evoked when any commands and data need to be sent out by the Communication Transmission Unit  522  via the function calls from platform APIs. The OCU  527  will check the size of the data in the outgoing data, if the size is too large, the fragmentation function will be performed to send out consecutive fragmental data.  
     [0098] If some of applications, which are provided by other entities (other software provides supports the software was not originally for communicating with BWPNS), want to communicate with BWPNS. These applications are able to communicate with BWPNS through platform APIs  523 .  
     [0099] Message flow chats FIGS. 9A and 9B illustrate the outgoing signal processing in the software portion  31  in FIG. 1B in BWPNC. The step S 2001  is performed when the BWPNC (a personal communicator) obtains the outgoing signal and data from the personal communicator&#39;s database (step S 20011 ), or from the request commands from the personal communicator&#39;s applications (step S 20012 ), or from Internet WEB Server (step S 20013 ), or from the input of key touch pad (step S 20012 ). After step S 2001  , the outgoing message is successfully received, and is kept in the temporary buffer. The step S 2002  then is performed to append the security data into the outgoing message based on the security information stored in the security database. The step S 2003  is performed to transmit the outgoing message to the output unit. After step S 2003 , the hand sharking status between server and client needs to be updated to indicate that the message has been sent from BWPNC to BWPNS (step S 2004 ).  
     [0100] A message flow chat FIGS. 10A, 10B, and  10 C illustrates the incoming signal processing in the software portion  31  in FIG. 1B in BWPNC. The processing is triggered when the incoming signal sent from BWPNS is received from the signal buffer (step S 2021 ). When the incoming signal is obtained, the security checking is needed to verify the cryptogrammic information that carried by the incoming signal. From the step S 2022 , if the incoming signal is unable to pass the security checking (has a security error), the step S 2023  is performed to send out a failure message to the Output Unit. If the incoming signal passed the security checking, the stepS 2024  is performed to assemble the fragmental signals. If all fragmental signals for one message are not all received, the fragmental signals are stored in the buffer, and the processing is looping back to wait for the next fragmental signal. If one intact message is received complete, the step S 2025  is performed to parse the incoming signal. According to the signal type, the signal can be distinguished.  
     [0101] On step S 2026 , it checks if the incoming signal is the response signal with an error indicator, which indicates the error was found in BWPNS during the processing, the step S 2027  is performed to modify the hand sharking status to express that the response is sent back. The step S 2028  is called to send the error indication to the output unit.  
     [0102] If the processing is complete (step S 2029 ), the step S 2030  is performed to modify the hand sharking status to express that the response is sent back.  
     [0103] If the text data is response as the request (step S 2031 ), the step S 2032  is performed to display the text data.  
     [0104] If the audio data is response as the request (step S 2033 ), the step S 2034  is performed to play the audio data.  
     [0105] If the image data is response as the request (step S 2035 ), the step S 2036  is performed to display the image data.  
     [0106] If the movie data is response as the request (step S 2037 ), the step S 2038  is performed to play the movie data.  
     [0107] If the diagnostic, warning, or management signal is response as the request (step S 2039 ), the step S 2040  is performed to send the response to the proper output unit.  
     [0108] If the executable binary data is response as the request (step S 2041 ), the step S 2042  is performed to execute the binary data, and then the step S 2043  is called to output the results.  
     [0109] If the bytecodes are response as the request (step S 2044 ), the step S 2045  is performed to interpreter the bytecodes to the binary codes, and the step S 2042  is performed to execute the binary codes, and then the step S 2043  is called to output the results.  
     [0110] If the video game data is response as the request (step S 2046 ), the step S 2043  is called to output the results.  
     [0111] After all checking, the processing is looping back from the beginning to wait or execute the next signal.  
     [0112] Second Embodiment  
     [0113]FIG. 11 generally illustrates the second usage of BWPNS and BWPNC. The BWPNS can be configured for multiple users. The clients denoted as  81 ,  82 ,  83 ,  84 , and  85  are allowed to access BWPNS simultaneously. All software and hardware portions of the new configuration are the identical as the first embodiment.