CN106664626B - Method for providing information to at least one of a first terminal system and a second terminal system - Google Patents

Abstract

A method for providing information to a first terminal system and/or a second terminal system (connected to each other via a network and subject to a potential or actual handover), providing convenience information on the execution of the potential or actual handover to at least one of the first and second terminal systems, the business communication being provided with the convenience information in relation to the business communication prior to the start of the handover or at the time of the handover and in addition to the business communication of the at least one of the first and second terminal systems on a business measure.

Description

for providing information to at least one of the first end system and the second end system Methods

This application is a continuation-in-part of co-pending application number 13/683,733, filed November 12, 2012, which is a continuation-in-part of application number 13/177,346, filed July 6, 2011, which Said application 13/177,346 is now US Patent No. 8,351,395, said US Patent No. 8,351,395 is a divisional application of Application No. 11/969,388 filed on January 4, 2008, said application 11/969,388 is now US Patent No. 8,014,364, It is required by 35 USC 119(e) in Provisional Application No. 60/889,341, filed on February 12, 2007, Provisional Application No. 60/895,238, filed on March 16, 2007, and filed on April 5, 2007 Priority of Provisional Application No. 60/910,384 and Provisional Application No. 61/014,157, filed on April 5, 2007.

【Technical field】

This patent application relates to a "net surfing" method for a terminal system A0 with a real or virtual home network integrated access device (home network integrated access device) A0-homeIAD0 and to a second terminal system A0 connection of Z0) for "Managed Handover (MHO)" of the terminal system to the actual IADx in the wireless local area network x (WLANx) or to the virtual IADx of the mobile network x. Controlled handover is supported by A0-homeIAD0.

The A0 connection is usually relayed through a controllable handover module (MHO-Module, MHOM), which is controlled by a controllable handover specification (MHO-Specification, MHOS) in A0-homeIAD0 (A0 belongs to IAD0). This provides advantages for operators of sharedIADx/A0-homeIAD0 (shared IADx/A0 home IAD0) and users of the operator's home terminal systems (home Terminal systemms).

MHOM (with or without MHOS) is distinct from the "Home Agent" of Internet mobile technology, and can therefore also support current WiFi/FMC phones. That is, the web surfing method is short-term adapted to (but not limited to) VoIP telephony.

【Background technique】

Existing handover technology US2006/0099948A1 accurately expounds the prior art of "seamless handover, seamless HO" in its background part and the description of its method, especially expounds "media independent handover (MIH)" "Existing Technology. (More broadly) "IEEE 802.21 Overview-Publication" by V. Gupta et al. (DCN 21-06-0706-00-0000), UCLA CSD-TRNo. 040012 by L.–J. Chen, G.A. Mills- ("Mobile Voice over IP (MVOIP)..." Proceedings of the 21st IEEE International Performance, Computing, and Communications Conference, 2002) and E. Edvardsen et al. ("Open Accss Networks", Telenor Research and Development, 2002) or H. Almus (“Open Broadband Access Networks”, TERENA Networking Conference 2006) or P.A. Frangoudis (“Experimental evaluation of community-based WLAN voice and data services”, ICST 978-963-06-2670-5) papers Different technical switching versions are discussed. A related and complete review of J. Schiller's book ("Mobile Communications", Addison-Wesley, 2003) discusses a wide range of instrumentation for Internet mobile technology for future generations of handover technology.

These papers carefully describe the state of the art for handover and show that the state of the art for handover does not realize the innovative features of the web surfing method, that is, the characteristics of the web surfing method:

■ Controlled handover support (MHO-support) suitable to support current WiFi or FMC phones as well as shared WLAN-IAD (shared WLAN-IAD), and special Yes

■Suitable to bring advantages to homeIAD/sharedIAD operators and end system users in the case of shielding this advantageous application from any other network operator.

With respect to Internet mobile technology and "Handover Convenience Information Support (HOCIS)" (PCT/EP2007/010485 of March 12, 2007, the contents of which are ”), the web surfing method has in each case at least one additional technical feature: its possible tunnelless relay (ie the first feature described above) or its technical communication is used to implement commercial measures of the homeIAD/sharedIAD operator (the measure This is usually carried out for two end-system users in a VoIP call, usually by means of different messages to both, specifically when one of the two end-systems is switched, and the convenience information is subsequently made available. interrelated (ie the second feature described above)). Neither the prior art of handover nor the prior art of internet mobility (the latter with its WO2006/031379A1 and WO2006/031384A1 which go in a similar direction, however they specifically exclude telephony/VoIP applications in particular) do not implement either of these technologies feature (no tunnel relay or additional (commercial) communication that technically correlates "facilitation information"), one of the HOCIS method and the "Sponsored-Call" method (see e.g. " ARGELA Multimedia Sponsored Call White Paper" or "Rich Multimedia Applications on IMS Framework" of August 2007) also do not implement these two technical features.

[Content of the invention]

This patent application discloses a "web surfing" method for a terminal system A0 with an actual or virtual home network integrated access device (home network integrated access device) A0-homeIAD0 and to a second terminal A0 connection of system Z0) for "Managed Handover (MHO)" of the end system to the actual IADx in the WLANx or to the virtual IADx of the mobile network x (IAD=Integrated Access Device). Controlled handover is supported by A0-homeIAD0.

The A0 connection is usually relayed through a controllable switching module (MHO-Module, MHOM), which is controlled according to the controllable switching specification (MHO-Specification, MHOS) in A0-homeIAD0 (both implementations are distributed or local), which provides advantages for operators of shared IADx/A0-homeIAD0 and users of the operator's home Terminal systems. The MHOS is proprietary to the A0-homeIAD0 operator and, if necessary, home terminal system-specific. This relay control provides the following advantages:

Offers the shared IADx operator the following advantages in terms of web surfers in A0: The web surfer is no longer a legal risk for the shared IADx operator, since homeIAD0 is identifiable to A0 and thus The operator of homeIAD0 is legally responsible for Internet misuse caused by A0.

■Provides the following advantages for the homeIAD0 operator and all shared IADx operators that cooperate with it, such as

○ Controllable handover versions (MHO-versions) of web surfing for IAD0/shared IADx Home End Systems, and consequent significant cost reduction/quality improvement potential for IAD0/shared IADx Home End System operation,

○ For the commercial possibility of the homeIAD0/shared WLANx operator, through the message "CI-correlation" of the "HOCIS" information that has receptiveness and resonance of the homeIAD0/shared WLANx operator and, if necessary, the Facilitating the transfer of information relevance not only to the web surfer but also to the web surfer's interlocutor (to be precise, respectively technically and content-compliant, ie designed differently),

o The security of exploiting these advantages (i.e. the exploitation of these advantages is independent of third parties, and if necessary even invisible to third parties (e.g. intermediary network operators)) (however this does not preclude the use of provider) to support the WLAN surfing method.

o Provides advantages for end system users because end system users (for the reasons mentioned above) find more open shared WLANs, and controllable handovers of end system users especially to these shared WLANs ( MHOs) are more comfortable for them than they are currently, especially due to the "convenience information correlation" of controllable switching.

Relative to the function of "Home Agent" of Internet mobile technology, the function of MHOM (with or without MHOS) is limited/extended on L3 to L7 of OSI-RM (Open Systems Interconnection Reference Model), so that it can also take advantage of the current WiFi/FMC phones and shared WLANs that do not have proper tunneling techniques implement this handover management or can take advantage of the above. That is, the web surfing method is short term for VoIP telephony, and more specifically for "WLAN surfing" (aka W surfing) in VoIP calls, the examples of which this Part B characterizes , security/privacy for WLAN surfing (see section C) and commercial utilization for WLAN surfing (not limited to the like).

In order to emphasize this point, the possibility of application of the W-surfing method is pointed out, for example, in the case of IP-TV transmission (rather than VoIP transmission or concomitant cases), or, for example, in the case of security-oriented real-time concomitants of users of AO application possibilities. In all of these communication applications, all the following descriptions of W-surfing/web-surfing apply equally to the case of VoIP communication applications. Therefore, the VoIP communication application can be regarded as representative of many other application possibilities for the method/apparatus according to the invention, so that these other application possibilities are mentioned only occasionally below.

A small homeIAD can enable at least one end system (eg telephone and its user) by accessing itself and supports access to at least one network in the above sense, eg access to the Internet and/or PSTN, wherein access to at least one network is as follows carry out:

via the wireless network and any arbitrarily definable area in the wireless network (eg the reachable range of the IAD or any (if necessary all) area of the GSM network), or

■ Via a physical connection (eg telephone cable or coaxial cable).

The implementation of a WLAN in the sense of this context may be based, for example, on "RFI (Radio Frequency Interference)" or "BlueTooth (Bluetooth)" or "Femtocell (Femtocell or Femtocell)" or "DECT (Digital Enhanced Cordless Communication)" or "Wimax" "or "GSM/CDMA/UMTS/GPRS/HSPDA/..." technology, especially based on "WiFi" technology, including, if necessary, the base station of the mobile network (BS=Base Station) and/or the various IADs (previously incorrectly called is an AP, AP = access point) and extends over an arbitrarily defined area of the reachable range of the IAD or base station. A large homeIAD/homeServer may enable thousands of end systems to network access and support them in the above sense, ie for example a homeIAD/homeServer may be an internet server or system of one of these networks.

