TW200816753A - DiVitas protocol proxy and methods therefor - Google Patents

Abstract

A mobility architectural arrangement for managing telecommunication mobility for a handset is provided. The arrangement includes a DiVitas protocol proxy (DPP), which is configured to manage connectivity between a mobility client of the handset and a mobility server within an enterprise. The DPP includes a client DPP being configured to manage the connectivity for the mobility client of the handset. The client DPP receives a plurality of client connectivity requests from a plurality of application clients. The server DPP is configured to manage the connectivity for the mobility server. The server DPP receives a plurality of server connectivity requests from a plurality of application servers. The client DPP and the server DPP are configured to interact with one another to establish a secure channel.

Description

200816753 IX. Description of the Invention [Technical Field] The present invention relates to a DIVITAS protocol agent and a prior art conventional mobile communication platform including cellular communication, for example, a full communication system (GSM). Others that support limited mobility are known as WiFi according to the IEEE 802.1 1 standard. Both cellular and WiFi are known and are established wireless communication platforms. The next-generation platform is designed to enable mobile users to move between bee networks and include unauthorized access (standard, the standard provides switching controllers for carriers) to enable users to be able to hive and WiFi Between standards, and vice versa. However, UMA has disadvantages such as the carrier usually controlling the phone and deciding whether and when to exchange users on the network. Advanced mobile communication platforms are needed to provide enterprise-level communication control users and networks, Enterprises (instead of carriers) can choose the network and/or telephone according to the driving criteria rather than the carrier driving criteria. In addition, in mobile/wireless communication, 'usually have the following (a) echo; (b) affect service quality (Q〇S) Packet delay delay variation (packet jitter), and packet loss; (c) coordination or software platform dependencies; and (d) enterprise resource access security issues are described as follows: Nested and UMA) are beyond the standard path, and according to the enterprise problem = late, sealed hard integrity. -5- 200816753 (a) Echo has widely used echo cancellation (EC) technology to improve end-user service quality (QoS) in voice communications such as the traditional PS TN, conference phones, cellular mobile phones, and Internet telephony. . There are usually two types of echo cancellers. One type of echo canceller is commonly referred to as a line or network echo canceller (LEC). The LEC is typically used to remove electrical echoes caused by reflections from mixed components on the network generated by 2-wire and/or 4-wire conversion. Another type of echo canceller is often referred to as an acoustic echo canceller (AEC). The AEC is typically used to remove acoustic echoes due to acoustical feedback from the microphone to the microphone, mobile phone, or conference phone on the speakerphone speakerphone. Compared with LEC, it is more difficult to implement AEC due to the following factors: Because the speed of sound is much slower than the speed of light (or electron velocity), the echo tail is longer, so the echo canceller must have more processing power and memory; because of the phone or The movement of the speaker and the changes in the environment, so the dynamics of the acoustic echo characteristics vary greatly, so the echo canceller must track and catch up with the changes in the echo characteristics more quickly; and because of the multiple objects from different distances and/or orientations. Multiple echo paths caused by reflections. Current acoustic echo cancellation techniques typically have limitations. Although acoustic echo cancellation techniques have been invented and used for at least 40 years, the basic method of eliminating acoustic echo has not changed significantly. Typically, a typical AEC uses an adaptive filter to model one or more echo path transfer functions and try to produce a copy of the echo. The AEC can then subtract this copy from the incoming input signal to form the final anecho-free far-end signal output. -6 - 200816753 To date, most of the developments in acoustic echo cancellation techniques have used filters such as FIR or IIR filters, single or multi-wave filters, or time or frequency domain filters. In addition, different algorithms such as LMS, APA, etc. have been used to improve filter efficiency. Despite all these technological improvements, AEC has designed and implemented a very difficult job today. Because of the complexity and variability of acoustic echoes, conventional filters present a number of limitations on the processing of acoustic echoes that are limited to poor two-end talk (near-end and far-end talker) performance. The result of the conventional filter calculation is to replace the convergence between echo and copy at the end of the talk. (b) Packet delay, packet delay (packet jitter), and packet loss affecting quality of service (Q〇S). In voice over internet and network video communications, voice and/or video content needs to be immediately transferred from the sender. The receiver, however, was originally designed for non-instant messaging. Therefore, providing and maintaining the ultimate quality of service (QoS) becomes a very difficult task. The packet delay, packet delay variation (packet jitter), and packet are considered to be qualities and important QoS parameters that affect the voice and video communications of the IP network. The current bounce buffering technique has limitations. A bounce buffering scheme, also known as debounce, is typically used on the receiver side to compensate or eliminate net bounce. Basically, the solution cannot be implemented as soon as the packet is received. Instead, the solution can be evenly spaced into the packets. Different types of bands filter RLS, and this is still a formal system. It is said that there is a delay between the frequency media IP network end user end-to-end loss of the three-pass scheme road packet packet. And implementation 200816753 has been packaged. In fact, the packet queue indicates the insertion delay before the implementation takes place. The delay of insertion is often referred to as the implementation delay. There are at least two problems with the current design and implementation of the bounce buffer. The first question is related to how many implementation delays need to be inserted. There can be more or less implementation delays. In the case of large delays, packet loss is less. On the other hand, in terms of small delays, the interaction feels better. The first problem can be solved expediently by an adaptive jitter buffering scheme. In the adaptive jitter buffering scheme, the receiver can estimate the network packet jitter based on the timestamp of the RTP header of the incoming packet and the local time of the receiver. The receiver then inserts a minimum delay just enough to compensate for network packet bounce. The second problem with the bounce buffer design is related to when the insertion delay is inserted. Ideally, an implementation delay can be inserted at the beginning of each speech. Therefore, although it is possible to implement each speech at equal intervals, only the silent period between the speeches is expanded or compressed. For example, if the transmitter utilizes a silent suppression technique, the packet entering the receiver desirably has a spacing between speeches, such that the device can be implemented to recognize each speech based on the timestamp and sequence number of the RTP header of the incoming packet. The beginning of the present. However, in fact, only in limited circumstances can the insertion delay be reached at the beginning of the speech. Most current silent suppression techniques have limitations and can only perform well in pure cases such as a single speaker or low background noise. Current silent suppression techniques are not well performed in a number of other situations, such as multiple speakers in a conference or high background noise such as mobile communications. Therefore, in order to preserve better audio quality, many applications -8-200816753 are performed without utilizing or actuating silent suppression. As a result, the packets entering the receiver can be continuous without any interruption. There are no clues on the timestamp and sequence number to see if the packet indicates silence or speech. Assuming that no silent clues are identified, the current bounce buffering technique performs poorly. One of the reasons for poor performance is that the current jitter buffer design usually only looks at the RTP header information of the packet, not the content on the RTP payload. (c) Protocol hardware or software platform dependencies Hardware or software platform dependencies can create interoperability and/or configuration issues. For interactive user conversations in communications involving multimedia elements such as video, audio, chat, games, or virtual reality, there is a need, for example, to be able to effectively communicate information between the server and the user and to be independent of the hardware. A lightweight protocol for communication protocols such as the Session Initiation Protocol (SIP) operating outside the software platform, a control plane protocol used between the server and the user, and a basic transport layer or medium for server and user communication. There is a need for an agreement that is fast enough to support emergency immediate control messages and is flexible enough to transfer large volumes of data with minimal delay. However, conventional technology agreements such as UMA are often complex and difficult to establish for interoperability. (d) Security when accessing corporate resources from mobile devices More and more companies are allowing their employees to use their own cellular/mobile phones to do business. With high-speed networks such as WiFi, Edge, UMTS, CDMAEVDO, and mobile phones, different vendors 200816753 have implemented VoIP (Internet Telephony) to mobile phones. Such implementation requires an open corporate firewall that enables VoIP-related protocols such as SIP and RTP to operate. In addition to VoIP, other enterprise data center applications can be extended to mobile phones. These applications can include one or more Presence / Instant Messaging, intranet web resources, CRM, Support database, and more. If a user uses a mobile phone to directly access corporate resources for one or more of these applications, the corporate firewall needs to be opened for multiple agreements, and an open corporate firewall can create security issues. SUMMARY OF THE INVENTION In one embodiment, the present invention is directed to an operational architecture configuration for managing telecommunications mobility of a handset. The configuration includes the DiVitas Protocol Proxy Servant (DPP), which is configured to manage the connectivity between mobile users of the handset and mobile servers within the enterprise. The DPP includes a user DPP that is configured to manage the connectivity of the mobile user's mobile users. User D P P receives multiple user connectivity requests from multiple application users. The server D P P is configured to manage the connectivity of the mobile server. The server d P P receives the complex server connectivity request from the plurality of application servers. The user DPP and the server DPP are grouped to interact with each other to establish a secure channel. The above summary is only one or more of the many embodiments of the invention disclosed herein, and is not intended to limit the scope of the invention, the scope of the disclosure of which is incorporated herein by reference. statement. These and other features of the present invention will be described in more detail in the detailed description of the invention hereinbelow. [Embodiment] Directory Architecture B. Acoustic Echo Cancellation Based on Encoder/Decoder C. Content-Based Bounce Buffer Design for IP Voice/Video Communication D. Divitas Description Protocol (DDP) E. Divitas Protocol Agent (DPP). Conclusion The present invention will now be described in detail with reference to certain preferred embodiments illustrated in the accompanying drawings. In the following description, numerous specific details are set forth. However, it will be apparent to those skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures are not described in detail in order not to obscure the invention. The features and advantages of the present invention will become more apparent from the understanding of the appended claims. The invention may be described with reference to particular apparatus and examples. Those skilled in the art will understand that the description is only illustrative and provides the best mode for practicing the invention. It should not be construed as limiting the scope of the invention. For example, although reference is made to a particular communication protocol, the present invention contemplates other agreements. For example, although WiFi (IEEE 802.1 1 ) is described as a protocol for wireless communication, -11 - 200816753 may also implement other protocols. The references made to D i v i t a s and the mobility server are equal here. Various embodiments are described below, including methods and techniques. It should be noted that the present invention also encompasses manufactured objects including computer readable media storing computer readable instructions for performing embodiments of the present invention. Computer readable media includes, for example, semiconductor, magnetic, magneto-optical, optical, or other forms of computer readable media for storing computer readable code. In addition, the present invention also encompasses an apparatus for carrying out embodiments of the present invention. Such apparatus includes circuitry (exclusive and/or programmable) that performs the operations of the embodiments of the present invention. Examples of such devices include versatile computers and/or proprietary computing devices when properly programmed, and include combinations of computer/computing devices and proprietary/programmable circuits for various operations related to embodiments of the present invention. . A. Architecture Figure 1 is a diagram of a system network 1 in accordance with an embodiment of the present invention. Setup Actions that use many possible ways to communicate with the network (Μ E ) 1 0 2 . Μ E 1 〇 2 can communicate with a cellular network 1 1 包括 including a base transceiver station (B T S ) 1 1 2, a B T S switching center (B S C ) 1 1 4 , and a mobile switching center (μ S C ) 1 1 6 . The M S C is coupled to a media gateway 120 coupled to a public switched telephone network (PSTN) 122. Other conventional public and private telephones 1 2 4 are also coupled to P S TN. P B X 1 3 0 is coupled to P S TN, and for example, to make and receive calls from the enterprise via telephone 1 36. The mobility server 150 is coupled to the PBX and other networks. For example, the mobility server 150 is coupled to the Internet Protocol Wide Area Network (Wan) through the router 132 - 12-200816753 1 3 8. The mobility server 15 5 is also coupled to the Internet 1 44 via the router 140 and the firewall 1 42. Although the present invention also contemplates multiple access points, only one access point is depicted herein. Access point 160 enables a user with Μ E 1 〇 2 to roam in the enterprise and maintain a connection with the PSTN via mobility servers 150 and 130. If the user roams beyond the border of the LAN, as will be explained in more detail below, the user will connect to another network (e.g., a cellular network). Also depicted is coupled to an internet access point 180 for access under certain conditions as described herein. 2A-C are actuating servers in accordance with an embodiment of the present invention. Security Manager - The security definition when two or more are in positive communication includes the following aspects: 1. Mutual authentication of the communication entity 2. Privacy of the communication channel 3. Integrity of the exchange message 4. Authentication of the message In the Divitas mobility scenario, there are three distinct communication entities: Divitas users, Divitas servers, and external VoIP GWs. And there are two clear path types between these entities: SIP signaling path and media path. As described in the Architecture Manual [1], the following mechanisms are used to achieve the above security aspects of the signaling and data paths between the user, the server, and the external gateway: 1. SIP TLS between the user and the server dialogue. 2. User authentication using SIP notification after SIP TLS is established -13- 200816753 3. Authentication by the user of the server 4. SIP TLS session between the server and the external VoIP gateway. 5. Server authentication using an external VoIP gateway 6. Secure Media Path 7 • Derived Demand User/Device Manager/Action Controller - Device and Mobility Manager (herein referred to as DMM) is on the device There are ongoing calls to handle both device configuration and status and mobility aspects of the module. The following paragraphs record the functions and design specifications of the DMM and the common interface supported by the DMM. 1. The device configuration controlled by the enterprise manager. 2. Report status of the device 3. Image management of the device 4. Maintain and implement mobile logic for mobile phones with ongoing calls - ie, handle WiFi to Cell (and cellular) and vice versa. 5 • Processing device initialization and configuration requests from the user. Control Plane/Telephone Control - Telephone Control (CC) is the main control plane module responsible for the following functions: 1. Voice over IP telephony

