TW200814679A - Code-based echo cancellation - Google Patents

Abstract

An apparatus for canceling a signal is disclosed. The apparatus may include an identification code (ID code) generator 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 a processed signal to produce a convolved signal. The processed signal is resulted from a processing of the signal. The apparatus may further include an ID code detector configured to detect at least one of the convolved signal, a transformed signal, and a transformation of the convolved signal. The transformed signal is resulted from the transformation of the convolved signal. The apparatus may further include an arithmetic function configured to remove at least one of the convolved signal and the transformed signal.

Description

200814679 IX. Description of the Invention [Technical Field of the Invention] The present invention relates to code-based echo cancellation. [Prior Art] The conventional mobile communication platform includes cellular communication, for example, Global System for Mobile Communications (GSM). Other well-known platforms that support limited mobility include WiFi according to the IEEE 802.11 standard. Both cellular and WiFi are well known and are established wireless communication platforms. The next-generation platform is designed to enable mobile users to move between cellular and WiFi networks and includes the Unlicensed Mobile Access (UMA) standard, which provides a switch controller to the carrier, allowing users to move beyond the cellular Between the WiFi standard and vice versa. However, the UMA standard has disadvantages including the carrier typically controlling the phone and deciding whether and when to exchange users between the networks. Advanced mobile communication platforms are needed to provide enterprise-level communications, and to control users and the network, enabling enterprises (instead of carriers) to select networks and/or phones based on corporate drive standards rather than carrier-driven standards. In addition, in mobile/wireless communication, there are usually the following problems: (a) echo; (b) packet delay affecting quality of service (QoS), packet delay variation (packet jitter), and packet loss; Or software platform dependencies; and (d) security of enterprise resource access. These issues are described as follows: (a) Echo 200814679 in voice communications such as the PSTN, conference phones, cellular phones, and VoIP Among them, echo cancellation (EC) technology has been widely used to improve the quality of service (QoS) of end users. There are usually two types of echo cancellers. One of the echo cancellers is usually called line or network echo canceller (LEC). LEC usually It is used to remove the electrical echo caused by the reflection of the mixed components on the network due to 2-wire and/or 4-wire conversion. Another echo canceller is often called the Acoustic Echo Canceller (AEC). AEC is usually used Remove the acoustic echo due to acoustic feedback from the speaker to the microphone, mobile phone, or conference phone on the speakerphone speakerphone. Compared with LEC, due to Some factors make it difficult to implement AEC: 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 speaker movement and environment Changes, so the dynamics of the acoustic echo characteristics vary greatly, so the echo canceller must track and catch up with changes in echo characteristics more quickly; and multiple echoes due to multiple reflections from different objects with different distances and/or orientations Paths. Current acoustic echo cancellation techniques are often limited. Although acoustic echo cancellation techniques have been invented and used for at least 40 years, the basic methods for eliminating acoustic echo have not changed significantly. Typically, typical AECs are modeled using adaptive filters. One or more echo path transfer functions and attempting 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. To date, most of the acoustic echo cancellation Technology development uses different types of filters, Such as FIR or IIR filters, single-band or multi-band filter 200814679, or time domain or frequency domain filters, etc. In addition, different algorithms such as LMS, APA have been used to improve filter efficiency. These technical improvements, today, AEC design and real work is very difficult. Because of the complexity and deterioration of acoustic echo, the conventional filter presents a number of limits on the processing of acoustic echoes. Both the end and the far-end speaker; performance. The calculation result of the conventional filter is to converge between echo and copy during the two-end call. (b) Packet delay and packet delay (packet extension) affecting quality of service (QoS) Bounce, and packet loss In VoIP and network video communications, voice and/or video content needs to be instantly moved from the sender to the receiver. However, the basic path was originally designed for non-instant messaging. Therefore, providing and maintaining the ultimate quality of service (QoS) becomes a very difficult task. End packet delay, packet delay variation (packet jitter), and packet loss Q 〇 S parameters that affect the quality and performance of voice and video communications over IP networks. 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 packets that can be queued at equal intervals are queued. In fact, the packet is listed as a 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. RLS, this is still the standard. Its £ talk) divergence takes late change frequency media IP network end user peer can be seen as three heavy-duty scheme road packet packet. And the implementation table is not inserted. The first 200814679 questions were 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 an adaptive jitter buffering scheme, the receiver can estimate the network packet jitter based on the timestamp of the incoming RTP header and the receiver local time. 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 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. False -8- 200814679 With no clues to identify silent, the current jitter 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) Hardware or software platform dependencies of the agreement 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 for bulk data transfer with minimal delay. However, conventional technology agreements such as UMA are often complex and difficult to establish 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 have implemented VoIP (Internet Telephony) to mobile phones. Such implementation requires an open enterprise 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/Audio Messaging, intranet web resources, 200814679 source, CRM, Supp〇rt database, and more. A mobile phone that directly accesses an enterprise firewall for one or more of the above applications needs to be opened for multiple protocols, and an open identity can create security issues. SUMMARY OF THE INVENTION In one embodiment, the present invention relates to an erase signal including an identification code (ID code) generator that is assembled into a production call and also includes an ID code injector that is grouped into an ID. Code 3 processes at least one of the signals to produce a whirling signal. Produced by the processing of signals. The apparatus additionally includes an ID code detection configured to detect one of a whirling signal, a transform signal, and a whirling signal. The transformed signal is produced by the transformation of the whirling signal. Arithmetic functions are included which are combined to remove the whirling signal and become a one. The above summary is only one or more of the examples disclosed herein, and is not intended to limit the scope of the invention. The following figures will be described in more detail in the detailed description of the invention. [Embodiment] Directory Architecture If the user utilizes the industry resources, the firewall can be installed. Install the ID code. At least a plurality of implementation ranges of the signal and the signal signal generator, which are group-transformed, at least the device additionally packets, in the present document, together with the invention of the present invention-10-200814679 B. Based on the encoder/decoder Acoustic Echo Cancellation C. Content-Based Bounce Buffer Design for IP Voice/Video Communications D. Divitas Description Protocol (DDP) E. Divitas Protocol Agent (DPP) H. Conclusion The invention will now be described in detail with reference to a preferred embodiment 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 processes 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, other protocols may be implemented by the present invention. The references to Divitas 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, -11 - 200814679 or other forms of computer readable media for storing computer readable codes. 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 100 in accordance with an embodiment of the present invention. Setup Mobile Device (ME) 102 that communicates with the network in many possible ways. The ME 102 can communicate with a cellular network 110 that includes a base transceiver station (BTS) 112, a BTS switching center (BSC) U4, and a mobile switching center (MSC) 116. The MSC is coupled to a media gateway 110 coupled to a public switched telephone network (PSTN) 122. Other conventional public and private telephones 1 24 are also coupled to the PSTN. The PBX 130 is coupled to the PSTN and, for example, calls and picks up the phone over the telephone 136. Couple the mobility server 55 p to p B X and other networks. For example, the mobility server 150 is coupled to the Internet Protocol Wide Area Network (W AN) through the router 1 32. The mobility server 150 is also coupled through the router 140 and the firewall 1 42. To the Internet 1 44. Although the present invention also contemplates multiple access points, only one access point is depicted herein. The access point 160 enables a user with ME 102 to roam in the enterprise and via action The sexual server 150 and the ΡΒχ 130 maintain a connection with the PSTN. If the user roams beyond the boundaries of the LAN, as will be described in more detail below, the user will connect to another network (eg, a cellular network). Coupled to an internet access point i 8 〇, which uses 12-200814679 for access under certain conditions as described herein. Figure 2 AC is an active server in accordance with an embodiment of the present invention. Security Management - The security definition when two or more bodies are communicating 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 Divitas mobility In the case, there are three Definite communication entities: Divitas users, Divitas servers, and external VoIP GWs. There are two clear path types between these entities: SIP signaling path and media path. As explained in the Architecture Manual [1], the following organizations The above security aspects used to achieve the signaling and data paths between the user, the server, and the external gateway: 1. SIP TLS session between the user and the server 2. Use SIP notification after SIP TLS is established User authentication 3. Authentication by the user of the server 4. SIP TLS session between the server and the external VoIP gateway 5. Server authentication using 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 an ongoing call on the device for simultaneous processing-13-200814679 Device configuration and status and mobility aspects Modules. 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. The reporting status of the device 3. The device's Like Management 4. Maintain and implement mobile logic for mobile phones with ongoing calls - ie, handle WiFi to Cell (and cellular) and vice versa. 5 · Process device initialization and configuration requests from the user. /Telephone Control - Telephone Control (CC) is the main control plane module responsible for the following functions:

1. Network language telephone processing 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 telephone control module resides on the DN media switch. The telephone control module interfaces with the SIP stack and the Asterisk (or any other) PBX to provide the above functionality. 1. SIP stack (for UA, CCM, and Asterisk, etc.): SIP stack is mainly used as the 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 B2BUA operations, 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. -14- 200814679 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 P A of any dynamic information (eg, the call is in progress or interrupted), or requires information (eg, SNMP GET). 3. Resource Manager (RM): 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 memory, data buffers, timers, queues, and so on. Resources do not include outlets for internal IPC communication. CC uses RM as a resource for CAC, resource reservation, and communication. As part of the communication, RM tells the media switch to program the hardware to make the media flow. The Media Switching Application (MSA)-MSA will be designed to be partially implemented on Linux and the rest on the TMS3 20DM64x DSP processor. The application will perform the following functions: RTP packet processing. exchange. Code conversion. conference call. Adaptive bounce buffer. Packet loss is hidden. Includes post processing of VAD/CNG and AGC. The MSA software needs to support encoding/decoding of different speech codecs/decoders -15- 200814679 code. The types of algorithms and channels can be changed during execution, ie multi-channel, multi-algorithm design is required. Each codec/decoder algorithm needs to be reentrant coded, and the program and data need to be fully releasable. In order to support various encoders/decoders, the following considerations are required: a. Because DSPs have limitations on the data memory of the wafer, not all data in the multi-channel, multi-algorithm application can be placed on the wafer. This requires the location of all data (text and tables) in each algorithm to be re-changed (between the wafer and the external memory) during the text exchange. This requires finding the memory, stack size, and MIPS requirements for each supported encoder/decoder. b. A mechanism for exchanging messages between the host and the DSP indicating the number of channels and the type of encoder/decoder and any other features. Channel Configuration Manager You need to open a channel that indicates the DSP of the desired type of function. A periodic message indicating the state of the DSP must be implemented. The DSP processor enables the external host to access the DSP external memory. The DSP has a first-order program and data memory of 16 kilobytes. The program shares the second-order memory of 256k bytes with the data memory. 16 million bytes of external memory (SDRAM) are available. The shared memory between the two processors stores incoming and outgoing RTP data. Since the DSP needs to support the number of N channels, this memory will contain N receive and transmit buffers for each length of 3 20 bytes (in the case of video, these buffers need to be 1 500 bytes). The data structure used for information between the host and the D S P and the information required for each call is required to be defined. The following steps define the DSP function: -16- 200814679 a. During startup, once the software is downloaded to the DSP (the host will be pointed out by downloading the predetermined location 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 for 10 msec. At this point, the DSP polls the channel status to change to processing, which is set by the host once the packet arrives. 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 open channel, 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 handsets with an IP connection that provides a cellular connection (CDMA or GSM) and a LAN connection (wired LAN or wireless LAN). 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 -17 - 200814679 • Change user status (INVISIBLE) /AVAILABLE) • Add corporate “buddies” (partners) and get their presence information (INVISIBLE/AVAILABLE/CALL-IN-PROGRESS) • Enterprise “buddies” (partners) display availability status and connect to them • joint venture User interface for phone features • Telephone dialing • Telephone answering • In-line docking • Designated transfer • Call forwarding • Multi-party conference calls • Voicemail notifications • Missed call notifications • Received call notifications • Pending call notifications • Numbers Query and dial with name • Manual control device using a cellular network instead of WiFi network • Display version mismatch • Upgrade request/status • Disable/disable user software An ISP application is used to dial/receive hive Telephone control and voice • Telephone control for making VoIP calls on the LAN interface-18- 20081467 9 • The voice engine for making VoIP calls on the LAN interface 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 which ip networks and their signal strengths can be used and pass the information to the server • AP users • 8 02.1 1 mini-connected power management - whenever the signal strength of 802.1 1 is below an acceptable threshold, Keep the network to sleep at rare intervals and poll the network to save power. • If the phone is in progress, package the signal strength and voice quality information into RTCP packets, or keep it valid if the phone is not in progress. Communicate 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 network. Platform Because there are many mobile phone vendors on the market and offer dual-mode phones, the software needs to be designed so that most of the code can be shared between phones. Therefore, the code must be divided into a platform dependent part and a platform independent part. In fact, almost all Divitas cores should be part of the platform of the software, so it can be easily carried from one platform to another. The platform dependencies should only have functional adaptation layers (especially, telephony, LAN, 802.11, audio, and display adaptation layers). Whenever the code is transferred to the new platform, it is only necessary to modify and rewrite these adaptation layers while providing the unified -19-200814679 API to the platform independent part. User software will be executed on multiple mobile platforms. 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.11 phones, PDAs, or laptop/desktop computers 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 it does not exist, the user application checks for the presence of the 8 02.1 1 network. Depending on the corporate security policy, wired or wireless media certification is required. Mobile phone users should support the security agencies used by the enterprise. 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 the D N S IP address from the persistence database and attempts to register with the D i v i t a s server. Application users can be executed on mobile phones within the corporate network. At that point, 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. -20- 200814679 The user application software authenticates the phone to the server by sending an encrypted digital visa (installed by the corporate IT). Once the phone is authenticated, the user obtains the login/password from the user or stored in the phone, encrypts the login/password and sends the encrypted login/password to the server as the user authentication. When successful authentication, the server answers 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. The above process is repeated each time the user restores network connectivity to the server. Constant Steady Operation By organizing on the GUI and saving the configuration in a persistent database, the user can select INVISIBLE or AVAILABLE at startup (invisible/available). The user updates the user presence information to the server. Users can also frequently enter so-called partners in the company and save the configuration in a persistent database on the phone. Whether they are INVISIBLE, AVAILABLE, or C A L L - IN - P R Ο G R E S S (in the phone), the user gets the presence information (huge amount) of these partners. When an event occurs, the server updates the presence information of these partners to the user. Whenever you are not on the phone, the user and server periodically exchanged for -21 - 200814679. The user periodically sends the network status to the server. If the user is on the 802.1 1 wireless network, the user sends the SSID, the associated signal strength and bandwidth of the access point (AP) to the server. If in the phone, the user sends the S S ID as part of the RTCP packet in the band. If not on the phone, the user sends a persistent message out of band. The preferred mode of making and receiving calls to users is on the network interface whenever a network conversation is available from the user to the server. However, the user can choose to place a call on the cellular network regardless of the presence of the preferred mode. This selection is not passed to the server and does not affect incoming calls. This selection is also not stored in the persistent database. The user must make a clear choice when the user dials out. The only way to make a phone-welded call is from the cellular interface whenever the network conversation is not available from the user to the server. Users do not have access to all corporate features. Whether the user software provides only a subset of service provider features, the user can make and receive calls using the user software UI. In order to use all the features of the cellular service provider network, the user must terminate (or disable) the user software and use the cellular service provider to dial the application. If the service provider application is being used to make and receive calls, the messaging described in 3.4.2 below will not be possible. As long as the user has a conversation that has been established to the server, the user has access to all enterprise features. User GUIs are used to provide access to these enterprise features to the user. Voice -22- 200814679 SIP signaling is used to establish a voice call between the user and the server. The speech from the audio receiver is encoded into one of the encoder/decoders supported by the GIPS Speech Engine (VE), which will be encapsulated into RTP packets, encrypted if necessary, and sent to the server over the IP interface. Similarly, if necessary, the RTP received from the server is decrypted and decoded and implemented using one of the encoder/decoder. Speed decoding, jitter control, and error concealment are performed by GIPS VE on the receiving side. In addition to encryption/decryption, speed encoding/decoding, the GIPS speech engine performs error concealment, jitter control, adaptive packet buffering, acoustic echo cancellation and suppression, noise cancellation and suppression, automatic gain control, voice activity detection, Comfort noise is 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 -23-200814679 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, performing a delay of 8 02·IX authentication may result in a significant interruption of the network connection, especially in terms of 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. PMK Cache When a wireless subscriber roams from one wireless AP to another, the wireless subscriber must perform full 802. IX authentication with each wireless AP. WPA enables wireless users and wireless APs to cache the results of full 802.IX 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 with the wireless subscriber's PMK cache entry for the wireless AP. If the wireless user is integrated with the wireless AP, the PMK cache entry is stored for a limited amount of time. In order to make the transition of the wireless network infrastructure using the switch that is used as the 802.1 X authenticator faster, the WPA/WPS IE Update calculates the PMK identification symbol 値 'to make it re-use when roaming between wireless APs attached to the same switch Such as the PMK determined by the switch 802. IX certification. This implementation is considered an opportunistic Ρ K cache. Pre-certification With pre-certification, while connected to its current wireless port, -24 - 200814679 WPA wireless users are free to perform 8 02· IX certification with other wireless APs in their range. 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. WPA users who support pre-authentication can only authenticate with wireless APs that publish their pre-authentication capabilities in the Beacon and Probe Response frames.