MHOM is composed of abstract (ie functional) hardware (hardware, HD)/software (Software, SW) components. MHOM needs to use its abstract hardware components not just for its MHOM functionality (aka web surfing functionality), but in order to be suitable for abstract applications of MHOM functionality to share with at least one functional non-MHOM (= "abstract resources" between modules shared", see Section C). Here, the MHOM can be located in any "physical" host system (Host-System) (eg, hosted by a physical IAD or a physical system in or on the network), without the IAD/system for this A physical hardware extension is required (see end of section C). The software components of the MHOM (in the MHOM's host system) may also exist elsewhere coded in some way (however in such a way that before the function of one of these software components is required, the part of the software component responsible for that function Can be translated into semantically equivalent code and loaded into a host system, and thus can be executed with the help of the MHOM hardware components described above. This scheme of MHOM is too narrow for the following discussion and is further divided in part C, however Sufficient for now. These terms/concepts are known to those skilled in the art.

The web surfing method is a communication application (according to MHOS) that is usually located on L7 of the OSI connection/Connection OC0 between A0 and Z0 (see below). Whether the MHOM function is implemented partially or completely within the WLAN0 (so eg in the IAD0 controlling the internet server/network system) or externally (so eg in the internet server or the network system and thus in the controlling internet server / IAD0 outside of the network system) is not implemented independently, the communication application can be supported by functions in the end systems A0 and/or Z0 (this generally increases the comfort of web surfing, but can also be omitted).

The legal protection of the above-mentioned web surfing in the form of a shared WLAN (shared WLAN) application (eg a mobile phone A0 calling Z0) is achieved by the use of web surfing according to the invention (eg a shared IAD). use) is restricted to use web surfing only as a router only to MHOMs with fixed IP addresses (ie to known operators). The MHOM operator can undoubtedly identify the responsibility of the OCO relayed through the MHOM operator (if the operator does the relay at all, and then for example at the start of the call or earlier (as is irrelevant here). That, but the skilled person knows suitable methods for this)). Thus, the MHOM operator is responsible for the identification of wireless telephone users on the shared IAD (rather than the operator of the shared IAD). Note that, unlike this, when emergency calls are involved (and this is currently fully open by law), the MHOM should be able to implement routing to that MHOM for A0 (and thus A0 to Z0 VoIP calls) , access to the Internet.

An exemplary implementation of the legal aspects of the shared IAD in the form of a web surfing application is outlined at the end of this Part B. However, the user's point of view of the core of the switching technology of the W surfing method is first shown only with the aid of specific examples, in which MHOM0 is integrated into homeIAD0/homeServer0 of the terminal system A0. Figures 6 to 8 and their description in Section D discuss separate versions of the functions used herein. Part C addresses the commercial core of the web surfing method and its "facilitating information relevance".

【Description of drawings】

FIG. 1 shows an example of a mobile terminal A0 moving between different WLAN areas according to an aspect of the present invention;

FIG. 2 shows an example of a mobile terminal A0 moving between different WLAN areas according to another aspect of the present invention;

FIG. 3 shows an example of a mobile terminal A0 moving between different WLAN areas according to another aspect of the present invention;

4 is a flowchart of a handover process according to an aspect of the present invention;

5 is a schematic block diagram of hardware and software components of an apparatus according to an embodiment of the present invention;

Figures 6a-6e show an example of a telecommunication device setup to which the method according to the invention may be applied;

Figures 7a-7e show additional examples of telecommunication device settings to which the method according to the invention may be applied;

Figures 8a-8e show additional examples of telecommunication device setups to which the method according to the invention may be applied.

【Detailed ways】

Figure 1 shows the simplest W surfing situation (aka Web surfing situation): TCP (Technical communication process, technical communication process, see part C) mobile terminal system A0 (such as FMC phone and its users) from the mobile terminal system The homeWLAN0 (abbreviated as W0, synonymous with homeIAD0) is directly or indirectly controllable handover (MHO) on path 1 or 2 to W1 intersecting with homeWLAN0 or W2 not intersecting with homeWLAN0. The L7 connection of OC0 is not affected by these controllable handovers (MHOs) on path 1 or 2 and exists between A0 and Z0. However, when the end system A0 is located in W1 or W2, at least one L3 connection of A0-OC0 is relayed according to the invention by the corresponding IAD1/IAD2 via MHOM0 into the homeIAD0 of W0. Details of this are disclosed by Internet Mobile Technologies (see Section A).

It is noted that there is no restriction here as to how the corresponding L3 connection (s-segment) between the mobile terminal system A0 in W1 or W2 and the homeIAD0/homeServer0 of W0 is established during the MHO: this patent application All the completely different possible scenarios of this L3 connection establishment between the L3 entity in A0 and the L3 entity in MHOM0 are then included. For example, if A0 is a phone, this L3 connection can be formed in particular by A0 calling MHOM0 and vice versa (or this L3 connection can exist from the start (technical details in favor of this are irrelevant here)) . This also applies to the current "fresh start" of WiFi/FMC phone A0 calling Z0 from WLANx, in order to achieve a fresh start, MHOM0 on L7 (in IAD0) must be properly designed.

From the discussion of "direct MHO" (ie direct controllable handover from one WLAN to another) it is easy to think how "indirect direct MHO" works according to the invention, so that in direct MHO two WLANs (end system A0 handovers between these WLANs) do not overlap each other in space or time (see WLANs W0 and W2 and path 2 in Figure 1).

Two cases are to be distinguished here:

■ In the spatial or temporal "no WLAN" range, there are also no other networks available for A0 (for technical or administrative reasons). In this case, no information transfer takes place in A0-OC0 to Z0 in this range because A0-OC0 to Z0 do not have a continuous L3 connection between A0 and Z0. Whereas the L4 to L7 connection in A0-OC0 is irrelevant for this and can remain present if necessary, so that the current communication between A0 and Z0 can survive and continue by means of A0-OC0 (ie A0-OC0 of the aborted TCP) Proceed, once A0 is in WLANx, a "W surfing connection" can be established for A0-OC0 between A0 and homeIAD0/homeServer0 (and its MHOM0) via IADx of WLANx.

■ There is another network available to A0 in this "no WLAN" range, to some extent W surfing an alternative network, such as a GSM/CDMA/GPRS/HSPDA... based mobile network or a fixed network. Without changing the first example and assuming that A0 is an FMC phone and has access to the mobile network (see below), W-surfing is established for A0 through the mobile network between A0 and homeIAD0/homeServer0 (via MHOM0 of homeIAD0/homeServer0) Connections (you can still ignore the details here). In the event that AO subsequently enters W2 and is registered in W2, then (if necessary after a security check in MHOM0 according to the invention) the Internet-based W-surfing connection of A0 is replaced by the mobile-network-based W-surfing connection of A0 .

From the detailed description of A0's "Calling End System" MHO (ie, "Supports the caller's web surfing", as shown in Figure 1), it is easy to think that there is also a "Called End System" MHO, that is, " A0's support for callee's web surfing" (see Figure 2). For the latter version of web surfing, what has been said in the preceding paragraph also applies, where the MHOM M' can be located, for example, in the IAD' between the Internet and the end system Z0. M' enables WLAN handover of A0, and the W surfing connection between A0 and M' takes place with exactly the same MHO functionality as M, ie M' is also MHOM (however especially by reducing the internet abuse protection explained above) .

The last thing to see is that OCO between A0 and Z0 can of course also be supported in the two end systems via MHOM, MHOM0 and M' respectively (see Figure 3). In this case, the two MHOMs can "re-route" the OCO's L3 connection between themselves, possibly autonomously, if needed (to thereby de-price their TCP or otherwise improve).

Returning now to the above assertion that the web surfing method makes the abuse of the Internet significantly difficult in supporting the caller's web surfing, and more generally to some communication (security) technical aspects of the method according to the invention.

This assertion of the difficulty of Internet abuse is appropriate, since any such abuse would seriously affect the more easily identifiable (since, eg, long-term unchanged) operator of MHOM M0, such that the operator would protect itself from such abuse , in such a way that the operator only provides access to the operator's MHOM to persons he knows well enough. Additionally, an implementation version can be used where, for example:

■ (after MHOM M0 is otherwise notified in some way of the validity of the W surfing connection, such as through the "A0 tracking system" or actively by A0 via GPRS or SMS, etc.) Only MHOM M0 may initiate A0's W The surf connection makes it impossible for shared IAD1 to even successfully initiate a W surf connection, since every such attempt alone has been rejected by MHOM M0 in homeIAD0, or

When an unknown terminal device (here eg A0) moving on IAD1 wants to use IAD1 for surfing, the terminal device does not know its specific MHOM0 (eg by initial brief "Blind-call" IAD1), but IAD1 routinely forwards all these wishes for the unknown content of IAD1 to an identity verification server trusted by IAD1, and this identity verification server first establishes a connection to MHOM0 by itself if necessary (wherein the identity verification server, for example, Provided to IAD1 for sharing by credit card institutions or ISPs or chain stores, etc.).

The web surfing method then allows to implement a completely different method which can exempt the shared IAD operator from all legal risks in "VoIP surfing" or "IP-TV surfing", as may also be referred to as the technique according to the invention. Appropriately dependent security-oriented method claims embody such a situation. It is evident that the scope of protection of the W-surfing method allows special implementations that virtually completely eliminate these known WLAN sharing risks.

In this context, lastly, the communication state CS is to be pointed out: for example, this communication state can change (and thus also change) in time/location/externally controlled (to a certain extent "independently", so to speak) The permissibility/disapproval/reasonableness of a web surfing connection between A0 and its homeIAD0, even though A0 itself has not changed at all in location). More clarification on this is included at the end of Part C.

C. Explanation of terms/concepts and OSI-RM description of web surfing methods and their MHO, ComMe-MHO and their "convenience information dependencies"

The description of the method/apparatus according to the invention in this text (like its terms and concepts) is purely functional, ie completely abstract, that is to say absolutely irrelevant to a physical implementation. For reasons of explanation, possible physical implementations of the method, apparatus and scheme/concept/terminology are occasionally set forth. It should be noted here that the following explanation of these terms/concepts (generally in the sense of OSI-RM) is only used to explain (the essence of) the method/device according to the present invention, i.e. no other communication technology issues are addressed explanation in principle.