2. SIP Proxy Server and B2BUA 3. PSTN Call Management via PSTN GWs 4. PBX Feature Management via Asterisk 5 • Resource and Connection Management The Telephony Control Module resides on the DN Media Switch. The telephony control module interfaces with the SIP stack and the Asterisk (or any other) PBX to provide the functionality described in the previous paragraph - 14-200816753. 1. SIP stack (for UA, CCM, and Asterisk, etc.): The sip stack is primarily used as a protocol message decoding/encoding engine. The SIP stack performs basic protocol designation, such as standards-based message profiling and verification, retransmission, and proprietary message verification. For most agents and B 2 B U A work, the SIP stack relies on the CC for decision. The interaction between CC and Asterisk and CC and C CM is based on standard-based SIP messages. 2. Agent Engine/Configuration Manager (PA/CM): The Agent Engine acts on the Configuration Manager for all applications. After reading the disc DB at the time of supply or after the system is started, download the phone control information with the PA. The CC stores the data in RAM for local/faster access. The CC updates the PA of any dynamic information (eg, the call is in progress or is interrupted) or requires information (eg, SNMPGET). 3_Resource Manager (11"): The resource manager provides a logical diagram of the entity/network resources. These resources include GE埠, DSP resources, sockets, UDP/TCP埠, etc., but do not include system resources, such as words. Body, data buffer, timer, 宁宁 column, etc. Resources do not include sockets for internal IP C communication. CC uses RM as resource CAC, resource reservation and communication. As part of the communication, RM tells the media switch Stylized hardware to enable media to flow. Media Exchange Application (MSA) - MSA will be designed to be partially executed on Linux and the rest will be executed on the TMS320DM64x DSP processor. The application will perform the following functions: RTP packet processing. - 15- 200816753 Exchange. Code conversion. Conference call. Adaptive jitter buffer. Packet loss concealment. Includes post-processing of VAD/CNG and AGC. MSA software needs to support encoding/decoding of different speech codecs/decoders. Changing the type of algorithm and channel, that is, the need to support multi-channel, multi-algorithm design. Each encoder/decoder algorithm needs to be reentrant coded, and The data and data need to be completely releasable. To support various encoders/decoders, consider the following: a. Because DSP has limitations on the chip data memory, not all in multi-channel, multi-algorithm applications Data can be placed on the wafer all the time. This requires re-changing (between the wafer and the off-chip memory) the location of all the data (text and table) in each algorithm during the text exchange. Memory, stack size, and MIPS requirements for each supported encoder/decoder b. Exchange mechanism for messages between the host and DSP indicating the number of channels and the encoder/decoder type and any other characteristics. Channel Configuration Manager A channel that indicates the DSP of the desired type of function needs to be opened. A periodic message indicating the state of the DSP must be implemented. The DSP processor enables the external host to access the external memory of the DSP. The DSP has a first-order program of 1 6 kilobytes. And data memory. The program and data memory share the second-order memory of 25 6k bytes. You can use 16-200816753 16 million-bit external record Body (SDRAM). The shared memory between the two processors stores incoming and outgoing RTP data. Because the DSP needs to support the number of N channels', this §5 memory will contain N bits of 320 bits per length. With the transfer buffer (in the case of video, these buffers need to be 1 00 bytes). The data structure used for the information between the host and the DSP and the information required for each call is defined. Define the DSP function: a. During startup, once the software is downloaded to the DSP (the host that will download the software will be indicated by writing the predetermined address in the fixed memory location so that the DSP indicates the same). b. When the software is successfully downloaded, the DSP will execute the internal timer 1〇 m s e c. At this time, D S P polls the channel status to change to processing, and this processing is once the packet arrives and is set by the host. c. Send a start or open channel command from the host indicating the encoder/decoder type, data ready, and phone type (initially only voice) to the RX and TX directions. d. Based on the channel being opened, the DSP takes the RTP data from the external buffer and performs DSP related functions on these. e. On the TX side, the DSP places the encoded data on an external buffer for TX to acquire. 3 is a diagram of a mobile device user in accordance with an embodiment of the present invention. Execute user software or phone software on a phone that is compatible with the Divitas server. Typically, these are dual-mode phones with an ip connection that provides a cellular connection (CDMA or GSM) and an ip connection to a LAN network (wired LAN or wireless LAN) -17-200816753. It can also be used as a software phone for desktop/laptop or PDAs with microphones and speakers. The user interface user interface provides the following functions: • Set boot configuration - DNS IP address, Divitas server URL, INVISIBLE / AVAILABLE, security settings • Change user status (INVISIBLE / AVAILABLE) • Increase the company "buddieS" (partners) and get their presence information (INVISIBLE/AVAILABLE/CALL-IN-PROGRESS) • Enterprise "buddies" to show the availability status and connect to them • Users of the corporate phone feature Interface • Telephone dialing • Telephone answering • In-line docking • Designated transfer • Telephone transfer • Multi-party conference call • Voicemail notification • Missed call notification • Received call notification • Call notification -18- 200816753 • Number inquiry Dial-up with name dialing • Manual control using a cellular network instead of a WiFi network • Display version mismatch • Upgrade request/status • Disabling/disabling user software An ISP application is used to dial/receive cellular phone calls And voice • Telephone control for making VoIP calls on the LAN interface • On the LAN interface Voice engine for V〇iP calls includes encoder/decoder, echo cancellation, jitter control, error concealment • telephony from cellular phones to VoIP phones • telephony from VoIP phones to cellular phones 802.11 • Decide to be available Which IP network and their signal strength and the information to pass to the server • AP users • 802.1 1 mini port 埠 power management - whenever the signal strength of 802.1 1 is below the acceptable threshold, at a rare interval The network goes to sleep and polls the network to save power. • If the call is in progress, the signal strength and voice quality information is wrapped into an RTCP packet, or if the call is not in progress, it remains active for communication to the server. Whenever the signal strength drops to an acceptable threshold or the speech quality degrades, the server will decide to switch from VoIP to the cellular -19-200816753 network. The platform has many mobile phone vendors on the market and offers dual-mode phones. , so the software needs to be designed so that most of the code can be shared between the phones. I need to divide the code into platform dependencies. Part and platform independent part. In fact, almost all Divitas cores should be in the platform independent part of the software, so it can be easily carried from one platform to another. The platform dependent part should only have the functional adaptation layer (especially, electric S Tongue, LAN, 802.11, audio and display adaptation layer. Whenever the code is transferred to the new platform, it is only necessary to modify and rewrite these adaptation layers while providing a unified API to the platform independent part. Execute user software on it. The most common mobile platforms are Windows CE, Symbian, and Linux. In addition to dual-mode phones, user applications are designed to operate on 802.1 1 phones, PDAs, or laptops/tablets that do not have a cellular phone interface. On these platforms, a subset of features can be utilized to the user. Basically, it is impossible to VoIP from cellular to cellular. Theory of Operation At startup, the user application looks for resources available on the phone. The user application first checks for the presence of the wired network. If not, the user application checks for the presence of the 802.1 1 network. Depending on the corporate security policy, it is wired or wireless media certified. Mobile phone users should support the company's use of the company's 20-200816753. The most common security mechanism is WPA (WiFi Protected Access). Once the authentication is successful, the wireless user obtains the IP address of the IP interface using DHCP. The application retrieves the Divitas server URL and DNS IP address from the persistence database and attempts to register with the Divitas server. Application users can be executed on mobile phones within the corporate network. At that time, the user can reach the Divitas server without any additional security overlay. When the user is on a public network (e.g., a cafe or airport with WiFi internet access), the user typically sets up a VPN connection to the enterprise. The user can only reach the Divitas server after the VPN tunnel is established. The user application software authenticates the server to the server by sending an encrypted digital visa (installed by the corporate IT). Once the handset is authenticated, the user obtains a login/password from the user or stored in the handset, encrypts the login/password and sends the encrypted login/password to the server as a user authentication. When successful authentication, the server responds by sending a corporate phone number. In response, the user sends a cellular phone number to the server. The server combines the two for all future messaging solutions. SIP/TLS for signaling and SRTP for media streaming are used to ensure signaling and media streaming. However, if the user is on a VPN link, the user does not need to add another level of encryption. Adding another level of encryption can result in reduced voice quality. In that example, SIP is used for signaling and RTP/RTCP is used for media streaming. Repeat the above - 21 - 200816753 whenever the user restores network connectivity to the server. Constant Steady Operation By combining on the GUI and in continuous state, the user can select invisible at startup (invisible/available). The user has more information on the server.

The user can also frequently enter the configuration in the so-called continuous database of the company to save the configuration INVISIBLE, AVAILABLE, or CALL-IN), and the user obtains the presence information of these partners (when the server occurs, the server updates the user) When the partners are not on the phone, the user and the server are effective. The user periodically sends the network status to the servo pen 802.1 1 wireless network, and the user sends the SSID, phase signal strength and bandwidth to the server. The SSID is used as part of the RTCP packet in the frequency band. The user sends an out-of-band persistent message. The best mode for making and receiving calls from the user to the server is the network interface. You can choose to ignore the presence of the preferred mode in a cellular phone. This selection is not passed to the server and does not affect the selection and is not stored in the persistent database. The group or AVAILABLE user is saved in the user repository. Companion, and on the mobile phone. Whether they are PROGRESS (electrical huge amount). When the event 帛 information. The term exchange continues to have I. If the user shows in the deposit Point (AP) §, if the user sends the call, if it is not on the phone, then it is on the user. However, use the call on the network to make incoming calls. This must be clear when the user dials -22-200816753. The choice is made. Whenever the network conversation is not available from the user to the server, the only way to solder the phone is on the cellular interface. The user accesses all enterprise features. Whether the user software only provides service provision. The feature is that the user can make a call using the user software UI. In order to use all features of the cellular service provider network, the user software must be terminated (or disabled) and the cellular service provider can be used to dial the application. The program is being used to answer the call, and the messaging described in paragraph 3.4.2 below will not be possible. As long as the user has a conversation that has been established to the server, access to all enterprise features is used. User GUI Used to provide access to the industry features to the user. Voice SIP signaling is used to establish the voice between the user and the server will come from the audio connection The voice of the device is encoded into a GIPS voice engine (one of the supported encoders/decoders, which will be encapsulated into RTP packets, encrypted, and sent to the server on the IP interface, if needed, decrypted from the server RTP, which decodes and implements one of the j decoders. GIPS VE degree decoding, jitter control, and error concealment on the receiving side. In addition to encryption/decryption, speed encoding/decoding, GIPS engine also performs error concealment, Bounce control, adaptive packet buffering, tone cancellation and suppression, noise cancellation and suppression, automatic gain control, dialing does not have a subgroup and reception, and the service provider dials the call. VE) If needed. The same hair code / speed speech voice acoustic back voice live -23- 200816753 motion detection, comfort noise generated. Roaming Unlike a portable laptop, a mobile phone user is a mobile device. Communication within the WLAN When the user is in an 802.11 network with a telephone conversation and walking between buildings, AP communication may occur, that is, the user's mobile phone is different from the AP previously combined with the mobile phone. AP combination. If the communication is on the same subnet or on another subnet, AP communication can occur without IP address change. In this example, the IP address of the mobile phone changes. If the IP address changes, the user needs to register with the server again. At the same time, the established phone continues to flow using the old mobile information until the voice engine (VE) is notified of the new IP address. When a wireless subscriber uses 802. IX authentication, a series of messages are sent between the wireless subscribers by wireless access point (AP) to exchange certificates. This message exchange causes a delay in connection processing. When a wireless user roams from one wireless AP to another, the delay in performing 802. IX authentication may result in significant disruption of the network connection, especially for time dependent traffic such as voice or video based data streams. To minimize the delay associated with roaming to another wireless Ap, the wireless device can support PMK caching and pre-authentication. -24- 200816753 PMK Cache When a wireless subscriber roams from one radio to another, the wireless subscriber must perform full 802. IX authentication with each radio. WPA enables wireless users and wireless APs to cache the results of full 802.1X authentication so that if a user roams back to a previously authenticated wireless AP of a wireless subscriber, the wireless subscriber only needs to perform a 4-way handshake and decide on a new pairing transition key. . In the associated request frame, the wireless subscriber includes the PMK identification symbol determined during the initial authentication and stored by the wireless subscriber's PMK cache entry for the wireless AP. For example, in a wireless user and a wireless AP, the PMK cache entry is stored for a limited period of time. In order to make the transition of the wireless network infrastructure using the switch that is used as the 8 02. IX authenticator faster, the WPA/WPS IE Update calculates the PMK identification symbol 値 so that when roaming between wireless APs attached to the same switch, Reuse the PMK as determined by the switch 802·IX certification. This implementation is considered an opportunistic PMK cache. Pre-certification With pre-certification, WPA wireless users are free to perform 8 02· IX authentication with other wireless APs within their range while connected to their current wireless AP. Wireless users send pre-authenticated traffic to additional wireless APs over their existing wireless connections. After pre-authenticating with the wireless AP and storing the PMK and its associated information in the PMK cache, the wireless user connected to the wireless AP that the wireless user has pre-authenticated only needs to perform a 4-way handshake. -25- 200816753 Support for pre-certified WPA users can only be used with the public: Force in the Beacon and Probe Response frames