WiFi - Honeycomb Messaging When there is a telephone conversation with 8 0 2. 1 1 The user in the network has not arrived. 8 02. 1 1 When the outside of the building is connected or insufficient, the call is sent to the cellular network. The decision by the user to make a communication call is based on 802. 1 1 Signal strength, channel load, and speech quality criticality. Once the decision is made, the decision is passed to the server that initiates the call to the user on the cellular network. The user checks the caller id (identification symbol) of the incoming call, with 8 02. 1 1 Dialer id comparison, if there is a match, accept the cellular phone and discard 8 0 2. 1 1 phone foot. On the server side, the server is dropped to the user's 80. 1 1 phone foot, patched to another speaker's 802. 1 1 phone foot. Source when the mobile phone user is at 802. 1 1 When the network is idle, 802. 1 1 Fan You connect to sleep. Before going to sleep, the phone tells the AP that the phone wants to pass 802. 1 1 Set the source bit in the header to go to sleep. The AP receives the frame and informs the user of the desire to enter the mode source mode -25- 200814679. In the user's 802. 1 1 When the mini-connector is asleep, the AP starts buffering packets for the user. The mini-connector has very low power consumption while asleep. You connect and periodically wake up to receive periodic help-transmissions coming in from the access point. The source user needs to be awake to receive help when transmitting for help. TSP (Time Synchronization Function) ensures that the AP and the section source user are synchronized. The TSP timer remains operational while the base station is asleep. These calls identify whether the sleeping base station has AP-packed packets and waits to be shipped to their respective destinations. When there is no incoming call for a long period of time, 802. 1 1 Mini connected to sleep. The mini-connector wakes up periodically to detect the AP's network connection. If it does not exist, the mini-connector returns to sleep. In this case, the mini-connector sleeps longer than the previous example. B. Acoustic Echo Cancellation Based on Encoder/Decoder One or more embodiments of the present invention are related to means for canceling signals. The device can include an identification code (ID code) generator that is configured to generate an ID code. The apparatus can also include an ID code injector 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 produced by the processing of the signal. The apparatus can additionally include an ID code detector configured to detect at least one of a transition of the whirling signal, the transformed signal, and the whirling signal, the transformed signal being resulting from a transformation of the whirling signal. The apparatus may additionally include an arithmetic function that is configured to remove at least one of the whirling signal and the variable number. 4 depicts a method of acoustic echo cancellation based on an encoder/decoder in accordance with one or more embodiments of the present invention. -26- 200814679 When both the near-end and far-end talkers are talking, it is difficult to distinguish between the far-end speaker’s head and the near-speaker’s vocabulary, because both exist in The near-end signal input of the same human speech feature. In this application, a new method is proposed to deal with acoustic feedback, which is quite different from the current AEC. An embodiment of the invention is a method for canceling echo during communication between a first node and a second node. The method includes injecting a password into the signal input of the first node. In accordance with one or more embodiments of the present invention, the first node is a network device used by a remote user and the second node is a network device used by a near end user. In accordance with one or more embodiments of the present invention, the first node is the network device used by the near end user and the second node is the network device used by the remote user. In accordance with one or more embodiments of the invention, a password is injected into the remote signal input. Thus, multiple echoes of the signal or far-end signal are carried on this password and arrive at the near-end signal input. The near-end signal in turn includes the near-end speaker voice. Because the password is only carried on the echo of the far-end signal rather than the voice of the near-end speaker, the password can be used as the echo itself and helps us distinguish between the near-end speaker voice. Some kinds of matched filters, such as association or other means, can be used to cryptographically recognize the echo of the far-end signal and the near-end speaker speech 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 should not allow end-to-end acceptance. -27- 200814679 The listener perceives the same consideration of the password. When someone speaks in front of the microphone, not only the voice of the person but also a certain degree of noise will enter the microphone. However, because the speaker's voice obscures background noise, this background noise usually 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. According to the above facts, first, the password can be converted into a virtual random noise called “crypto random noise.” Then, the existing background noise is removed from the far-end signal input, and the password random noise 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, a non-linear processor can be used after the matched filter to further reduce the residual echo and improve AEC performance. 200814679 The features and advantages of the present invention will become more apparent with reference to the following drawings and discussion. Echo is a major problem in communication. As discussed in the background of the invention, in the prior art, a filter (or echo canceller) can be used. It is used to model the attempt to provide a signal to eliminate the echo path of the echo. Figure 8A is an exemplary prior art communication device 800 including a filter 8 1 4 (or echo canceller 8 14) for echo cancellation (known techniques) A block diagram of apparatus 800). As shown in the example of FIG. 8A, conventional technique device 800 can include a signal receiver 802 for receiving a far-end signal from a remote (or far-end) (eg, signal y' And a signal transmitter for transmitting a signal (eg, signal z) to a remote location. The prior art device 800 further includes a speaker 806 for playing the received signal to the prior art device 800. The user (ie, local or near-end party); and the microphone 810 are used to collect near-end signals (eg, signal x, which may include local voice and background noise). The prior art device 800 includes buffering. 8 1 2 for buffering the signal received from the signal receiver 802; and a filter 8 1 4 for modeling the echo path 8 0 8 between the speaker 8 06 and the microphone 8 1 0 The signal buffered in the buffer 8 1 2 is processed. The echo path 800 8 may represent multiple paths of delay, attenuation, reverberation, etc., for example, converting the signal y to yl, etc. The prior art device 800 additionally includes a sum. The function 8丨6 is used to subtract the output of the filter 8丨4 from the output of the microphone 810. The prior art device 8 00 additionally includes a signal feedback path for feeding back the output -29-200814679 of the sum function 816. Go to filter 8 1 4 . The signal (e.g., signal y') received by signal receiver 82 can be forwarded to speaker 806 and buffer 812. Filter 814 receives the signal from buffer 812, processes the signal using the model of echo path 8000 to produce a cancellation signal (e.g., a function of x2, y'), and transmits the cancellation signal to summation function 8 16 . Next, the sum function 8 16 subtracts the cancellation signal (eg, x2 = f(y')) received from the filter 814 from the signal received from the microphone 8 1 0 (eg, xl=x + yl). A subtraction signal (e.g., z) is generated and a subtraction signal is sent to the signal transmitter 8 1 8 . The output of the sum function 8 16 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 will be described with further reference to FIG. 8B. Figure 8B is a flow diagram of an exemplary prior art method for eliminating echo in a prior art device 800 (shown in Figure 8A). The method of Figure 8B shows that 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 54. At step 8 52, speaker 806 (shown in Figure 8A) receives signal y. In step 156, microphone 81 (shown in Figure 8A) receives signal yl plus the near-end signal X. The signal y 丨 represents a deformation signal due to the signal y generated by delay, attenuation, reverberation, or the like. Delay, attenuation, reverberation, etc. are generated by the echo path 808 between the speaker 806 and the microphone 8 8 (shown in Figure 8A). The signal X includes the local voice plus the local surroundings picked up by the microphone 8 i 〇 Background noise. Then, the signal X 1 representing the combination of the signal y 1 and the signal X is sent to the sum function 8 i 6 (shown in FIG. 8A) ^ - 30 - 200814679 In step 8 5 4, the buffer 8 1 2 receives the signal again. y '. In step 558, filter 814 processes signal y' using the model of echo path 808 to generate a signal 'which is a function of 'y', eg, f(y')' and then sends this to sum function 8 1 6 ( Figure 8 A)). In step 860, the sum function 8 16 subtracts the signal X 2 from the signal X 1 to produce the 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 y1). 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. Corrective modeling of echo path 808 (e.g., by executor of filter 814) in relation to prior art devices, configurations, and methods (as shown by the prior art device 800 of FIG. 8A and the method of FIG. 8B). It is important to effectively eliminate echo. However, the established echoes, the reverberation of the surrounding noise, and/or other factors, the echo path 800 is dynamic and therefore difficult to accurately model. As a result, conventional techniques, configurations, and methods are not effective. -31 - 200814679 In addition to echo. The prior art devices, configurations, and methods additionally face bilateral conversations where the local (or near-end) and distant (or far-end) simultaneous speech. Since the local speech and the distant speech have similar vocal characteristics, the filter 8 1 4 cannot accurately identify which signal is to be input to the model of the echo path 808. As a result, the speech portion of the locality may be eliminated, and the echo portion is not eliminated, and the error of the echo path model in the filter 8 14 may become divergent instead of convergence, resulting in undesirable communication quality. Therefore, many resources have been invested in the prior art to improve the algorithm for modeling the echo path 8000. In addition, the filter 1 1 4 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 produced 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 indicates 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 present at the delay. The device additionally -32- 200814679 includes an arithmetic function 'which 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 no filters are 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 916), etc. . There is an echo path from speaker 914 to microphone 916. 90 8 Device 900 may also include a signal processing module, 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 , for example to transform signals, introduce delays. The module may also include an arithmetic function 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. This part of the signal is then removed, for example, for echo cancellation -33-200814679. 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 a virtual random noise sequence to be used as an ID code. Additionally, the ID code can include high frequency or low frequency signals that are not detectable by the human ear. In one or more embodiments, the sampling rate of the microphone 916 can be grouped into, for example, by hardware and/or software (or drive tracing) to process the local or low frequency. In one or more embodiments, the device 900 may not include the 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 may be configured to have the ID code generator 922 The generated ID code is injected into the signal, and can be implemented by a well-known algorithm such as a digital correlation method such as inserting an ID code into the signal, for example, by rotating the ID code and the signal to generate a whirling signal. ID code injector 910 〇 ID code detector 924 can be configured to detect an ID code within a whirling signal, such as in a mix, overlay, and/or another whirling signal that includes one or more other signals. The ID code detector 924 can be configured to detect the transformed signal and/or ID code generated by the transformation of the whirling signal; for example, the configuration and/or environment of the device 900 can be transformed. The detector 924 can be configured to detect transforms. The transform can include delays The signal code detector 924 can implement one or more well-known algorithms, such as a digital correlation method or a matched filter for detecting IDs, etc. The delay 928 can be configured into The delay is introduced into the signal. The delay -34-200814679 can be used for analog conversion. The delay 928 can be implemented by introducing a simple delay line shift register for delay. Each noise remover 906, ID code generation The 922, the ID code injector 910, the ID code detector 924, and the delay 92 8 are all included in a user device (eg, for acoustic echo cancellation) that can be downloaded to, for example, a telephone, a mobile phone, a teleconferencing device, And/or in a software device (e.g., for line or network echo cancellation). Figure 9B is an ID code generation for device 900 (shown in Figure 9A) in accordance with one or more embodiments of the present invention. A block diagram of the 922. The ID code generator 922 may be included only in the code generator 921 that will directly generate a random code. In this example, such as by linearly selecting a shift register by carefully selecting an appropriate feedback function, etc. Some well-known algorithms implement code production The ID code generator 922 may include a code generator 921 that is accompanied by a random function generator 923. In this example, first, the code generator 921 may generate an appropriate identification code without fear of randomization occurring. Then, This identification code is 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 the feedback function controlled by the code generator 92 1 to implement randomization. Function Generator 923 Figure 9C is a flow diagram of a method for canceling, for example, echo in device 900 (shown in Figure 9A) in accordance with one or more embodiments of the present invention. The method begins in step 9 5 2 ' in this step, the signal receiver 904 (not shown in Fig. 9A) can receive the shank number y'(n) from a distance. 35- 200814679 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. In step 958, ID code generator 922 (shown in Figure 9A) may generate an ID code c(n). The ID code c(n) can represent a known and controllable function. In step 95 6 , the ID code injector 91 0 (shown in Fig. 9A) can inject the ID code c(n) into the signal y (η). As a result, a convolution of C (η) and y (η) can be produced. For example, the wrap of c(n) and y(n) may be the whirling signal c(n)*y(n). Control is then transferred to step 962 and step 980. In step 962, speaker 914 (shown in Figure 9A) can receive a whirling signal c(n)*y(n). In step 964, microphone 916 (shown in Figure 9A) can receive a delayed signal, i.e., signal c(n-d)*y(n-d), from speaker 914. The microphone 916 can also pick up another input signal x(n) that includes the local voice (e.g., in a bilateral call plan) and/or background noise surrounding the microphone 916. The microphone 916 can then output the combined signal x(n) + c(n-d)*y(n-d) to the ID code detector 924 (shown in Figure 9A) and the sum function 93 0 (shown in Figure 9A). In step 980, buffer 926 (shown in Figure 9A) may buffer a copy of the whirling signal c(η) * y (η) and output a copy of the gyroscopic number to delay 928. In step 966, the ID code detector 9 2 4 (shown in FIG. 9A) can detect the ID code c(nd) in the combined signal x(n) + c(nd)*y(nd). 'And assuming that c(n) is a known and controllable function, the delay amount d° can be determined by comparing c(n) and c(nd) received from the 1D code generator 922. - 200814679 The delay amount d is fed to the delay 928 (shown in Figure 9A). In step 982, delay 928 (shown in Figure 9A) may introduce delay amount d from the output of buffer 926 (i.e., a copy of c(n)*y(?)) from step 980 to produce c(nd)*y. A copy of (nd). In step 990, the sum function 93 0 (shown in Figure 9A) may subtract the output of step 982 (i.e., the signal) from the output of step 964 (i.e., signal x(n) + c(n_d)*y(nd)). Generate a copy of c(nd)*y(nd)). In other words, in step 99, the sum function 93 0 calculates the signal x(n) + c(nd)*y(nd)-c(nd"y(nd) to obtain the signal χ(η), which represents the absence of the signal The echo of y'(n) (represented by signal y(nd)) is the input signal picked up by the receiver microphone 916 (shown in Figure 9A). The signal χ(η) may include speech such as in a bilateral call scenario And/or background noise around the microphone 916. In step 992, speech such as local to the bilateral call plan and/or background noise around the microphone 916 and signal x(n) not containing the echo 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. As can be understood from the above, the embodiment of the present invention can effectively eliminate the echo without requiring the prior art device and configuration. , or a filter (or echo canceller) required in the method. Embodiments of the present invention can provide more accurate echo cancellation and faster cancellation, while avoiding possible errors in filter-dependent echo path modeling, , get better service quality In addition, embodiments of the present invention can effectively eliminate echo in a bilateral talk scheme where conventional filters are generally poorly implemented. -37- 200814679 Under the practical complexity of not relying on filters and without echo path modeling, Embodiments of the present invention may also advantageously eliminate the need for high CPU processing power and large data memory required for the filter, thereby reducing the cost of implementing echo cancellation. The content-based jitter buffering scheme for video over IP communications, without relying on filter and associated echo path modeling complexity, also advantageously removes the high CPU processing power required by the filter. And the need for large data memory to reduce the cost of implementing echo cancellation. C. Content-Based Bounce Buffer Design for IP Voice/Video Communication Design One or more embodiments of the present 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 the RTP payload content of -38-200814679 is noted to identify the silent and speechal presence on the incoming packet. A clue is then generated based on this silence and speech to determine when an implementation delay can be inserted 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 packet queues, packet implementation, jitter calculation, and jitter compensation. Here, the decoder and VAD will produce silent and speech indicators. The Silent -39-200814679 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 hopping 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 the video, the insertion implementation silently actually stops the implementation of the new frame while repeating the previous video frame. As noted above, issues such as packet delay (i.e., packet arrival late), packet delay variation, and packet loss have a negative impact on quality of service (QoS) in packet communications. 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 the existing VAD calculation -40-14871679 method, the transmitter side VAD may generate unwanted noise or Mutant language. As another example, when the transmitting party uses G with the open transmitter side VAD.  When the 7 2 9 A B code/decoder plays some music, the user on the receiver side will perceive the distorted 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. In addition, the receiver side silent detector can be used to control the packet buffer overflow in the prior art to prevent packet loss. However, according to the combination in the prior art, the voice packet is discarded, so that the packet buffer is almost full when it is full or full. This quality of 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 V A D 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). Another option is that the 'characterized content can represent at least one of a lower than critical movement or no movement. For example, the border of no moving or still image can be selected as 10% to 15% of all moving images in the video communication (in terms of the volume of -41 - 200814679). 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 the adjusted packet if the detector has detected the characterization content in the incoming packet. Adjustments include delayed insertions in the form of, for example, silent packets or comfort noise packets. Alternatively, the adjustment may include iteratively implementing a previously implemented packet. As a result, the delay and delay variations of the incoming packets received in the packet buffer can be compensated in a timely manner, and the adjusted packets are of acceptable quality to the recipient. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 10A is a block diagram of a first exemplary conventional technology packet voice communication configuration (first prior art configuration) with an adaptive jitter buffer design. As shown in the example of Fig. 1A, in general, the first prior art configuration includes a transmitter side device 1091 and a receiver side device 1 092 connected via a network 1003. Each of the transmitter side device 1091 and the receiver side device 1 〇 92 can represent a telephone, a mobile phone, or a teleconference device. The transmitter side device 1 〇 9 1 may include the following components: a speed buffer 1 0 0 0, a voice activity detector 1 0 0 1 (V A D 1 0 〇 1 ), and a transmitter 1 002. These components are described as follows: Speed buffer 1 〇 〇 〇 can be configured to receive voice packets (packets) from the microphone, buffer packets, and then transmit buffered packets to VAD 1 00 1. The VAD 1001 can be configured to insert a silent descriptor (SID) when there is no sound in the packet received from the speed buffer 1 (i.e., a time period between voice packets). -42- 200814679 Transmitter 1 002 can be configured to receive packets from VAD 1 000 and transmit packets to network 1 0 0 3 . Next, the network 1 003 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, a packet implementation controller 1〇〇5, and a delay insertion controller 1〇〇 6. Delay the information module 1 〇 0 7. Bounce the computer 1 〇〇 8, and implement the delay computer 1 009. These components are described as follows: Packet buffer 1 004 can be configured to receive packets from network 1〇〇3, buffer packets, then send packets to jitter computer 008, delay insertion controller 1 006, and packet implementation controller 1〇〇5. The beat computer 1 008 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 1091. The delay insertion controller 1 006 can receive the jitter size information from the jitter computer 1008 and can receive the packet from the packet buffer 1 004. 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 1 007 can be configured to integrate information about the timing of the insertion delay from the delay insertion controller 1 006 and the size of the delay from the implementation delay computer 1 009. Therefore, the delay information is -43-200814679 Module 1 007 can establish integrated information into the data structure and send the data structure to the packet implementation controller 1 005. The packet enforcement controller 1 005 can be configured to receive packets and insertion delays from the packet buffers 〇〇4 to the packets based on the data structure received from the delayed information module 007. 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. The transmitter side processing begins in step 1 060, in which the speed buffer 1 (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 062, the speed buffer 1 设定 can set the flag bit of each packet to 〇 by default. When each packet reaches the last step 1 0 72, if the packet is the first voice packet that is spoken, the flag bit of the packet is set to 1. Otherwise, the marker symbol can be kept as 〇. In step 1 064, VAD 1001 may 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 0 74; if not, control transfers to step 1 066. In step 1 074, the VAD 1001 can determine if the SID 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, then control is transferred directly back to 1 072; if not set, then control is transferred to step 1 076 before moving to step 1072. In step 1076, VAD 1001 may generate a SID for the -44-200814679 packet. In step 1072, the transmitter 1002 (shown in Figure 10A) can transmit the packet to the network 1 0 0 3 . In step 1 066, 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 voice packet, then control transfers to step 1 072, in which the transmitter 1002 can transmit the packet to 1 〇 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 1092 shown in the example of FIG. 10A, the delay insertion controller 1 006 bounces the computer 1 00 8 , implements the delay computer 1 009 , and delays the information module 1 007. The delay calculation process can begin in step 1 022, where the packet buffer 1 004 can receive the packet from the network 1 003 and buffer the packet. For example, the packet may represent a packet transmitted by the transmitter 1 0 0 2 (shown in FIG. 10A) in step 1072 (not shown in FIG. 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 1028, the implementation delay computer 1009 can use j and v and the basis The network model represented by (j, v) calculates the implementation delay (ie, -45-200814679 delay d = f(j,v)). In step 1030, the insertion control is delayed: Whether the punch 1 004 is empty. If the packet buffer is transferred to step 1 〇 3 8 ; if it is not empty 1 032 ° In step 1032, the unsigned bit of the control 疋値1 is delayed. If one is set, you can move control to step 1 〇 3 8; if it is not 1034. In step 1 03 4, the delay insertion control has a SID. If there is a SID, the control shift has, and control moves to step 1 〇 3 6 . In step 1 03 6 , the delay insertion control j is greater than a preset threshold. For example, the length of this device 1 004. If the average jitter j is greater than the preset threshold 1 0 3 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 in step 1 040 , the controller 1 005 can be inserted. FIG. 1D is a conventional technology packet implementation control packet implementation control process, which may be used in the receiver side device 1 〇 92 of FIG. 10 A configuration, and may determine that the packet buffer 1 004 is empty. Control, then control moves to stepper 1 006 to determine whether the flag bit of ί 1 has been set, and the setting will control the shifter 1 006 to determine that the packet is transferred to step 1 03 8; 6 can determine that the average hop I threshold can be a packet buffer, then control moves to step 1 step 1 0 4 0. 1 007 can integrate the insertion delay L to step 1 0 4 0. The delayed information is output to the flow chart of the actual processing. Sealed as the first known technique [part of the processing of the device side. -46- 200814679 The packet implementation control process can be performed by the packet implementation controller 1 〇 〇 5 shown in Fig. 10A. 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〇〇4 (shown in FIG. 1A), and can receive the packet from the delay information module 10 7 (shown in FIG. 10A) receives information about the insertion delay as a 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 〇 4 . In step 1048, the packet enforcement controller 1005 can retrieve the packets from the packet buffer 1 〇 。 4. In step 1000, the packet enforcement controller 1 004 can implement the packets generated from steps 1 046 and 1 048.

Figure 10E is a schematic representation of the packet stream received by the packet buffer benefit 1 〇 〇 4 when the transmitter side VAD 1001 (shown in Figure 10A) is turned on. As shown in the example of FIG. 10 E, the received packet stream may include a voice packet 1080, a voice 1084 behind the voice packet 1 〇 80, a voice packet 1 0 8 6 following the silence 1084, and a voice packet. 1 〇 8 6 behind the silent 1〇88 and so on. Silent 1084 and Silent 1088 indicate the time period during which the packet enforcement controller 1〇〇5 has not received the voice packet. Since vaD-47-200814679 1001 is turned on, the VAD 1001 has set the sign bit of the first voice packet such as packets 1080a and 1086a to 1. The steps shown in Figure 1 〇 c can be used in 1 0 3 2 to determine when to insert the delay. In addition, the VAD 1001 inserts the SID 1082 at the beginning of the silent 1 084 and inserts the SID 1090 at the beginning of the silent 1088. SID 1082 and S ID 1090 can also be used in step 1034 shown in Figure 10C to determine when to insert a delay. Figure 10F is a schematic representation of the packet stream received in the packet buffer 1 〇〇 4 (shown in Figure 10A) when the transmitter side VAD 1001 (shown in Figure 10A) is turned off. Because existing algorithms used in VAD 1001 generate unwanted noise or abrupt speech during music playback, VAD 1 00 1 is normally turned off by the packet communication service provider and therefore cannot provide information about voice activity. . As shown in the example of FIG. 10F, the received packet stream includes a voice packet 1092, a silent packet 1094 connected behind the voice packet 1092, a voice packet 1 096 connected to the silent packet 1 094, and a voice packet 1096. The latter silent packet 1 098 is not inserted because the VAD 1001 is turned off, so the SID is not inserted for the silent period represented by the silent packet 1 094 and the silent packet 1 098. As a result, the step 1 03 4 shown in Fig. 10C is not performed (i.e., the SID is detected). In addition, although voice packet 1 092a has a sign bit 値 of 1, all remaining received packets have a 标示 sign bit 値. Therefore, step 1 032 shown in FIG. 10C is not executed (ie, it is determined whether the flag bit 第一 of the first -48-200814679 packet is set to 1). In addition, when the VAD 1001 on the transmitter side 1091 is turned off, the packet buffer continually enters the packet buffer 1 〇〇 4 ' on the receiver side 1 092 so that the packet buffer 1 004 is never empty. Therefore, depending on the visual design, step 1300 shown in Fig. 10C is not executed (i.e., it is determined whether the packet buffer 1 004 is empty). Therefore, when the VAD 1001 is turned off, the delay insertion control 1〇〇6 cannot perform steps 1〇3〇, 1 03 2, and 1 034 for the timing of determining the insertion delay. Although in step 186 shown in Fig. 10C, the delay insertion controller 1 006 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 voice communications. Moreover, even if the existing VAD algorithm of the VAD 1001 is turned on, the VAD 1001 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 1A is a block diagram of a receiver-side device 1 1 0 0 of a second conventional technology packet voice communication configuration (second prior art configuration) including an adaptive buffer overflow controller. As shown in the example of Fig. 1 1 A, the receiver side device 1 1 〇〇 includes the components of the receiver side device 1 092 in the first prior art configuration shown in Fig. 1A. Further, the receiver side device 1 1 〇〇 includes an additional component 1 1 800. The add-on component 1 1 8 0 may include a decoder 1 1 18, a silent detector 1 1 16 , and a buffer overflow controller 1 1 1 4, as described below: 49- 200814679 The silent detector η 16 can be The composition is configured to detect silence in the packets received from the decoder η 18 . 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 1 1 1 6 can set the silent flag to 0. The buffer overflow controller 1 1 1 4 can be configured to monitor the state of the packet buffer 1 1 02. Based on the state of the packet buffer 1 102, the buffer overflow controller 1 1 1 4 can decide whether to drop or hold the next packet received in the packet buffer 1 1 〇2. Fig. 1 is a flow chart of the silent detection processing used by the receiver side device 1 1 0 0 shown in the example of Fig. 1 1 . The silent detection process is started in step 1 120. In this step, the decoder 1 1 18 (shown in FIG. 11A) can decompress the voice received from the packet implementation controller 1104 (shown in FIG. 11A). Packet (package). In step 1 1 2 4, 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 moves 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 is transferred to step 1 1 2 6, in which the silent detector 1 1 16 sets the silent flag 〇 to 〇. In step 1 1 2 8 , the silent detector 1 1 16 can output a silent flag 値. Fig. 1 1 C is a flowchart of the buffer overflow control process used in the receiver side device 1 1 〇 所示 shown in the example of Fig. 1 1A. 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 1 1 3 2, in which the buffer overflow controller 1 1 14 receives the silent flag from 1116 (shown in FIG. 11A). In step 143, the buffer overflow control 1 Π 4 rusher 1102 (shown in FIG. 2A) has reached the first 〇〇%〇〇% and the like. If the packet buffer 1 102 has reached the first approach, the process proceeds to step η 44; if not, the control moves to the step in step 1 1 44, and the buffer overflow controller 1 1 buffer 11 02 discards the most recently received Packet, regardless of whether the packet indicates a voice packet. The buffer overflow controller causes the packet buffer 102 to provide the packet to be implemented. In step 1 1 3 6 , the buffer overflow controller 1 1 buffer 1 1 02 has reached the second critical, such as just after the packet buffer 1 1 02 has reached the second critical, then control < 1 1 40; If not, control transfers to step 1 1 3 8 . In step 1 1 40, if the silent flag received by the buffer overflow controller 1 1 acoustic detector 11 16 is 1 or not, then control transfers to step 1142; if not to step 1 1 3 8. In step 1 1 42, the buffer overflow control 1 1 i 4 buffer 1 102 discards the most recently received packet because it is silent recently. The buffer overflow controller 1 1 1 4 can also provide a packet to be implemented. Control then shifts to step In step 1 1 3 8 , the packet buffer 11 0 2 can be wrapped. The silent detector can determine the packet mitigation, such as just the boundary, then control the shift 1 1 3 6 ° 1 4 can command the packet. The most recently received 1 1 1 4 can also be ordered 1 4 can determine the packet is 80%. If you move to step 1 4, you can decide to go from none. If there is no voice flag, then the control transfer can command the packet to be buffered to receive the packet buffer step 1 1 3 8 . Receive and Buffer Seal -51 - 200814679 The buffer overflow control processing shown in the example of Figure 1 1 C is invalid for maintaining service quality. For example, when the packet buffer 1 102 reaches the first threshold, for example, exactly 100%, the voice packet can be discarded according to step 1 1 4 4 . Therefore, a mutant speech is generated. In addition, when the packet buffer 1 102 reaches the second threshold that is not the first threshold, such as, just not exactly 100% of 100%, the packet buffer 1 1 02 still receives the packet buffer 1 1 〇 2 The remaining capacity of the large voice packet data set. As a result, the overflow still occurs, and packets (including voice packets) that exceed the capacity of the packet buffer 1102 are still lost. As a result, the quality of service is not what the recipient wants. Figure 12A 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 1 208, a decoder 1210, a delay insertion controller 1214, and a delay information. Module 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 - 52 - 200814679 packet) via link 1 299 to the delay insertion controller 1214. The package or components may be packaged in software downloaded to the receiver side device 1 200. One or more components of the receiver side device 1 200 may have the capability of a component similar to the receiver side device 1 1 所示 shown in FIG. However, the silent detector 1 1 1 6 of the receiver side device 1 100 is instead, the silencer 1 2 1 2 can be configured to determine when to insert a delay in processing the jitter to control the packet buffer overflow, or in addition to the control packet The buffer overflow is added to this function. In addition, contrary to the delay insertion controller of the receiver side device 1 00, the delay insertion controller 1 2 1 4 can receive information from the silent detection 1 2 1 2 instead of the receiving jitter computer in the prior art jitter buffer design. 1 204 information. Delay insertion controller 1214 can directly couple acoustic detector 1212 via link 1 299. Link 1 299 can represent a direct logical link or real path. A chain between the delay insertion controller 1108 and the computer 1110 shown in the example of FIG. 11A and the dynamic computer 1 00 8 and the delay insertion controller 1 006 shown in the example of FIG. 10A Conversely, there is a direct logical or physical connection between the jitter calculation 1 204 and the delay insertion controller 1 2 1 4 . Fig. 1 2B is a diagram of a delay insertion control process for adaptive processing utilized in the receiver side device 1 200 shown in the example of the drawing according to one or more embodiments of the present invention. The delay insertion control process is in step 1220, in which the insertion controller 1214 is delayed (Fig.

In addition, the image buffer 1 202 (shown in Figure 12A) can be determined by the 1108 detector from the jump of the body chain jump 1099 and the 12A beat start 1 2 A -53- 200814679. When is the empty packet, that is, there is no packet containing the implementation. If the packet buffer 1 202 is empty, then control transfers to step 1 228; if not, control transfers to 1 222 °. In step 1 222, the delay insertion controller 1214 may determine to pass the packet buffer. 1 202 receives the marked symbol bit of 値1 in the incoming packet. If there is a SID, then control transfers to step 1228; if there is no S ID, then control transfers to step 1 2 2 6 . 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, control can be transferred to step 1 2 2 8; if not 1, control can be moved to step 1 2 3 0. In step 1 228, the packet implementation controller 12〇8 (shown in FIG. 12A) can be inserted according to the delay information module 1 2 1 6 (the information received by the delay shown in FIG. 1 2 A (eg, silent packet or comfort) The noise packet, etc.) arrives at the incoming packet to produce an adjusted packet. The delay information includes implementing the size information provided by the delay computer 1 6 6 (shown in FIG. 3A) and delaying the timing information provided by the controller 12 14 . In 1 2 3 0, the packet implementation controller 1 2 〇 8 may 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 2 0 0. As shown in FIG. B It will be understood that in general, according to one or more embodiments of the present invention, that is, any information received from the beating computer 1 204, the delay insertion controller 1 2 1 4 can still be based on the slave silent detector 1 2 1 2 (in Step 1 2 2 6) -54- 200814679 The received silent flag determines the timing of the insertion delay. FIG. 13 is a packet video communication using the adaptive jitter processing according to one or more embodiments of the present invention. A block diagram of the receiving side device 1 300 of the system. The receiving side device 1 300 can represent at least one of a telephone, a mobile phone, a teleconferencing 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 may include a component that performs functions similar to those of the components of the receiver side device 1 200 shown in the example of Fig. 3A. Receiver side device 1 3 0 0 may include a packet buffer 1 3 0 2, a beat computer 1 3 04, a compensation controller 1314, a compensation computer 1 3 06, a compensation information module 1 3 1 6 , a packet implementation controller 1 3 0 8 , a decoder 1 3 1 0, and one or more of the video 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 1 3 1 4, and the compensation information module 1 3 1 6 can be combined to calculate and integrate the video compensation information to replace the information that is assembled into the calculation and integration delay insertion. Video compensation can include stopping the broadcast while repeating the video frame A new video frame, and can be executed by the packet implementation controller 1 3 0 8. Similar to the configuration of the receiver side device 1 200, the compensation controller 1 3 1 4 can be directly coupled via link 1 3 9 9 The video detector 1 3 1 2 determines the timing of the video compensation. The video compensation control for the jitter processing of the receiver side device 1 300 0-200814679 handles the delay insertion shown in the example of FIG. The control process is similar. One or more embodiments of the present invention include a receiver side device that includes a configuration similar to the configuration of the receiver side device 1 300 and is configured to process multimedia communications including voice and video Bounce in the middle. 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 insertion control instead of using only receiver side silent detectors for buffer overflow control, embodiments of the present invention can accurately insert delays without the need to insert delays into speech packets. Advantageously, the mutated speech can be reduced to ensure speech quality. Additionally, embodiments of the invention may 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 through SIP that will effectively transfer information between the server and the user and will be unaffected by 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 OS: Protocol (DDP) structure and format is DDP does not know the server or mobile hardware platform and on both platforms The operating system executed on it. 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 supported by the Operating System/SW platform. 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. Decoupling from control plane protocols: DDP has been framed 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. Not subject to media: The agreement is not subject to the media that connects users to the server. Dialogues are available 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, 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, providing 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. Ii. 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 the delivery of DDP messages, depending on the application requirements. V. DDX (Divitas Data Transfer) Module: A module that uses DDP to transfer files and data buffers between the same layer. The DDX module will operate without the control of the file format or buffer content and has an organization for error checking and shipping confirmation.

Vi. DDPS: A module in DDP that encrypts and decrypts DDP content before inserting DDP into the envelope. 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, D D P 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 DDP message being transmitted, each DDP message includes a set of command columns or fields and any columns or fields. If the command line is missing, the parser will reject the DDP 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: ν = 0·0·0· 1 o=server r = data 2 c=ext 4444 -59- 200814679 c = pref cell wifi gprs sms wka 5 cka 10 pwd 1200 whys 20 chys 60 c = wifi rssilo 30 rssihi 60 chlo 30 chhi 50 c = qos delaylo 50 del ay hi 10 0 losslo losshi 10 j itterlo 30 jitterhi 50 c = srv intip 1 0234 1 4444 extip- 1 3 43 245 03 2 c = end Then add DDP The message is treated as the message body in the SIP message with the message body type of "application/ddp" or "application/ddps". The DDP body can be sent with other delivery protocols if needed. 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 action decision. The WiFi 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 movement of the predictive handset. In addition to automating updates based on WiFi 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 control and massive transfer messages used by users: -60 - 200814679 a. Device configuration: Once the device/user has been authenticated, the device-specific group is sent during startup. State to device. b. Mobility Critical: Activate the mobile activity based on the WiFi threshold set by the administrator to the user. c·User Information: When the user logs in to one of the users, the server pushes the user-specific information (eg, extension, preference, etc.) through D D P. d. Device image management; using DDP's massive transfer capability to achieve the ability to upgrade mobile software via a network connection. Downloading Voicemail/Email to your phone: One of the main differences between the D i v i t a s 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 amount of transfer capability in the DDP that transfers voice mail to the mobile phone. A similar function can also be achieved for an email system that can establish an adapter module to interface with a selected email system. User attendance management: Deliver DDP messages with user preferences through voice and content from different media 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 designed to provide service calls based on enhanced attendance and user preferences all through DDP. 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. -61 - 200814679 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 to download the software through 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 1404 and the application server 1402. 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 1402 can send a TCP SYN-ACK (TCP synchronization response) back to the application user 1404. 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 1 404 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 1 402 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 transmitting the requested software as a data packet (e.g., TCP data segment) 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 processing. -62- 200814679 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 1 402 °. The requested software can be sent by the application server 1402. Before downloading all the data packets to the application user 1 404, repeat steps 1418 and 1420 °. Once all TCP data segments have been sent, in the next step 1422, the application server 1 402 can send an HTTP 200 OK to the application user. 1404. Upon sending an HTTP 200 OK, the application server 1 402 notifies the application user 1 404 that all data packets for the software download request have been sent. Once the application user 1 4 0 4 has received each data packet, the application user 1 404 can send a notification 1 424 to the user informing the user that the download has been completed. For each application user on the mobile phone, the method described in the telephone flow of Figure 1 must be performed by each application user. In this case, if the mobile phone includes multiple application users (eg, video application users, voice application users, instant messaging application users, game application users, virtual reality application users, etc.), then the application users and applications Before the interaction between the application servers begins, an independent channel must be established between each application user and its corresponding application server. Since multiple applications are executed on the user, communication between different applications cannot be guaranteed. As a result, an application executing on a particular user fails to notice that another application is being exchanged for data on the same user. -63- 200814679 In addition, the method illustrated in Figure 1 is a cumbersome method that requires the appropriate application of each application on the home to ensure that the application can interact with its corresponding application on a designated server within the enterprise. . Individual applications that communicate between the user and the server require separate conversations, so this approach creates security risks and adds complexity. In one aspect of the present invention, the inventors herein are implemented without hardware (eg, mobile phones) and software (eg, video application user application users, instant messaging application users, game application users, virtual A real-world application web user conversation dominated by a single application. In other words, the inventor realizes that the application user does not need to establish multiple networks with the corresponding application server. Instead, the existing control and transport protocol can be used to implement the protocol and the agreement is independent of the software and the hardware, thereby enabling 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 (DDP). In an embodiment, the DDP DDP user and the 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 applications within the enterprise. Embodiments of the invention are in turn capable of being implemented without the control of hardware and software platforms. In an embodiment of the invention, the DDP is not subject to the hardware platform. DDP can be implemented on dual mode handsets, personal digital assistants (P D A s), 802.11, and the like. In an embodiment of the invention, the DDP is also not subject to the platform. As a result, it is possible to use the Linux® system and the Symbian® system for network usage and language programming. The protocol is included in the servo DDP. Such as telephone software system, -64- 200814679

DDP is executed on the Window TM Mobile 5.0 system. In the prior art, the establishment of multiple network conversations requires the creation of multiple channels between the user and the server. In other words, multiple “holes” must be “pierced” within the corporate firewall to enable multiple application users to interact with their corresponding application servers. In an embodiment of the invention, DDP can be implemented to establish a single secure channel that enables interaction between application users on the handset and application servers within the enterprise. The information downloaded to the phone can be managed by the application user with a single secure channel that exchanges multiple data traffic. As such, application users who need to utilize the downloaded information do not have to request to download the data again. Instead, an active user with DDP can direct the application user to where the requested data is stored. In an embodiment of the invention, the DDP may be unaffected by the network. In an example, the secure channel established by the DDP can be via a Wi-Fi network or a cellular data network, for example. This allows DDP to ensure that network conversations are delivered to separate networks when users on the user device roam. In an embodiment, the DDP is built on top of the control protocol and transport protocol. In an embodiment, the DDP can be implemented using any available control protocol (e.g., SIP, H.23, etc.). In another embodiment, the DDP can be implemented using any available transport protocol, such as User Data Element Agreement (UDP), Transmission Control Protocol (TCP), or Transport Layer Security Protocol (TLS). As such, DDP can efficiently route data packets and manage connectivity without having to worry about available control and/or transport protocols. In an embodiment of the invention, the DDP may include a reliability module -65 - 200814679 (RDDP) that ensures a reliable level of delivery of data traffic. Use this module when using transport protocols such as UDP that do not provide reliability. As such, DDP provides a guarantee of successful transmission and relieves the burden of monitoring 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, DDP can be utilized by an application with instant data exchange requirements. Due to the adjustability of DDP, 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. The D D P can utilize the priority message scheduling module to automate the downloading and uploading of multiple applications required or required by the plurality of 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, the DDP 1536 can be implemented on a plurality of user devices, including but not limited to, dual-f mobile phones, PDAs, laptops, and the like. In another example, D D P 1 5 3 6 can be implemented with a different operating system such as a Linux® system, a Symbian® system, a WindowTM Mobile 5.0 system, or the like. As a result, the DDP 1536 can be loaded onto different hardware and/or software platforms with minimal modifications. -66- 200814679 DDP 1 5 3 6 can be established at the top of the control agreement and transport agreement. In an example, it can be combined with different control protocol types (eg, SIP 1 5 3 2 and another control protocol 1 524) and different transport protocol types (eg, UDP 1534, UDP 1528, TCP 1530, TCP 1526, etc.) Use DDP 1536. The type of control protocol and/or transport protocol that may be utilized by DDP 1536 to perform the functions of DDP 1536 may be readily accommodated by the DDP. Thus, if the control agreement and/or transmission agreement changes, DDP 1 5 3 6 will be able to utilize itself any combination of available transmission 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 1 504, the plan management application 1 502, and the voice mail. /Email transmission application 1 508, 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 the DDP 1536, 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 1 5 18, and a reliable DDP. Module (RDDP module 1 5 1 6 ), built-in dialog management module 1 5 20, and Divitas data exchange module (DDX module 1514). • 67- 200814679 In an embodiment, the D D P S module 1 5 2 2 can provide a security function to the 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 a 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 1522 can include a database that includes authentication data needed to establish a connection between an application user and an 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, the 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 522 to encrypt data packets sent between IM users. In an embodiment of the present invention, the DDP 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 a 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 an embodiment, the -68-200814679 preemptive message scheduling module 1 5 1 8 can establish a policy for processing incoming and outgoing data packets. In one embodiment, the priority message scheduling module 1 158 may have different priority levels depending on the source application. In the example, application A (eg, 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 information scheduling module 1 158 may be any DDP module. In one example, if the DDP 1536 currently only processes data traffic for an application, the DDP 1 5 3 6 does not have to use the priority message scheduling module 1 5 1 8 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 1516) that provides assurance of the positioning of one of the plurality of data packets. In one embodiment, to warrant shipment, 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 the preset time interval, the packet is retransmitted. The packet can be retransmitted a specific 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 an embodiment, DDP 1 5 3 6 may include a DDX module 1514, which

Can be used to transfer large amounts of data (eg, image files, log files, etc.) between mobile users and mobile servers. In an embodiment, the DDX module 1 51 includes a mechanism to ensure the integrity of the data transfer between the mobile user and the mobile server. In another embodiment of the present invention, the DDX-69-200814679 module 1 51 may include a mechanism for confirming completion of data transfer to the application. In the embodiment of the present invention, DDP can be implemented for multiple applications. 1 5 3 6 'Multiple applications include voice mobile control application 1 5 06, device management application 15〇4, planning management application 1 5 02 , 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 1512, etc.) are applications that are easy to send large files. The program, such that DDP 1 5 3 6 can utilize the DDX module 1514 to convert the file into smaller data packets that can utilize any other module within the DDP 1536 including 1516, 1518, 1522, and provide the data file that has been successfully transferred and Notify the application of the guarantee of completed transmissions. In the second group, the plurality of applications (voice activity control application 1506, device management application 1504, planning management application 1 502, 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 an example, the S-U-Action Controller 1 506 can enable mobile users and mobile servers to share an operative state that can be sent by a single DDP packet. Figure 16 is a diagram of how the data in the mobile architecture configuration with dDP in an embodiment is between the application user in the user device and the application server managed by the enterprise-70-200814679 industry. An example of the flow. Assume that the user on the user device wants to retrieve the voicemail from the voicemail server 1604 using the voicemail user 1 602. Upon receiving a request from application user 1 602, voicemail server 1604 can initiate a file transfer. The voicemail server 1 6 0 4 can send files 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 that is compatible with the control and transmission protocols of the secure channel. In one example, the server DDX module 1 608 can convert a dual format file into a format that can be transmitted via the SIP protocol. Furthermore, the server 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 the boot process is completed, the server D D X module 1 0 0 8 can send the first data packet to the server DDP 1 6 16 . In one embodiment, the server D D P 1 6 1 6 may include a DDP S 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 D D P 1 6 1 6 , the first data packet can be encapsulated as a SIP notification message (as shown in code example 3 70 of Figure 16B) and transmitted to the user device via the secure channel via the network 1 624. In one example, the first data packet can be sent via the secure channel by using the server SIP Control Protocol 1 620 and the Server UDP Transport Association -71 - 200814679. The first data packet is securely received by the mobile user of the user device that can receive the data packet via the user UDP transport protocol 1 626 and the user SIP control protocol 1 62 8 . Within the mobile user, the user D D P 1 6 3 2 can receive the first data packet. The user RDDP 1 63 4 can perform a similar check as performed by the server RDDP 1614. Furthermore, the user R D 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 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 R D D P module 1 6 1 4 does not receive the R D D P response, 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 the D D P response has been received. In one example, the server DDx module 1608 does not send the second data packet until the DDP 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 1680 can send a group of 1 data packets and wait until at least one response is received before the additional data packets can be transmitted. Once the mobile user has sent a D D P response to the mobile server, the routing data is encapsulated to the user D D X module 1 6 3 6 . In an example, the user D D X module 1 6 3 6 can protect the data packet from -72 to 200814679 before all data packets have been received. In one embodiment, the server DDX module 1 60 8 can send a message indicating that the data packet of the requested file has been sent and there is no additional file data packet to the upcoming message. Once all data packets have been received, the user DDX module 1 63 6 will reorganize the file and notify the voice mail user 1 602 to utilize the voice mail profile. 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 to have received all data packets, and no loss of data packets. In one example, the DDP architecture allows large files to be divided into smaller data packets that can be sent with a guarantee that the receiving side receives the response. 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 1724, 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 1 7 2 6 to the user S IP 1 7 1 6 via the server UDP 1712 and the user UDP 1714. Once the SIP registration has been successfully completed, the step of establishing a secure DDP channel is initiated. In the next step 1728, the user DDPS module 1718 (the module of the user DDP 1 720) 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 1708 will be sent via the server SIP 1 7 1 0, the server UDP 1712, the user UDP 1714, and the user SIP 1716. The DDPS dialogue responds to 1 7 3 0 to the user DDPS module 1 7 1 8 . 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. When the notification is received, in the next step 1 7 32, the application user 1722 sends a DDP registration request to the user/device manager 17〇4. 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 ι716, user UDP 1714, server UDP 1712, server SIP ι 710, and server DDPS module 1 708) Information to DDP 1 708, the latter then routes the registration information to 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 -74- 200814679 to server DDP 1 706. The server DDP 1 706 sends the registration information to the DDP 1 720 via the established channel (ie via the server DDPS 1 70 8 , the server SIP 1710 UDP 1712, the user UDP 1714, the user SIP 1716, the DDPS 1718), which then registers the response. Routed to the user of 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 started, it will be registered with the mobile server. Since the channels are full at steps 428 and 430, the user of the user device can ensure that the transmitted registration information has been encrypted and passed through the secure channel. In an embodiment, the secure channel between the home device and the mobile server is maintained without additional DDP registration. In one embodiment, the user device user and the application server managed by the enterprise can be securely implemented via a single secure channel. Figure 18 and] In an embodiment, an example of how DDP handles interaction between an application on a user device and an application server managed by the enterprise. Figure 18 is a consistent file that must be sent in a consistent application. Emotional phone flow chart. Assume that the user device needs to download the latest software. In one example, the application user 1 8 1 4 sends a software request 1 8 1 6 to manage the different software image manager 1 802 on the server side. In a first step 1818, the application user 1814 sends an image request to the image manager 1802. In an example, the security, the servo, and the user who first sent the request from the user application 1 8 1 4 to the user DDP 1 8 1 0 will establish the sensitivity of the DDP as a primary device. [9 Graphical User's Situation of the upgraded image of the new image of the new movie. After receiving a new image request at -75-200814679, the DDP 1810 can send a request to the server D D P 1 8 0 8 via the secure channel. Send to the image manager! Prior to 8 〇 2, new image requests can be routed to the device/user manager 1804 responsible for deciding which software to upgrade. After the device/user manager 1804 has determined which software upgrade the user device requires, the device user/manager 108 can route a new image request to the image manager 1 8 〇 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 8 06. 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 8 06 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 8 06 can send a DDX file transfer to the user DDX module 1812 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 to start responding to the server D D X 1 8 0 6 . In one embodiment, the RDDP module within the D D P can send a DDX to start responding. In the next step 1 826, the server DDX module 1 8 06 can send -76- 200814679 the first D D X data packet to the user D D X module 1 8 1 2 . As shown in Fig. 16. Generally, the DDX data message is first sent to the server DDP 1 8 08. In one embodiment, the DDX data message is encapsulated into a SIP notification message and sent over a secure channel via a SIP Control Protocol and a UDP Transport Agreement. On the user device, the DDX data message can be received by the user DDP 1810, and then the user DDP 1810 can route the DDX data message to the user DDX module 1 8 1 2 ◦ In the next step 1 82 8 , when receiving the DDX data message, The user DDP 1810 sends a DDP answer. 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 8 06 has successfully received the incoming DDX data message. Steps 1 826 and 1 82 8 are repeated steps that can be repeated until all DDX data packets and replies 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 may be sent from the server DDX module 1 806 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 1802. At the same time, the user DDP 1810 can route the DDX file transfer to the user DDX module 1812, which will notify the application user 1814. -77- 200814679 As can be seen in Figure 18, it is not necessary to establish a new secure channel in order to request a software upgrade. Instead, the application server receives and processes requests for software upgrades without having to establish a new secure channel. 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 192. In one example, the user presence manager 1 910 can send the presence preference (as a single DDP data packet) to the user DDP 1908, which then sends the presence preference settings to the server DDP 1 906 via the secure channel. When the attendance preference setting is received, in the next step 1978, 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 regarding attendance preference settings via the device/applicator manager 1 904. Suppose another situation in which the same user wants to find the presence status of another user. In a first step 1922, the user presence manager 1910 can send a 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 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 1 90 8 via the secure channel and the user DDP 1 90 8 then routes the presence response to the User Manager 1 9 1 0. As described above, Figures 18 and 19 illustrate examples of how DDP can be used to manage the difference between the interaction between the complex data application on the device and the complex application server 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 mobility architecture with DDP now coordinates the various activities that the phone's users have previously managed individually. In an example, FIG. 18 illustrates how to use the DDP management user on the user device to attend the secure enquiry 1904 requesting that the processor will present the DDP DDP attending the user program to the user of the mutual reliable receiving system. - 200814679 "Including software upgrades, device configuration, user information management, etc., but not limited to this. In another example, the DDP can manage the presence of the user by allowing the user to share their status (as shown in Figure 119), thus enabling 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 roam 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 protocols. 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 Figures 7A-D, mobile-based VoIP users act as servers for different applications executing on mobile phones. This component uses existing V 〇 IP-related connections (eg, SIP) to send application load across the enterprise-80-200814679 industry. The server side proxy component is responsible for removing the load and connecting to the actual enterprise server. The user and server side proxy components are further subdivided into multiple subcomponents. Each subcomponent is responsible for proxying an agreement. Figure 7A illustrates a network architecture in accordance with one or more embodiments of the present invention and each host includes two network interfaces. Two paths are provided via two separate networks, one from interface C0 to S0 and the other from C1 to S1. In SCTP, these two paths will be combined.

Divitas "weak users" use built-in power to monitor the combined path; when a path failure is detected, the agreement sends traffic through another path. The application does not have to know that a failed takeover restore has taken place. Failed takeovers can also be used to maintain network application connectivity. For example, assume that wireless 802 is included. 1 1 interface and Ethernet interface laptop. The higher speed Ethernet interface is more suitable when the laptop is in its docking station; however, when the connection is interrupted (away from the docking station), the connection should be failed to take over to the wireless interface. When returning to the docking station, the Ethernet connection should be detected and communication resumed via this interface. This is a powerful institution that provides high availability and reliability. In accordance with one or more embodiments of the present invention, multiple start-up plans are implemented to provide an application that is more usable than those using T C P. Multiple start-up hosts have more than one network interface host, so they have more than one IP address that can address multiple start-up hosts. In TCP, a connection means a channel at both ends (in this case, a socket between the interfaces of the two hosts). 7B-D illustrates how the weakening of the interconnect with the weak user on the server in accordance with one or more embodiments of the present invention effectively establishes information for transport status between the handset and the server. An efficient transportation agency. 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 2 000 may include a plurality of application users including Divitas User 2002, CRM (Customer Relationship Management) application user 2 0 0 6 , and mail application user 2 0 0 8, but 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. The plurality of application servers include a Divitas server 2022, a CRM application server 2026, and a mail application server 202, but are not limited thereto. The application server can interact with each other independently or through the 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 002. Despite talking to their users, stock brokers want to get their users' portfolios at their fingertips. In this case, the stockbroker must establish two different conversations. Stockbrokers can establish a first conversation to enable them to talk to their users through Divitas User 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 the mail application server located in the corporate firewall, the network administrator must establish a new secure channel. Thus, in a typical SSL VPN environment, the user must establish multiple sessions, which require multiple start communication commands and make the enterprise more vulnerable to security risks. The SSL VPN environment is not only inconvenient for the user, but also requires more types of this environment. More human resources to manage the security of the corporate network environment. In order to minimize the number of secure channels established, the Internet can be replaced by the Internet-83-200814679 Protocol (IP) Security Gateway. In an IP-secured 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 2084 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 secure channels and re-authentication must occur each time the session 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. -84- 200814679 Assume that the user of the mobile phone 2000 wants to use the mail application user 2008 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 2028 within the enterprise. In the next step 2104, the electronic data stream is received by an IP Security Client 2014 that can check to determine how to route traffic. In other words, IP Security User 2014 can analyze individual packets to determine if the packet is a packet that 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 servers in the enterprise 2090, then in the next step 2106, the IP security user 2014 may discard the traffic or direct the email traffic to the server that is not in the enterprise 2090. Device. How to handle email traffic that is not the application server within enterprise 2090 depends on how IP security users are 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 the case of voice communications, such as VoIP (v〇ΙΡ) communication conversations. In other words, the speech quality during a 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 2 0 1 4 can send encrypted traffic to Enterprise 2090's IP Security Gateway 2030 via Network 2 0 50 and Firewall 2 0 4 0. In the next step 21 12, the IP security gateway 203 0 performs a check to determine how to route traffic. Similar to IP Security User 2014, IP Security Gateway 203 0 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 1 8 'IP security gateway 203 0 forwards the data packet to the appropriate application server (eg, mail application server 2 0 2 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 of the phone added to the -86-200814679 user must be configured differently. When adding new application users, the management of various application users and their corresponding application servers leads to a more complex relationship-building network environment, which is costly to maintain. Furthermore, the user must be responsible for performing multiple authentications. This requires the user to remember the plural authentication information. In addition, the benefits of operating within 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 increased potential. In addition, the user will be frustrated by the limited mobility provided, and each time the conversation 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, a mobile architecture configuration is provided by implementing a Divitas Protocol Proxy Servant (DPP). In an embodiment, the DPP includes a user D P P and a server D P P . In an embodiment of the invention, the handset may include an active user (eg, a Divitas user, which may include a user DPP to manage connectivity between the handset and the mobile server (eg, Divitas server) In an embodiment of the invention, the mobility server may include a server DPP to manage connectivity between the mobility server and the handset. In an embodiment of the invention, the user and server DPP may include a plurality of sub-users. /Server DPP to manage different protocol types (eg, SIP, SMTP, etc.) In an embodiment of the invention, DPP can create a single secure channel from each application user interacting with its corresponding application server. The program is routing its data traffic via a common DPP, so DPP can now manage connectivity between mobile phones and mobile servers. Connectivity information can include establishing mobile and mobile servers through control protocols such as SIP (Dialog Initiation Protocol). A secure channel between. Connectivity information can be used to determine when and how to connect the phone. In addition, connectivity information can also include Perform communication from one network to another (eg, from a Wi-Fi network to a cellular network) so that it can seamlessly change between different networks. Refer to the following diagram and discussion for more information. The features and advantages of the present invention are apparent. Figure 22 is a simplified block diagram of a mobile architecture configuration in an embodiment of the present invention. In the mobile architecture configuration 2200, the mobile phone 2202 and the D ivitas server 2 in the enterprise 2 2 16 2 1 8 (eg, mobile server) interaction. Mobile 2 2 2 2 may include D ivitas users 2 2 0 4 (eg, mobile users) and plural application users (2206 and 2208). Implementation in the present invention In the example, the Divitas user 2204 can include the user DPP to manage the connectivity between the mobile phone and the mobile server. Unlike the prior art, the application user 2206 and the application-88-200814679 user 2208 are not directly configured. Interacting with their corresponding application servers (2220 and 2222). In one embodiment, the various configurations for each application user can be simplified to direct all data traffic to Divitas. The single area IP host 22 10 associated with the subscriber 2204 (eg, 127. 0. 0·1 IP address). In other words, data traffic from application users 2206 and 220 8 can now be configured to be routed to DiWtas 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 i v i t a s server 2 2 1 8 has received the data traffic, the D i v i t a s server 2218 can properly route traffic to the corresponding application servers (2220 and 2222) via APIs (223 2 and 2234). Assume that the user of the handset 2202 wants to send an email by utilizing the application user 2 206. 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 22 04. 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 a 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 traffic 89-200814679. 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 221 8 along the security channel 2250 including the traversal network 2 2 2 4 . It should be noted that if the enterprise is protected by one or more security modules (eg, firewall 222 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 2218 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 22 20) in the enterprise is the desired data packet. Receiver. 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 establish another security every time the application user (2206 and 2208) wants to interact with the application server (2220 and 2222). aisle. In an embodiment, the mobile architecture configuration may also include a database, and the -90-200814679 database includes authentication 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' generally makes time and effort efficient, and network managers 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 23 is a block diagram showing the configuration of an active architecture 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 application configuration, etc.). Assume, for example, that the user of the mobile phone 23 02 wants to retrieve the mail application server 23 26 (eg, Micro so ft® Exchange server, etc.) from the enterprise 2318 by using the mail application user 2310 (eg, Microsoft® Outlook, etc.). ) The situation of the email. Figure 24 - and Figure 23 will be discussed. Figure 24 is a simplified flow diagram of an example of a method for utilizing an active architecture configuration in the embodiment of the present invention. In a first step 2402, the application user sends data traffic to the regional host of the Divitas user. In the mobile architecture configuration, the application user 2310 has been configured to route its data traffic via the regional host 2300 in the Divitas user 2304. In one example, the application user 2310 can send an SMTP (Simple Mail Transfer Protocol) data packet 2312 to the Divitas User 2304 over TCP-IP. The SMTP data packet 23 1 2 can be received by the 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 1 . 0. 0. 1 / 25. In this case, the number 127. 0. 0. 1 is the IP address unique to the regional host 2 3 0 8 , and the number 25 indicates the 埠 number associated with the SMTP proxy user 23 06 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 2304 reformats the SMTP data packet 2330 into a SIP data packet 2330 (such as SIP Notify Message, etc.) that can be transmitted via a control protocol such as a SIP mobile phone. In an embodiment of the invention, the SIP data packet 23 30 includes a source data packet (e.g., data packet 2 3 1 2) having a DDX header 23 3 0a and a SIP header 23 3 0b. As mentioned above, the D D X header includes an application server-specific special-92-200814679 with an identification number. In an embodiment of the 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 an example, the transport agreement label 23 3 0c may be a UDP-IP transport token. 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 pass through the secure channel 23 50 via the network 23 14 and/or the firewall 23 16 Send SIP data packet 23 3 0 to Di vitas server 23 20. In the next step 2408, the Di vitas server can check to determine if the incoming data packet is a SIP Notify Message. If the incoming data packet is not SIPNotifyMessage, 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 a 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 2320 knows the routing data packet 2330 to the SMTP generation -93-200814679 server 2322. In an embodiment of the invention, the server DPP may comprise a plurality of sub-servers DPP. In an embodiment of the invention, the type of proxy server that handles incoming traffic is a type of data traffic. In the next step 24 1 4, the data packet can be routed to the proxy server. Since the SIP data packet 23300 is an SMTP data packet, the formatted data packet (e.g., sub-server D P P) 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, the SIP data packet 23 3 0 can be converted from a SIP Notify Message to an SMTP data packet 23 2 8 . 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 via API 23 3 2 (eg, mail application server 2326). The illustrated method steps do not illustrate the encryption and/or decryption of the data packet. 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. Undesired encryption reduces the processing power to be utilized and reduces the underlying factors typically associated with encrypted data packets. As can be seen from Figures 23 and 24, in general, the rich mobility architecture configuration can be used as an mobility manager that enables mobile phone application users to interact with the application server in a single communication command environment. 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 25 00 wants to call a friend. Users can make calls using the phone application user 25 08 (eg, VoIP, etc.). It is assumed in this example that a secure channel 2550 has been established between the DiWtas user 2502 and the Divitas server 2518 located within the enterprise 2530. To establish a telecommunications conversation, the telephony application user 25 08 can send a data packet 2512 (e.g., SIP/UD-IP) to the regional host 2510 within the Divitas user 2502. As noted above, multiple proxy users can reside within the 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 埠 number (eg, 5060, etc.). Using this information, Divitas user 2502 can route data packet 2512 to Divitas server 25 1 8 via network 2514 and firewall 2528 via -95-200814679. In one 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 the format that Divitas User 25 02 can use to route its data traffic. In an embodiment, the plurality of proxy servers can reside within the Divitas server. In an example, SIP proxy server 25 32 can reside within Divitas server 25 18 to manage the incoming traffic from the phone application user 2508. Since the data packet 25 12 has been sent from the phone application user 2 5 0, the data packet is processed by the SIP proxy server 25 3 2 . When receiving the data packet 2512, the SIP proxy server 25 32 can forward the data packet 25 1 2 to the destination telecommunications device (e.g., telephone) via the telephone gateway 2520 (e.g., PSTN, GSM, CDMA, etc.) along path 2522. Wait). Once a telecommunications conversation has been established between the handset 25 00 and the destination telecommunications device, other data packets 25 3 0 (eg, RTP data packets, etc.) sent by the telephony application user may follow the path via the secure channel 2 5 5 0 The 2560 is sent to the Divitas server 2518 without having to go through the Divitas user 2502. 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 servers can share their connectivity status and be able to handle roaming seamlessly. -96- 200814679 In the example, the users in the above case are currently connected via a Wi-Fi network. During a telephone conversation, the user 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-) without the user being aware of the changes. Fi to the cellular 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 an environment for a single start of 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. With an environment that starts with a single communication command, the cost and effort of managing a telecommunications infrastructure can be greatly reduced. In addition, the mobile architecture configuration can monitor and seamlessly handle connectivity without negatively impacting the user's telecommunications experience. F. The present invention has been described with reference to a few preferred embodiments, and modifications, alterations, 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 embodiments of the present invention can be found in other applications. For convenience, -97- 200814679 This article provides abstract commemoration, which is limited to the convenience of reading and is not intended to limit the scope of patent application. Therefore, the scope of the following appendices should be construed to include all such modifications, alterations, and equivalents in 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 a return canceller based on encoding/decoding benefits, 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 hopping 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. Figure 6B is a diagram of a DDP message exchange in accordance with one or more embodiments of the present invention. Figure 7A is a diagram of a network architecture for each host including two network interfaces and fabricated in accordance with one of the 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. Figure 10A is a block diagram of a first exemplary prior art packet voice communication system (first prior art configuration) with an adaptive jitter buffering scheme. Figure 10B is a flow diagram of transmitter side processing for a conventional technique bounce buffering scheme for the first prior art configuration shown in the example of Figure a. -99- 200814679 Figure 1 0C 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. 10F 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 1 A is a block diagram of a receiver side device of a second conventional technique packet voice communication system (second prior art configuration) including adaptive buffer overflow control. Fig. 1 1 B is a flow chart for the silent detection processing 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. 11A. 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. 1 2B is a diagram of a delay insertion control process utilized for the adaptive jitter processing of the receiving side device shown in the example of Fig. 1 2 A 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. 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 the information in the mobile architecture with DDP in the embodiment flows between the application user located in the user device and the application server managed by the enterprise. Figure 16B is a diagram showing an example of a code of a encapsulated 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 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. -101 - 200814679 [Explanation of main component symbols] 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 : Action exchange Center 120: Media Gateway 122: Public Switched Telephone Network 1 2 4: Conventional Public and Private Telephone 1 3 0: Private Branch Switch 1 3 2: Router 1 3 6: Telephone 1 3 7: Telephone 1 3 8: Internet Protocol WAN 1 4 0: Router 1 4 2: Firewall 1 4 4: Internet 1 5 0: Mobility Server 1 6 0: Access Point 1 8 0: Access Point 800: Conventional Technology Communication device 802: signal receiver 806: speaker-102- 200814679 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 9 0 0: communication device 904: signal receiver 906: background noise remover 90 8 : echo path 9 1 0 : identification code injector 914: speaker 916: microphone 922: identification code generator 924: identification code detector 926: Buffer 928: delayer 93 0 : sum function 93 2 : signal transmitter 1 速度: speed buffer 1001 = language Activity detector 1 0 0 2 : Transmitter 1 0 0 3 : Network 1 004 : Packet buffer -103- 200814679 1 0 0 5 : Packet implementation controller 1006: Delayed insertion controller 1 007 : Delay information module 1 〇〇8: Bounce computer 1 009: Implement delay computer 1 0 8 0: Voice packet 1080a: Packet 1 〇 8 2: Silent descriptor 1 〇 8 4: Silent 1 0 8 6 : Voice packet 1086a: Packet 1 0 8 8 : Silent 1 090 : Silent Descriptor 1091 : Transmitter Side Device 1 092 : Receiver Side Device 1 092a : Voice Packet 1 〇 9 4 : Silent Packet 1 0 9 6 : Voice Packet 1 09 8 : Silent Packet 1100 : Receive Device side device 1102: packet buffer 1 104: packet implementation controller 1 1 0 8 : delay insertion controller 1 η 〇: jitter computer -104 - 200814679 1 1 1 4 : buffer overflow controller 1 η 6 : silent Detector 1 1 1 8 : Decoder 1 1 8 0 : Add-on 1 1 9 9 : Link 1 200 : Receiver side device 1 2 0 2 : Packet buffer 1 204 : Bounce computer 1 206 : Implement delay computer 1 2 0 8 : Packet implementation controller 1 2 1 0 : Decoder 1 2 1 2 : Silent detector 1 2 1 4 : Delayed insertion control 1 2 1 6 : Delay information module 1 2 9 9 : Link 1 3 00 : Receiving side device 1 3 02 : Packet buffer 1 3 04 : Bounce computer 1 3 06 : Compensating computer 1 3 0 8 : Packet implementation control 1 1 1 1 : decoder 1 3 1 2 : video detector 1 3 1 4 : compensation controller 1 3 1 6 : link compensation information module 105 200814679 1 3 9 9 : link 1 402 : application Server 1 404: Application User 1 406: Software Download 1424: 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 : Voice Mail/Email Transfer 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 Group 1 5 1 8 : Priority Message Scheduling Module 1 5 2 0 : Built-in Dialogue Management Module 1 5 22: Davista Description Protocol Module with Security Extension 1 524: Control Protocol 1 5 2 6 : Transmission Control Protocol 1 5 2 8 : User Data Meta-Contract 1 5 3 0 : Transmission Control Protocol 1 5 3 2: Dialogue Startup Agreement 1 5 3 4: Use Data Element Agreement 1 5 3 6 : David describes the agreement 1 602 : Voice Mail User -106- 200814679 1 604 : Voice Mail Server 1 60 8 : Server David Data Exchange Module 1 6 1 4 : Server Reliable David describes the protocol module 1 6 1 6: Server David describes the protocol 1 62 0: Server Session Initiation Protocol Control Agreement 1 622: Server User Data Meta-Contract Transfer Protocol 1624: Network 1 626: User User Data Meta-Contract Transfer Agreement 1 62 8: User Dialogue Startup Protocol Control Agreement 1 6 3 2: User David describes the agreement 1 63 4: User Reliable David describes the agreement 1 63 6: User David Data Exchange Module 1 6 5 0 : Path 1652 : Path 1 700 : Enterprise Server 1 702 : User Device 1 704 : User / Device Manager 1 706 : Davida Description Protocol 1 7 〇 8 : Decentralized Data Processing System 1 7 1 0 : Dialogue initiation agreement 1 7 1 2 : User data element agreement 1 7 1 4 : User data element agreement 1 7 1 6 : Dialogue initiation agreement 1 7 1 8 : Decentralized data processing system -107- 200814679 1 720: David describes the agreement 1 722: application user 1 802 : Image Manager 1 804 : Device / User Manager 1 8 0 6 : 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 Davis 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 Wear Vita Description Agreement 1908. User Davide describes Coordination 1910: User Attendance Manager 1 9 2 0: Attendance Enquiry 2 0 0 0: Mobile 2002: David He User 2006: Customer Relationship Management Application User 200 8: Mail Application User 2010: Application Agreement Interface 2012: Application Agreement Interface 2014: Internet Protocol Security User 2022: David Server-108- 200814679 2 026: Customer Relationship Management Application User 202 8: Mail Application Servo 203 0 : Internet Protocol Security Gateway 203 0 : Application Protocol Interface 203 2 : Application Protocol Interface 2040 : Firewall 2 0 5 0 : Network 2084 : Security Channel 2090 : Enterprise 2200 : Mobile Architecture Configuration 2 2 0 2 : Mobile 2 204: David User 2206: Application User 220 8: Application User 2210: Regional Internet Protocol Host 2212: Application Agreement Interface 2214: Application Agreement Interface 2216: Enterprise 2218: David Server 2220: Application Program Server 2222: Application Server 2224: Network 2226: Firewall 223 2: Application Protocol Interface -109- 200814679 223 4: Application Protocol Interface 225 0: Secure Channel 2 3 0 2: Mobile 23 04: David He User 23 06: Simple Mail Transfer Protocol Proxy User 2 3 0 8 : Zone Host 2310: Mail App User 23 12: Simple Mail Transfer Protocol Data Packet 2 3 1 4: Network 2 3 1 6: Firewall 2318: Enterprise 23 2 0 : David Server 23 22 : Simple Mail Transfer Protocol Proxy Server 23 26 : Mail Application Server 23 2 8 : Simple Mail Transfer Protocol Data Packet 23 3 0 : Dialogue Start Protocol Data Packet 23 3 0a : Wear Vita data exchange header 23 3 0b: dialog initiation protocol header 23 3 0c: transport agreement mark 23 3 2 : application protocol interface 23 5 0 : secure channel 2 5 0 0 : cell phone 25 02 : Vita User 25 04: Dialogue Startup Protocol Agent User-110- 200814679 25 0 8: Phone App User 2 5 1 0: Zone Host 2512: Data Packet 2 5 1 4: Network 2518: David Server 2520: Telephone Gateway 2522: Path 25 2 8: Firewall 2530: Enterprise 25 3 2: Session Initiation Protocol Proxy Server 25 5 0: Secure Channel 2 5 5 2: Application Protocol Interface 2560: Path 25 62: Immediate Agreement X: Signal y ': signal y 1 : signal Z: signal -111 -