The handover (HO) (aka handover procedure) of the end system and its TCP, ie its handover, takes place between at least two of the communication network or the access point of the network or the functional features on the access point of the network. The present invention then takes into account not only "vertical" HO, ie handover between different networks, but also functional characteristics of the same network and/or handover between access points, so-called "horizontal" HO, and all of the above mentioned handover types any mix between.

Conceptually (i.e. purely functional, completely abstract)

An abstract "communication process" (aka "telecommunications process, TCP") over which multiple human and/or non-human "subscribers (SUBCS)" are "users" of "terminal systems" (see below) (or their representatives/partial functions/supplementary functions, e.g. call responders, mailboxes, MP3 players, IVR systems, documents/scripts/images) /symbol/voice/…/dual tone multi frequency (DTMF) generator/DTMF detector/translator/active and/or passive type filters, in general: "communication application systems" (see below)) and belong to end systems, wherein these end systems have access to at least one network. The network/end system/user collectively completes the (abstract) technical implementation of TCP.

here:

○ Communication process, aka TCP:

If, for the communication process, at least in the TCP end systems involved in the communication process, although specific measures have been carried out, no specific measures have been carried out in the devices of its TCP end systems (ie firstly in at least one TCP end system of these TCP end systems) in at least one of the TCP-SUBCs, see below), this communication process is called "latent";

If a specific action has taken place in at least one such terminal device, the communication process is called "current", and;

In either case, the communication process is called "initialized" aka "initiated";

If specific measures are no longer implemented in the participating TCP end devices for the communication process, the communication process is called "retrospectively" aka "finished";

That is, the communication process is referred to as "existing" or "existing" in all these cases.

It is noted that TCP is not activated/started at the latest when at least one action involving this communication process is initiated/initiated in at least one end device (eg a telephone) of one of its end systems (eg picking up the telephone receiver, or by Some participant of the TCP locally inputs/outputs the telephone number of the person to be called or simply selects the telephone number of the person to be called locally, or manually or automatically starts a timer for the call to proceed when it expires, etc.).

○ The current TCP is in

"Connected" until the SUBC data exchange has been started in the current TCP;

Once the SUBC data exchange has been initiated, the current TCP is said to be "initiated", and;

Once the SUBC information exchange has been initiated, the current TCP is said to be "running";

An "exchange" is initiated as soon as an exchange of at least one "SUBC data" or "SUBC information" of the TCP-SUBC is initiated between at least one TCP end system and at least one network currently used by this end system. In this case, SUBC data or SUBC information is the last/originally detectable/producible information of the SUBC, which is output to/from the (human or non-human) SUBC by means of the terminal system, or is input or selected.

The difference between SUBC data and SUBC information is:

o SUBC data is usually exchanged only for the management (=establishment, interruption, ..., termination) of the TCP or the OSI connection of the TCP or its Li connection (i.e. usually during Li connection establishment and/or start-up) as necessary, while

o SUBC information is exchanged for TCP purposes, i.e. during TCP operation (that is, no longer used for technical establishment/technical management of TCP as described above),

In both cases it is between TCP's (if necessary corresponding) SUBCS or the above-mentioned representatives/partial functions/....

■Communication technology concepts/concepts/terms used in this patent application are defined in the internationally standardized "ISO7498-1 Information technology-Open Systems Inter connection-Basic Reference Model: The basic model" abbreviation: ISO/OSI-reference model or OSI- in RM. For those skilled in the art, this forms the binding theoretical/conceptual basis of this patent application.

The wording of the web surfing method/device according to the invention in most of the claims (despite its "pseudo-natural language" formulation) is based on terms/concepts defined in OSI-RM, that is to say already OSI-RM The exact representations/limitations of the communication technology that remove the uncertainty of its "purely natural language" meaning.