WiFi-Hive Communication A cellular network when there is an 802.1 1 connectivity or insufficient building in an 802.1 1 network with telephone conversations. The decision of the user to make a communication call. Decide on the strength of the ί, channel load, and speech quality criticality. One mutual decision is passed to the caller id that initiates the call on the cellular network to the monthly user check incoming call (identification symbol caller id comparison, if there is a match, accept the hive 8 02 · 1 1 phone call. On the server side On, the server 8 02 · 1 1 phone foot, patched to the other speaker's 8 02.1 source when the mobile phone user is idle on the 802.1 1 network, your connection 埠 goes to sleep. Before going to sleep, the phone hopes to In each frame, the 802.1 1 header is set to sleep. The AP receives the frame and informs the user of the desired expression. The user's 802.1 1 mini connection is asleep with the user buffering the packet. The mini connection is sleeping while sleeping. The interpreter of your connection 埠 periodically wakes up to receive the entry from the access point. The source user needs to wake up to the pre-authentication AP authentication when transmitting the call for help. The user did not send the call to the customer. According to the 802.11 letter β made a decision, then the server of one household.), and the 802.11 type telephone and lost the [phone foot lost to the user. At the time, 802.1 1 confused to inform the mobile phone ί section source bit to enter (to enter the mode source mode, ΑΡ start for ^ consumption is extremely low. Fan J regular help to pass for help. -26- 200816753 TSP (timing synchronization The function ensures that the AP and the source user are synchronized. When the base station is asleep, the TSP timer keeps running. These calls identify whether the sleeping base station has the AP buffered packets and waits for delivery to their respective destinations. When there is no incoming call for a long period of time, the 8 0 2 · 1 1 mini-connector goes to sleep. The mini-connector wakes up periodically and detects the AP's network connection. If it does not exist, the mini-connection is back. Sleep state. In this example, the mini-link sleeps longer than the previous example. Β·According/Decoder-Based Acoustic Echo Cancellation One or more embodiments of the present invention are related to signal cancellation. The apparatus may include an identification code (ID code) generator that is configured to generate an ID code. The apparatus may also include an ID code injector configured to inject the ID code into at least one of the signal and the processed signal. With Generating a gyro signal. The processed signal is generated by processing of the signal. The apparatus may additionally include an ID code detector configured to detect at least one of a transition of the gyro signal, the transformed signal, and the gyro signal, and transform the signal The apparatus is generated by a transformation of the gyro signal. The apparatus can additionally include an arithmetic function that is configured to remove at least one of the gyro signal and the transformed signal. Figure 4 depicts encoding/decoding in accordance with one or more embodiments of the present invention. Device-based method for acoustic echo cancellation. When both the near-end and far-end talkers are speaking, it is difficult to distinguish between the echo of the far-end speaker's voice and the voice of the near-end speaker' because both exist in In the same application, the application of the 27-200816753 program proposes a new method for processing acoustic echo, which is quite different from the conventional AEC. An embodiment of the present invention is A method for canceling echo during communication between a first node and a second node. The method includes injecting a password into a signal input of a first node. One or more according to the present invention In an embodiment, the first node is the network device used by the remote user, and the second node is the network device used by the near-end user. According to one or more embodiments of the present invention, the node is The network device used by the near end user, the second node is the network device used by the remote user. According to one or more embodiments of the invention, the password is injected into the far end signal input. This password carries multiple echoes of the signal or far-end signal and arrives at the near-end signal input. The near-end signal in turn includes the near-end speaker voice. Because it is carried only on the echo of the far-end signal rather than the voice of the near-end speaker. Passwords, so passwords can be used as echoes themselves, and help us distinguish between near-end speaker speech. Certain types of matched filters, such as correlation or other means, can be used to identify the echo and near-end of the far-end signal with a password. Speakers speak and remove them. A final echo-free signal will be generated at the far-end signal output. There are two important implementation considerations for this new design effort. One of the considerations is how to choose and design a password, and another consideration is how to inject the password into the far-end input signal. Both considerations have the same consideration that the end-to-end listener should not be aware of the password. When someone speaks in front of the microphone, not only the voice of the person but also a certain amount of background noise will enter the microphone. However, because the speaker's voice covers -28-200816753 and the background noise is off, usually this background noise does not interfere with the listener. As long as the background noise remains low and the SNR (signal-to-noise ratio) remains above a certain critical level, background noise does not become an influential factor. In fact, background noise is always present in actual today's voice communications. Based on the above facts, first, the password can be converted into a virtual random noise called "cryptographic random noise. Then, the existing background noise is removed from the remote signal input" and the random noise of the password is inserted into the far end. Signal input. The near-end listener does not hear any difference as long as the new SNR remains above a certain threshold. According to one or more embodiments of the invention, the injector shown in Figure 4 scrambles the password into a virtual random Noise, remove the existing background noise in the far-end signal input, and then insert the password random noise. Because the echo will exist only when the far-end speaker is speaking, the far-end signal detector will detect the far-end signal. The cryptographic generator is present and triggered. The cryptographic pilot can include the cipher timing and phase. The crypto pilot detector is used to detect the cryptographic pilot carried on the echo of the far-end signal, and because of the variable echo path, It is also used to adjust the cipher delay to the matched filter. The cipher pilot detector will eventually need to be scrambled. The cipher and cipher pilot can be designed as a cipher detector and The matched filter easily recognizes the echo of the far-end signal with this cipher and its pilot, and then removes these echoes. In addition, the nonlinear processor can be used to further reduce the residual echo and improve AEC performance after the matched filter. The features and advantages of the present invention will become more apparent from the drawings and discussion. Echo is a major problem in communication. As discussed in the background of the invention, generally -29-200816753 In the prior art, a filter (or echo canceller) An attempt can be made to provide a signal to cancel the echo path of the echo. Figure 8A is a block diagram of an exemplary conventional communication device 800 (conventional 800) including a filter 814 (or 8 1 4) for echo cancellation. As shown in the example of FIG. 8A, conventional techniques may include a signal receiver 802 for receiving signals from a remote (or far-end signal (eg, signal y'); and a signal transmitter for (eg, signal z) to The prior art device 800 further includes a speaker 806 for the signal to the user of the prior art device 800 (ie, the party): and the microphone 810 for collecting the near-end signal (eg, Including local voice and background noise.) The prior art device 800 further includes a buffer 8 12 for receiving the signal received by the receiver 802; and a filter 814 between the speaker 806 and the microphone 810. The echo path 808 processes the signal buffered in the buffer 8 1 2. The echo path 8 0 8 multiple paths of delay, decay, reverberation, etc., for example, the signal yl, etc. The prior art device 800 additionally includes a sum function 8 16, The output of the wind 8 1 0 subtracts the output of the filter 8 4. The conventional 800 additionally includes a signal feedback path for feeding the sum function 8 i back to the filter 8 1 4. The signal receiver 802 receives The signal (eg, the signal is sent to the speaker 8 06 and the buffer 8 1 2). The filter 8 1 4 plays the received or near-end signal X from the transmitted signal of the modeled echo cancellation technology device device 800, buffers the credit from the model, and is used to represent the delay y' The output y') of the wheat technology device 6 can receive signals, and the signal is processed by the model of the echo path 800 to generate a cancellation signal (such as a function of x2, y '), and transmitted. Eliminate the signal to the sum function 8 1 6 . Next, the sum function 8 16 subtracts the cancellation signal received from the filter 8 1 4 from the signal received from the microphone 8 (eg, X 1 =x + y 1 ) (eg, x2 = f (y) ')) to generate a subtraction signal (eg, z) and send a subtraction signal to the signal transmitter 8 1 8 . The output of the sum function 8 1 6 is fed back to the filter 8 1 4 to update and improve the echo path model in the filter 8 1 4 . The retro-removal method implemented in the conventional configuration 800 is further described with reference to FIG. 8B. Figure 8B is a flow diagram of an exemplary prior art method for removing echo, such as the prior art device 800 (shown in Figure 8A). As shown in the example of Figure 8B, the method begins in step 850 with the receiver 802 (shown in Figure 8A) transmitting a signal y'. Then, control is moved to steps 8 52 and 8 5 4 . At step 852, speaker 806 (shown in Figure 8A) receives signal y'. In step 156, microphone 810 (shown in Figure 8A) receives signal yl plus the near-end signal X. The signal yl represents a deformation signal of the signal y' generated due to delay, attenuation, reverberation or the like. Delay, attenuation, reverberation, etc. are produced by the echo path 8 〇 8 between the speaker 806 and the microphone 808 (shown in Figure 8A). The signal x includes the local voice plus the local ambient background noise picked up by the microphone 8丨〇. Then, a signal X 1 representing a combination of the signal y 1 and the signal 发送 is sent to the sum function 8 1 6 (shown in FIG. 8A). In step 854, the buffer 8 1 2 in turn receives the signal y. In step 8 5 8 , the filter 8丨4 processes the signal y using the model of the echo path 8000 to generate a signal x2, which is a function of y, such as f(y,), and then this -31 - 200816753 is sent to the sum function 8 1 6 (shown in Figure 8A). In step 860, sum function 816 subtracts signal x2 from signal x1 to produce signal z. Ideally, if f(y,) is equal to y1' then z will be equal to X, which is the near-end signal associated with the far-out of the echo (represented by yl). However, the model of the echo path 808 implemented in filter 814 may be inaccurate, typically z is not equal to z. In step 826, the sum function 8 16 sends the signal z to the signal transmitter 8 1 8 that passes z to the far side. In step 864, the sum function 8 16 feeds the signal z back to the filter 8 1 4 to update and improve the echo path model utilized in step 851. The feedback of the signal z and the associated calculations and updates cause the filter 8 1 4 to require additional processing time or processing power. The quality of the signal z (i.e., the error of the signal z associated with the signal X) depends on the echo path model and algorithm implemented in the filter 814 and the memory and processing power of the computing device implementing the filter 814. With respect to prior art devices, configurations, and methods (as shown by the prior art device 800 and the method of FIG. 8B of FIG. 8A), the correction model of the echo path 80 8 (eg, filter 8) 1 4 performers) is important to effectively eliminate echo. However, the echo path 808 is dynamic, so it is difficult to accurately model the various surrounding noises, the reverberation of the surrounding noise, and/or other factors. As a result, conventional techniques, configurations, and methods do not effectively eliminate echo. The prior art devices, configurations, and methods additionally face bilateral calls where the local (or near) and remote (or remote) speak simultaneously. Since the local-32-200816753 local speech and the distant speech have similar vocal characteristics, the filter 814 cannot accurately identify which signal is to be input to the echo path 808 model. As a result, the local speech portion may be eliminated, and the echo portion is not eliminated, and the error of the echo path model in the filter 8.1 may become divergent instead of convergence, resulting in undesirable communication quality. Therefore, in the prior art, many resources have been invested to improve the algorithm of the modeled echo path 808. In addition, the filter 114 requires a large amount of data memory and CPUs that require high processing power. As a result, a high cost of implementing echo cancellation is generated. In contrast, one or more embodiments of the present invention include a device for canceling signals even if no filters are provided. In one or more embodiments, the signal represents a digital signal. The device includes an identification code (ID code) generator that is configured to generate an ID code. The device in turn includes an ID code injector that is configured to inject an ID code into at least one of the signal and the processed signal to produce a whirling signal. The processed signal is generated by the processing of the signal, such as the removal of background noise. The apparatus additionally includes an ID code detector configured to detect at least one of a transition of the whirling signal, the transformed signal, and the whirling signal, wherein the transformed signal is produced by a transformation of the whirling signal. The transformation of the whirling signal can be caused by the configuration of the device and/or the environment. For example, the transition of the whirling signal represents the delay produced by one or more echo paths between the speaker and the microphone of the device; the transformed signal represents the delayed signal that is delayed. The apparatus additionally includes an arithmetic function that is configured to remove at least one of the whirling signal and the transformed signal. Figure 9A is a block diagram of a communication device 900 (device 900) that cancels echo even if the -33-200816753 filter is not provided, in accordance with one or more embodiments of the present invention. The block diagram again shows a communication system or configuration having the components shown in Figure 9A implemented in one or more devices. Apparatus 900 includes input/output components, such as signal receiver 904 for receiving remote signals from a remote location, signal transmitter 93 2 (to transmit signals to a remote location), speaker 914, and microphone 916 (local microphone 9 1 6 )Wait. There is an echo path 9 0 8 that travels from the speaker 9 1 4 to the microphone 9 16 . Device 900 can also include signal processing modules, such as background noise remover 906 and the like. The background noise remover 906 can be configured to remove background noise from signals received from the signal receiver 904. The background noise remover 906 can be implemented using one or more well-known algorithms such as spectral subtraction for background noise removal. Device 900 can also include a module for canceling echo. The module can include an identification code generator 922 (ID code generator 922), an identification code injector 910 (ID code injector 910), an identification code detector 924 (ID code detector 924), and a buffer 926. The module may also include a transform module, such as a delay 92 8 or the like, for example to transform signals, introduce delays. The module may also include arithmetic functions such as, for example, a sum function 93 0 and the like. The ID code generator 922 can be configured to generate a controllable and removable ID code such that a portion of the signal can be identified. The partial signal is then removed, for example for echo cancellation purposes. The ID code can represent a virtual random code that can simulate background noise or mitigate noise. The ID code generator 922 can include a linear feedback shift register for generating the virtual random noise sequence to be used -34-200816753 as the ID code. In addition, the ID code can include high frequency or low frequency signals that are not detectable by human ears. In one or more embodiments, the sampling rate of the microphone 9 i 6 can be grouped to process high frequency or low frequency signals, for example, via hardware and/or software (or drivers) that assemble the microphone 916. In one or more embodiments, device 900 may not include background noise remover 906 by virtue of an ID code indicating a signal that is not detectable by the human ear. The ID code injector 910 can be configured to inject the ID code generated by the ID code generator 922 into the signal. The ID code injector 910 〇 ID code detection can be implemented by a well-known algorithm such as by inserting an id code into a signal by a digital correlation method, for example, by rotating an ID code and a signal to generate a whirling signal. The detector 924 can be configured to detect an iD code within the whirling signal, such as in a mix, overlay, and/or another whirling signal that includes one or more other signals. Additionally, ID code detector 924 can be configured to detect transformed signals and/or ID codes generated by the transformation of the whirling signals; for example, the configuration and/or environment of device 900 can produce transforms. Additionally, ID code detector 924 can be configured to detect transforms. The transform can include delay and signal level attenuation. ID code detector 924 can implement one or more well-known algorithms, such as digital correlation or matched filters for detecting IDs. Delayer 92 8 can be configured to introduce delay into the signal. A delay can be used to simulate the transformation. The delay 928 can be implemented by introducing a simple delay line shift register for delay. Each of the noise remover 906, the ID code generator 922, the ID code injector - 35-200816753 910, the ID code detector 924, and the delay 928 are all included in downloadable to, for example, a telephone, a mobile phone, a teleconferencing device, and the like. Software in user devices (eg, for acoustic echo cancellation), and/or server devices (eg, for line or network echo cancellation). Figure 9B is a block diagram of an ID code generator 922 for apparatus 900 (shown in Figure 9A) in accordance with one or more embodiments of the present invention. The ID code generator 922 may be included only in the code generator 921 which will directly generate a random code. In this example, the code generator 921 is implemented, such as by a well-known algorithm such as a linear feedback shift register that carefully selects an appropriate feedback function. However, the ID code generator 922 can include a companion random function. The code generator 921 of the device 923. In this example, first, the code generator 921 can generate an appropriate identification code without fear of randomization occurring. This identification code is then fed into the random function generator 923 to become a virtual random noise sequence that is the output of 922. The modified linear feedback shift register can be implemented by means of a feedback function controlled by the code generator 92 1 to implement a random function generator 923. FIG. 9C is used to eliminate, for example, the device 900 in accordance with one or more embodiments of the present invention. A flow chart of the method of echoing in Figure 9A). The method begins in step 9 52, in which signal receiver 904 (shown in Figure 9A) can receive signal y'(n) from a remote location. In step 954, the noise remover 906 can remove background noise from y'(n), producing a signal y(n). In order to leave space for the ID code including random noise, background noise can be removed. Therefore, this place does not receive excessive noise. -36- 200816753 In step 958, ID code generator 922 (shown in Figure 9A) can generate an ID code c(n). The a code c(n) can represent a known and controllable function. In step 956, the π code injector 910 (shown in Figure 9A) can host the ID code ^"^ into the signal y(n). As a result, a convolution of c(n) and y(n) can be produced. The cyclotrons such as C(n) and y(n) may be the convoluted signal c(n)*y(n). Then, control is transferred to step 9 6 2 and step 9 80. In step 962, the speaker 914 (shown in Figure 9A) can receive the whirling signal c(n)*y(n). In step 964, microphone 916 (shown in Figure 9A) can receive a delayed signal from speaker 914, i.e., signal c(n-d)*y(n-d). The microphone 916 can also pick up another input signal x(n) that includes local voice (e.g., in a bilateral call plan) and/or background noise that surrounds the microphone 9 16 . Then, the microphone 9 16 can output the combined signal x(n) + c(nd)*y(n_d) to the ID code detector 924 (shown in FIG. 9A) and the sum function 9 3 0 (as shown in FIG. 9A). Show). In step 980, buffer 926 (shown in Figure 9A) may buffer a copy of the whirling signal c(n)*y(n) and output a copy of the whirling signal to delay 928. In step 966, the ID code detector 9 24 (shown in FIG. 9A) can detect the combined signal ^11) + (: 11 in 11(1)(7)) Taking 11-magic' and assuming that c(n) is a known and controllable function' can be determined by comparing c(η) and c(η - d) received from the ID code generator 9 2 2 The amount of delay d. The amount of delay d can be fed to a delay 928 (shown in Figure 9A). In step 982, the 'delay 928 (shown in Figure 9A) can introduce a delay 纛d from the output of the buffer 926 from step 980. (ie, complex -37-200816753 of c(n)*y(n)), produces a replica of c(nd)*y(nd). In step 9900, the sum function 9 3 0 (Fig. 9A The output from step 964 can be output (ie, signal + subtracts the output of step 982 (ie, the signal produces a replica of c(n_d)*y(n_d)). In other words, in step 990, the sum function 93 0 calculates the signal. x(n) + c(nd)*y(n_d)-C(nd)*y(nd) to obtain the signal x(n), which represents the absence of the echo of the signal y'(n) (with the signal y(n_d) The input signal picked up by the receiver microphone 916 (shown in Figure 9A). The signal x(n) may include such a place as in a bilateral call plan Voice, and/or background noise around the microphone 916. In step 992, voices such as local to the bilateral call plan and/or background noise around the microphone 916 and signals not including the echo x (n) are included. It can be sent to the signal transmitter 93 2 . Thus, the echo in the unilateral call and the bilateral call scheme can be effectively eliminated. From the above, it can be understood that the embodiment of the present invention can effectively eliminate the echo without requiring a prior art device, Filters (or echo cancellers) required in the configuration, or method. Embodiments of the present invention provide more accurate echo cancellation and faster cancellation, without the possible errors in echo-dependent echo path modeling. Therefore, a better quality of service is obtained. In addition, embodiments of the present invention can effectively eliminate echo in a bilaterally-talking scheme in which a conventional filter is generally poorly implemented. In fact, it does not rely on filters and correlations without echo path modeling. Under the complexity, the embodiments of the present invention can also advantageously eliminate the high CPU processing power required by the filter and the need for large data memory. To reduce the cost of echo cancellation in real-38-200816753. C. Content-based jitter buffering scheme for video over IP communication, without relying on filter and associated echo path modeling complexity, the present invention The embodiment also advantageously removes the high CPU processing power required by the filter and the need for large data memory, thereby reducing the cost of implementing echo cancellation. C. Content-based jitter buffer design for voice/video communication over IP One or more embodiments of the invention provide a mechanism to handle excessive WLAN jitter using audio VAD and jitter compensation. One or more embodiments of the present invention also operate for video that is used with no or no movement and packet bounce. One or more embodiments of the invention are related to packet communication devices. The packet communication device can include a detector that is configured to detect the characterization content in the incoming packet received by the packet communication device. The packet communication device can additionally include an implementation controller that is configured to perform an adjustment of the incoming packet to produce an adjusted packet and an output adjusted packet if the detector has detected the characterization content in the incoming packet. A new jitter buffer design called a content-based jitter buffer is proposed to address the current jitter buffering technique limitations. In accordance with one or more embodiments of the present invention, not only the RTP header information of incoming packets is noted, but also their RTP payload content is noted, thereby recognizing the silent and speechal presentations on incoming packets. Then based on this silent and speaking clues to determine when -39-200816753 enough to insert the implementation delay to compensate for network packet bounce. With this new design, the jitter buffer on the receiver side will no longer rely on the silent suppression of the transmitter. Figure 5 A-B is a high-order schematic diagram of the jitter buffer architecture. The path of the packet will be tracked via the function block in the Voice Quality Engine (VQE). The purpose here is to introduce an adaptive debounce controller to make the implementation equal. A similar design can be used to handle video jitter. In one of the conventional technique bounce buffer designs, the medullary reception VAD (Voice Activity Detection) is used to prevent the bounce buffer from overflowing. In other words, when a silent or speech cues reaches the maximum length, an unvoiced or spoken cues are used to embed the bounce buffer. Differences between new and conventional technology designs include silent or speech, which is now used to control when insertion delays can be inserted to compensate for network packet bounce. Thus, in accordance with one or more embodiments of the present invention, silent or speech detection will become an important part of the jitter buffer design. In some cases, when the bounce buffer becomes an overflow, it is too late to make any adjustments. Here's how to apply this content-based bounce buffer device and method to a working application. Both voice and video examples are explained below. Figure 5A is a block diagram of a speech hopping buffer in accordance with one or more embodiments of the present invention. The core jitter buffer includes one or more components for the packet, the packet implementation, the jitter calculation, and the jitter compensation. Here, the decoder and VAD will produce silent and speech indicators. The Silent or Speaking Indicator is then fed back to the Bounce Compensation section and used to determine when the insertion is silent to compensate for network packet bounce. Figure 5B is a block diagram of a video jittering -40 - 200816753 buffer in accordance with one or more embodiments of the present invention. The core jitter buffer is similar to the core jitter buffer of speech except that when the video frame is not moved or the movement is extremely low, the insertion delay is implemented. Here, after the decoder, the motion estimation and motion compensation will produce the remaining frames. From this remaining frame, some specific thresholds can be added to form a no-movement indicator. The no-movement indicator is then fed back to the jitter compensation portion and used to detect when the insertion is silent to compensate for network packet bounce. In video, inserting a silent implementation actually stops the implementation of the new frame while repeating the previous video frame. As mentioned above, issues such as packet delay (i.e., packet arrival late), packet delay variation, and packet loss have a negative impact on the quality of service (Q〇s) in packet communication. Packet delay and packet delay variation can also be considered as jitter. In order to solve these problems, in the prior art, a fixed debounce buffer is designed to compensate by periodically inserting a delay (ie, a silent packet or a comfort noise packet) when implementing a packet from a packet buffer. The late arrival of the packet. However, with a fixed debounce design, excessive insertion delays between voice packets can result in abrupt speech. In the prior art, a transmitter side voice activity detector (VAD) can also be used for adaptive insertion delay to compensate for packet delay and packet delay variation. However, some user devices do not support the transmitter side VAD. In addition, for example, when the transmission party is performing music playback, since the music interruption is regarded as silent and inappropriate processing, if it is an existing VAD algorithm, the transmitter side VAD generates unwanted noise or abrupt speech. As another example, when the transmitting party uses the G.729AB encoder/decoder to play some music with the open transmitter side VAD, the user on the receiver side -41 - 200816753 will perceive distortion distortion. music. Therefore, the packet communication service provider usually turns off the transmitter side VAD and cannot compensate for packet delay and packet delay variation. As a result, the fixed debounce buffer design is still used, and the quality of service is still not what the receiver wants. Additionally, in the prior art, a receiver side silent detector can be used to control the packet buffer overflow to prevent packet loss. However, according to the combination in the prior art, the voice packet is discarded, so that when the packet buffer is almost full or full, the quality of the service is not what the receiver wants. Conversely, embodiments of the present invention may utilize receiver side silent detectors to compensate for delay and delay variations in a timely manner, and adaptively implement packets from the packet buffer. Advantageously, the transmitter side VAD is not required to provide the desired quality of service. Additionally, one or more embodiments of the present invention may utilize a receiver side video detector to adaptively handle jitter in video communications. In one or more embodiments, the present invention is directed to a packet communication device, and the device can include a detector configured to detect characterized content in an incoming packet received by the packet communication device. The characterization content can represent a silence in the voice communication (e.g., a time period in which the received voice packet is not received). Alternatively, the characterization content can represent at least one of less than critical movement or no movement. For example, the border of no moving or still images can be selected to be 10% to 15% of all moving images in the video communication (in terms of data volume). The packet communication device can additionally include an implementation controller configured to perform an adjustment of the incoming packet to generate the adjusted packet and output if the detector has detected the characterization content in the incoming packet Adjusted packets. Another option, including delays in the form of, for example, a silent packet or a comfort noise packet, is that the adjustment may include iteratively implementing a previously implemented packet, and timely compensating for incoming packets and delay variations received in the packet buffer, And the adjusted package is acceptable to the recipient. The features of the present invention will become more apparent with reference to the drawings and discussion below. Figure 1 〇A is a block diagram of a first exemplary practice packet vocabulary communication configuration (first prior art configuration) with an adaptive jitter buffer design. Figure 10A shows an example. Generally, the first prior art configuration includes The transmitter side device 1091 and the receiver side device 1092 connected to the sender side device 1091 and the receiver side device 1 092 may represent an electric mobile phone or a teleconference device. The transmitter side device 1 〇 9 1 may include the following components: speed slow 1000, voice activity detector 1001 (VAD 1001), and hair 1 002. These components are described as follows: Speed buffer 1 〇〇〇 can be configured to receive voice (packet) from the microphone, buffer the packet, and then transmit the buffered packet to 1001. The VAD 1001 can be configured to have a silent descriptor (SID) when there is silence (i.e., a time period between voice packets) from the packets in the speed buffer 1000. Transmitter 1 002 can be configured to receive packets from VAD 1 000 and packet to network 1 〇 〇 3. Adjust in. . Junction delay and good idea. Such as the Internet. Each of the words, the transmitter and the packet are VAD-received and then transmitted. -43- 200816753 Next, the network 1003 can transmit the packet to the receiver-side device 1 092 °. The receiver-side device 1 092 can include the following components: a packet buffer 1004, The packet implementation controller 1〇〇5, the delay insertion controller 1006, the delay information module 1 007, the jitter computer 1 008, and the implementation delay computer 1〇09. These components are described as follows: Packet buffer 1004 can be configured to receive packets from network 1 003, buffer packets, then send packets to jitter computer 008, delay insertion controller 1 006, and packet implementation controller 1 005. The beat computer 1 〇〇 8 can be configured to calculate the jitter size in the packet. Bounce can indicate silence, that is, the time period between the arrival of two voice packets without data. The delay insertion controller 1 006 can be configured to determine the insertion delay in accordance with the SID inserted in the packet in accordance with the VAD 1001 of the transmitter side device 109 1 . The delay insertion controller 1 006 can receive jitter size information from the jitter computer 008 and can receive packets from the packet buffer 1 〇〇 4. The implementation delay computer 1 009 can be configured to receive jitter size information from the jitter computer 008. Based on the jitter size information, the implementation delay computer 1 009 calculates the delay size to be inserted into the packet. The delay information module 007 can be configured to integrate information about the timing of the insertion delay from the delay insertion controller 1006 and information about the size of the delay from the implementation of the delay computer 009. Therefore, the delay information module 1 007 can establish the integrated information into the data structure and send the data structure to the packet implementation controller 1 0 0 5 ◦ -44- 200816753 The packet implementation controller 1 005 can be configured to be based on the delay information. The data structure received by module 1 007 receives the packet from packet buffer 1-4 and the insertion delay to the packet. Figure 10B is a flow diagram of the transmitter side processing of the prior art jitter buffer design utilized in the first prior art configuration shown in the example of Figure 10A. Transmitter-side processing begins in step 1 060, in which a speed buffer 1 000 (shown in Figure 10A) can receive, for example, a packet from a microphone used by the transmitting party. The speed buffer 1 000 can then buffer the packet. In step 1 0 6 2, the speed buffer 1 〇 〇 〇 can set the flag bit of each packet to 以 by default. When each packet reaches the last step 1 0 7 2, if the packet is the first voice packet, the flag bit of the packet is set to 1. Otherwise, the marker symbol can be maintained as 〇 〇 In step 1064, the VAD 1001 can determine whether the packet contains one or more silent periods (i.e., one or more periods of no data between packets). If the packet contains one or more silent periods, then control transfers to step 1 074; if not, control transfers to step 1 066. In step 1 〇 74, VAD 1〇〇1 may determine whether the S ID has been set in the packet. The S ID (Speech Descriptor) is grouped to indicate the beginning of the silent period. If the S ID has been set for the silent period in the packet, the control moves directly back to 1 072; if it is not set, then control is transferred to step 1 0 7 6 before moving to step 1 072. In step 1 0 7 6 , V A D 1 0 0 1 may generate a SID for the packet. In step 1072, the transmitter 10〇2 (shown in Figure iA) can transmit the packet to the network 1003. -45- 200816753 In step 1066, VAD 1001 may determine whether the packet contains the first voice packet after the silent period. If the packet contains the first voice packet, then control transfers to 1 068, in which VAD 1001 may set the flag bit of the first voice packet to one. If the packet does not contain the first language packet, then control transfers to step 1 072, in which the transmitter 1〇〇2 can transmit the packet to 1 0 0 3. FIG. 1C is a flow chart of a conventional technique delay calculation process. The delay calculation process may be part of the receiver side processing in the receiver side device 1 092 for the first prior art configuration shown in Fig. 10A. The delay calculation process can be performed by the packet buffer 1 004 including the receiver side device 1 092 shown in the example of FIG. 10A, the delay insertion controller 1 006 bounces the computer 1 〇〇 8, implements the delay computer 1 009, and delays the information mode. Group 1 007. The delay calculation process can begin in step 1 022, in which packet buffer 1 004 can receive the packet from network 1 003 and buffer the packet. For example, the packet may represent the packet transmitted by the transmitter 1 0 02 (shown in Figure 10A) in step 1 072 (shown in Figure 10B). In step 1 024, the jitter computer 1 008 can calculate the average jitter j °. In step 1 026, the jitter computer 1 008 can calculate the jitter deviation v °. In step 1 028, the implementation delay computer 1 009 can use j and v and The network model represented by f(j, v) is used to calculate the implementation delay (ie, delay d = f(j, v)). In step 1030, the delay insertion controller 1006 can determine the packet buffer -46-200816753