Claims (1)

200814679 X. Patent application scope 1. A device for eliminating signals, comprising: an identification code (ID code) generator, which is configured to generate an id code; an ID code injector is configured to inject the id code into the signal And at least one of the processed signals to generate a whirling signal, the processed signal being generated by processing of the signal; an ID code detector configured to detect the whirling signal, the transformed signal, and the whirling signal At least one of the transforms, the transform signal is generated by the transform of the whirling signal; and the arithmetic function 'is configured to remove at least one of the whirling signal and the transform signal. 2. The device of claim 1, wherein the id code comprises a virtual random noise signal. 3. A device according to the first aspect of the patent application, wherein the ID code comprises a signal that is not detectable by the human ear. 4. The device of claim 1, further comprising a noise remover configured to remove background noise from the signal to generate the processed signal, wherein the processing of the signal is removed by the noise Executed by the device. 5. The apparatus of claim 1, further comprising a transform module configured to convert the replica of the whirling signal into a replica of the whirling signal detected by the ID code detector A copy of the transformed signal. 6. The apparatus of claim 5, wherein the transform module comprises a delay function, and the transform of the whirling signal comprises a delay of the whirling signal -112-200814679. 7. The apparatus of claim 5, wherein the arithmetic function is configured to subtract the copy of the transformed signal from a combined signal comprising the transformed signal. 8. The device of claim 7, wherein the signal represents a far-end signal received from a remote location in the communication configuration, and the combined signal additionally includes a near-received local microphone from the communication configuration. End signal. 9. A communication system comprising: an identification code (ID code) generator configured to generate a code); an ID code injector configured to inject the ID code into at least one of the signal and the processed signal Generating a signal to be generated by the processing of the signal; the ID code detector is configured to detect at least one of the gyro signal, the transformed signal, and the transformation of the gyro signal, The transformed signal is generated by the transformation of the whirling signal; and an arithmetic function is configured to remove at least one of the whirling signal and the transformed signal. 1 通讯 A communication system according to claim 9 of the patent application, wherein the ID code comprises at least one of a virtual random noise signal and a signal that is undetectable by a human ear. 11. The communication system according to claim 9 of the patent application, further comprising a noise remover configured to remove background noise from the signal to generate the processed signal, wherein the processing of the signal is by the noise The remover is in operation -113- 200814679. 12. The communication system according to claim 9 of the patent application scope additionally includes a conversion module configured to convert the replica of the convoluted signal according to the transformation of the convoluted signal detected by the ID code detector A copy of the transformed signal. 13. The communication system of claim 12, wherein the transform module includes a delay function, and the transform of the whirling signal comprises a delay of the whirling signal. 14. The communication system according to claim 12, wherein the arithmetic function is configured to subtract the copy of the converted signal from a combined signal comprising the transformed signal. 1 5 . The communication system according to claim 14 of the patent application, wherein the signal represents a remote signal received from a remote location in the communication system, and the combined signal additionally includes a local microphone from the communication system. The received near-end signal. 16. The communication system according to claim 9 wherein at least one of the ID code generator, the ID code injector, and the ID code detector is implemented in a user device, the user device table Not at least one of a telephone, a mobile telephone, and a teleconferencing device. 1. The communication system according to claim 9, wherein at least one of the ID code generator, the ID code injector, and the ID code detector is included in a software downloaded to the user device. The communication system according to claim 9 , wherein the ID code generator, the ID code injector, and the ID code detector are at least 114-200814679 implemented in a server device of a communication network in. The communication system according to claim 9, wherein at least one of the ID code generator, the ID code injector, and the ID code detector is included in a software downloaded to the server device. 20. The communication system according to claim 9 of the patent application, which represents a user device, the user device representing at least one of a telephone, a mobile telephone, and a telecommunications conference device. 21. A method of canceling a signal, comprising: generating an identification code (ID code); injecting the ID code into at least one of the signal and the processed signal to generate a whirling signal, the processed signal being processed by the signal Generating at least one of detecting the transition of the gyro signal, the transformed signal, and the gyro signal - the transformed signal is generated by the transform of the gyro signal; and removing at least one of the gyro signal and the transformed signal . 22. The method of claim 21, wherein the id code comprises at least one of a virtual random noise signal and a signal that is undetectable by a human ear. 23. The method of claim 21, further comprising removing background noise from the signal to produce the processed signal, wherein the processing of the signal should not remove the background noise from the fe. 24. The method of claim 21, further comprising converting the replica of the convoluted signal into a replica of the translating signal based on the transformation of the convoluted signal. The method of claim 24, wherein the transforming the replica of the convoluted signal comprises introducing a delay into the replica of the convoluted signal, and wherein the transforming of the convoluted signal comprises a delay of the convoluted signal . 26. The method of claim 24, further comprising subtracting the copy of the transformed signal from the combined signal comprising the transformed signal. The method of claim 26, wherein the signal represents a far-end signal received from a remote location in the communication configuration, and the combined signal additionally includes a near-end received from a local microphone in the communication configuration signal. 2 8. The method of claim 21, further comprising performing at least one of the generating, the injecting, and the detecting in the user device, the user device representing a phone, a mobile phone, and a teleconferencing device At least one of them. 29. The method of claim 21, further comprising downloading, to the user device, software that performs the generation, the injection, and the detecting. 3. The method of claim 21, further comprising performing at least one of the generating, the injecting, and the detecting in a server device of the communication network. -116-