The description of the web surfing method/apparatus according to the present invention also uses OSI-RM terms/concepts as far as possible, such as OSI connection/PDU/SDU/layer/Li connection/..., which belong to the "artificial" terms of OSI-RM/ Concept (that is, avoided in the wording/meaning of the claim's pseudo-natural language). Thus, the description takes advantage of the clarity of the expressive power of those skilled in the art through OSI-RM terminology/concepts, some of which have been mentioned, for example, above. This is considered to be helpful for those skilled in the art to confirm their correct understanding of the substantive description of the pseudo-natural language description of the web surfing method/device in their corresponding independent claims.

For the following uses of OSI terms/concepts and in particular for OSI-RM terminology/concepts in this document, it should first be noted that:

o On the one hand, this paper does not fully generalize these technical terms/professional concepts, making reference to the above-mentioned international standards as compensation, in which case this paper is conclusive in case of doubt, and;

o On the other hand, this paper has been slightly simplified/roughened in several places regarding the situation in MHO (see below and Section D).

And finally it should be emphasized that the reliance on OSI-RM terminology/concepts in this patent application is indispensable: in practice the currently dominant "Internet jargon" is far from the conceptual certainty desired for legal documents (In order to achieve conceptual certainty, at least to correct the language/concept confusion that has become increasingly common in communication technologies, OSI-RM was finally developed). The conceptual determination of the present patent application is here not only used to determine the meaning of the main claims, but also to make its description of the method/apparatus according to the invention easy to understand/accurately understood (and in particular to combat the possibility of Attempts to circumvent the claimed scope of protection, which are intended to narrow the scope of protection by limitation, and likewise narrow the scope of protection by description, simply because no limitation is indicated in this patent application as impermissible).

Furthermore, it is not allowed to obfuscate the emphasis in the above paragraph:

○ Emphasize in the previous paragraph the absolute necessity for borrowing OSI RM

o Accompanying this is the idea that underlies OSI-RM, that a clear description of a complex system (regardless of origin) invariably requires abstraction of multiple (physical) implementation details of the complex system and an unconditional understanding of the functionality of the complex system (so abstracted) s concern.

More precisely (with attention to the last-mentioned requirement), OSI-RM can firstly define fundamental concepts, concepts and terminology on this basis, which are clear for many aspects of communication systems in particular Descriptions are very helpful or even required.

■In each "n-point communication process" (n>=2), there is an abstract "OSI connection" between any two of its end systems, eg between A0 and Z0 (this connection also extends to these two On the communication application system in each end system, as explained below. According to OSI-RM, each OSI connection is basically always divided into at least 7 "over each" abstract "Li" according to OSI-RM Connections" (1<=i<=7), by means of which the communication process between the two end systems A and Z takes place (where "L" stands for "layer").

OSI-RM thus defines an "OSI communication architecture" which in itself is based on all OSI connections The basic abstract meaning of the "7-layer structure". OSI-RM calls the basic 7 abstraction layers of its communication architecture (completely independent of each OSI connection) as "Li" respectively, 1<=I<=7.

In a single OSI connection, there can be multiple Li connections for each "i". Each such Li connection must, for its realization, use at least one Lj connection of the same OSI connection, where j is always less than i (j < i), except

o an L7 connection (ie i=7), for which another L7 connection can be used, and

○ L1 connections, which typically use a "physical medium" for this,

Wherein Lk connections (1<=k<=7) can be used by multiple OSI connections, or in OSI connections by multiple Lk+i connections (1<=i<=7-k).

An L7 connection of an OSI connection is often called a "communication connection" because the only thing that matters in an L7 connection is "communication" in the sense of the specific TCP process on which the OSI connection is based or a "communication application" that supports the TCP process (the latter "communication" in the sense of at least these two end systems connected by OSI). That is, the L7 connection is entirely derived from the information transfer (= function of L1 to L4), information partition (= function of L5) and information representation (= function of L1 to L4) used in communication (of the communication application system driven by the human SUBCs therein if necessary). = function of L6): the L7 connection is only aware of the "interaction" in this "communication application" communication.

Once one of the TCP-SUBCs starts the TCP in one of its two (TCP) end systems A0 and Z0, i.e. once the TCP exists (that is to say both (OC0 and its TCP0) can still be "latent" at the moment (see above)), the OSI connection "exists" between A0 and Z0. That is, the L7 connection of the A0-OC0-Z0 exists between A0 and Z0 for the TCP0 from then on. The connection remains in existence until the two TCP-SUBCs consider the TCP to end (this would be understood in OSI-RM as the end of the L7 connection and the OSI connection). TCP also still exists after it, as "past" TCP (see above), so the modelling by OSI-RM relative to TCP is somewhat primitive.

In other words, an OSI connection (of TCP)

o Not only "exists" in position between the two (TCP) end systems A0 and Z0, (more precisely: there is an L3 connection of the OSI connection between these two end systems A0 and Z0) but also by means of the existence L7 connections between the communication application systems and even the OSI connections that exist between the TCP-SUBCs of these end systems A0 and Z0, and

o Exists in time once the TCP starts in one of its SUBCs (in particular, the OSI connection's L7 connection exists between the TCP's SUBCs from that moment on (and remains in existence until both SUBCs will The TCP is considered to end).

Correspondingly, the OSI connection exists at the latest from the time from which, in the terminal device of the end system in A0 or Z0 that created the OSI connection (TCP-)SUBC, some measure. According to OSI-RM and in the sense of the present patent application, the OSI connection has undoubtedly existed since the moment when the TCP has been started in the SUBCs of the TCP on which the OSI connection is based, and this is also only a precaution Sexual (eg, by self-confirming, either explicitly or implicitly, reachability to emergency call numbers (eg, 110 or 112) or reachability to its callers).

At this moment, however, any Li connection (1<=I<=7) of the OSI connection does not need to be (abstractly) realized or can be realized. Thus, the existence of Li connections does not imply an (abstract) realization or realizability of Li connections. And more generally: there are also at least 7 Li connections of the OSI connection along with the OSI connection, however for j (1<=j<=7) there is no need to abstractly implement the Lj connection (and the Lj connection to the OSI connection Interaction of other Li connections (OSI-RM does not consider physical implementation/implementation anyway)). The (abstract) implementation of the Li connection only needs to exist in its current (abstract) use.

This implies that for this TCP, an OSI connection remains between the two end systems A0 and Z0, even if in particular at least one L3 connection between A0 and Z0 in this OSI connection for the transmission of L3 user data does not (abstract and/or physically) implementation (as often happens in HO). The existence of the L7 connection of the OSI connection in the handover situation (at least its abstract and, if necessary, its physical realization) can be ensured by means of the above-mentioned "HOCIS method" (see Part A, and below with reference to "Facilitation Information Dependencies") .

■Abstract "End System" except including its abstract human users and/or non-human users (= user automata) and/or any of its above-mentioned representative/partial functions (both understood as TCP-SUBCs) In addition, it also includes abstract "end devices", the whole of which is also occasionally called "end devices" in the end system, i.e. non-human functional groups, such as LAN, WLAN, mainframe computers, databases, PBXes , RASes, firewalls, functional groups for all types of switches, and functional groups for network access, IADs, I/O devices. A non-human functional group (an abstract or physical implementation) in an end system is often referred to below as a "module".

■ The individual "end devices" of the abstraction of the end system can be considered independently of each other, in particular:

o "terminal equipment of a user terminal", having an electronic/physical/acoustic/optical/"logical"/... user interface (in this context generally mobile, for example in a mobile phone);

o "Non-terminal terminal equipment" with its network-specific "terminal adapter (TA)" for the "network termination" (NT = "network terminator") of that network, where;

o User terminal and non-terminal end devices of the end system interact with each other through physical/communication technology interfaces and/or other end devices, where only some of the devices are usually standardized devices, and

o Terminal equipment that is not a terminal (and even its TA and associated NT) can in particular be integrated into a terminal equipment of a mobile terminal (eg a mobile phone), (making the former also mobile).

In order to divide OSI-RM compliant end systems into abstract people and abstract devices, it is to be noted that OSI-RM ostensibly avoids end system division, but OSI-RM ends up implicitly making end system division very clearly . The reason for this is the mental necessity of the division of communication applications, which are usually at L7 in the end system, in order to understand the nature of these communication applications. In (the relevant International Standard ISO/IEC7498 of 1994 and the same ITU-T Recommendation X.200, especially pages 32/33, and its corresponding International Standards, such as ISO/IEC9545 of 1994 and the same ITU-T Recommendation X.207) for L7, this necessity leads to the definition of a functional structure of an OSI-RM compliant abstract communication application which logically enforces the implication of the end system containing the abstract communication application. , the functional division corresponding to the functional structure, at least in the scope of the applications included in the terminal systems.

In the present patent application, the above-mentioned division of the OSI terminal system is a specific and particularly simple conforming to the following functional division of OSI-RM (with correspondingly simplified and above/below-introduced terminology for this division), namely The OSI end system is divided into different types of people and end devices.

An abstract "server" (aka "server end system", aka a humanless TCP user's end system) is a functional group in or on a network (either under the management of its network operator) , they are also regarded as terminal system/terminal equipment in this paper, however the latter cannot be divided into terminal/non-terminal.

■Abstract "system" is end system/end device or network-integrated computer.

At least one of these non-terminal end devices of the end system and thus the end system has " access" (through which the terminal can perform handover, see below), to be precise, via a corresponding "access point" of the network. Since these two terms are often misunderstood, the meaning (as known to those skilled in the art) of both of them is first clarified here (at least to the extent sufficient for this patent application):

The professional definition of "access" (in simple terms) is: when an end system/end device can at a certain moment communicate on the OSI layers L1 to L3 of its connection to the functional access point of the network in the following sense : enable the terminal system/terminal device to transmit data with all terminal systems/terminal devices of the network that also have functional access to the network at this moment, then the terminal system/terminal device is at this moment in Functionally "connect to its network". It follows from this that the end systems/terminals of the network do not need to have constant access to the network (as is generally known in the case of end systems/terminals of mobile networks).

The "point of access" to the network is here the legal/commercial/technical responsibility of the operator of the network to the person responsible for the end system/terminal equipment and its data transmission part (the data transmission part for the connection). (functional capabilities of these three layers on the datatransfer sections, DTSs), the transition locations. The abstract termination device on the network side of the data transmission part at the access point is called "network terminator" ("network terminator", NT), and the abstract termination device on the user side of the data transmission part at the access point It is called "terminal adapter" ("terminal adapter", TA). In the physical implementation of the network access point, these two conceptual functional units NT and TA can be integrated as much as possible (as is usually the case in mobile phones). (It should be noted in particular for mobile phones that when the capabilities of a mobile network phone for "direct mobile HO" involve GSM/CDMA/satellite networks on the one hand and WLAN on the other hand, the mobile network Telephones are now often referred to as "FMC telephones" (fixed mobile conversion, FMC = fixed mobile conversion): the mobile network telephone then supports not only the use of WLAN/VoIP technology, which is currently colloquially called fixed network technology, but also the GSM/CDMA/Satellite technology for mobile network technology).

According to the interpretation of network "access" and network "access point" in terms of their common legal understanding to those skilled in the art (skilled in the art will also know that these terms have other concepts, however they need to correspond to their The unambiguous name of the "Reference Model" (see: J. Schiller, Part A)), it is clear that the mobile end systems/terminal devices, especially mobile phones, which can be directly involved in handover HO, usually consist of a terminal and At least three non-terminal end devices:

○ The terminal equipment of the switching terminal is by definition mainly used to realize the functional acoustic/optical/mechanical user interface of the communication process;

o Three non-terminal end devices for handover are usually required, whereby the end system/end device is able to interact with two different networks/access points/function features in the handover: they exist at the "switch" of the function In this case, the "switch" is used for the functional data exchange between the terminal equipment, which is the switching terminal on the one hand, and the TA/NT functionally for/for the corresponding mobile network, on the other hand.

Finally, in this patent application, the explanation of the concept of access point will remove the conceptual confusion due to the concept of "Wireless Access Point (Wireless Access Point (Wireless Access Point ( WAP)" generated:

o On the one hand, the concept "Wireless Access Point (WAP)" is misleadingly used as a synonym for "Integrated Access Device (IAD)", ie as a synonym for a device. However, a device (abstract or physical) is conceptually and explicitly slightly different than the set of rights-related responsibility transition locations on an OSI-connected Li (ie the "access point" of this patent application).

○ On the other hand, the acronym "WAP" in the field of wireless technology has over the years represented a completely different concept anyway, namely "Wireless Application Protocol" (which has nothing to do with the concept of "Access Point" because the application is located in On L7, while the network access points of different possible meanings are usually on layers L1 to L3 (and the physical medium below them).

○ The "handover HO" of the end system and its TCP (and their two OCs), aka "handover process HOprocess", (similar in meaning to the above TCP (see there for details)) is called:

○ "Potential", when no handover measures have been carried out in the terminal for the handover/handover procedure, but at least another measure is in the terminal for this purpose (for reasons not relevant here and in a manner not here) ) and/or have been triggered in the end system, and;

o "current", when such exchange measures have been carried out in the terminal for this;

Wherein the end system/TCP is said to be "involved" by the handover during this period, and during the handover at the network and/or network access point and/or network access point used by the end system (and its TCP and their two OCs) Or in network service features, "handover" means change. Here, as soon as at least one such change measure is "initiated"/"started" in at least one of its terminal devices for the handover procedure, the potential handover becomes current, and the current handover is then "running" until the end of execution of all such changes Change measures (successful or unsuccessful).

The two end systems connected by the OSI of TCP can belong to two different networks (as shown in Figure 1), so that the abstract "OSI-Transit-System" connects the OSI to these two networks "Relay" (= "transfer"/"link"/...) between them. This patent application generally considers this abstract "relay system" as the end system of the two networks, and at least as the "transit system" of the OSI connection through which the relay is carried out. According to the invention, the abstract "relay" is performed for at least one of the abstract Li connections (1<=I<=7) of the OSI connection (there are multiple relays relayed by the OSI connection in the relay system). In the case of several Li connections, the relaying of these Li connections takes place individually and/or jointly).

It should be noted here that this relay function of the switching system can also be extended to at least one potential OSI connection, ie in particular to at least one of the at least 7 Li connections that generate the OSI connection (abstract and/or physical) implementation.

An example of such a relay system is the commonly known VoIP gateway between the Internet and PSTN/ISDN/UMTS, when the A0 end system is on the Internet and the Z0 end system is on the PSTN/ISDN/UMTS, the A0 and Z0 Telephone calls/conversations between the two are relayed (at least in part) through the gateway. The skilled person also knows that the Li connection of the OSI connection between A0 and Z0 can (temporarily or permanently) go through a number of relay systems: in this example, in addition to a VoIP gateway, for example through a SIP server.

Another example of such a relay system is WLAN-IAD on the Internet. The WLAN-IAD communicates with the WLAN end systems at L1 to L3 by means of the "WLAN air interface" protocol of the IAD, while the WLAN-IAD uses the corresponding Internet protocols at L1 to L3 for communication with the Internet end systems (this is in A huge "protocol and data conversion" would be required in the corresponding Li connection of an OSI connection relayed through such an IAD. For L4 to L7 connections of an OSI connection, the IAD may or may not change the protocol and data when relaying .

Those skilled in the art know all this, and in particular know that Li connections can have "tunnels" in order to produce "IP-Adressen-End-to-End-Significance" (although Mobility of at least one of the end systems for which there is an OSI connection, see Part A). Abandoning the end-to-end validity of this IP address opens up the possibility that various functions can be located in the relay (e.g. for users of end systems, ie SUBCs of these TCPs, "in the relay the common Mixing, such as 'appropriate superposition of the audio channels of these TCPs' which is important to the present invention (more on this see below)"), i.e. where this "mixing capability" is abandoned in the end systems of the SUBCs (Especially since even current FMC phones or PDAs (Personal Digital Assistants) etc don't have this capability). It is therefore necessary to distinguish whether the (possible) relay of an OSI connection involves such a tunnel or not, so that a distinction is also made between "Tunnelling-Relay" and "Tunnelling-Relay", which are limited in the functionality of the relay. (Tunnel-free Relay)”. The system may contain/use multiple relays of different types for one or more OSI connections, and then implement both relay techniques in parallel if necessary. Correspondingly, a distinction is made between two types of MHO, ie "tunnelless MHO" and "tunneled MHO", depending on whether the MHO requires tunnelless relaying for this or no relaying at all or tunneled relaying is required.

Thus, it has been implicitly mentioned that the present invention essentially (just as described in the HOCIS method) mixes an end system A with at least one "Secondary TCP (STCP)" "of usually at least another system Y" to the "Primary TCP (PTCP)" of "Terminal System A and Terminal Z". The simplest example is A's IP-TV-TCP with TV server Z as PTCP, and a VoIP call from Y to A during this IP-TV-TCP as STCP. If it is desired to implement a web surfing method with the aid of current FMC phones, ie for example MHO in this case in another WLAN, the mix must be transferred for PTCP to the above-mentioned and in this sense "tunnelless relay" (This does not preclude the use of tunneling techniques that provide radical simplification in the web surfing method by a system capable of this. More on mixing at least one PTCP with at least one STCP below for "MHO measures) ” explained after the introduction).

A final note is that the MHOM of an IAD, etc. can be used as a substitute for Internet access to other networks, such as access to another WLAN or PSTN access through one of its IADs. If the information exchanged over a network is packaged, tunneling is in principle always available (in particular regardless of the switching technology of the network).

■ "Controllable HO specification, MHOS" always

○ is associated with exactly one real or virtual (see below) homeIAD or homeServer (represented by the unified acronym "homeMIAD"), so the MHOS does not have to be contained in it (one of the number of homeTerminalSystems belongs to homeMIAD, only the manager of homeMIAD may be defined such that the acronym is reminiscent of the security/privacy aspects of MHOS),

○Only the administrator of homeMIAD can define MHOS and assign it to his homeMIAD,

○ Know at least two types of "Controlled HO Measures, MHO-Me", which are implemented in its MHO by means of a homeTerminalSystem controlled by this MHOS, specifically, by the homeMIAD containing the MHOS itself or within the control of this homeMIAD performed by another system, wherein at least one type causes at least one user communication, and

o illustrates the synergy of its MHO-Me implementation in performing MHO, where homeIAD (instead of "homeMIAD") is occasionally mentioned below for simplicity.

In the sense of the PTCP/STCP terminology/concept of the HOCIS method described above, each MHO-Me implementation that causes at least one user communication is an STCP.

In the web surfing method application, not all HOs of a TCP underlying it must be MHOs, but MHOS causes at least one MHO in the TCP. The MHO is always controlled by at least one MHOS (that is, multiple, possibly differently defined MHOSs can be associated with the control of the MHO. Conversely, a homeMIAD can contain multiple MHOSs.

The task of a MHOS of a homeMIAD is to determine in which MHO the MHOS controls which of these measures the MHOS controls in the homeTerminalSystem of the homeMIAD, that is, how and which of the measures for the terminal system in the MHO are related to Other measures of this interaction. Figures 6-8 in Part D discuss the distributed implementation of MHOS (and formerly MHOM) and its enforceability aspects.

In this patent application, belonging to the MHO-Me type in MHOS are:

○ Optional type of MHO-Me, "MHO Control Measures, ConMe", controls and enforces permissive monitoring of the use of network x through the homeTerminalSystem in the MHO, and if necessary controls and enforces controls and enforcement for A0 and this network x (i.e. for no Tunnelless network surfing connection/relay establishment or appropriate management (see above and below) for MHO of tunnels.

o By means of another optional type of MHO-Me, by means of "MHO-HOCIS measures, HOCISMe" (HOCIS = "HO Convenience Information Support", see Section B), control and generation of current and current information about homeTerminalSystem for users of homeTerminalSystem Various support measures for HO.

o For so-called "ComMe-MHO" (which can be implemented without tunneling if necessary), at least one "MHO business measure, ComMe" type of MHO-Me is indispensable, while this type is optional for MHO. In both cases, the homeMIAD with executive control of ComMe can implement various operations during MHO or ComMe-MHO for its operator (and if necessary the operator of the shared IAD with which the operator is commercially cooperating) Commercial measures, such as type of advertisement. Here, the execution of ComMe always enables communication with the TCP-SUBC whose homeTerminalSystem is just involved in the HO, where the TCP-SUBCS must or must not be aware of this communication (ie, acknowledged in some way).

o Other types of optional MHO-Me may be arbitrarily defined or specified for or in MHOS, for example to enable various overlays of IP-TV-TCP to VoIP-TCP (or vice versa), and by anyone controls.

o For simplicity reasons, the HO itself (ie the MHO basic process) is also considered an optional "MHO-HO measure, HOMe".

Individual, specific MHO measures of this type are generally identified below by a trailing "0" (eg as in "ComMe0" or "HOMe0") and are provided with the prefix "MHO" for revalidation reasons.

Each ComMe-MHO is "CI-related" (CI = "convenience information") in the sense that this ComMe-MHO feature represents the situation that, during the execution of the ComMe-MHO, at least one MHO- The execution of ComMe is performed (implicitly or explicitly) in connection with the execution of the optional MHO-Me. ComMe in tunnelless MHO does not have to be CI dependent, but can be CI dependent.

MHO-ComMe implementation with at least one optional MHO-Me implementation in ComMe-MHO (ie, eg "ComMe implementation with implementation of HOMe and/or ConMe and/or HOCISMe, etc."), appearing to be intuitive The CI correlation features that may be directly comprehensible above are described more precisely below for security reasons.

What is especially important to distinguish is explicit and implicit such CI correlations, where these two types of CI correlations are completely unrelated to each other. A specific MHO-ComMe0 (and thus the web surfing method using MHO-ComMe0) is called with at least one of these optional MHO-Me0s (both in the same web surfing method):

o "explicitly related" (in terms of at least one optional specific MeO implementation order independent of the ComMeO implementation order described below), when at least one message described by a ComMeO or that MeO (during its execution) communicated to at least one SUBC each type of such association or itself is related to it, and;

o "Implicitly relevant" when the following holds: There is a TCP for this web surfing method such that one of the SUBCs for TCP and the (potential and/or current) HO of the end system for TCP:

There is an execution of at least one of the Me0 and ComMe0, respectively,

And the start time of the execution of this ComMe0 and/or the start time of its display in the SUBC:

later than 30 seconds before the start time of the execution of Me0, and

not later than 30 seconds after the latter's termination time,

It does not matter if/when/how SUBC undergoes this Me0 execution.

By virtue of this ComMe association (the homeMIAD operator (more precisely, its MHOS) executes this ComMe for at least one end system (and its users) managed by this operator/MHOS), the associated ComMe communication is "good. " is set in TCP (may form the basis for the application of this web surfing method in VoIP calls). And the most advantageous setting of this commercial communication (not originally requested by the SUBC and thus possibly perceived as interference by the SUBC) takes place during the HO procedure. Here, the commercial communication can be designed such that it not only interferes with the TCP/SUBC "as little as possible" due to the commercial communication, but TCP-SUBCS even finds the commercial communication helpful at that moment, which decisively improves this customer acceptability/effectiveness of such commercial communications. It is the task of appropriately designed HOCIS behavior to create such "moments of advantage" in as many HO times as possible. Based on its CI correlation feature (which accepts all optional MHO-Me as a correlation basis), the web surfing method can then achieve in a simple way the transformation of an imaginary possible interference of a HO in a VoIP call into For the convenience and commercial possibilities just described for this HO. The CI correlation of ComMe-MHO (as it is called) can be considered to be convenient, even though the CI correlation for the optimal "Productivity development" in the web surfing method may generally be the HOCISMe correlation.

As a conclusion of this discussion on ComMe-MHO, it should be noted that the authors of the present patent application anticipate that most MHOs for web surfing in the future (ie also cases where ComMe or its CI dependencies can be omitted) (see claim 2)) it is possible to implement the commercial utilization of HO for ComMe discussed above, as the cost/usage balance of ComMe-MHO accounts for this for all participants.

The latter is slightly more precise: the MHOS-/ComMe-MHO technology implements the two bases of the W-surfing method according to the invention:

○ One is the economic basis, especially in the context of VoIP calls making the homeIAD within a company a clockwork of new and useful economic activity for its operator (as much as possible with the participation of a public shared IAD), and

○The other is the social basis, which is achieved by means of current mobile network technologies (based on GSM, CDMA, UMTS, Wimax, etc. and their derivatives) alone (where these mobile network technologies are used as "fall-back technologies"). )" is largely reserved everywhere where shared WLAN technology is not available or can not be used cost-effectively), short-term and cheaper to provide anyone with more information for their future multimedia terminal systems in all densely populated areas For comfortable and more powerful communication technology (especially for exploiting IP-TV capabilities).

Some simple examples of this CI-related MHOS-/ComMe-MHO technique and a description of the technique can illustrate this. With the help of:

o Optional MHOS0/Function1, assigned to a homeMIAD0 that decides before or at the beginning of the HO of WiFi phone A0 (A0 is HomeTerminalSystem of homeMIAD0) whether homeMIAD0 is allowed to use its current TCP to another phone Z0 /OC0 to perform MHO (=MHO-ConMe) to IAD1, where the TCP/OC0 is relayed through MHOMO,

o optional MHOS0/Function2, which is also associated with homeMIAD0 which informs both SUBCs of TCP of potential and/or current HO executions (=MHO-HOCISMe) before or at the beginning of the above-mentioned HO,

○ For ComMe-MHO obligated MHOS0/Function3, which is also assigned to this homeMIAD0, the latter (or its MHOS) implements business measures, such as communicating advertising notices to the users of the homeMIAD0-HomeTerminalSystem involved in this HO or its TCP (=MHO- ComMe)).

It is clear from this small example that the execution of the MHO-ComMe occurs best when correlated with the execution of the previous MHO-ConMe (where the CI correlation does not require the execution of the MHO-ConMe to communicate with a TCP SUBC one), however first the previous MHO-HOCISMe was implemented, where Cl correlation in particular in VoIP calls now uses a rule as the fact that the implementation of this MHO-HOCISe as a rule is always in any case with two TCPSUBCs communication. This does not mean, however: the web surfing method is only possible if the HOCIS method is also used: the web surfing method is technically completely independent of the HOCIS method, and MHO of the web surfing method on the content is also possible, in these MHOs , the CI correlation between MHO-ComMe and MHO-HOCISMe was not significant.

here,

○ This decision of homeMIAD0 (based on this MHO-ConMe) and its deterministically communicable HOCIS measures and business measures can be interactively designed in the sense commonly known for example to IVR systems (e.g. shared with homeMIAD0 supported end system users on the IAD and the way they interact with other business partners of homeMIAD0).

o MHOS may be provided with at least one communication state, and this state is recorded/modified/analyzed by homeMIAD0 (e.g. by means of its MHO-Me) and taken into account for example in the above-mentioned decisions, and this communication state may have the impact of the decision.

○ These MOHS-controlled MHO-Mes of the homeMIAD0 can be constructed context-sensitively (i.e., eg, designed differently during a potential TCP/OC than during an ongoing TCP/OC) and/or multimedia (i.e., eg, After or simultaneously with the audio signal to the SUBC, the text or image information is copied for the SUBCS to the end system of the SUBCS in parallel and if necessary without affecting the VoIP audio information).

o In any abstract and/or physical implementation of all MHO-Me types, arbitrary MHO-Me types can be intertwined with each other as closely as possible such that the end system users involved cannot recognize these MHO-Me types as individual type, and

○The homeIAD operator can determine at least one and/or all entities of its homeTerminalSystem (such as the entity of the OC of the homeTerminalSystem and the entity of the homeTerminalSystem itself) respectively determine the same or different MHOS and distinguish them, and the corresponding complex , or very simply design. The latter means that only unimportant restrictions (eg "new MHOM host system=homeIAD" and "new terminal system=homeTerminalSystem") are always specified in MHO-ConMe, and only unimportant restrictions are always specified in MHO-ComMe unimportant user communication (such as "when end system Ax is at risk of HO > '1x audio short signal' and 'current shared IAD-operator ID flashing' and 'signal strength flashing'"

"At the start of HO at end system Ax > '2x audio short signal' and 'current shared IAD-operator ID-announce bye (bye)' and 'signal flasher'""

"At the end of HO at end system Ax > '3x audio short signal' and 'new shared IAD-operator ID-announce hallo' and 'new signal strength flashing'""

"On HO failure of end system Ax > '7x audio short signal' and '3x audio long signal'").

The communication of the audio short signal/audio long signal can be regarded as HOCISMe, while the shared IAD-operator ID-announced (preliminary) advertisement information communication. This MHO-Me can be specified globally for all homeTerminalSystems in MHOS or selectively for individual homeTerminalSystems, and MHOS can also be pre-set in a fixed configuration (however this is irrelevant here, as this is a matter of construction and physical implementation of the invention).

The person skilled in the art understands that the MHOS of the operator of the virtual or actual homeMIAD in the physical implementation (=implementation form) of the W-surfing method is a specification in this homeMIAD, which is partly or completely determined by the operator of the homeMIAD in some form means entered into homeMIAD and/or already included in it and configured by the operator only, and/or fixedly pre-set in it, and the MHO-Me of homeMIAD (associated with this MHOS) is passed by the homeMIAD to this MHOS explanation to achieve. The skilled person also understands that any specific MHO-ComMe and its specific CI correlation are not the essence of the invention, but only the fact that the two are in each (according to claim 1) are present in MHOS, so that in any case each ComMe-MHO is characterized by a very specific technical feature: the "CI correlation between the user of the "MHO (Controlled Handover)" end system and the homeMIAD of the end system "Limited" communication to achieve this MHO-ComMe (however other MHOs may have this feature as well).

■ The attribute "homeMIAD private" of the MHOS is only used to emphasize the "privacy" of the MHO management measures indicated above for and only for this homeMIAD and only for the operator of this homeMIAD. It should be noted here that the abstract homeMIAD operator can be implemented by two different physical persons, and the abstract "operator" can mean "physical operator-man and/or physical manager-man" .

This privacy then precludes a situation where a second person (other than the homeMIAD as the first person) learns or sets or changes the private MHOS for its homeMIAD without the first person knowing or agreeing to it. If the second person is in particular the operator and/or manager of a network of some type (which is not homeMIAD's network) or service (which is not homeMIAD's service), these MHOSs are not accessible to the second person and incomprehensible. However, this privacy does not mean that the second person does not know or is not allowed to know which MHOS the homeMIAD operator can assign to him. The encryption of this last required and known SUBCS information is not discussed here.

■ There are two types of homeMIAD: "real and virtual homeMIAD" types, both abstractly and physically implemented if necessary. There is conceptually exactly one "logical" manager and "physical" operator for each homeMIAD (real and virtual homeMIAD). In the actual homeMIAD case, its manager and its operator are the same (this need not be the same in both implementations).

The previous language idioms have been suggested, in this document the terms/concepts "MHO", "MHO method" and "MHO process" and "MHO PDU" and "PDU" (PDU=protocol data unit protocol data unit) are sometimes used separately as synonyms (the term is then e.g. simplified in its slightly cruder sense) (although this is not per se allowed in the first case, since an abstract "procedure" is always an abstract" method", i.e. its abstract "application instantiation").

■Finally, some other terms/concepts matching the situation of this patent application are now explained.

o "homeWLAN" aka "homeNet": here the end system A0 is administratively assigned to the homeWLAN aka homeNet and its at least one real or virtual homeMIAD according to the invention. A0 is "homeTerminalSystem" for this homeWLAN/homeNet/homeMIAD. The simplest example for homeMIAD/homeWLAN/homeNet according to the invention can be realized by means of WiFi IAD/WLAN and its homeTerminalSystem A0 (person with WiFi phone). The WiFi phone A0 can then use the WiFi-WLAN Wx aka Netx according to the invention for any sharing in W-surfing/net-surfing, if A0 can only "check in" in Wx/Netx (see below) and AO's homeMIAD contains MHOS/MHOM according to the present invention (and this MHOS/MHOM is ready for W-surfing connection via Wx/Net's IADx).

This commonly known homeWLAN/homeNet concept is first extended in this patent application to the WLAN/Net concept used here (see Part B). Second, the concept extends to possibly "impractical" related homeTerminalSystems, such as A0 above, a phone, where this impractical "home" characteristic of the terminal system can be generalized to any IAD/server due to CS (see below) , for example, the CS of the end system itself or the CS of its OC, or the CS of the TCP of the end system, or the CS of other end systems, or the entire homeWLAN, or the IAD/server and so on. The CS can then have the effect that the OC of the end system or TCP can or even have to relay through the IAD/server (eg by means of the MHOM actually in charge of this) even if the end system is not at all (in the above sense) the The actual homeTerminalSystem of the MHOM/IAD/server. In this patent application, its actual and unreal homeTerminalSystem belongs to homeWLAN/homeNet/homeMIAD/MHOM.

○ "Checking in": an end system A0 that receives electronic signals such as WiFi-WLAN or other networks available for communication (in particular via the Internet), usually only when the end system (possibly multiple) The terminal system can use the network for communication only after at least one of the IAD or the base station or the like applies for the right to use the network. If the use authority is given to the terminal system, A0 is registered in the network. The procedure or agreement between the A0 and the IAD/base station in which the application and granting or providing/accepting the use rights of the network is carried out according to these procedures or agreements is irrelevant to this patent application.

However, it needs to be limited that when A0 is registered or can be registered in Netx, then A0 is considered to be "reachable" on Netx. It is sufficient if necessary that A0 is there "W surf-registered", as explained in Part D (where possible cases and implementations of such registration restrictions or limited registration possibilities are described in this patent application). is irrelevant).

o "netsurfing connection (NSC)": this is at least one L3 connection of an OC0 segment of OC0 between A0 and Z0, i.e. OC0 between systems S0 and A0 in/on WLANx/Netx section, this WLANx/Netx is different from A0's WLAN0/homeNet0.

○ "communication status (CS)": As explained above, TCP/OC for a specific communication application based on the W surfing method (such as in TCP with specific characteristics, such as emergency from a certain time or at a certain time) Calls or all types of reduced cost calls, or calls to be monitored, or calls to minors, or calls to a defined far-end network or WLAN or location or event, etc.) may be characterized by the following: W surfing at end system A0 causes that end system to be prioritized, for example in such a way that the end system's OC can or even has to be relayed by whomever, as long as he is technically suitable for it ( Wherein the necessity/significance of the priority is not considered in this patent application for commercial or legal or other reasons, but only the fact that the priority may exist).