Whether the punch 1 004 is empty. If the packet buffer I is transferred to step 1 〇 3 8 ; if it is not empty 1 03 2 〇 In step 1 03 2, the delay insertion control | 疋値1 is not marked. If 値 is already set, move control to step 1 03 8 ; if 1 034 is not set. In step 1034, the insertion control is delayed, and there is a SID. If there is a SID, the control shift has, and control moves to step 1 0 3 6 . In step 1 03 6 , the delay insertion control | action j is greater than a preset threshold. For example, the length of the device 1 0 0 4 here. If the average jitter j is greater than the preset threshold 1 03 8 ; if not greater, the control directly moves to the size and timing information of the delay information module in step 1 0 8 , and then transfers the control to step 1 040, The relevant controller 1 〇〇 5 can be inserted. FIG. 10D is a conventional technology packet implementation control implementation control process may be used for the receiver side of the receiver side device 1 092 of FIG. 1A, the packet implementation controller 1 0 〇5 shown in FIG. Reason. 1 004 is empty, then control 'then control moves to step 1 006 to determine whether the 1 symbol bit has been set, : fixed, then transfer control to Rong 1 006 can determine the packet to go to step 1 0 3 8 ; If not Rong 1 006 can determine the average jump; the threshold can be the packet buffer, then the control moves to step 1 0 4 0. 1 007 can integrate the insertion delay to step 1 040. The delayed information is output to the flow chart of the real I processing. Packet: The first known technology configuration part of the processing. The packet implementation control process can be performed by the execution packet-47-200816753. The packet implementation control process begins in step 1 042, in which the packet implementation controller 1 005 can receive the packet from the packet buffer 1 004 (shown in FIG. 10A), and can The delay information module 1〇〇7 (shown in FIG. 10A) receives the information about the insertion delay as the result of step 1 040 (shown in FIG. 10C). In step 1044, the packet enforcement controller 1005 can determine if sufficient packets have been inserted. If sufficient packets have been inserted, control transfers to step 1 048; if sufficient packets are not inserted, control transfers to step 1 046. In step 1046, the packet enforcement controller 1005 can insert a delay (e.g., in the form of a silent packet or a comfort noise packet) to the packet received from the packet buffer 1 004. In step 1048, the packet enforcement controller 1005 can retrieve the packet from the packet buffer 1 0 0 4 . In step 100, the packet enforcement controller 1 004 can implement the packets generated from steps 1046 and 1048. Figure 10E is a schematic representation of the packet stream received by the packet buffer 1 〇〇 4 when the transmitter side VAD 1001 (shown in Figure 10A) is turned on. As shown in the example of FIG. 10E, the received packet stream may include a voice packet 1080, a silence 1084 behind the voice packet 1080, a voice packet 1 〇 8 6 following the silence 1084, and a voice packet 1 〇 8 6 behind the silent 1 088 and so on. Silent 1 084 and Silent 1 08 8 indicate the time period during which the packet implementation controller 1 005 did not receive the voice packet. Since the VAD 1001 is turned on, the VAD 1001 has set the sign bit of the first voice packet such as the packets 100a and 1086a to 1. The signal symbol of 値1 can be used in step-48-200816753 1 032 to determine when to insert the extension. VAD 1001 is inserted at the beginning of silence 1084 and inserted at the beginning of silent 1088. SID 1090. SID and SID 1090 can also be used in step 1034 shown in Figure 10C to when the insertion delay is inserted. Figure 10F is a diagram showing the flow of the stream received in the packet side buffer V1 1001 (shown in Figure 10A) when the transmitter side VAD 1001 is turned off. Because VAD 1 0 The existing performances used in 0 1 generate unwanted noise or abrupt speech during music playback, and the VAD 1001 will normally be turned off by the packet communication service provider, thus providing information about voice activity. As shown in the example, the received packet stream includes a packet 1 092, a silent packet 1 〇 94 connected to the voice packet 1 092, a voice packet 1 096 behind the silent packet 1 094, and a silent packet 1098 following the voice packet. Etc. Because the VAD 1001 is turned off, it is a silent weekly S ID represented by the silent packet 1 094 and the silent packet 1 098. As a result, the step 1 034 (i.e., SID) shown in Fig. 10C is not executed. Although the voice packet 1 092a has the designation symbol 1 of 1, the remaining received packets all have the 标示 mark symbol 値. Therefore, the step 1 03 2 shown in FIG. 10C is not executed (ie, the flag of the packet is determined. Whether Yuanxiao is set to 1). In addition, When the VAD 1001 on the transmitter side 1091 is turned off, the packet buffer 1 004 on the receiver side 1 092 can be continuously entered. The SID 1082 determines the packet algorithm so that it cannot be sealed at 1096 to intervene. The bitwise bit is fixed so that the -49-200816753 packet buffer 1 004 is never empty. Therefore, depending on the visual design, the step 1 03 0 shown in Fig. 10C is not executed (i.e., it is determined whether the packet buffer 1004 is empty). Therefore, when the VAD 1001 is turned off, the delay insertion control 1006 cannot perform steps 1030, 1032, and 1034 for determining the timing of the insertion delay. Although in step 1036 shown in FIG. 10C, the delay insertion controller 1006 is still able to obtain information as to whether the average jitter j(i) is greater than a preset threshold, the information is insufficient to determine the timing of the insertion delay. For example, when the average jitter j(i) is greater than the preset threshold, the insertion delay is too late. As a result, delays are inserted in inaccurate timings to produce abrupt speech in speech communications. Moreover, even if the existing VAD algorithm of the VAD 1001 is turned on, the VAD 10 01 cannot be accurately inserted into the SID. As a result, the front end of the voice packet is clipped and/or the back end is clipped, and the voice quality is not desired by the recipient. Figure 1 A is a block diagram of a receiver side device 1 1 第二 of a second conventional technique packet voice communication configuration (second prior art configuration) including an adaptive buffer overflow controller. As shown in the example of Fig. 11A, the receiver side device 1 1 includes components of the receiver side device 1 092 in the first prior art configuration shown in Fig. 10A. Further, the receiver side device 1 1 〇〇 includes an additional component 1 1 80. The add-on component 1 1 80 may include a decoder U 18, a silent detector 1 1 16 , and a buffer overflow controller 1 1 1 4, as explained below: The silent detector 1 1 1 6 may be configured into The silence in the packet received from the decoder 1 i 8 is detected. If there is no sound, the silent detector 1 1 1 6 can set the silent flag 1 to 1. If there is no silence, the silent detector 1116 can set the silent flag 0 to zero. -50- 200816753 The buffer overflow controller 1 1 1 4 can be configured to monitor the state of the packet buffer 1102. Based on the state of the packet buffer 1102, the buffer overflow controller 1 1 1 4 can decide whether to drop or hold the next packet received in the packet buffer 丨 02. Fig. 11B is a flow chart showing the silent detection processing utilized by the receiver side device 1100 shown in the example of Fig. 11A. In step 11 20, the silent detection process is started. In this step, the decoder 1 1 18 (shown in FIG. 1 1 A) can be decompressed and received from the packet implementation controller 1 10 04 (shown in FIG. 1 1 A). Voice packet (packet). In step 1 24, the silent detector 1 1 16 (shown in Figure 1 1 A) can determine if there is silence in the receiving packet. If there is no sound, the control shifts to 1 1 3 0. In this step, the silent detector 1 1 16 sets the silent flag 1 to 1. If there is no silence, then control transfers to step 1 1 26, in which the silent detector 1 1 16 sets the silent flag 〇 to 〇. In step 1 1 2 8 , the silent detector 11 16 can output a silent flag 値. Fig. 1 1C is a flowchart of the buffer overflow control process utilized in the receiver side device 11A shown in the example of Fig. 11A. The buffer overflow control process can be performed by the buffer overflow controller 1 1 1 4 shown in Fig. 11A. The buffer overflow control process is started in step 11 3 2, in which the buffer overflow controller 1 1 1 4 receives the silent flag from the silent detector 1 1 16 (shown in FIG. 1 1 A). value. In step 1 1 3 4, the buffer overflow control 1 1 1 4 determines whether the packet buffer η 02 (shown in Figure 2A) has reached the first critical value, such as just -51 - 200816753 1 〇 ο % and so on. If the packet buffer 1 102 has reached the first threshold, then control transfers to step 1 1 4 4; if not, control transfers to step 1 1 3 6 . In step 11 44, the buffer overflow controller 1 1 1 4 may command the packet buffer 1 1 2 2 to discard the most recently received packet, regardless of whether the most recently received packet indicates a voice packet. The buffer overflow controller 1 1 1 4 can also command the packet buffer 1 1 〇 2 to provide the packet to be implemented. In step 1 1 36, the buffer overflow controller n i 4 may determine whether the packet buffer 1 1 〇 2 has reached the second threshold, such as exactly 80%. If the packet buffer η 02 has reached the second threshold, then control transfers to step 1 1 4 0; if not, control transfers to step 丨丨38. In step 1 1 40, the buffer overflow controller n i 4 may determine whether the silent flag received from the silent detector η 16 is 1. If the silent flag 値 is 1 ' then control transfers to step 1 1 4 2; if not, control transfers to step 1 1 3 8 . In step 11 4 2, the buffer overflow control η 丨 4 may command the packet buffer 1 1 02 to discard the most recently received packet because the most recently received packet indicates no silence. The buffer overflow controller 1 1 1 4 can also command the packet buffer 1 1 02 to provide the packet to be implemented. Control then moves to step n38. In step 1 1 3 8 , the packet buffer 1 i 〇 2 can receive and buffer the packet. The buffer overflow control process shown in the example of Fig. 1 1 C is ineffective for maintaining the service quality. For example, when the packet buffer Π 02 reaches the first threshold, such as just 100%, the voice packet can be discarded according to step 1144. Therefore, a mutant speech is generated. In addition, when the packet buffer 1 1 〇 2 reaches a critical threshold of -52·200816753, if the threshold is just 80% of the exactly 1 〇 0%, the packet buffer 1 1 〇 2 still receives the packet. The data set of the voice packet of the buffer 1 1 〇 2 is still large. As a result, the overflow still occurs, and packets (including voice packets) that exceed the capacity of the packet buffer 1 102 are still lost. As a result, the quality of service is not what the recipient wants. Figure 1 2A is a block diagram of a receiver side device 1 200 of a packet voice communication system with adaptive jitter processing in accordance with one or more embodiments of the present invention. The receiver side device 1 200 can represent a user device such as a telephone, a mobile phone, a teleconferencing device, an audio player, or a video phone. Alternatively, the receiver side device 1 200 can represent a server device in the packet communication network. As shown in the example of FIG. 12A, generally, the receiver side device 1 200 may include one or more of the following components: a packet buffer 1 2 0 2, a packet implementation controller 1208, a decoder 1210, a delay insertion controller 1214, and a delay information mode. Group 1216, jitter computer 1 204, and implementation delay computer 1 206. The receiver side device 1 200 may additionally include a detector that is configured to detect the characterization content, such as detecting a silent silent detector 1 2 1 2, and the like. The silent detector 1 2 1 2 can be configured to receive the decompressed packet from the decoder 1 2 1 0. The silent detector 1 2 1 2 may additionally be configured to process the decompressed packet and provide a silent flag (but not a decompressed packet) via link 1 29 to the delay insertion controller 1 2 1 4 . One or more components may be included in the software downloaded to the receiver side device 12000. One or more components of the receiver side device 1 200 may have capabilities similar to those of the receiver side device 1 100 shown in Figures 53-200816753 1 1A. However, contrary to the silent detector η 16 of the receiver side device 1100, the silent detector 1 2 1 2 can be configured to determine when to insert a delay in processing the beat to replace the control packet buffer overflow, or in addition to control This feature is added in addition to the packet buffer overflow. In addition, contrary to the delay insertion controller 1108 of the receiver side device 1100, the delay insertion controller 1 2 1 4 can receive information from the silent detector 1 2 1 2 instead of receiving from the prior art jitter buffer design. The information of the computer 1 204 is beaten. Delay insertion controller 12 14 can be directly coupled to silent detector 1212 via link 1 299. Link 1 299 can represent a direct logical link or an entity link. The link 1 199 between the delay insertion controller 1108 and the hopping computer 1 1 10 shown in the example of FIG. 11A and the hopping computer 1 008 and the delay insertion controller 1 〇〇 6 shown in the example of FIG. Link 1 099 Conversely, there is no direct logical or physical connection between the jitter calculation 1 204 and the delay insertion controller 1 2 1 4 . Figure 12 is a diagram showing a delay insertion control process for adaptive bounce processing utilized in the receiver side device 1 200 shown in the example of Figure 12A, in accordance with one or more embodiments of the present invention. The delay insertion control process begins in step 1 220, in which the delay insertion controller 1214 (shown in Figure 12A) determines when the packet buffer 1 202 (shown in Figure 12A) is empty, i.e., does not contain the implemented packet. . If the packet buffer 1 202 is empty, then control transfers to step 1 22 8; if not, control transfers to 1 222. -54- 200816753 In step 1 222, the delay insertion controller 1214 may determine to set a flag bit of 値1 in the incoming packet received via the packet buffer 12.2. If there is a SID, then control transfers to step 1228; if there is no S ID, then control transfers to step 1226. In step 1226, the delay insertion controller 1214 may determine whether the silent flag received from the silent detector 1 2 1 2 (shown in Figure 1 2A) is one. If the silent flag 1 is 1, then control can be transferred to step 1 22 8; if not 1, control can be moved to step 1 2 3 0. In step 1 2 2 8 , the packet implementation controller 1 2 0 8 (shown in FIG. 1 2 A) may be based on the delay information module 1 2 16 (the information insertion delay shown in FIG. 1 2 A (eg, , the unvoiced packet or the comfort noise packet, etc.) to the incoming packet to generate the adjusted packet. The delay information includes implementing the size information provided by the delay computer 1 2 06 (shown in FIG. 3A) and the delay insertion controller 1 2 1 4 The timing information is provided. In step 1 2 3 0, the packet enforcement controller 1 2 〇 8 can implement the adjusted packet. The adjusted packet is decompressed by the decoder 1 1 1 0 and then implemented by the receiver side device 1 200. As can be appreciated from FIG. 12B, in accordance with one or more embodiments of the present invention, that is, any information received from the jitter computer 1 2 0 4, the delay insertion controller 1214 can still rely on the slave silence detector ι 212 (in steps) The silent flag received in 1226 determines the timing of the insertion delay. Fig. 13 is a receiving side device 1 3 of the packet video communication system using the adaptive jitter processing according to one or more embodiments of the present invention. Block diagram of the 〇. Receive side loading Setting 1 300 indicates at least one of a telephone, a mobile phone, a teleconference-55-200816753 device, a video phone, and a video player. Alternatively, the receiver-side device 1 300 can represent a packet communication network. The server side device 1 300 can include components that perform functions similar to those of the components of the receiver side device 1 200 shown in the example of Fig. 3A. The receiver side device 1 300 can include a packet Buffer 1 3 02, jitter computer 1 3 04, compensation controller 1314, compensation computer 1 3 06, compensation information module 1 3 1 6 , packet implementation controller 1 3 0 8 , decoder 1 3 1 0, and video One or more of the detectors 1 3 1 2. The difference is that the video detector 1 3 1 2 can be configured to detect no movement or low movement in the video packet instead of silent. In addition, the compensation computer 1 3 06. The compensation controller 1314 and the compensation information module 1316 can be configured to calculate and integrate the video compensation information to replace the information that is assembled into the calculation and integration delay insertion. The video compensation can be included in the repeated video frame. Stop playing new views at the same time Frequency frame, and can be performed by the packet implementation controller 1 3 0 8. Similar to the configuration of the receiver side device 1 2 0 0, the compensation controller 1 3 1 4 can be directly coupled to the video detection via the link 1 3 99 The timing of the video compensation is determined by the device 1 3 1 2. The video compensation control process for the jitter processing of the receiver side device 1 300 is similar to the delay insertion control process shown in the example of Fig. 12B. The or more embodiments include a receiver side device that includes a configuration similar to the configuration of the receiver side device 130, and is configured to handle a jump in multimedia communication including voice and video - 56- 200816753 Move. Additionally, one or more embodiments of the present invention may include delay insertion control and video compensation control processing similar to the delay insertion control process illustrated in the example of FIG. As can be appreciated from the above, embodiments of the present invention can effectively handle jitter in packet communications without relying on a transmitter side voice activity detector (VAD) or a fixed jitter buffer design. To delay the insertion control instead of using the receiver side silent detector only for buffer overflow control, embodiments of the present invention can accurately insert delays without the need to insert delays into the voice packets. Advantageously, the mutated speech can be reduced to ensure speech quality. Additionally, embodiments of the present invention can be used for video communications and/or multimedia communications. D. Divitas Description Protocol (DDP) One or more embodiments of the present invention include a lightweight protocol over SIP that will effectively transfer information between the server and the user and will be unaffected by the hardware and software platforms. Under work. DDP architecture; architecture DDP has been considered under the following factors: not subject to server and user software and 〇S: the structure and format of the protocol (DDP) is DDP does not know the server or mobile hardware platform and in two The operating system executed on the platform. In accordance with one or more embodiments of the present invention, the protocol is architected and designed to execute on any server or mobile hardware platform and is also not subject to the Operating System/SW platform being executed. For example, DDP can be executed on Linux, Symbian, Windows Mobile 5.0, and so on. In summary, it is not necessary to design or develop a particular adapter layer each time a module is transferred to a new hardware or software platform. -57- 200816753 Decoupling from Control Plane Agreement: DDP has been constructed to work with any control plane technology used on a particular platform (ie SIP, H.3 23, etc.). Not subject to the delivery protocol: designed to be valid when used by both UDP and TCP. If the best choice is through the transport layer, there is a random module to ensure reliability and performance levels (using ACK/NACK and windowing). Especially in environments with high packet loss, this reliable module removes the burden of higher-level applications from worrying about shipping. Smart and careless applications: DDP will be used for a wide range of applications ranging from critical control surface messages with strict on-demand requirements to applications that need to transfer large amounts of data between servers and users. The random module within the DDP enables the application to transfer files and buffers between the server and the user. The agreement also does not care about the type of application data, namely binary, this article. Service Priority Level: Ability to schedule and queue messages with different priority levels for applications with different latency and service requirements. Encryption support: Random modules within the DDP enable the server and handset to establish a secure channel at boot time, and all further DDP exchanges are encrypted to provide a secure level for applications that require encryption. This will still allow the application to exchange unencrypted messages for such applications that do not require encryption. Built-in dialog management: Has specific control messages to initiate and maintain a dialogue between the server and the user. -58 - 200816753 Not subject to media: The agreement is not subject to the media that connects users to the server. Dialogues can be via wiFi, cellular data channels, or wired Ethernet. 6A is a schematic diagram of a DDP architecture fabricated in accordance with one or more embodiments of the present invention. As shown in Fig. 6A, the DDP is a dialog layer application executed through the SIP protocol. The transmission of encrypted application layer information between the user and the server is used to influence the messaging decision to provide dialog persistence to the data application, such as email or SMTP, but is not limited thereto. Figure 6A is a high-order diagram of the different modules that make up the DDP. Different modules within a DDP in accordance with one or more embodiments of the present invention are described herein. i. DDP Message Processor: This consists of a parser and a message formatting module. The parser is responsible for checking the validity of the received DDP message and extracting various pieces of information before summoning the recycling processor.对话. Dialogue Management: A health-built institution that evaluates the health of DDP conversations between two peers, and an organization that has notified the registered application if the conversation fails. Iii. DDP Scheduler: Provides DDP messages with different priority levels depending on the application requirements. Iv. Reliable DDP Module: Support for reliable delivery of DDP messages, depending on application requirements. V· DDX (Divitas Data Transfer) Module: A module that uses DDP to transfer files and data buffers between layers. The DDX module will operate without the constraints of the file format or buffer content and will have mechanisms for error checking and shipping confirmation.

Vi· DDPS: A module in DDP that encrypts and decrypts DDP content before inserting DDP-59-200816753 into the envelope package. DDP has a protocol to establish a secure DDP tunnel between 2 Divitas peers. Figure 6B is an exchange diagram of DDP messages during user activation when a user logs into one of the devices in accordance with one or more embodiments of the present invention. In accordance with one or more embodiments of the invention, the DDP is a layer 4 or application layer protocol. DDP can use TCP, UDP, or TLS for transmission. Similar to SIP or SDP, DDP is a protocol for content encoding. In accordance with one or more embodiments of the present invention, the DDP message includes an order of columns or fields, wherein the columns of the field begin with a single lowercase letter indicating the type of information being shipped; the remaining columns or fields contain and A fragment of information associated with a function or method. In accordance with one or more embodiments of the invention, there may be multiple columns or fields having the same starting name or type. In accordance with one or more embodiments of the present invention, depending on the particular type of D D P message being transmitted, each d D P message contains a set of command columns or fields and any columns or fields. If the command line is missing, the parser will reject the D D P message. Skip any column that the parser does not understand. This allows for upward compatibility and interoperability between different software versions. Here is an example of a DDP message: v = 〇. 〇. 〇. 1 o=server r = data 2 c=ext 4444 c = pref cell wifi gprs sms wka 5 cka 10 pwd 12 0 0 whys 20 chys 60 c = wifi Rssilo 30 rssihi 60 chlo 30 chhi 50 -60- 200816753 c = qos delaylo 50 delayhi 10 0 losslo losshi 10 jitterlo 3 0 j itterhi 5 0 c = srv intip 1 0234 1 4444 extip- 1 3 43 245 03 2 c = end Then Add the DDP message as the message body in the SIP message with the message body type of "application /ddp" or "application/ddps". If required, the DDP body can be sent with other delivery protocols. An exemplary application of the DDP in accordance with one or more embodiments of the present invention will be described below. Voice Mobility: Voice mobility depends on many factors... The main factor is the WiFi quality perceived by the user. The DDP is used to instantly send a WiFi report with information about the AP currently associated with the handset to make an operational decision. The W i F i report can also optionally contain information about neighboring APs so that the mobile server can use this information to make pre-emptive action decisions based on the predicted mobile phone movement. In addition to automating updates based on W i F i conditions, DDP is also used by users to initiate action decisions. User/Device Management: Extend DDP to the user and user experience on managing mobile phones. There are several ways to manage DDP-based controls and massive transfer messages used by users: a. Device configuration: Once the device/user has been authenticated, the device-specific configuration is sent to the device during startup. b. Mobility Critical: Based on the administrator's setting of the user's WiFi Pro 200816753 to initiate an active activity. C. User Information: When the user logs in to one of the users, the server pushes the user-specific information (eg, extension, preferences, etc.) through the DDP. d·Device image management; using DDP's massive transfer capability to achieve the ability to upgrade mobile software over a network connection. Download voicemail/email to your phone: One of the main differences between Divitas solutions is the ability to download voicemails to your phone and manage them as you need them. With the priority control message connected to the voice mail system, there is the ability to manage voice mail without IVR, and the same is true for the huge transfer capability of transferring the voice mail to the DDP of the mobile phone. It can also perform similar functions for an e-mail system that can establish an adapter module to interface with a selected e-mail system. User attendance management: A D D P message with user preferences through voice and content of different media is delivered to the attendance management server. This is an important part of the ability to support attendance calls. The structure and design of the conference call is also based on enhanced attendance and user preferences... all delivered through DDP to provide service conference calls are designed to be provided. Instant messaging: Messages for IM through the DDP session. This allows the IM user on the handset to be unaware of the media/agreement that the device is operating on. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 14 is a diagram showing an example of a conventional technique for establishing a connection between an application user and an application server. Assume that the user of the mobile phone wants to use the application user 1 404 to request the software download 1 406 via the web browser via the HTTP (Super File Transfer Protocol) connection. Before the software download 1 406 occurs, an HTTP connection must first be established between the application user 1 404 and the application server 1 402. In a first step 1408, the application user 1404 can send a TCP (Transmission Control Protocol) SYN (synchronized) to the application server 1 402. In the next step 1410, the application server 1 402 can send a TCP SYN-ACK (TCP synchronization response) back to the application user 1 404. In the next step 1412, the application user 1404 can send a TCP ACK to the application server 1 402. Once an HTTP connection has been established between application user 1 404 and application server 1402, then in next step 1414, application user 1404 can send HTTP Get to application server 1 402. In other words, in step 1414, the application user 1404 is sending a user request for software download 1 406 to the application server 1 402. Upon receiving HTTP Get, in a next step 1416, the application server 1402 can perform a search to find the requested download. In the next step 1 4 18, once the software has been found, the application server 1 402 can begin sending the requested software as a data packet (e.g., a TCP data section) to the application user 1 404. When the requested software file is sent, the software file can be divided into multiple data packets to help send the software file via the network. In the next step 1 420, when receiving the TCP data section, the application user 1 404 can send a TCP ACK to the application server -63-200816753 1 402 °. The requested request can be sent by the application server 1 402. All data packets are soft before the application user 1 404, weighing 1418 and 1420. Once all TCP data segments have been sent, in the next step, the application server 1 402 can send an HTTP 200 OK to the user 1 404. When sending an HTTP 200 OK, the application 14 02 notifies the application user 1 404 that the software package has been sent to download all the data packets. Once the application user 1 404 has received the individual data package, the application user 1 404 can send a notification 1 424 to the user, and the advertiser has completed the download. For each application user on the mobile phone, the method described in the telephone flow of Figure 1 must be performed by each program user. If the mobile phone includes multiple application users (eg, video application audio application users, instant messaging application users, game application users, virtual reality application users, etc.), between the application application servers Before the interaction begins, multiple applications must be executed independently between the various users and their corresponding application servers, so communication between different applications cannot be guaranteed. As a result, the application executing on a particular user is not being exchanged for data with another application on the same user. In addition, the method illustrated in FIG. 1 is a cumbersome method in which each application on the home is appropriately configured to ensure that the application can download the packet requested by the application server in step I 1422, and it is known to use the application. If you are a user, a language user and an application. The application can be used to successfully interact with the corresponding application on the specified server in the enterprise -64- 200816753. Since each application that communicates between the user and the server requires a separate network conversation, this approach creates a security risk and adds complexity. In one aspect of the present invention, the inventors herein are enabled to utilize hardware (eg, mobile phones) and software (eg, video application users, voice application users, instant messaging application users, game applications). The single agreement governed by program users, virtual reality application users, etc., integrates all application web conversations. In other words, the inventor realizes that the application user does not need to establish a plurality of network conversations with the corresponding application server. Instead, the existing control and transport protocols can be used to implement the protocol, and the protocol is independent of the software and hardware so that multiple application users can interact with their corresponding multiple application servers. In accordance with an embodiment of the present invention, an operational architecture configuration is provided by implementing a Divitas Description Protocol (DDP). In an embodiment, the DDP includes a DDP user and a DDP server. Embodiments of the present invention enable DDP to efficiently transfer data packets between a plurality of application users on a mobile phone and a plurality of application servers within the enterprise. Embodiments of the present invention in turn enable DDP to be implemented without being dominated by hardware and software platforms. In an embodiment of the invention, the DDP is not subject to the hardware platform. As such, DDP can be implemented on dual mode handsets, personal digital assistants (PDAs), 802.11 phones, and the like. In an embodiment of the invention, the DDP is also not subject to the software platform. As a result, DDP can be executed on Linux® systems, Symbian® systems, and Window TM Mobile 5.0 systems. In the prior art, the establishment of multiple network conversations requires establishing multiple channels between the user and the server. In other words, multiple “holes” must be “pierced” within the enterprise's defense to enable multiple application users to interact with their application servers. In an embodiment of the invention, the DDP can be used to establish a single secure channel that enables interaction between application users on the handset and a program server within the enterprise. With a single secure channel that exchanges multiple data traffic, program users can manage the information downloaded to the phone. In this way, application users who need to use the loaded information do not have to request to download the data again. In this case, an active user with DDP can direct the application to the location where the requested data is stored. In an embodiment of the invention, D D P may be unaffected by the network. In the sub-network, the secure channel established by the DDP can be, for example, via a Wi_Fi network nested data network. This enables the network conversation to be transmitted to a separate network when the user on the user device roams. In an embodiment, the DDP is established at the control protocol and transport protocol layer. In an embodiment, the DDP can be implemented using any available control protocol (SIP, H. 3 23, etc.). In another embodiment, any available transport protocol DDP, such as User Data Element Agreement (UDP), Transmission Control Protocol (TCP) Transport Layer Security (TLS), may be utilized. As such, DDP can efficiently route data packets and manage connections without having to care about the available control and/or transport protocols. In an embodiment of the present invention, the DDP may include reliability (RDDP), which ensures that the reliability level of the delivery data flow utilizes a transmission protocol such as UDP that does not provide reliability, and the use of the fire wall corresponds to the implementation of the application application. An example of a user or a DDP, such as, or a connection module. When this model is -66- 200816753 group. As such, DDP provides a guarantee of successful transmission and relieves the burden of data traffic from application users. In an embodiment of the invention, DDP can be implemented for a plurality of applications (i.e., application users and their corresponding application servers). In an example, DDP can be utilized by a simple application that does not require instant exchange of data. In another example, DD P may be utilized by an application having an instant data exchange requirement. Due to the adjustability of D D P, applications can be added or removed without affecting the power and diversity of DDP. In an embodiment of the invention, the DDP includes a priority message scheduling module that can be configured to schedule and queue data traffic. DDP can use the priority message scheduling module to automate the download and upload of multiple applications required or required by multiple applications. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 15 is a simplified architectural diagram of the D D P invention in an embodiment of the present invention. In an embodiment of the invention, the DDP 1536 is not subject to hardware and/or software platforms. In one example, DDP 1 5 3 6 can be implemented on a plurality of user devices, including dual mode handsets, PDAs, laptops, etc., but is not limited thereto. In another example, D D P 1 5 3 6 can be implemented with different operating systems such as Linux® systems, Symbian® systems, WindowTM Mobile 5.0 systems, and the like. As a result, the DDP 1536 can be loaded onto different hardware and/or software platforms with minimal modifications. DDP 1 5 3 6 can be built on top of control agreements and transport protocols. In an example, different types of control agreements (eg, s IP 1 5 3 2 and another -67-200816753-control agreement 1 524) and different transport protocol types (eg, UDP 1534, UDP 1528, TCP 1530, TCP 1526, etc.) Use DDP 1536 together. The type of control protocol and/or transport protocol that can be utilized by DDP 1536 to perform the functions of DDP 1536 can be readily adapted by DDP. Thus, if the control agreement and/or transport protocol changes, Bay ij DDP 1536 will be able to utilize itself any combination of available transport and control protocols as needed. It should be noted that the change of the control protocol and/or the transport protocol does not affect the application layer. The application layer includes the voice mobility control application user 1 5 06, the device management application 15〇4, the plan management application 1 502, and the voice. Mail/email transmission application 1 5 08, device image management application 1 5 1 0, instant messaging application 1 5 1 2, etc., but not limited to this. Moreover, in an embodiment, DDP 1 5 3 6 can determine a preferred transport protocol that provides optimal performance and reliability. In this way, the responsibility for identifying the correct transport agreement can be centralized and moved from the complex application to DDP 1 5 3 6 . Because all data traffic between the DDP user and the server is now handled by DDP 1 5 3 6 , DDP 1 5 3 6 can determine the optimal transport protocol for routing data traffic while minimizing data packet loss. In an embodiment, the DDP 1 5 3 6 may include one or more modules, such as a DDP module with secure extension (DDPS module 1 522), a priority message scheduling module 1518, and a reliable DDP module ( The RDDP module 1516), the built-in dialog management module 1 520, and the Divitas data exchange module (DDX module 1514). In one embodiment, the DDPS module 1 52 can provide a security function to the -68-200816753 DDP 1536. In one example, the DDPS module 1522 enables a secure channel to be established between the mobile user of the mobile phone and the mobile server within the enterprise. With Secure Channel, all incoming and outgoing data traffic from multiple applications can be routed through a single secure channel. In some cases, individual authentication must occur before an application user can interact with their corresponding application server. Unlike conventional techniques, authentication processing can be automated. In one embodiment, the DDPS module 1 52 2 2 may include a database that includes authentication data required to establish a connection between the application user and the application server. In an embodiment of the invention, the DDPS module 1 522 can provide encryption/decryption functions, thus enabling the DDP 1 5 3 6 to provide security to applications that require this functionality, in an example, routing from an email server from an application. The program user 1 5 0 8 important email to the email application user on the phone. To ensure the security of the email DDPS module 1 522 can encrypt the data packet before sending the packet to the corresponding application server. In another example, an instant message between two IM users can be sent in a non-secure manner. In this way, DDP 1 5 3 6 can route instant messages without having to use DDPS module 1 5 22 to encrypt the data packets sent between IM users. In an embodiment of the present invention, D D P 1 5 3 6 may include a priority message scheduling module 1 5 1 8 , and the module 1 5 1 8 may be configured into a schedule and queue data package. In other words, the priority message scheduling module 1518 is responsible for managing a plurality of different data packets served by the DDP 1 5 3 6 . In one embodiment, the priority message scheduling module 1 158 can establish policies for processing incoming and outgoing data packets -69-200816753. In one embodiment, the priority message scheduling module 1 158 may have different priority levels depending on the application of the source. In one example, application A (e.g., email) does not require immediate delivery of a chess data packet. However, application B (eg, attendance management) is quite sensitive to time delays and requires immediate delivery of data packets. In an embodiment, the priority message scheduling module 1518 can be any DDP module. In one example, if DDP 1 5 3 6 currently only processes data traffic for an application, DDP 1 5 3 6 does not have to use priority message scheduling module 1518 to process the schedule of the data packets. In an embodiment of the invention, the DDP 1 5 3 6 may include a reliable module (RDDP 15 16 ) that provides assurance of the positioning of one of the plurality of data packets. In one embodiment, to warrant shipment, the RDDP 1516 has a mechanism to retransmit packets that have not successfully reached their destination within a particular time interval. In an embodiment, if the data packet is not received within a preset time interval, the packet is retransmitted. The packet can be retransmitted a certain number of times before the transmission of the notification application packet has failed. With the RDDP 1516, the DDP 1536 provides the assurance that data packets are sent and/or received in the order required by the application. In one embodiment, DDP 1 5 3 6 may include a DDX module 1514 that can be used to transfer large amounts of data (e.g., image files, log files, etc.) between the mobile user and the mobile server. In an embodiment, the DDX module 1 51 includes a mechanism for ensuring data integrity of data transmission between the mobile user and the mobile server. In another embodiment of the present invention, the DDX module 1 51 may include a mechanism for confirming completion of data transfer to the application -70-200816753. In an embodiment of the present invention, DDP 1 5 3 6 can be implemented for a plurality of applications, and the plurality of applications include a voice mobility control application 1 5 06, a device management application 1 504, a plan management application 1 502, and a voice. Mail/email transmission application 1 5 08, device image management application 1 5 1 0, instant messaging application 1 5 1 2, etc., but not limited to this. In an embodiment of the invention, the plurality of applications can be divided into two groups. In the first group, multiple applications (eg, voicemail/email transmission application 158, device image management application 1 5 1 0, instant messaging application 1 5 1 2, etc.) are easy to send larger The file application, so DDP 1 5 3 6 can use DDX module 1514 to convert the file into any other module that can utilize DDP 1 5 3 6 including 1 5 1 6 , 1 5 1 8 , 1 5 2 2 The smaller data packet and the guarantee that the data file has been successfully transferred and the application is notified about the completed transmission. In the second group, the plurality of applications (voice mobility control application 1506, device management application 15 04, planning management application 1 5 02, etc.) are usually applications that are easy to send smaller control messages. Often, the application in the second group tends to control the application. In one example, voice mobility controller 160 can enable mobile users and mobile servers to share an active state that can be sent by a single DDP packet. Figure 16A is a diagram showing an example of how data within a mobile architecture configuration with DDP flows between an application user in a user device and an application server managed by the enterprise in one embodiment. Assume that the user on the user device wants to use the voice mail user 1206 to retrieve the voice mail from the -71 - 200816753 audio mail server 1604. Upon receiving a request from the application user 162, the voicemail server 1604 can initiate a file transfer. Voicemail server 1 604 can send the file along path 1 65 0. When a file is received, the mobile server can prepare an active user to send the file to the user device via a secure channel. In one embodiment, the server DDX module 1 608 within the mobile server can be used to convert the file into a format compatible with the control and transport protocols of the secure channel. In one example, the server D D X module 1680 can convert a dual format file into a format that can be transmitted via the SIP protocol. Furthermore, the servo DDX module 1 608 can divide the file into multiple data packets to ensure the validity of routing the plurality of data packets via the secure channel. After completing the boot process, the server DDX module 1 608 can send the first data packet to the server DDP 1 6 16 . In one embodiment, the server DDP 1616 can include a D DPS module that is required by the application to encrypt the data packet. In one example, a simple data package (e.g., an instant message) can be sent without encryption. In another example, important data packets (e.g., confidential email) can be encrypted before being routed to the requester. From the server DDP 1616, the first data packet can be encapsulated as a SIP notification message (as shown in code example 370 of Figure 16B) and transmitted to the user device via the secure channel via network 1 624. In one example, the first data packet can be transmitted via the secure channel by using the server SIP Control Protocol 1 620 and the Server UDP Transport Protocol 1622. The first user packet is securely received by the mobile user of the user device that can receive the data packet from -72-200816753 via the User UDP Transport Protocol 1 626 and the User SIP Control Protocol 1 628. Within the mobile user, the user D D P 1 6 3 2 can receive the first data packet. User RDDP 1 634 can perform a similar check as performed by server RDDP 1614. Furthermore, the user RD D P 1 6 3 4 can send a SIP notification message with a DDP answer to the server DDX module 1608 via the secure channel along the path 1 6 5 2 . By transmitting a DDP answer, the user RDDP 1634 can send a guarantee from the mobile user to the mobile server that has received the data packet. Similarly, if the server RDDP module 1614 does not receive an RDDP response, then the server RDDP module 1614 will retransmit the data packet until the maximum number of packets has been successfully acknowledged or the retry has been exhausted. In an embodiment, the data packet will be sent and the next data packet will not be sent until a DDP response has been received. In one example, the server D d X module 1680 does not send the second data packet until the D D P response has been received. In another embodiment, the number of fixed data packets can be sent, and no additional packets are sent until a response has been received for one or more of the original data packets. In one example, the server D D X module 1 6 〇 8 can send a group of 10 data packets and wait until at least one response is received before being able to transmit additional data packets. Once the mobile user has sent a DDP reply to the mobile server, the routing data is encapsulated to the user D D X module 1 6 3 6 . In one example, the user DDX module 1 63 6 may retain the data packet before all data packets have been received. In one embodiment, the server DDX module ι 60 8 may send a message indicating that the requested file has been sent and there is no additional -73-200816753 file data packet to be sent. Once all of the funds have been received, the user DDX module 1 63 6 will reorganize the file and notify the voice mail user 1 602 that the voice mail profile can be utilized. As can be seen from Figures 15 and 16, the DDP architecture provides a single secure channel for multiple application users to interact with multiple application servers. By having data traffic through a single secure channel, the DDP architecture can provide control by ensuring that data packets are received, verified to be known, and that there are no data packets received. In the example, the DDP architecture allows large files to be divided into smaller data packets, which can be sent using the guarantee g received by the receiving side. Figure 17 is a diagram showing an example of a telephone flow for establishing a secure channel between a user device and an activity server in an embodiment of the present invention. In one embodiment, registration is initiated in order to establish a secure channel. Assume that the user first starts the user device.

In a first step 1 724, a SIP registration must first be established. In an example, user SIP 1716 can send a SIP registration request via server UDP 1714. The SIP registration request can be received by the server SIP 1710 via the server UDP 1712. Upon receiving the SIP registration request, the server SIP 1710 can send a SIP registration response 1726 to the user SIP 1716 via the server UDP 1712 and the user UDP 1714. Once the SIP registration has been successfully completed, the steps to establish a secure DDP channel are initiated. In the next step 1728, the user DDPS module 1718 (the user-74-200816753 DDP 1 720 module) will send a DDPS dialog request to the server DDPS module 1708. In one example, the DDPS dialog request can be routed to the server DDPS module 1 708 via the user SIP 1716, user UDP 1714, server UDP 1712, server SIP 1710. When receiving the DDPS dialog request, in the next step 1 73 0, the server DDPS module 1 70 8 will send a DDPS fefg tongue response 1730 through the server SIP 1710, the server UDP 1712, the user UDP 1714, and the user SIP 1716. Go to the user DDPS f旲 group 1718. Once the secure channel has been established, the user must register with the mobile server. To notify the user, the user DDPS 1718 can forward the DDPS dialog response to the application user 1722. Upon receiving the notification, in the next step 1 7 32, the application user 1 722 sends a DDP registration request to the user/device manager 1 704. In an example, application user 1 722 can send registration information to user DDP 1720. User DDP 1720 can send registration via established secure channel (ie via user DDPS module 1718, user SIP 1716, user UDP 1714, server UDP 1712, server SIP 1710, and server DDPS module 1 708) Information to d DP 1 7 0 6, the latter then routes the registration information to the User/Device Manager 1 704. Upon receipt of the registration information, in the next step 1 7 32, the user device manager 1 704 can send a DDP registration response to the application user. In one example, user device manager 1704 sends a DDP registration response to server DDP 1706. The server DDP 1706 is via the established secure channel (ie via the server D D P S 1 7 0 8 , the server S I P 1 7 1 0, the servo -75- 200816753)

The UDP 1712, user UDP 1714, user SIP 1716, and user DDPS 1718) send registration information to the DDP 1720, which then routes the DDP registration response to the user of the application user 1 722. In an active architecture configuration with DDP, registration can be an event. In one example, when the user device is first activated, the user device will register with the mobile server. Because the secure channel has been established at steps 428 and 430, the user of the user device can ensure that the transmitted sensitive registration information has been encrypted and passed through the secure channel. In one embodiment, no additional D D P registration is required as long as the secure channel between the user device and the mobile server is maintained. In one embodiment, the interaction between the application user on the user device and the application server managed by the enterprise can now be safely implemented via a single secure channel. Figures 18 and 19 illustrate an example of how DDP handles interaction between an application user on a user device and an application server managed by the enterprise in one embodiment. Figure 18 is a flow chart of a simple telephone in the case where a large file must be transmitted in an embodiment. Assume that the user device needs to download the latest software upgrade. In one example, the application user 1 8 1 4 sends a software upgrade request 1 8 1 6 to the image manager 1 802 responsible for managing different software images on the server side. In a first step 1 8 1 8 , the application user 1 8 1 4 sends a new image request to the image manager 1 8 0 2 . In one example, a new image request is first sent from the user application 1 8 1 4 to the user DDP 1 8 1 0. After receiving a new image request, the DDP 1810 can send a request to the server DDP 1 80 8 via the secure channel. Before being sent to Image Manager 1 802, -76-200816753 can route new image requests to Device/User Manager 1 804 which is responsible for deciding which software to upgrade. After the device/user manager 1 804 has determined which software upgrade the user device requires, the device user/manager 108 04 can route a new image request to the image manager 18〇2. Upon receiving the request, the image manager 108 is then sent the requested software upgrade (e.g., requested data 1 802) to the server DDX module 1 806. In one embodiment, the server DDX module 108 can convert the file into a format that can be transmitted via a secure channel established between the user device and the mobile server. In one embodiment, the server DDX module 1 806 divides the large file into multiple data packets for transport via a secure channel. In the next step 1 822, the server DDX module 1 806 can send a DDX file transfer to the user DDX module 1 8 12 via the server DDP 1808 and the user DDP 1810. In one embodiment, the DDX file transfer start means a notification between the server DDX that is about to send the file and the user DDX. The DDX file transfer start can include basic information about incoming files such as file name, file size, number of data packets sent, application requesting files, and so on. In the next step 1824, the user DDP 1810 may send a DDX start response to the server DDX 1 806. In an embodiment, the RDDP module within the DDP can send a DDX to start responding. In the next step 1 826, the server DDX module 1 8 06 can send the first DDX data packet to the user DDX module 1812. As shown in FIG. 16, the DDX data message is first sent to the server DDP 1801 -77 - 200816753. In one embodiment, the DDX data message is encapsulated into a SIP notification message, and the secure channel is transmitted through the SIP control protocol and the UDP transport protocol. send. On the user device, the DDX information can be received by the user DDP 18 10, and then the user DDP 18 10 can route the DDX data message to the user DDX module 1812. In the next step 1828, when the DDX data message is received, the DDP answer will be sent by the user DDP 1810. In one embodiment, the RDDP module within the user DDP 1810 will send a DDP response to inform the server that the DDX module 1 806 has successfully received the incoming DDX data message. Steps 1 826 and 1 828 are repeated steps that can be repeated until all DDX data packets and responses have been exchanged between the server and the user DDX module. Once the last DDX data message and the DDX response have been sent, in the next step 1 8 3 0, the server DDX module 1 806 will send the DDX file transfer to the application user 1 8 1 4 to notify the application user that the message has been sent. All DDX data messages. In one example, the DDX file transfer end can be sent from the server DDX module 1 8 06 to the server DDP 1 8 08 to the user device.