However, the CS may also contain differential or other relay handling of the OC (through which IAD/server and how, until relaying is completely rejected, ie the "home" feature of the denial entity).

The CS of the method/apparatus according to the invention or the CS of the entity of the OCO (see below) then impairs this feature set of the relay of the OC.

○ "Entities of an OCO": Here is understood the Li-connected Li entities of the OCO as well as the Li-connection itself, at least one network required for realizing the OCO and, if necessary, other devices required for this purpose.

FIG. 4 is a flow chart showing the method steps of claim 1 . Figure 5 shows the hardware/software components of the abstract means of the device according to the invention according to claims 14-16. Usually connected to the bus (1) are: a memory (2) for storing, in particular, the MHOM-SW modules, which contain the MHOS; a processor (3) for implementing the MHOM function, in particular according to the MHOS; at least one network output/input device (4) for MHO-PDU transmission/reception; output/input device for exchanging at least one MHO-PDU between the MHOM and at least one local functionally non-MHOM module (5) (implemented, if necessary, by means of a locally coupled device with the means of the device independent claim).

Accordingly, this article considers in particular an abstract web surfing device which consists of abstract hardware/software functional components, wherein the assignment of the functional web surfing device components to the hardware/software is completely irrelevant. It is important that the abstract realization of the functional components of the abstract web surfing device takes place by means of the following components:

■ Separate functional hardware/software components on the web surfing device, or

functionally identical and/or functionally suitable end system/IAD hardware/software components, or

■ Functionally identical and/or functionally appropriate hardware/software components of other systems, such as the operating system and the hardware components of the functions managed by the operating system.

Disregarding the first case, then "abstracted hardware/software resource sharing" takes place between the Wsurfing device components and the other mentioned functional components of the system. This abstracted hardware/software resource sharing may or may not be found in the physical implementation (aka implementation form) of the W-surfing device, and is referred to as "physical hardware/software resource sharing" in the first case. That is to say: the abstract realization of the web surfing device in the abstract web surfing device terminal system/IAD where abstract hardware/software components, such as operating systems that are functionally identical or functionally suitable, can be used jointly by abstract resource sharing. (and abstract hardware components managed by that operating system).

Conversely: the implementation of the abstraction of the web surfing device (which should complement the abstract end system/IAD to be supported by the web surfing method) may not require hardware extensions of the abstract end system/IAD at all for this, since the end system/IAD's The abstracted hardware components are sufficient for the abstracted device implementation, ie the abstracted device implementation can be implemented by means of "abstracted hardware resource sharing" with the abstracted end systems/IADs to be supported. This can then also apply to the physical implementation of the web surfing device terminal system/IAD by means of the physical terminal system/IAD and its physical hardware components.