The end of the DDX file transfer can be received by the user DDP 1810. In an embodiment, in a next step 1832, the RDDP of the user DDP 1810 may send a DDP response to the image manager 1 802. At the same time, the user DDP 1810 can route the DDX file transfer to the user DDX module 1 8 1 2, which will notify the application user 1 8 1 4 . As you can see in Figure 18, you don't have to create a new secure channel to request a software upgrade. Instead, the application server receives and processes requests for software upgrades without having to establish a new Secure Channel -78-200816753. It can also be seen that Figure 18 illustrates how the DDP architecture can be used to send data traffic in a secure and reliable manner, allowing the sender and requester to ensure that all data packets for the requested file have been successfully received. Figure 19 is a simplified telephone flow diagram of a case in which a small control message such as a sender of a control application can be transmitted in an embodiment of the present invention. In Figure 19, the interaction between the application user and the application server can occur without the DDX module. It is assumed that the user of the user device wants to share his or her user's presence (eg, available, busy, only phone, etc.). In a first step 1914, the User Attendance Manager 1 9 1 0 on the user device can send the presence preference settings to the server presence manager 1 902. In an example, the user presence manager 1910 can send the presence preference (as a single DDP data packet) to the user DDP 1 90 8, then the latter sends the presence preference setting to the server DDP 1 906 ° via the secure channel when receiving To attend the preference setting, in the next step 1 9 18, the server DDP 1906 can send a DDP answer. In one embodiment, the RDDP module within the DDP can send a DDP response. At the same time, the server DDP 1906 will notify the server attendance manager 1 902 via the device/applicator manager 1 904 regarding attendance preference settings. Suppose another situation in which the same user wants to find the presence status of another user. In a first step 1 922, the user presence manager 1910 can send the presence -79-200816753 query 1 920 to the user DDP 1 908, which can send the presence query to the server DDP 1 906 via the established channel. Upon receiving the challenge, the server DDP 1 906 will forward the query via the device/user manager to the server presence manager 1 902, which can perform the requested query to retrieve the requested information. In the next step 1928, the server presence manager 1902 responds (e.g., the requested status profile) to the user attendance tube 1910. In an example, it may be sent from the server out-of-service manager 1 902 to the server 1 906 via the device/user manager 1904. The presence response is then sent to the user 1908 via the secure channel, and the user DDP 1908 then routes the presence response to the user manager 1 910. As described above, Figures 18 and 19 illustrate examples of how DDP can be used to manage the interaction between a complex data application on a device and a plurality of application servers managed by the enterprise. The DDP-enabled configuration creates a single channel through which individual application users and application servers can interact. Furthermore, the DDP architecture can be used to send data traffic in a secure and secure manner, enabling the sender and requester to ensure that all data packets for the requested file have been successfully successful. Because the mobility architecture with DDP can now be a control center, the mobile architecture with DDP now coordinates the various activities that the users of the phone have previously managed individually. In an example, FIG. 18 illustrates how to use the DDP to manage user authentication on the user device, including software upgrades, device configuration, and user information management, etc., and the processor will present the DDP DDP to the user. The program is a user of this mutual reliable receiving system, but -80-200816753 is not limited to this. In another example, DDP can manage the presence of the user by allowing the user to share their status (see Figure 119). This enables the system to manage incoming traffic and allow others to see his or her status. . In another example, DDP can manage mobility by allowing users to navigate from one data network to another without having to worry about dialog management. As can be appreciated from embodiments of the present invention, a mobile architecture configuration with DDP reduces the security risk by providing a single secure channel through which multiple applications on the user device can communicate with multiple applications on the enterprise server. A DDP is a diversity agreement that can be advantageously implemented regardless of hardware and/or software limitations. Furthermore, DDP is an adaptive protocol that can be controlled to utilize complex numerical control and/or transportation protocols. E. Divitas Protocol Agent (DPP) If the user of the application on the mobile phone directly accesses the enterprise resources, the enterprise firewall needs to be opened for multiple agreements. The method conceived in accordance with one or more embodiments of the present invention enables a mobile-based enterprise application to use existing VoIP-related connections in a secure manner. The invention is implemented by conceiving a decentralized protocol agent. The decentralized protocol agent can be divided into two parts. Some of them are stationed on mobile phones along with VoIP users. The other part is stationed in the enterprise along with the VoIP server. As shown in Figure 7 A - D, the mobile phone-based V ο IP user acts as a server for different applications executed on the mobile phone. This component uses existing V 〇 IP-related connections (eg, S IP ) to send application load across the enterprise -81 - 200816753 industry. The server side proxy component is responsible for removing the load and connecting to the real server. The user and server side proxy components further subdivide the components. Each subcomponent is responsible for proxying an agreement. Figure 7A illustrates one or more embodiments in accordance with the present invention and each host includes two network interfaces. Via two separate network paths, one path comes from interface C 0 to S 0 and the other path comes to S1. In SCTP, these two paths will be combined.