The above discussion on the modeling of abstract hardware/software components of means of a web surfing device serves to indicate the purely functional nature of the means according to the wording/meaning of the claims, by means of which the realization of the The implementation form may determine whether a "netsurfing suspect" implementation form falls within the scope of this document.

The present patent application is currently mainly directed to the implementations of the method/device for web surfing which, with regard to the hardware components of the patent application, are (should) be supported by the physical hardware components of the physical terminal system/IAD supported by these implementations. (ie generally only includes additional (due to the web surfing device) physical software components. Hence, the physical implementation of such a web surfing device is based on its physical hardware components and supported physical end systems/ Physical resource sharing of IAD hardware components.

The physical implementation of the web surfing method is entirely possible by means of physical software components, which are essential for those skilled in the art. Those skilled in the art will also immediately see that all the means in the claims of the web surfing device can be implemented physically by means of software components, as long as these means are not based on the abstract hardware components in FIG. 5 , these abstract hardware components can be shared through physical resources to be physically implemented (see above). The scope of protection of the present patent application is not limited to these specific implementation forms, but may include network surfing-specific hardware components if necessary.

D. Further Description of the Invention

This Part D will help avoid: determining and limiting the meaning and/or scope of this patent application in light of its very limited exemplary embodiments (though "patent logic" would be inappropriate and Strictly prohibited in patent law in particular, however for the authors of this article it has appeared in rights disputes in their other patents, and thus greatly affected the drafting of this patent application (and not because of the authors' intentions). Claim wording provided abstractly and thus fairly broad). (as opposed to all other possibilities of the patent's method of interpretation/meaning determination) the way the patent is interpreted in terms of the patent's claim wording (ie the meaning determination method) It is unequivocally specified in all patent regulations.

For these two reasons, Part D below also describes the essence of the invention of the present patent application by means of a somewhat complex specification of its method claims. Accordingly, a second and similarly complex review of the device claim appears unnecessary. Thus, part D is part of the description of the method/apparatus according to the invention.

There are three aspects (some of which have been covered in this article) to start with:

■ The individual features of the method/apparatus according to the invention are not subject to limitations not mentioned herein, in particular by the "general context" of the individual features of the method/apparatus according to the invention, regardless of Whoever imagined this "comprehensive full text" and however he designed it, because he cannot justify it with what is in this article.

Since all claims of this patent application word/meaning uniquely and individually define the features of the method/apparatus according to the invention in their essence, there is absolutely no reference to these features in a certain embodiment of the invention. Physically implemented versions are described (instead these features are "functional" aka "abstract", ie "purely conceptual").

■In this text (including the claims herein), the syllable "a" (in the absence of "at least") and all conjugations/slants/versions thereof means "at least one", so long as such substitution is in some way might make sense.

Now with regard to claims 1 and 2: their first paragraph defines the basic terms/characteristics of the telecommunication arrangement with which the Wsurfing method works.

■It should be reminded on the one hand that, in this patent application, the OCO according to claims 1 and 2 (see part C) need only be latent. A known example of this is an OSI connection that is conceptually realized at the latest with the SUBCS decision to initiate a call to either emergency call number (eg 911 or 112), ie the OSI connection (in a potential way ) exists from the moment the (abstract) SUBCS (as part of the abstract end system A0) thought of calling the connection. Another example of this is a potential OSI connection between a T0 user and a potential Z0 user, for which the former is expected to be reachable when the latter calls him, where for the moment of the MHO it is assumed that there is already such Z0 user (an assumption, the reason for which is irrelevant here (but not unreasonable)). In the case of an IP-TV communication application, its potential OCO exists at the latest when the user of A0 makes a "program selection" on it.

It is also here to point out the abbreviation of the wording which is not valid in the text: when referring to "TCP between A0 and Z0", it should therefore always be understood as "between each of the at least one user of A0 and Z0" TCP".

■ On the other hand, features have been mentioned here

In claim 1, reference is made to "MHO-ComMe" and

In claim 2, the relay of A0-OC0 is mentioned,

It does not implement the prior art methods of HO or the methods of Internet mobile technology: this HO management feature is so far completely unknown (see sections A and C for this).

A brief description is also given for steps a)-b) in claims 1 and 2, wherein it should be clear from the prior art that there are other (in a)-b) not mentioned but for the present Steps required for web surfing that are obvious to those skilled in the art) and are therefore not worth mentioning here.

■ The implementation of the MHO of A0 to network x according to claim 1/2 starts in at least one execution of checking step a) by its determination of the "presence of a reachability signal of A0 to network x". Since the preceding description of the invention does not limit this in any way, the meaning of the wording a) is just intuitively easy to think of: the presence of a signal (of any type and in any way determined anywhere), the presence of which indicates: Because A0 is registered there/can be registered there, A0 can communicate in network x with all end systems on the entire Internet by means of IADx or BSx of network x and homeMIAD0 of A0 and can reach network x from these end systems (see B at the beginning and C at the end).

■ The abstract or physical implementation of steps a)-b) can be arbitrarily temporally overlapped (a person skilled in the art knows, for example, that a separate pre-check in a) is not necessary in order to perform a) and b). In particular, check a) is performed one or more times depending on the wording/meaning.

The execution of the MHO according to claim 1 or 2 may require/imply/utilize further steps in the physical implementation (besides steps a)-b)), said additional steps being able to An additional or alternative optional MHO-Me is automatically implemented and/or included, eg for utilizing IP-TV. That is, claims 1 and 2 do not specify at all any question of the physical implementation of their method, such as when and how and under what conditions the actual registration of A0 in network x can and/or must be effected. However, it is clear to a person skilled in the art that it may not be necessary to perform any of the method steps required for registration, whereby the MHO can be initiated and/or performed and/or terminated according to a)-b) (as in particular in the would be possible if Internet IPv6 was implemented on end systems/IADs/BSs/...). That is, although the web surfer or his terminal system is not registered anywhere at all or at least in the case of a real or virtual distributed or locally implemented IADx/BSx that implements the web/W surfing method preventively if necessary , the web/W surfing method can operate completely and preventively. The same applies that IADx/BSx preventively establish a complete or partial web surfing connection NSCO and/or A0-OC0 and/or IP-TV connection and/or A0 to A0 before A0 is registered in network x Other optional MHO-Me connections (e.g. any security related reminders to its users and/or security principals elsewhere) and/or keep IADx/BSx preventatively establishing a connection to A0 until A0 exits network x Full or partial web surfing connection NSC0 and/or A0-OC0 and/or IP-TV connection and/or other optional MHO-Me connection of A0 (e.g. to its users and/or other location security officers of any safety-related reminders), where the AO user is informed and/or utilizes or does not utilize such precautions.

For a person skilled in the art, the method according to this version of the invention is not excluded from the wording/meaning of claim 1/2 in this patent application and its description, wherein only by way of example are explicitly mentioned in this version. several. That is, the wording/meaning of claim 1/2 (at least due to this description of the method according to the invention) includes all versions.

■ The W-surfing method according to claim 1 is designed to use two relay methods (tunnelless relay and tunnel relay, see claim 3 for this), ie no "tunnelless" restriction is included for this purpose. However, with respect to claim 2, the MHO of this method is limited by having to implement ComMe and its CI dependencies. While these limitations do not actually appear as such, they appear as advantages of the web surfing method (see Section C for the advantages of ComMe and its CI correlation in MHO).

■ Abstract relaying involves each bit transmitted in A0-OC0. But it is also possible to carry out every physical implementation of the web surfing method such that it is only necessary under certain conditions (eg the capacity of the information transmitted by A0-OC0) to ensure the implementation of this "tunnelless" relay feature. The person skilled in the art knows how and under what conditions this is done and why this is reasonable.

■ Regarding the wording/meaning of claim 1/2, the last thing to note is that,

"Management of MHOS0 performed in accordance with the HO", an abstract or physical version of the implementation (in the case of controlling real and virtual homeMIAD0, locally or distributed implementation, and in the case of controlling their respective MHOS shares) is known to those skilled in the art at least from the preceding description, and is therefore irrelevant here (so that the management of HO performed according to MHOSO is completely unrestricted in its abstract or physical implementation), and

The "Additional Commercial Communications"

Neither additional PDU exchanges are required (but additional business communications can take place by means of PDU exchanges that are already required);

There is also no restriction on the network used by the additional business communications (ie, a different network than the one originally used may be used).

With regard to the scope of protection of claim 1 or 2, this implies in particular that as soon as an embodiment detects the presence of a signal according to a) by means of some (presumed) non-MHOM (without any limitation in this description) and thus leads to the successful implementation of step b) in some way, then this implementation form (together with the non-MHOM) falls within the scope of protection of claims 1 and 2

With the aid of the five Figures 6a-6e also a few basic explanations are made in terms of a telecommunication arrangement in which a web surfing/W surfing method can be applied, wherein the method's MHOM and/or its virtual or actual homeMIAD and/or Its MHOS is implemented abstractly or physically distributed. For the sake of simplicity, in Fig. 6a it is based on the fact that the system S0 with a part of the virtual homeMIAD can only control and execute ConMe when necessary, while the system S1 with the other part of the virtual homeMIAD can only control and when necessary Execute ComMe (both control as a whole and execute both when necessary). The three Figures 6b-6d differ from Figure 6a only in that in Figures 6b-6c one of the two is located in the actual homeMIAD0, while in 6d the two MHO-Me types are located in the actual homeMIAD0 middle. Here, it is noted that SO and/or S1 and their virtual homeMIAD parts (in Figures 6a-6c) can be located in the TK network, then the operator of the communication network supports the W-surfing method, so that in these If necessary, a further actual homeMIAD can be installed in a functionally simpler manner than in the case of FIG. 6d, in particular the currently installed shared IAD (see below). Naturally, there are many hybrid forms of prototype communication arrangements for web surfing methods/devices (these hybrid forms are disclosed by means of the wording/meaning of claims 1/2 and the description above). All in all, the full form and structure of the abstract and/or physical, distributed implementation of the method according to the invention will be apparent to those skilled in the art from the description by means of the wording/meaning of claims 1/2.

As already mentioned, in terms of the method according to the invention, an economical benefit that can easily be envisaged is the complete integration of homeMIAD in the network (be it a communication network or a large WLAN) or eg a network server, since so many are already installed A "functional upgrade" of a non-W-surfing IAD can be implemented simply around the web surfing function (= a complete "virtual homeMIAD server"). Figure 6e shows a communication arrangement with a large WLAN and a single virtual homeMIAD server. In order to obtain the desired "homeMIAD privacy" in this case (ie to ensure that the network or server operator/manager hosting the virtual homeMIAD server cannot gain access to the hosted virtual homeMIAD), this The communication of the operator/manager of a virtual homeMIAD remains as incomprehensible to the network/server operator/manager as the MHOS for it stored in the virtual homeMIAD (based on the communication). Those skilled in the art know how this can be implemented in both abstract and physical, distributed or centralized implementations of web surfing methods/devices (ie homeMIAD server for web surfing methods/devices, MHOS for web surfing methods, web surfing methods MHOM and functional modules for execution).

Figures 6a-6e then depict only a possible separation (ie a possible distributed implementation) of the ComMe functions (from other MHO-Me functions) required by MHOS. Figures 7a-7e depict, for each of these Figures 6, a possible separation (ie, a possible distributed implementation) of the homeMIAD0 control function of the MHOS from the owning, executed functional modules in another system, so that in each In this case the implementation of MHOS is not yet distributed. Thus, Figures 8a-8e depict, for each of the MHO-Me functions, a possible separation of the homeMIAD0 control function of the MHOS from at least one part of the MHOS that controls the homeMIAD0 control function, by distributing the homeMIAD0 control function to the two systems. In this sense, at least a part of the MHOS can itself be considered executable, which part is also interpretable.

Based on the method according to the invention, such a suitable distributed (finally physical) implementation makes it easy to operate large networks or Internet servers, in all possibili- ties such as with shared WLAN operators and/or IP-TV programs provided The cooperation between the two parties provides vastly different innovative multimedia communication services.

Hereafter it is especially clear that "having" in the claim language is not allowed to be limited to "now includes/comprising", but that other meaningful interpretation possibilities of natural language also apply to such "having" at this point , such as "associated with" and/or "to be noted/observed," and this also includes the future.

Additional features

Additional functional units of a home/shared IAD according to other aspects of the present invention will now be described.

The functional unit at the server determines the "managed handover" related information available in the context of the home/shared IAD and provides it in a controlled manner to other end systems Ax to support their MHO decisions.

Information that may be collected and provided by IAD can include, for example:

· Possible (potential) home/shared IADs in the IAD's reception area, and information about the services they offer (Internet, VoIP, IPTV, etc.), quality features, security, etc.

· In particular information on the support and design of potential MHO processes

• Its location and the location of adjacent IADs.

The determination of information about potential IADs inside the receiving area will be arranged in such a way that, if necessary with the help of a second receiving unit or by using a parallel collection that allows for interference-free, such information is available at the end system and Active connections between IADs are immune to impact.

The retrieval of information in this process need not originate only from the IAD, it can also obtain information from suitable external sources (eg user input or database queries). The data now available for the home/shared IAD can be provided to other MHO-enabled end systems so that they can make handover decisions that suit their own requirements. In particular, time-consuming and expensive information collection by end systems should be avoided.

Therefore, the provision of this information does not have to take place at all, but can also be limited according to different criteria, which can especially depend on the end system using the information.

Cost considerations for switching decisions/settings:

Handover decisions from users can be influenced and made by taking into account cost factors such as roaming charges, paid services of (mobile) networks (eg VoIP, GSM, etc.) or additional supplementary services. These considerations and the user's final decision can be implemented as user defaults or presets, respectively, under which conditions the handover should be performed.

Backups and reminders:

On the other hand, in the case where the communication connection is interrupted, or even if the communication connection cannot be performed or established, information that facilitates information may be provided, for example. Via SMS containing information about the loss of the communication connection and/or a timely reminder of re-execution/establishment of the communication connection and/or a convenience message where the communication connection can be re-executed or re-established.

Controllable handover from one end device (eg mobile phone A0) to a second end device (eg mobile phone A1) of the first end system and/or the second end system:

In order to achieve cost reduction and/or in case of quality problems and/or in order to provide greater convenience (eg hands-free function) etc., from a terminal device (eg mobile phone A0) to a first terminal system and/or a first terminal system The controllable handover performed by the second terminal device of the two-terminal system (eg mobile phone A1 ) can be performed.

User-specific information such as cookies:

User-specific information, such as cookies, may also be implemented to enable the storage and execution of important basic settings reflecting the user's actions and/or decisions regarding past handover executions. Allowing these cookies to be stored and/or executed may be a user's preference and may have the consequence that future requests/information/offers will be increasingly relevant to the user and tailored to a particular user's personal needs and preferences. Cookies can be implemented on IAD devices as well as on mobile devices.

Claims (11)

1. A method for providing information to at least one of a first end system and a second end system, the first end system and the second end system being connected by a network and subject to a potential, actual or completed handover procedure, the method comprising:

providing convenience information regarding at least one potential handover procedure to at least one of the first and second terminal systems, the convenience information relating to the user and/or the handover network to which the user is being transferred,

wherein the convenience information relates to factors for determining measures to take to perform the potential handover, and the method is in accordance with one of:

a) the factors are related to cost factors including roaming charges, paid services of the network or other additional supplementary services, and the cost factors are provided to the user of the first or second terminal system in order to influence the handover decision of the user;

b) the factors are related to potential handover from a terminal device to a second terminal device in a terminal system, and the factors are used for providing user setting execution measures to execute the handover from the terminal device to the second terminal device; and

c) the method further comprises identifying and storing user specific information for performing basic settings reflecting past user behavior for automatically performing measures for performing a handover.

2. The method of claim 1, wherein the method comprises a) and the cost factor is used to provide a user setting for performing the handover performing action.

3. The method according to claim 1, characterized in that the method comprises a) and the cost factor is used to define the conditions for performing the handover measures.

4. The method according to claim 1, characterized in that the method comprises a) and the cost factor is used to implement the final decision of the user as user default or preset under the condition that a handover shall be performed.

5. The method of claim 1, wherein the factor relates to a status of a Li connection between the first terminal system and the second terminal system, wherein the Li connection is used to conduct a communication process between the first terminal system and the second terminal system.

6. The method of claim 5, wherein the status is one of an interrupted Li connection, an unexecuted Li connection, or an unestablished Li connection.

7. The method of claim 6, wherein the status is used to provide information about the loss of the Li connection, information to remind of re-performing or re-establishing the Li connection, or information about whether the Li connection can be re-performed or re-established.

8. The method of claim 7, wherein the information is provided via an SMS message.

9. The method of claim 1, characterized in that the method comprises c) and further comprises evaluating ongoing user behavior for potential modification of the user-specific information, such that future convenience information provided to the user will be increasingly tailored to the needs and/or preferences of the user.

10. The method according to claim 1, characterized in that the method comprises c) and the user specific information is stored on the mobile device of the terminal system in the form of a cookie.

11. The method according to claim 1, characterized in that the method comprises c) and the user specific information is stored in the form of a cookie on an Integrated Access Device (IAD) associated with the terminal system.

Images