Divitas "weak users" use built-in power monitoring integration When a path failure is detected, the protocol sends the stream through another path without knowing that a failed takeover recovery has occurred. Failed takeovers can also be used to maintain network application connectivity. Assume that a laptop with a wireless 802.1 1 interface and an Ethernet interface has a higher speed Ethernet interface when it is connected to the station but when the connection is interrupted (leave 埠When the station is connected, the connection should be lost. When returning to the docking station, the Ethernet interface should be detected to restart communication. This is a highly available and reliable organization. In accordance with one or more embodiments of the present invention, implementing multiple starts provides an application that is more usable than using TCP. The host room has more than one host of the network interface, and therefore has more than one IP address of the host at the beginning. In TCP, the channel at both ends (in this case, the interface of the two hosts). 7B-D illustrate an enterprise in a plurality of sub-network architectures providing two paths from C1 to a quantity in accordance with one or more embodiments of the present invention; Application. For example, a computer. When it is more suitable, the receiver can reach and pass through one of the strongest plans to have addressable at the beginning, and the weak connection between the ports is used to match the weak users on the server. An efficient transportation mechanism for transporting status information between the mobile phone and the server. Examples of e-mail applications (eg, SMTP) are illustrated using the SIP-NOTIFY method to tunnel application layer packets without knowing the SMTP application. The presence of the presentation layer encapsulation application on the user does not have to be changed to provide continuity of conversation. Advantageously, mobile applications use the above approach to achieve enterprise security that is safer and easier to manage. This approach also enables VoIP vendors to extend their mobility solutions to different enterprise applications. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 20 is a diagram showing an example of a conventional technique in which the respective applications on the mobile phone are individually connected to the corresponding application server in the enterprise. The mobile phone 2000 may include a plurality of application users including Divi t as User 2002, CRM (Customer Relationship Management) application user 2 006, and mail application user 2 008, but is not limited thereto. Application users can interact with each other independently or through the Application Agreement Interface (API). In one example, application users 2006 and 2008 can interact with Divitas User 2002 via API 2010 and API 2012, respectively. Application users in Mobile Phone 2000 can interact with application servers within Enterprise 2090. The enterprise 2090 can include a plurality of application servers including, but not limited to, a Divitas server 2022, a CRM application server 2026, and a mail application server 2 028. The application server can interact with each other independently or through the -83-200816753 API. In one example, application servers 2026 and 2028 can interact with Divitas server 2022 via API 2030 and API 2032, respectively. It should be noted that the purpose of the API is to enable applications to interact with each other. However, because the applications are independent of each other, the interaction through the API is arbitrary. Assume that a stockbroker on mobile phone 2000 can communicate with its users via Divitas user 2 0 02. Despite talking to their users, stockbrokers want to get their users' portfolios at their fingertips. In this case, the stock broker must establish two different conversations. Stockbrokers can establish a first dialogue to enable them to talk to their users through Divitas users 2002. To mention the portfolio, the stockbroker can establish a second conversation by utilizing the CRM application user 2006 to interact with the CRM application server 2026 under the firewall 2040 within the enterprise 2090. In a typical Secure Sockets Layer (SSL) virtual private network (VPN) environment, network managers must establish different configurations for each established channel. In order to establish two different conversations, two separate security channels must be established. In one example, a new mail application user has been added to the phone. In order to communicate with a mail application server located within the corporate firewall, the network administrator must establish a new secure channel. Thus, in a typical SSL VPN environment, a user must establish multiple sessions that require multiple start communication commands and make the business more vulnerable to security risks. The SSL VPN environment is not only inconvenient for users, but this type of environment also requires more human resources to manage the security of the enterprise's network environment. To minimize the number of secure channels established, the Internet-84 - 200816753 Protocol (IP) Security Gateway can be used instead of SSL. In a 1P secure VPN environment, one or more application users on the handset can interact with the application server through a secure channel across the IP security user 2014 and the IP security gateway 2030. In order to establish a secure channel, the user must first provide authentication information (eg, username, password, etc.). Once a secure channel has been established, the user is also responsible for the certification each time a different application user is utilized. In other words, each application user can be configured to communicate with its corresponding application server via a different IP address. In one example, the CRM application user 2006 wants to interact with the application server 2026. If Secure Channel 2084 has not been established, the user must first provide authentication information. Once the secure channel 2 0 8 4 has been established, in order for the CRM application user 2006 to interact with the CRM application server 2026, the user must provide additional authentication material. In addition, new security channels and re-authentication must occur every time the conversation is interrupted. In an example, if the user is moving during the conversation, if the connection is not visible, the user is at risk of a sudden interruption from the conversation. For example, users connected via a Wi-Fi network will traverse the Wi-Fi network. The conversation will be interrupted and the user must establish another conversation, such as a cellular connection. As a result, the user is disturbed by the inconvenience of establishing a new conversation and is also frustrated by limited mobility. Providing conventional techniques Figure 2 1 illustrates how an application user interacts with an application server. Figure 21 is a flow diagram of a prior art process for enabling an application user to communicate with an application server in an ip secure VPN environment. Figure 21 discusses Figure 20. -85- 200816753 Suppose the user of the mobile phone 2 0 〇 想要 wants to use the mail application user to send an email. In a first step 2102, the email material traffic is sent to the application server. In one example, the mail application user 2008 can send an email message packet to the mail application server 2 0 2 8 in the enterprise 2090. In the next step 2104, the IP Security Client (IP Security Client) 2014, which can check to determine how to route traffic, receives the electronic material. The IP Security User 2014 can analyze each packet to determine if the packet is a packet that the enterprise 2090 wants. The IP Security User 2014 can identify the recipient of the packet by analyzing the IP address and the 埠 number located in the packet. If the recipient of the email data traffic is not one of the plurality of application server sinks in the enterprise 2000, then in the next step 2106, the IP security user 2 0 1 4 may discard traffic or bootable email traffic to no The server is located in the enterprise 2 090. How to handle e-mail traffic that is not the application server in enterprise 2090 depends on how the IP security user 20 i 4 group is configured to handle non-enterprise data traffic. If IP Security User 2014 determines that the data traffic is what the application server in Enterprise 2090 wants, then in the next step 2 1 0 8 , IP Security User 2014 can encrypt each data packet before forwarding the data packet. . Encrypting the processing of individual data packets requires that the mobile phone 2000 have sufficient CPU processing power. In addition, the requirement to encrypt individual data packets in an IP-secured VPN environment can create potential problems in voice communication situations such as voice over Internet Protocol (VoIP) communication sessions. In other words, the speech quality during the voice communication session is severely degraded, resulting in poor voice communication experience (eg, echoes in the background, inaudible conversations, etc.). In the next step 2110, the IP Security Client 2014 can send the encrypted traffic along the secure channel 2084 to the desired application server. As mentioned above, the secure channel must establish a secure channel each time a new application is utilized. In one example, IP Security User 2014 can send encrypted traffic to Enterprise 2090's IP Security Gateway 2030 via network 2050 and firewall 2040. In the next step 21 12, the IP security gateway 203 0 performs a check to decide how to route the traffic. Similar to IP Security User 2014, IP Security Gateway 2030 analyzes each packet to determine if the packet is what Enterprise 2090 wants. If the received data packet is occasionally not an encrypted IP security packet, then in a next step 2114, the IP security gateway 2030 discards the packet. If the data packet is an encrypted IP security packet, then in a next step 21 16 the IP security gateway 2030 may decrypt the traffic. Once the packet has been unsealed, the IP Security Gateway 203 0 analyzes the packet to identify the IP address and port number of the received application server. In the next step 21 18, the IP security gateway 2030 forwards the data packet to the appropriate application server (e.g., mail application server 202 8). The method described in step 2 1 02 to 2 1 1 8 is continuous processing and is performed for each packet received by the application user. There are several disadvantages to the prior art. In one example, each new application user added to the -87-200816753 user's mobile phone must be configured differently. When new application users are added, the management of various application users and their corresponding application servers leads to a more complex setup network environment, which is costly to maintain. Furthermore, the user must be responsible for performing multiple certifications, thus requiring the user to remember the multiple authentication materials. In addition, the benefits of operating in an IP-secured VPN environment are reduced due to the need to encrypt data traffic, resulting in increased hardware costs (eg, the handset must have sufficient CPU processing power) and potential factors. In addition, the user will be frustrated by the limited mobility provided, and each time the g tongue is interrupted, the user must re-establish the connection and re-authenticate. In one aspect of the present invention, the inventors herein implement a prior art architecture configuration that integrates multiple authentications and/or multiple secure channels to create an environment in which a single communication command is initiated. In other words, the inventors have realized that data traffic from multiple applications can be transmitted by grouping applications into a single application (eg, Divitas user) and a single server (eg, Divitas server) to direct their data traffic. A single secure channel is sent without requiring the user to perform multiple authentications. In addition, the loss of dialogue can be significantly reduced without sacrificing mobility. In accordance with an embodiment of the present invention, an Active Architecture configuration is provided by implementing a Divitas Protocol Proxy Servant (DPP). In an embodiment, the DPP includes a user DPP and a server DPP. In an embodiment of the invention, the handset may include an active user (eg, a Divitas user, which may include the user Dpp to manage connectivity between the handset and the mobile server (eg, Divitas server). In the present embodiment, the mobility server may include a server DPP to manage connectivity between the line server and the handset. In an embodiment of the invention 'and the server DPP may include a plurality of sub-users/servers DPP is managed by the type of agreement (eg, SIP, SMTP, etc.) In an embodiment of the invention, DPP is able to interact with each application and its corresponding application server to establish a single secure channel. Each application is routing via a common DPP. Its data flow, so it can now manage the connectivity between the mobile phone and the mobile server. The connection can include a secure channel between the control protocol mobile phone and the mobile server such as SIP (Dialog Start Protocol). Decide when and how to connect your phone. In addition, when connectivity information can be sent from one network to another (eg, from Wi-Fi) To the cellular network, the feature points of the present invention can be more clearly understood by referring to the following drawings and discussions between different networks. FIG. 2 is a configuration of a mobile architecture in an embodiment of the present invention. Block diagram. In the mobile architecture configuration 2200, the Divitas server 2218 in the mobile phone 2 2 2 2 and 2216 (eg, mobile server. The mobile phone 2202 can include Divitas user 2204 (eg, mobile) and Multiple application users (2206 and 2208). In the present embodiment, Divitas user 2204 may include user DPP to manage connectivity between the mobile server and the mobile server. Unlike conventional techniques, application users 2 2 0 6 and the user of the application of the dynamic user, because the DPP resource is used to be used, including the network) and the simple and easy enterprise, the interoperability of the mobile phone program-89-200816753 users 2208 are not grouped directly with their corresponding applications. The program server (222 0 and 2222 ) interacts. In one embodiment, instead, various different configurations for individual application users can be simplified to direct all data traffic to a single regional IP host 2210 associated with Divitas User 2204 (eg, 127.0.0. 1 IP address). In other words, data traffic from application users 2206 and 2208 can now be combined to be routed to Divitas User 2204 via APIs 2212 and 2214. From Divitas User 2204, all data traffic can then be routed through the network 2224 (e.g., the Internet) via the intranet 2216 Divitas Server 2218. In an embodiment of the invention, the Divitas server 2218 may include a server DPP to manage connectivity between the handset and the mobile server. Once the D 2 server has received the data traffic, the J2 server can properly route traffic to the corresponding application servers (2220 and 2222) via APIs (2232 and 2234). Assume that the user of the handset 2202 wants to send an email by utilizing the application user 2206. Since the application user 2206 has been configured to send all data traffic to the zone to host 22 1 0, the data traffic from the application user 2206 is sent via the API 2212 to the zone IP host 2210 associated with the Divitas user 2204. When receiving traffic from application user 2206, Divitas User 2204 can use Divitas Data Exchange (DDX) to encapsulate traffic within the SIP Notify Message. As discussed herein, DDX refers to the protocol used to transfer data packets between a handset and a server. When encapsulating a data packet, DDX adds a new tag that adds information about the application user who sent the data stream -90-200816753. Unlike conventional techniques, all data packets are not encrypted. Instead, the data packet is encrypted depending on the preferences specified by the application user. In an embodiment of the invention, the newly added DDX is encrypted. Once the data packet has been encapsulated within the SIP Notify Message, the encapsulated data packet is now forwarded to the Divitas server 2218 along the security channel 2250 including the traversing network 2224. It should be noted that if the enterprise is protected by one or more security modules (eg, firewall 2 2 2 6), the data packet must also traverse one or more security modules. Once the data packet has been received by the Divitas server 2218, the Divitas server 22 18 can utilize the DDX tag to retrieve the location of the application server. In an example, the DDX tag can include an identification number (eg, MAC address, 埠 address) that indicates which application server (eg, application server 2220) in the enterprise is the desired data packet reception. By. In an embodiment, the mobility architecture configuration manages connectivity between the handset and the mobile server. In an embodiment, the mobile architecture configuration may utilize control protocols utilized by general handsets such as SIP. In a mobile architecture configuration, in order to establish a secure channel, the user must only perform a manual authentication. In other words, once a secure channel has been established between the mobile phone and the mobile server, there is no need to create another security every time the application user (2206 and 2208) wants to interact with the application server (2220 and 2222). aisle. In the usual case, the mobile architecture configuration can also include a database. This -91 - 200816753 database includes certification materials for each application user. Thus, each time a different application user is utilized, in one embodiment, the mobility architecture configuration can utilize the application specific credentials stored in the database to automatically authenticate the user. From the user's point of view, the mobility architecture configuration is essentially a single start communication command environment. Advantageously, the 'actual architecture configuration is generally time and effort efficient' network administrators must spend on assembling individual application users. Network administrators can largely eliminate this process by assembling individual application users to interact with the regional host, instead of adding a new application each time a user has to establish a new secure channel to the phone. In addition, with a single start communication command, network managers can substantially reduce the time and cost associated with managing security. The mobile architecture configuration can be implemented as a rich or weak user. Figure 2 is a block diagram of an active architecture configuration as a rich user in an embodiment of the present invention. As discussed in this article, rich users mean that user DPP and server DPP not only manage a variety of different applications but also provide support to at least one or more application user functions (eg, voice application users, instant messaging application users). Mobile architecture configuration for email applications, email applications, etc.) Assume, for example, that the user of the mobile phone 23 02 wants to retrieve the mail application server 2326 from the enterprise 2318 using the mail application user 2310 (eg, Microsoft® Outlook, etc.) (eg,

The case of emails such as Micro so ft® Exchange servers. Figure 24 - and Figure 23 will be discussed. Figure 24 is a simplified flow diagram of an example of a method for configuring with an active architecture in the embodiment of the present invention -92-200816753. In the first step 2402, the application user sends the data traffic to the regional host of the user. In the mobile architecture configuration, the application user 2310 has been configured to route its data traffic via the regional host 2308 located within the Divitas user 23 04 . In one example, the application user 2310 can send an SMTP (Simple Mail Transfer Protocol) data packet 2312 to Divitas User 2304 over TCP-IP. The SMTP data packet 2312 can be received by an SMTP proxy user 2306 (e.g., sub-user DPP) located in the Divitas user 2304. In an embodiment, the user DPP may include a plurality of sub-user DPPs. The type of proxy user used to process data traffic depends on the type of application user. In an embodiment of the invention, the data packet includes a UI number unique to the application user. In one example, the SMTP data packet 2312 includes the following information one 127.0.0.1 /25. In this example, the number 127.0.0.1 is the IP address unique to the regional host 2 308, and the number 25 indicates the 埠 number associated with the SMTP proxy user 236 in this example. In the next step 2404, the data traffic can be encapsulated as a SIP Notify Message with a DDX tag. In other words, when receiving the data packet 2312, the Divitas user 23 04 reformats the SMTP data packet 23 3 0 into a SIP data packet 2330 (such as SIP Notify Message, etc.) that can be transmitted via a control protocol such as a SIP handset. In an embodiment of the invention, the SIP data packet 23 3 0 includes a source data packet (e.g., data packet 23 12 ) having a DDX header 23 3 0a and a SIP header 23 3 0b. As mentioned above, the DDX header includes an application server-specific special-93-200816753 with an identification number. In the embodiment of the present invention, a unique identification number can be generated based on the 埠 number included in the SMTp data packet. In an embodiment of the invention, additional indicia may be included in the formatted data packet to identify how the formatted data packet is to be transported. In the example, the transport agreement mark 23 3 〇c may be a UDP-IP transport mark. In an embodiment of the invention, one or more portions of the SIP data packet 23 30 may be encrypted. In one embodiment, the DDX portion is encrypted even if the remainder of the data packet is not encrypted. In the next step 2406, the Divitas user can send a data packet to the Divitas server. Once the data packet 2312 has been reformatted into a SIP data packet 23 3 0 (eg, encapsulated as a SIP Notify Message), it can be sent over the secure channel 23 50 via the network 2314 and/or the firewall 23 16 SIP data packet 23 3 0 to Divitas server 2320. In the next step 2408, the Divitas server can check to determine if the incoming data packet is a SIP Notify Message. If the incoming data packet is not a SIP Notify Message, then in the next step 2410, the data packet may be discarded. However, if the incoming data packet is a SIP Notify Message, then in the next step 2412, the Divitas server can check the expected proxy server by checking the DDX flag. In one embodiment, the Divitas server must decrypt the DDX packet to read the information stored in the DDX packet. In one example, based on the unique identification number in the DDX tag, the Divitas server 23 20 knows the routing data packet 23 3 0 to the SMTP proxy -94 - 200816753 server 2 3 2 2 . In an embodiment of the invention, the server D P P may comprise a complex sub-server D P P . In an embodiment of the invention, the type of proxy server that handles incoming traffic is dependent on the type of data traffic. In the next step 2 4 1 4, the data packet can be routed to the proxy server. Since the SIP data packet 2330 is an SMTP data packet, the formatted data packet (e.g., sub-server DPP) is processed by the SMTP proxy server 23 22 located inside the Divitas server 2320. In the next step 2416, the data packet is routed to the intended application server. In an embodiment of the invention, the SMTP proxy server 23 22 can convert the SIP data packet 23 30 into a format acceptable to the application server. In one example, SIP data packet 23 3 0 can be converted from SIP Notify Message to SMTP data packet 2328. In addition, the DDX part can be discarded. In addition, the transport protocol can be changed from UDP-IP to TCP-IP, which is more conducive to deploying email data traffic to the respective application server (eg, mail application server 2326) via API 2332. The method steps illustrated in Figure 24 do not illustrate the encryption and/or decryption of data packets. In an embodiment, the data packet can be sent without encryption. The requirements for encryption are arbitrary and can be determined by the user's requirements. In an embodiment, some or all of the data packets may be encrypted. In one embodiment, the DDX portion may be encrypted while leaving the remainder of the data packet unencrypted. Random encryption reduces the processing power to be utilized and reduces the underlying factors typically associated with encrypted data packets. As can be seen from Figure 2 3 and 2 4, the rich mobile architecture configuration can be used to enable mobile phone application users to move with the application server in a single start communication command environment. Device. In addition, a rich mobility architecture configuration can include data packets from various applications to be converted into data packets that can be transported by control protocols and transport protocols specific to established secure channels. In an embodiment of the invention, as shown in Figure 25, the mobility architecture configuration can be implemented as a weak user. In a weakly mobile architecture configuration, the user DPP and the server DPP can only be utilized as an mobility manager (e.g., to manage application connectivity) and not to provide support to at least one or more application functions. Assume, for example, that a user of the mobile phone 2 500 wants to call a friend. Users can make calls using the phone application user 2508 (eg, VoIP, etc.). In this example, it is assumed that a secure channel 2550 has been established between the Divitas user 25 02 and the Divitas server 2518 located within the enterprise 25 3 〇. To establish a telecommunications conversation, the telephony application user 2 0 0 8 can send a data packet 2512 ( For example, SIP/UD-IP) to the regional host 2510 within the Divitas user 2502. As noted above, multiple proxy users can reside within Divitas User 2502 to support a variety of different application users. In one example, SIP proxy user 2504 can be located within Divitas user 2502 to process data packets from telephony application user 2508. Upon receiving the data packet 2512, the SIP proxy user 25 04 can analyze the data packet to determine how to route the packet. As mentioned above, the data packets that can be sent to Divitas users can include the application server-specific 埠-96-200816753 number (eg, 5060, etc.). Using this information, the Divitas user 2502 can route data packets 2 5 1 2 to the Divitas server 25 1 8 via the network 2 5 1 4 and the firewall 2 5 2 8 . In an embodiment, if the data packet is already in a format routable by the Divitas user, then the data packet does not have to be converted. In one example, data packet 2512 is shown in the SIP/UDP-IP format, which is a format that Divitas user 25 02 can use to route its data traffic. In a consistent embodiment, the 'multiple proxy server' can reside in the D i v i t a s server. In an example, SIP proxy server 253 2 can reside within Divitas server 2518 to manage the incoming traffic from telephone application user 2508. Since the data packet 2 5 1 2 has been sent from the phone application user 2 5 0 2, the data packet is processed by the SIP proxy server 2 5 3 2 . When receiving the data packet 2512, the SIP proxy server 253 can forward the data packet 25 1 2 to the destination telecommunications device along the path 2522 via the telephone gateway 2520 (eg, PSTN, GSM, CDMA, etc.) (eg, Telephone, etc.). Once a telecommunications conversation has been established between the handset 25 00 and the destination telecommunications device, other data packets sent by the telephony application user 2 5 3 0 (eg, RTP data packets, etc.) may be routed along the secure channel 2 5 5 0 Path 2 560 is sent to the Divitas server 25 1 8 without having to go through the Divitas user 25 02. In a weakly mobile architecture configuration, the purpose of establishing a telecommunications conversation with the help of Divitas users is to enable application users to take advantage of the mobility features of Divitas users. In other words, a control center has been established between the Divitas user and the Divitas server to monitor the connectivity of the application user. By establishing this relationship, when the situation occurs, Divitas users and Divitas -97-200816753 servers can share their connectivity status and be able to handle roaming seamlessly. In the example, the user in the above case can currently be connected via the Wij_F i network. During a phone conversation, users can roam outside the Wi-Fi network. In the prior art, the connection may be interrupted and the user must redial. However, in a mobile architecture configuration, the connectivity status of the user's handset has been monitored, and Divitas users and Divitas servers can perform seamless network exchanges (eg, from Wi_Fi to the user without noticeable changes). Honeycomb network). Advantageously, companies that have invested a large amount of money into multiple applications and only need an mobility manager can implement a weakly mobile architecture configuration. In this way, organizations can leverage the mobility manager-configured mobility manager performance without having to re-engineer their telecommunications infrastructure. As can be appreciated from the embodiments of the present invention, an active architecture configuration with DPP provides an mobility manager that enables a smooth telecommunications infrastructure. In other words, the mobile architecture configuration provides a single environment for starting communication commands. In the example, a single secure channel can be used to achieve the same function to replace multiple secure channels of the enterprise. Using an environment that starts with a single communication command can significantly reduce the cost and effort of managing a telecommunications infrastructure. In addition, the mobility architecture can monitor and seamlessly handle connectivity without negatively impacting the user's telecommunications experience. F. CONCLUSION Although the invention has been described in terms of several preferred embodiments, modifications, variations, and equivalents are possible within the scope of the invention. It should also be noted that there are many other ways of implementing the methods and apparatus of the present invention. Moreover, the utility of the embodiments of the present invention can be found in other applications. For the sake of convenience, this article provides abstract commemoration, which is limited to the convenience of reading and is not intended to limit the scope of patent application. Accordingly, the scope of the appended claims should be construed as including all such modifications, alterations, and equivalents of the true spirit and scope of the invention. BRIEF DESCRIPTION OF THE DRAWINGS The present invention is illustrated by way of example only, and not by way of limitation Network map. 2A-C are diagrams of actuating servos in accordance with one or more embodiments of the present invention. 3 is a mobile device user diagram in accordance with one or more embodiments of the present invention. 4 is a block diagram of an encoder/decoder based echo canceller in accordance with one or more embodiments of the present invention. Figure 5A is a diagram of a speech jitter buffer in accordance with one or more embodiments of the present invention. Figure 5B is a diagram of a speech jitter buffer in accordance with one or more embodiments of the present invention. Figure 6A is a schematic diagram of a DDP architecture in accordance with one or more embodiments of the present invention. -99-200816753 Figure 6B is a D D P message exchange diagram in accordance with one or more embodiments of the present invention. 7A is a network architecture diagram of each host including two network interfaces and fabricated in accordance with one or more embodiments of the present invention. Figure 7B is a diagram of a network architecture made in accordance with one or more embodiments of the present invention. Figure 7C is a diagram of a network architecture made in accordance with one or more embodiments of the present invention. Figure 7D is a diagram of a network architecture made in accordance with one or more embodiments of the present invention. Figure 8A is a block diagram of an exemplary prior art communication device including an echo cancellation filter. Figure 8B is a flow diagram of an exemplary conventional technique communication device for use in, for example, the exemplary prior art communication device illustrated in Figure 8A. Figure 9A is a block diagram of a communication device (or system or configuration) that cancels echoes without relying on a filter, in accordance with one or more embodiments of the present invention. Figure 9B is a block diagram of an ID code generator for the communication device (or system or configuration) of Figure 9A, in accordance with one or more embodiments of the present invention. Figure 9C is a flow diagram of a method for canceling echoes, such as the communication device (or system or configuration) of Figure 9A, in accordance with one or more embodiments of the present invention. FIG. 10A is a block diagram of a first exemplary conventional method with an adaptive jitter buffering scheme -100 - 200816753 technical packet voice communication system (first prior art configuration). Figure 10B is a flow diagram of transmitter side processing for a conventional technique bounce buffering scheme for a first prior art configuration, such as the one shown in the example of Figure 10A. FIG. 1C is a flow chart of a conventional technique delay calculation process. Figure 10D is a flow chart of a conventional technology packet implementation control process. Fig. 10E is a schematic diagram showing the flow of the received packet in the packet implementation control when the transmitter side voice activity detector (VAD) is turned on. Fig. 1 〇F is a schematic diagram showing the flow of the received packet in the packet implementation control when the VAD on the transmitter side is turned off. Figure 11 A is a block diagram of a receiver-side device that includes adaptive buffer overflow control, a packet voice communication system (second prior art configuration). Fig. 1 1 B is a flow chart for the kidneyless detection process of the receiver side device shown in the example of Fig. 1 1 A. Fig. 1 1 C is a flowchart of a buffer overflow control process for the receiver side device shown in the example of Fig. 1 1 A. Figure 1 2A is a block diagram of a receiver side device having an adaptive jitter processing packet voice communication system in accordance with one or more embodiments of the present invention. Fig. 1B is a diagram of a delay insertion control process utilized for adaptive bounce processing of a receiving side device such as the one shown in the example of Fig. 1 2A according to one or more embodiments of the present invention. Figure 13 is a block diagram of a receiver side device of a packet voice communication system with adaptive jitter processing in accordance with one or more embodiments of the present invention. -101 - 200816753 Figure 14 is a diagram showing an example of a conventional technique for establishing a connection between an application user and an application server. Figure 15 is a simplified block diagram of the DDP invention of the embodiment of the present invention. Figure 1A is a diagram showing an example of how data within a mobile architecture configuration with DDP flows between an application user located within a user device and an application server managed by the enterprise. Fig. 16B is a diagram showing an example of a code of a packaged SIP notification message in the embodiment. Figure 17 is a diagram of an example of a telephone flow illustrating how to establish a secure channel between a user device and a mobile server in an embodiment. Figure 18 is a simplified telephone flow diagram showing the case where a large file must be transmitted in the embodiment. Figure 19 is a simplified telephone flow diagram illustrating the manner in which small control messages, such as those sent by a control application, can be sent in an embodiment of the present invention. Figure 20 is a diagram showing an example of a conventional technique for individually connecting individual applications on a mobile phone to a corresponding application server within the enterprise. 21 is a flow diagram of a prior art technique for enabling an application user to communicate with an application server in an IP secure VPN environment. Figure 22 is a simplified block diagram showing the configuration of an active architecture in an embodiment of the present invention. Figure 23 is a block diagram showing the configuration of the mobile architecture in the embodiment of the present invention as a heavy load client. Figure 24 is a simplified flow diagram of an example of a method of -102-200816753 utilizing an active architecture configuration in an embodiment of the present invention. Figure 25 is a diagram of a mobile architecture configuration implemented as a lightly loaded client in an embodiment of the present invention. [Main component symbol description] 1 〇〇: System network 102: Mobile equipment 1 1 〇: Honeycomb network 1 1 2: Base transceiver station 1 1 4 : BTS switching center 1 1 6 : Mobile switching center 120: Media gate Router 122: Public Switched Telephone Network 124: Conventional Public and Private Telephone 130: Private Branch Switch 1 3 2: Router 1 3 6: Telephone 1 3 7: Telephone 1 3 8: Internet Protocol Wide Area Network 1 4 0 : Router 142: Firewall 144: Internet 1 5 0: Mobility Server 1 6 0: Access Point - 103- 200816753 1 8 0: Access Point 800: Conventional Technology Communication Device 802: Signal Receiver 806: Speaker 8 0 8 : Echo path 810: Microphone 8 1 2 : Buffer 8 1 4 : Filter 8 1 4 : Echo canceller 8 1 6 : Sum function 900 : Communication device 9 0 4 : Signal receiver 906 : Background miscellaneous Remover 9 0 8 : Echo path 9 1 0 : ID injector 914 : Speaker 916 : Microphone 922 : ID generator 924 : ID detector 926 : Buffer 92 8 : Delay 9 3 0 : Sum Function 93 2 : Signal Transmitter 1 0 0 0 : Speed Buffer - 104 200816753 1001 : 1 002 : 1 003 : 1 004 : 1 005 : 1 006 : 1 007 : 1 008 : 1 009 : 1 080 : 1 080a 1 082 : 1 084 : 1 086 : 1 086a 1 08 8 : 1 090 : 1091 : 1 092 : 1 092a 1 094 : 1 096 : 1 098 : 1100: voice activity detector transmitter network packet buffer packet implementation controller delay insertion controller delay information module jitter computer implementation delay computer voice packet: packet silent descriptor silent voice packet = Packet Silent Silence Descriptor Transmitter Side Device Receiver Side Device: Voice Packet Silent Packet Voice Packet Silent Packet Receiver Side Device -105 200816753 1102: Packet Buffer 1104: Packet Implementation Controller 1108: Delay Insertion Controller 1 η 〇: Bounce computer 1 η 4 : Buffer overflow controller 1 1 1 6 : Silent detector 1 1 1 8 : Decoder 1 1 8 0 : Add-on 1 199 : Link 1 200 : Receiver-side device 1 202 : Packet buffer 1 204: Bounce computer 1 2 0 6 : Implement delay computer 1 208 : Packet implementation controller 1 2 1 0 : Decoder 1 2 1 2 : Silent detector 1 2 1 4 : Delay insertion controller 1 2 1 6: Delay information module 1299: link 1 3 00: receiving side device 1 3 02 : packet buffer 1 3 04 : jitter computer 1 3 06 : compensation computer 1 3 08 : packet implementation controller -106- 200816753 1 3 1 0 : Decoder 1 3 1 2 : Video Detector 1 3 1 4 : Compensation Controller 1 3 1 6 : Link Compensation Information Module 1399 : Link 1 402 : Application Server 1 404 : Application User 1 406 : Software download 1 4 2 4 : Notification 1 5 02 : Planning management application 1 5 04 : Device management application 1 5 06 : Voice mobility control application user 1 5 0 8 : Voicemail/Email transmission Application 1 5 1 0 : Device Image Management Application 1 5 1 2 : Instant Messaging Application 1 5 1 4 : David Data Exchange Module 1 5 1 6 : Reliable David describes the protocol module 1 5 1 8 : Priority Message Scheduling Module 1 5 20 : Built-in Dialogue Management Module 1 5 22 : Davida Description Protocol Module with Security Extension 1 524 : Control Protocol 1 5 2 6 : Transmission Control Protocol 1 5 2 8 : User Data Meta- Agreement 1 5 3 0 : Transmission Control Protocol-107- 200816753 1 5 3 2: Dialogue Startup Agreement 1 5 3 4: Data Element Agreement 1 5 3 6 : David He describes Agreement 1 602: Voice Mail User 1 604: Voice Mail Server 1 608: Server David Data Exchange Module 1 6 1 4 : Server Reliable David Description Protocol Module 1 6 1 6: Server Davies Description Protocol 1 620: Server Session Initiation Protocol Control Protocol 1 622: Server User Data Meta-Conference Transfer Protocol 1624: Network 1 626: User User Data Element Agreement Transfer Agreement 1 628: User Dialogue Startup Agreement Control Agreement 1 63 2: User David describes his agreement 1 634: User Reliable David describes the agreement 1 63 6 : User David Data Exchange Module 1 6 5 0 : Path 1 652: Path 1 700: Enterprise Server 1 702: User Device 1 704: User/Device Manager 1 706: Davida Description Protocol 1 708: Decentralized Data Processing System 1 7 1 0: Session Initiation Protocol - 108 - 200816753 1 7 1 2 : User Information Meta- Agreement 1 7 1 4 : User Data Meta-Contract 1 7 1 6 : Dialogue Initiation Agreement 1 7 1 8: Decentralized Data Processing System 1 720: Davide describes the Agreement 1722: Application User 1 802: Image Manager 1 804 : Device / User Manager 1 8 06 : Server Davis Data Exchange Module 1 8 0 8 : Server David describes the agreement 1 8 1 0 : User David describes the agreement 1 8 1 2 : User wears Vita Data Exchange Module 1 8 1 4 : Application User 1 8 1 6 : Request 1 902: Server Attendance Manager 1 904: Device/User Manager 1 906: Server Davide Description Protocol 1 9 0 8: User Davide describes the agreement 1910: User Attendance Manager 1 9 2 0: Attendance Enquiry 2 0 0 0: Mobile 2002: David User 2006: Customer Relationship Management Application User 2008: Mail Application User-109- 200816753 2010 : Application Protocol Interface 20 12 : Application Protocol Interface 2014 : Internet Protocol Security User 2022 : David Server 2026 : Customer Relationship Management Application User 2028 : Mail Application Server 203 0 : Internet Protocol Security Gateway 203 0 : Application Protocol Interface 203 2 : Application Protocol Interface 2040 : Firewall 2 0 5 0 : Network 2084: Secure Channel 2 0 9 0 : Enterprise 2200: Mobile Architecture Configuration 2 2 0 2 : Mobile 2204: David User 2206: Application User 2208: Application User 2210: Regional Internet Protocol Host 2212: Application Agreement Interface 22 14: Application Agreement Interface 2216: Enterprise 2218: David Server 2220: Application Server - 110- 200816753 2222 : Application Server 2224 : Network 2226 : Firewall 2232 : Application Protocol Interface 2234 : Application Protocol Interface 2250 : Secure Channel 2 3 0 2 : Mobile 23 04 : David User 2 3 06 : Simple Mail Transfer Protocol Agent User 2 3 0 8: Zone Host 2310: Mail Application User 23 12: Simple Mail Transfer Protocol Data Packet 2 3 1 4: Network 2 3 1 6: Firewall 23 1 8: Enterprise 2320: David Server 2 3 22: Simple Mail Transfer Protocol Proxy Server 23 26: Mail Application Server 2 3 2 8: Simple Mail Transfer Protocol Data Packet 2 3 3 0: Dialogue Start Protocol Data Packet 23 3 0a: David Data Exchange Header 23 3 0b : dialog start protocol header 23 3 0c : transport agreement mark 23 3 2 : application protocol interface -111 - 200816753 23 5 0 : secure channel 2500: mobile phone 25 02 : David user 2504: Dialogue Startup Protocol Proxy User 25 0 8: Phone Application User 2 5 1 0: Zone Host 2512: Data Packet 2 5 1 4: Network 2518: David Server 2520: Telephone Gateway 2522: Path 2 5 2 8: Firewall 2530: Enterprise 25 3 2: Session Initiation Protocol Proxy Server 25 5 0: Secure Channel 2552: Application Protocol Interface 2 5 6 0: Path 25 62: Immediate Protocol X: Signal y ': Signal y 1 : Signal z: Signal -112-

Claims (1)

200816753 X. Patent Application Scope 1 · An operational architecture configuration for managing the telecommunications mobility of a mobile phone. The mobile architecture configuration includes: DiVitas Protocol Proxy Server (DPP), which is configured as a tube S. Connectivity between an active user and an active server within the enterprise, wherein the DPP includes a user DPP that is configured to manage the connectivity of the mobile user of the mobile phone, the user DPP receiving from a plurality of application users a plurality of user connectivity requests, and a server DPP, configured to manage the connectivity of the mobility server. The server DPP receives a plurality of server connectivity requests from a plurality of application servers, wherein the user DPP And the server DPP are grouped to interact with each other to establish a secure channel. 2. The mobility architecture configuration according to claim 1 of the scope of the patent application, wherein the user DPP is configured to include a plurality of sub-user DPPs, each of the plurality of sub-user DPPs being configured to process an agreement of a plurality of agreements. 3. The mobility architecture configuration according to claim 1 of the scope of the patent application, wherein the server DPP is configured to include a plurality of sub-servers DPP, each of the plurality of sub-servers DPP being configured to process an agreement of a plurality of protocols. 4: According to the mobile architecture configuration of claim 1, wherein the first application user of the plurality of application users sends a set of data packets to the user DPP through an application protocol interface (API), the data packet is The grouping is comprised of a regional host address and a number, the host-113-200816753 address is associated with the mobile user, and the number is associated with the first application user. 5. The mobility architecture configuration according to item 4 of the scope of the patent application, wherein a DiVitas Data Exchange (DDX) tag is configured to be attached to the group of data packets, the DDX tag including a unique feature associated with the first application user Identification. 6. The mobility architecture configuration according to item 5 of the scope of the patent application, wherein the DDX tag is encrypted. 7. The mobility architecture configuration of claim 6 wherein the user DPP formats the set of data packets having the DDX tag into a format of the server DPP that can be transmitted to the mobility server via the secure channel. . 8. The mobility architecture configuration of claim 7, wherein the server DPP is configured to decrypt the DDX tag and use the unique identification to send the group of data packets to the first application server. 9. The mobility architecture configuration of claim 1 wherein the mobile user is configured to include a database for storing authentication data for each of the plurality of application users. 10. A method of managing telecommunications mobility for a mobile phone, comprising: utilizing a DiVitas Protocol Proxy Server (DPP) to manage connectivity between an active user of the handset and an active server within the enterprise, wherein the DPP Including the user DPP, which is configured to manage the connectivity of the mobile phone. The user DPP receives multiple user connectivity requests from multiple application users, and the server DPP is configured to manage the mobile servo. Connectivity of the server, the server DPP receives a plurality of server connectivity requests from the plurality of application servers; and uses the user DPP and the server DPP to establish a secure channel between the mobile phone and the mobile server Enables the plurality of application users to interact with the plurality of application servers. 11. The method of claim 1, further comprising transmitting, by the application protocol interface (API), a group of data packets from the first application user of the plurality of application users to the user DPP of the mobile user Attaching a DiVitas Data Exchange (DDX) tag to the set of data packets, the DDX tag being configured to include information about the first application user, via the secure channel, sending the set of data packets having the DDX tag to the The server DPP of the mobile server; analyzing the DDX tag to identify the first application server of the plurality of application servers, the first application server being associated with the first application user; and transmitting The set of data is encapsulated into the first application server. The method of claim 1, wherein the user DPP is configured to include a plurality of sub-user DPPs, each of the plurality of sub-users DPP being configured to process an agreement of a plurality of agreements. The method of claim 1, wherein the server-115-200816753 DPP is configured to include a plurality of sub-servers DPP, each of the plurality of sub-servers DPP being configured to process one of the complex protocols agreement. 1 4. The method of claim 11, wherein the data packet is configured to include a regional host address and a 埠 number, the host address of the region is associated with the mobile user, and the 埠 number is The first application user is associated. The method of claim 11, wherein the user DPP formats the set of data packets such that the set of data packets can be transmitted via the secure channel, the secure channel being established by a control protocol. 16. The method of claim 15, wherein the control agreement is a Session Initiation Agreement (SIP). 17. The method of claim 11, wherein the DDX mark is grouped to include a unique identification. 18. The method of claim 17, wherein the DDX tag is encrypted by the user DPP. 19. The method of claim 18, wherein the server DPP is configured to decrypt the DDX tag. The method of claim 10, wherein the mobile user is configured to include a database for storing authentication data for each of the plurality of application users. 2 1 . An article of manufacture comprising a program storage medium having a computer readable code embodied therein, the computer readable code being configured to manage telecommunications activity of a mobile phone within an operational architecture configuration, the computer readable code comprising Used to establish a secure channel code between the mobile user of the mobile phone and the mobile server located in the enterprise by using the DiVitas Protocol Proxy Server (DPP), which includes the user DPP. The group is configured to manage the connectivity of the mobile phone, the user DPP receives multiple user connectivity requests from multiple application users, and the server DPP is configured to manage the connectivity of the mobile server, the server DPP receives a plurality of server connectivity requests from the plurality of application servers; and a secure channel between the handset and the mobile server using the user DPP and the server DPP to enable the plurality of application users to The code that interacts with the plural application server. 22 _ The article manufactured according to claim 21 of the patent application, further comprising a packet of a first application user sent from the plurality of application users through the application protocol interface (API) to the mobile user a code of the user DPP; a code for attaching a DiVitas Data Exchange (DDX) tag to the set of data packets, the DDX tag being configured to include information about the first application user for sending via the secure channel The set of data having the DDX tag is encoded by the server DPP of the mobile server; the DDX flag is analyzed to identify the code of the first application server of the plurality of application servers, the first An application server is associated with the first application user; and -117-200816753 is configured to send the set of data packets to the first application code. 23. The manufactured user DPP according to claim 21 of the patent application is organized to include a plurality of sub-user DPPs, each of which is configured to process an agreement for the plural agreement. 24. The server DPP manufactured according to claim 21 of the patent application is assembled to include a plurality of sub-servers DPP, which are grouped into a protocol for processing a plurality of agreements. 25. According to the scope of claim 22 The manufactured packet data packet is assembled to include the regional host address and the nickname host address associated with the mobile user, and the 埠 number is associated with the program user. 26. The user DPP, manufactured according to Article 22 of the scope of the patent application, formats the data packet of the group so that the data is transmitted by the secure channel, and the security channel is transmitted through the control protocol; 27. According to the scope of application 22 The manufactured DDX mark is assembled to include a unique identification, and the DDX mark is used by the user. 28. The object manufactured by the server according to claim 27, the server DPP is assembled to decrypt the DDX mark. 29. The manufactured structure according to claim 21 of the scope of the patent application is configured to include a database for storing the authentication data of each of the plurality of application users. The server of the server, wherein the plurality of sub-products, wherein the plurality of products, the code, the area and the first item 'where the packet can be determined to be established. Product, where the 1 DPP force secret product 'where g Hai products, where the library is used to store -118-