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

Method for providing information to at least one of a first terminal system and a second terminal system

This application is a partially continuous application of co-pending application number 13/683,733 filed on 12/11/2012, said application 13/683,733 is a partially continuous application of application number 13/177,346 filed on 6/7/2011, said application 13/177,346 is now U.S. patent number 8,351,395, said U.S. patent number 8,351,395 is a divisional application of application number 11/969,388 filed on 4/2008, said application 11/969,388 is now U.S. patent number 8,014,364 claiming priority from 35USC 119(e) to provisional application numbers 60/889,341 filed on 12/2007, provisional application number 60/895,238 filed on 16/2007, provisional application number 60/910,384 filed on 5/2007, and provisional application number 61/014,157 filed on 5/2007.

[ technical field ] A method for producing a semiconductor device

The present patent application relates to a "web surfing" method for a terminal system a0, which has a real or virtual home network integrated Access Device a0-homeIAD0 and an a0 connection to a second terminal system Z0, for "Managed Handover (MHO)" of the terminal system to a real IADx in a wireless local area network x (anwlx) or to a virtual IADx of a mobile network x. Controllable switching is supported by a0-homeIAD 0.

The a0 connection is typically relayed through a controllable handover Module (MHOM) controlled by the MHO-Specification (MHOs) in a0-homeIAD0(a0 home IAD 0). This provides advantages for the operator of sharedIADx/A0-homeIAD0 (shared IADx/A0 Home IAD0) and the user of the operator's home terminal system (homeTerminal systems).

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

[ background of the invention ]

The prior art handover technique US2006/0099948a 1in the description of its background section and its method accurately illustrates the prior art of "seamless handover, seamless HO", and in particular the prior art of "Media Independent Handover (MIH)". More generally, "IEEE802.21overview-Publication" (DCN 21-06-0706-00-0000) by V.Gupta et al, UCLA CSD-TRNo.040012 by L.J.Chen, Conference statement by G.A.Mills-text et al ("Mobile Voice IP (MVOIP) … …" 21 st time IEEE International Performance, Computing, and Communications Conference statement by 2002) and "Open Accetwork", television Research and development 2002 by E.Edvardsen et al or "Open Accetwork", WLAN Access networking 2006, Conference Publication 2006, WLAN Access 2006, and communication Conference Publication ", by P.A.Fragment et al, or" Open communication distribution "(" WLAN 2006-Publication 2006 "and data), different versions of the field communication ST-978, discussed in the patent article, Inc. Gupta et al. A related and complete review of the schiller work ("Mobile Communications", Addison-Wesley,2003) discusses extensive instrumentation for internet Mobile technology for future generation switching technology.

These papers describe carefully the prior art of handover and show that the prior art of handover does not implement the innovative features of the netsurfing method, i.e. the features of the netsurfing method:

■ is adapted to support controllable handover support (MHO-support) of current WiFi or FMC phones and shared WLAN-IAD (shared WLAN-IAD), and in particular to WiFi/FMC phones by abandoning technology not currently common to WiFi/FMC phones (not yet) yet

■ are adapted to provide advantages to homeIAD/sharedIAD operators and end system users in the event that such advantageous use is shielded from any other network operator.

With respect to internet mobile technology and a "Handover convenience information Support method" (HOCIS) (PCT/EP 2007/010485 on3, 12 th 2007, the contents of which are incorporated by reference in the present application, so-called "incorporated contrast documents"), the web surfing methods have at least one additional technical feature, respectively: the possible tunnel-free relaying thereof (i.e. the first feature described above) or the technical communication thereof is used to implement the business measures of the homeIAD/shared iad operator (which are usually carried out for both end system users in a VoIP call, usually by means of different messages to both, specifically at the time of a handover of one of the two end systems and then to correlate the convenience information (i.e. the second feature described above)). Neither the prior art of handover nor the prior art of internet mobility (the latter with its evolution in a similar direction, WO2006/031379a1 and WO2006/031384a1, which however specifically exclude telephony/VoIP Applications) implement both technical features (no tunnel relay or additional (commercial) communication technically correlating "convenience information"), nor do one of the HOCIS method and the "originated Call (Sponsored-Call)" method (see for example "ARGELA Multimedia conference Call White Paper" on the respective web page or "Rich Multimedia Applications on IMS Framework" in 8 months 2007) implement both technical features as such.

[ summary of the invention ]

The present patent application discloses a "web surfing" method for a terminal system a0 (the terminal system has a real or virtual home network integrated Access Device a0-homeIAD0 and an a0 connection to a second terminal system Z0) for "controlled Handover (MHO)" of the terminal system to a real IADx in wlan x or a virtual IADx (IAD) to a mobile network x. Controllable switching is supported by a0-homeIAD 0.

The a0 connection is typically relayed by means of a controllable handover Module (MHOM) controlled (both implementations distributed or local) according to the MHO-Specification (MHOs) in a0-homeIAD0, which provides advantages for the operator of the shared IADx/a0-homeIAD0 and the user of the operator's home terminal system (homeTerminalsystems). MHOS is proprietary to the a0-homeIAD0 operator and is individual to the home terminal system if necessary. This relay control provides the following advantages:

■ provides shared IADx operators with the following advantages in terms of web surfers in a 0: the web surfer is no longer a legal risk to the shared IADx operator because the homeIAD0 is identifiable to a0 and thus the operator of homeIAD0 is legally responsible for internet abuse by a 0.

■ provide advantages for the homeIAD0 carrier and all shared IADx carriers with which it cooperates, for example

The controllable handover version (MHO-versions) of web surfing of the IAD0/shared IADx home terminal system, and the consequent significant cost reduction/quality improvement potential of the IAD0/shared IADx home terminal system operation,

the commercial possibility for the homeIAD0/shared wlan operator, the message "convenience information relevance" (CI-relevance) with the "HOCIS" information generating the receptivity and the resonance by the homeIAD0/shared wlan operator and, if necessary, the convenience information relevance to not only the network surfer but also to the interlocutor of the network surfer (to be precise, technically and contextually satisfactory, i.e. designed differently, respectively),

security exploiting these advantages (i.e. exploiting them independently of the third party, if necessary even invisible to the third party (e.g. the intermediate network operator)) (however this does not preclude the support of the WLAN surfing method by the other party (e.g. the network operator).

End system users are provided with advantages because they find more open shared WLANs (for the reasons mentioned above) and their controlled handovers (MHOs) especially to these shared WLANs are more comfortable for them than today, especially due to the "convenience information dependency" of controlled handovers.

In contrast to the functionality of the "Home Agent" of internet mobility technology, the functionality of MHOM (with or without MHOS) is limited/extended on L3 to L7 of OSI-RM (open systems interconnection reference model) in order to be able to implement the handover management also with the current WiFi/FMC phones and shared WLANs without knowledge of suitable tunneling technology or to be able to exploit the advantages described above. That is, the web surfing method is for VoIP telephony for a short period of time, and more particularly for "WLAN surfing" (aka W surfing) in VoIP calls, the example of section B describes the features of this "WLAN surfing", security/privacy for WLAN surfing (see section C) and commercial exploitation for WLAN surfing (not limited to similar situations).

To emphasize this, the application possibilities of the W-surfing method are indicated, for example, in the case of IP-TV transmissions (instead of VoIP transmissions or the accompanying case), or in the case of real-time accompanying, for example, of the security-oriented users of a 0. In all these communication applications, all the following explanations of W/web surfing are equally applicable in the case of VoIP communication applications. Therefore, VoIP communication applications may be seen as representative for a variety of other application possibilities for the method/device according to the invention, which are only occasionally mentioned in the following.

The small homeIAD can enable access to at least one terminal system (e.g. a telephone and its user) by accessing itself and support access to at least one network in the above sense, for example access to the internet and/or the PSTN, wherein access to at least one network is performed as follows:

■ are made via the wireless network and an arbitrarily definable area in the wireless network, for example the reachable range of an IAD or an arbitrary (if necessary total) area of a GSM network, or

■ are made through a physical connection such as a telephone cable or coaxial cable.

A WLAN in the present context can be implemented, for example, on the basis of "RFI (radio frequency interference)" or "BlueTooth" or "Femtocell (home Base Station or Femtocell)" or "DECT (digital enhanced cordless communication)" or "Wimax" or "GSM/CDMA/UMTS/GPRS/HSPDA/…" technologies, in particular on the basis of "WiFi" technologies, including, if necessary, Base Stations (BS) of a mobile network and/or various IADs (previously erroneously referred to as APs, APs) and extending over an arbitrarily defined area of reach of the IAD or Base Station. A large homeIAD/homeServer may enable network access for thousands of end systems and support them in the sense described above, i.e. for example the homeIAD/homeServer may be an internet server or system of one of these networks.

MHOM consists of abstract (i.e. functional) hardware (hardware, HD)/Software (SW) components. MHOM needs to use its abstract hardware components not only for its MHOM functionality (also known as web surfing functionality), but also for the purpose of adapting abstract applications of MHOM functionality to be shared with non-MHOM on at least one function (i.e. "abstract resource sharing" between modules, see section C). The MHOM can be located in any "physical" Host System (Host-System) (e.g. hosted by a physical IAD or physical System in or on the network), for which the IAD/System does not require a physical hardware extension (see end of part C). The software components of the MHOM (in the host system of the MHOM) may also be present encoded elsewhere in some way (however in such a way that, before the functionality of one of these software components is needed, the part of the software component responsible for the functionality can be translated into semantically equivalent code and can be loaded into the host system and can thus be executed by means of the above-mentioned MHOM hardware component.

The web surfing method is a communication application (according to MHOS) that is typically located on L7 of OSI Connection/Connection OC0 between a0 and Z0 (see below). Regardless of whether the MHOM functionality is implemented partially or completely within the WLAN0 (and thus for example in the IAD0 controlling the internet server/network system) or externally (and thus for example in the internet server or network system and thus externally of the IAD0 controlling the internet server/network system), the communication application may be supported by functionality in the terminal system a0 and/or Z0 (which generally promotes the comfort of web surfing, but which may also be omitted).

The legal protection measures in the form of shared wlan (shared wlan) applications for web surfing (e.g. mobile phone a0 calling Z0) referred to above are implemented as follows: the use of web surfing according to the invention, e.g. the use of shared IADs, is limited to the use of web surfing only as a router to only MHOMs with fixed IP addresses, i.e. to known operators. The MHOM operator can undoubtedly identify the responsibility of OC0 relayed by the MHOM operator (if the operator has done the relay at all and then, for example, at the start of the call or earlier (as is not relevant here, but the skilled person knows the methods suitable for this)). Thus, the MHOM operator is responsible for the identity determination of the wireless telephone user on the shared IAD (rather than the operator of the shared IAD). Note that unlike this, when an emergency call is involved (which is currently fully legally open), the MHOM should be able to achieve access to the internet routed to it for a0 (and thus for a0 to Z0 VoIP calls).

An exemplary implementation version of the legal aspect of the web surfing application form of sharing IAD is outlined at the end of this section B. However, first, the user viewpoint of the switching technology core of the W surfing method is shown only by way of specific examples, in which MHOM0 is integrated into homeIAD0/homeServer0 of terminal system a 0. Fig. 6 through 8 and their description in section D discuss separate versions of functionality used herein. Section C illustrates the commercial core of the web surfing method and its "convenience information relevance".

[ description of the drawings ]

FIG. 1 illustrates an example of a mobile terminal A0 moving between different WLAN areas in accordance with an aspect of the present invention;

FIG. 2 illustrates an example of a mobile terminal A0 moving between different WLAN areas in accordance with another aspect of the present invention;

FIG. 3 illustrates an example of a mobile terminal A0 moving between different WLAN areas in accordance with another aspect of the present invention;

FIG. 4 is a flow diagram of a handover process in accordance with an aspect of the present invention;

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

6 a-6 e show examples of telecommunication device arrangements to which the method according to the invention can be applied;

figures 7 a-7 e show additional examples of telecommunication device arrangements to which the method according to the invention can be applied;

fig. 8 a-8 e show additional examples of telecommunication device arrangements to which the method according to the invention can be applied.

[ detailed description ] embodiments

Fig. 1 shows the simplest W-surfing case (also known as a web-surfing case): the mobile terminal system a0 of TCP (technical communication process, see section C), for example, FMC phone and its user, is controllably handed over (MHO) directly or indirectly on path 1 or 2 from the homeWLAN0 (abbreviated W0, synonymous with homeIAD 0) of the mobile terminal system into W1 intersecting the homeWLAN0 or into W2 not intersecting the homeWLAN 0. The L7 connection of OC0 exists between a0 and Z0 unaffected by these controllable handovers (MHOs) on path 1 or 2. 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 respective IAD1/IAD2 through MHOM0 to the homeIAD0 of W0. Details of this are disclosed by internet mobile technology (see section a).

Note that there is no restriction here on how the respective L3 connections (s-segments) between the mobile end systems a0 in W1 or W2 and the homeIAD0/homeServer0 of W0 are established during MHO: the present patent application then includes all the completely different possible scenarios of this L3 connection establishment between the L3 entity in a0 and the L3 entity in MHOM 0. For example, if a0 is a telephone, the L3 connection can be formed in particular by a0 calling the MHOM0 and vice versa (or the L3 connection can be present from the beginning (the technical details which are advantageous for this are irrelevant here)). This also applies to the "brand new start" of the current WiFi/FMC phone a0 outgoing phone call Z0 from wlan x, in order to achieve the brand new start, the MHOM0 on L7 (in IAD0) must be properly designed.

From the discussion of "direct MHO" (i.e., directly controllable switching from one WLAN to another), it is easy to think of how "indirect direct MHO" functions according to the present invention, so that in direct MHO the two WLANs (between which end system a0 switches) do not overlap each other spatially or temporally (see WLANs W0 and W2 and path 2 in fig. 1).

Two cases are to be distinguished here:

■ are in "no WLAN" range, either spatially or temporally, and no other networks are available for a0 (either for technical or regulatory reasons). In this case, no information transfer takes place in a0-OC0 to Z0 in this range, since a0-OC0 to Z0 has no continuous L3 connection between a0 and Z0. The L4 to L7 connection in a0-OC0 is not relevant and may remain present if necessary, so that the communication currently between a0 and Z0 may continue by means of a0-OC0 (i.e. a0-OC0 of the aborted TCP) and proceed, once a0 enters wlan x, a "W-surfing connection" may be established between a0 and homeIAD0/homeServer0 (and its MHOM0) for a0-OC0 by means of the IADx of wlan x.

■ there is another network available for use by the A0 in the "no WLAN" range, to some extent a W-surfing alternative network, such as a GSM/CDMA/GPRS/HSPDA … -based mobile network or a fixed network. If the first example is not changed and it is assumed that a0 is a FMC phone and accesses the mobile network (see below), a W-surfing connection is established for a0 over the mobile network (again, the details may not be taken into account here) between a0 and homeIAD0/homeServer0 (via MHOM0 of homeIAD0/homeServer 0). In case a0 subsequently enters W2 and is registered in W2, then (if necessary after the security check according to the invention in MHOM0) the mobile network based W surfing connection of a0 is replaced by an internet based W surfing connection of a 0.

From the detailed description of the "calling end system" MHO of a0 (i.e. "caller web surfing enabled", as shown in fig. 1), it is easy to think that there is also a "called end system" MHO, i.e. "callee web surfing enabled" of a0 "(see fig. 2). For the latter web surfing version, the same applies as described in the preceding paragraph, where MHOM 'may here be located, for example, in IAD' between the internet and the terminal system Z0. M ' is able to implement WLAN handover of a0 and the W surfing connection between a0 and M ' is made by means of exactly the same MHO functionality as M, i.e. M ' is also MHOM (however especially by reducing the internet abuse protection explained above).

Finally, it is to be noted that OC0 between a0 and Z0 can of course also be supported in both end systems by MHOM, i.e. MHOM0 and M', respectively (see fig. 3). In this case, the two MHOMs may self-responsibly "reroute" the L3 connection of OC0 between themselves (to thereby de-rate or otherwise improve their TCP) if desired.

Returning now to the above argument, the netsurfing method makes the abuse of the internet significantly difficult in supporting the caller's netsurfing, and more generally to some of the communication (security) technical aspects of the method according to the invention.

This argument for internet abuse difficulties is appropriate, as any such abuse would seriously affect the more easily identifiable (because e.g. long-term invariance) operator of MHOM M0, so that the operator would protect himself from such abuse in such a way that the operator only provides his sufficiently well-known person with access to his MHOM. Additionally, an implementation version may be used in which, for example:

■ (after MHOM M0 is additionally informed in some way of the reasonableness of the W-surfing connection, such as by the "a 0 tracking system" or actively by a0 via GPRS or SMS etc.) only MHOM M0 can initiate the W-surfing connection of a0 so that shared IAD1 cannot even start establishing the W-surfing connection successfully, since each such attempt has been rejected by MHOM M0 in homeIAD0, either alone or else

■ when an unknown terminal device (here, for example, a0) moving over the IAD1 is to surf W using the IAD1, the terminal device does not determine its own MHOM0 (for example, by initially briefly "Blind-calling" the IAD1), but rather the IAD1 forwards on schedule all these wishes for the unknown content of the IAD1 to an identity check server trusted by the IAD1, and the identity check server first establishes itself a connection to the MHOM0 (where the identity check server is shared by the IAD1, for example, by a credit card institution or ISP or chain store or the like), if necessary.

The web surfing method then allows implementing completely different methods that can relieve the shared IAD operator of all legal risks in "VoIP surfing" or "IP-TV surfing", as can also be referred to as the technique according to the invention. Appropriate dependent security-oriented method claims concretise such a situation. It is evident that the scope of the W-surfing method allows specific implementations that practically completely eliminate these known WLAN sharing risks.

Finally, in this context, the communication state CS is to be noted: for example, the communication state may be changed in time/location/external control (to some extent "independently") (and thereby also change the admissibility/disapproval/rationality of the web surfing connection between a0 and its homeIAD0, even if a0 itself does not change in location at all). More description of this is contained at the end of section C.

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

The description of the method/device according to the invention in this context (as well as its terms and concepts) is purely functional, i.e. completely abstract, that is to say absolutely not relevant for a physical implementation. For the sake of explanation, possible physical implementations of the methods, devices and schemes/concepts/terms are occasionally set forth. It is to be noted here that the following description of these terms/concepts (generally in OSI-RM sense) is only intended to explain (the nature of) the method/device according to the invention, i.e. without a principal explanation of other communication technical problems.

The Handover (HO) of the terminal system and its TCP, also known as handover procedure, i.e. its handover, takes place between at least two of the communication networks or access points of the networks or functional features on the access points of the networks. The invention then considers not only "vertical" HO, i.e. handover between different networks, but also functional features of the same network and/or handover between access points, so-called "horizontal" HO, and any mix between all the above handover types.

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

■ the abstract "communication process" (also known as "telecommunications process", TCP ") is carried out between a plurality of human and/or non-human" users "(subs) who are" users "(see below) of" end systems "(see below) in their respect (or their representatives/parts of functions/supplementary functions, such as call answering machines, mailboxes, MP3 players, IVR systems, files/scripts/images/symbols/speech/…/Dual Tone Multi Frequency (DTMF) generators/DTMF detectors/translators/filters of active and/or passive type, in general:" communication application systems "(see below)) and belongs to end systems which have access to at least one network. The network/end system/user collectively complete the (abstract) technical implementation of TCP.

Here:

the communication process, also known as TCP:

a communication process is called "potential" if, despite the specific measures being carried out for the communication process, no specific measures have been carried out in the devices of its TCP end systems (i.e. first in at least one TCP-subsc of at least one of the TCP end systems, see below) at least in the TCP end systems participating in the communication process;

if a specific measure has taken place in at least one such terminal device, the communication process is referred to as "current", and;

in either case, the communication process is referred to as "initiated" or "initiated";

if a specific measure is no longer implemented in the TCP end device in which the communication procedure is involved, the communication procedure is called "retrospectaly" also known as "finished";

that is, a communication process is referred to as "present" or "existing" in all of these cases.

It is noted that TCP is started/started at the latest when at least one measure related to the communication procedure is started/started in at least one terminal device (e.g. a phone) of one of its terminal systems (e.g. picking up a telephone handset, or locally inputting/outputting the telephone number of the intended caller or only locally selecting the telephone number of the intended caller by some participant of TCP, or manually or automatically starting a timer to make a call at its end, etc.).

O Current TCP is

"connected State" until SUBC data exchange has been initiated in the current TCP;

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

once the SUBC information exchange has been initiated, the current TCP is referred to as "running";

wherein the exchange of at least one "SUBC data" or "SUBC information" of a TCP-SUBC is initiated upon initiating an exchange between at least one TCP end system and at least one network currently used by the end system. The subsc data or subsc information is information that is finally/originally detectable/producible by the subsc and is output to/by the subsc (human or non-human) or is input or selected by means of the terminal system.

The difference between the SUBC data and the SUBC information is that:

the subsc data are typically exchanged only for the TCP management (set up, interrupt, …, end) or the OSI connection of the TCP or its Li connection (i.e. typically during the Li connection set up and/or start-up) that is required if necessary, and

the SUBC information is exchanged for TCP purposes, i.e., during TCP operation (i.e., not for technical set-up/technical management of TCP as described above),

in both cases, this takes place between TCP's (corresponding if necessary) subss or the above-mentioned representatives/partial functions/….

■ The communication technology concepts/terms used in The present patent application are defined in The International Standard "ISO 7498-1Information technology-Open Systems Inter connection-basic reference Model: The basic Model" abbreviation: in the ISO/OSI-reference model or OSI-RM. This forms the basis for a binding theory/concept of the present patent application for a person skilled in the art.

The wording of the web surfing method/device according to the present invention in most of the claims, although written in its "pseudo-natural language", is based on the terms/concepts defined in OSI-RM, that is to say there are already accurate representations/limitations of the communication technology of OSI-RM, which remove the uncertainty of its "purely natural-language" meaning.

The description of the web surfing method/device according to the present invention also uses OSI-RM terms/concepts as much as possible, e.g. OSI-connection/PDU/SDU/layer/Li-connection/…, which belong to "artificial" terms/concepts of OSI-RM (that is to say, are avoided in the wording/meaning of the claimed pseudo-natural language). The description thus exploits the definitiveness of the expressive power of the person skilled in the art by OSI-RM nomenclature/concepts specialization (some of which have been mentioned above, for example). This is considered by the person skilled in the art as helping himself to confirm a correct understanding of the essential description of the pseudo natural language description of the web surfing method/device in its respective independent claim.

The following description of the use of OSI terms/concepts and in particular of OSI-RM terms/concepts in this context is intended primarily to be given:

on the one hand, these terms/concepts cannot be fully generalized here, so that reference is made to the above-mentioned international standards as a compensation, where in case of doubt the text is decisive, and;

on the other hand, the text is somewhat simplified/roughly described in several places with respect to the case in MHO (see below and section D).

And finally it is also emphasized that the dependence on OSI-RM terms/concepts is indispensable in the present patent application: the "internet jargon" which is currently dominant in practice is far from the conceptual certainty desired for legal documents (in order to achieve conceptual certainty, at least the language/concept confusion of communication technologies that have become more and more common is corrected, and OSI-RMs are finally developed). The determination of the concepts of the present patent application is not intended here to be solely used for determining the meaning of the main claims but also for making the description of the method/device according to the invention easy to understand/precisely understood (and especially for countering possible attempts to bypass the claimed scope of protection, these attempts being intended to be drawn to the extent that it is intended to narrow the scope of protection by way of limitation and likewise by way of description only, since no limitation is indicated as being impermissible in this patent application.

Furthermore, it is not allowed to confuse the following highlighted in the above paragraph:

emphasis in the previous paragraph on the absolute necessity for borrowing OSI RMs

The idea that underlies OSI-RM is also attached, that is, a clear description of a complex system (regardless of origin) always requires an abstraction of many (physical) implementation details of the complex system and an unconditional focus on the functionality of the complex system (thus abstracted).

Rather (with the last-mentioned requirement in mind), the OSI-RM may first of all define basic concepts, concepts and terminology on this basis, which are very helpful or even necessary for a clear description of many aspects of, in particular, communication systems.

■ in each "n-point communication process" (n > -2), there is an abstract "OSI connection" between any two of its terminal systems, for example between a0 and Z0 (which connection also extends to the communication applications in the two terminal systems, as explained below.) according to OSI-RM, each OSI connection is essentially always divided according to OSI-RM into at least 7 "abstract" Li connections "above each (1< ═ i < (7)), by means of which the communication process between the two terminal systems a and Z takes place (where" L "stands for" layer ").

The OSI-RM thus defines (based on its "7 layers" of "abstract meaning" which is always the same principle of Li connection in any OSI connection) an "OSI communication architecture" which is based in its own right on a "7-layer structure" of the basic abstract meaning of all OSI connections. OSI-RM designates the basic 7 abstraction layers of its communication architecture (completely independent of the respective OSI connections) as "Li", 1 ═ I < ═ 7, respectively, in a conceivable way.

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

O L7 connection (i.e. i ═ 7), for which another L7 connection may be used, and

the L1 connection, for which "physical media" is usually used,

where an Lk connection (1< ═ k < ═ 7) can be used by multiple OSI connections, or in an OSI connection by multiple Lk + i connections (1< ═ i < ═ 7-k).

The L7 connection of the OSI connection is often referred to as a "communication connection", since the only important thing in the L7 connection is "communication" in the sense of the particular TCP process on which the OSI connection is based or "communication application system" which supports the TCP process (the latter being located in at least these two terminal systems of the OSI connection). That is, the L7 connection is completely abstracted from the forms of information transfer (═ L1 to L4 functions), information partitioning (═ L5 functions) and information representation (═ L6 functions) used in communications (of the communications applications driven by human SUBCs therein as necessary): the L7 connection is only aware of "interactions" in the "communication application" communication.

As soon as one of the TCP-s starts it in one of its Two (TCP) end systems a0 and Z0, i.e. as soon as it exists, that is to say both (OC0 and its TCP0) may be "potential" at the moment or not (see above), the OSI connection "exists" between a0 and Z0. That is, there is an L7 connection of the a0-OC0-Z0 for the TCP0 from then on between a0 and Z0. The connection remains present until both TCP-subscs consider the TCP to end (which in OSI-RM would be understood to be the end of the L7 connection and the OSI connection). TCP also remains behind as "past" TCP (see above) and is thus somewhat primitive with respect to modeling of TCP by OSI-RM.

In other words, the OSI connection (of TCP)

O locally not only "exists" between the Two (TCP) end systems a0 and Z0, (more precisely: there is an L3 connection of the OSI connection between the two end systems a0 and Z0) but also an L7 connection by means of OSI connections existing between the communication applications and even between the TCP-susbcs of the end systems a0 and Z0, and

it exists in time as soon as the TCP starts in one of its subacs (in particular the L7 connection of the OSI connection exists between the subacs of the TCP from that moment on (and remains present until both subacs consider the TCP as finished).

Accordingly, the OSI connection exists at the latest starting from the following: from this point in time, some measure has been taken for OSI connection/TCP in the terminal devices of the terminal systems in a0 or Z0 that create OSI connection (TCP-) subsc. According to OSI-RM and in the sense of the present patent application, this OSI connection has to date existed from the following: at this point TCP is already started in its SUBCs underlying the OSI connection, and this is also only preventive (e.g. by explicitly or implicitly confirming reachability to an emergency call number (such as 110 or 112) or reachability to its caller) itself).

At this point in time, however, any Li connection (1< ═ I < ═ 7) of the OSI connection need not be (abstractly) implemented or can be implemented. Thus, the presence of a Li-junction does not imply a (abstract) implementation or realizability of the Li-junction. And more generally: there are also at least 7 Li connections of an OSI connection accompanying the OSI connection, wherein however the Lj connection need not be realized abstractly for j (1< ═ j < ═ 7) (and the interaction of the Lj connection with other Li connections of the OSI connection (anti-positive OSI-RM does not take into account the physical realization/implementation)). The (abstract) implementation of Li concatenation only needs to exist in its current (abstract) use.

This implies that: for this TCP, the OSI connection remains present between the two terminal systems a0 and Z0, even if at least one L3 connection for transmitting L3 user data between a0 and Z0 is not (abstractly and/or physically) implemented (as often occurs in HO), in particular at least in this OSI connection. The L7 connection of the OSI connection remaining present (at least its abstract and, if necessary, its physical realization) in the case of a handover can be ensured by means of the "HOCIS method" described above (see section a and below with reference to "convenience information correlation").

■ the abstract "end system" contains, in addition to its abstract human and/or non-human users (═ user automation) and/or its above-mentioned representatives/parts of the functions (all understood as TCP-subscs), abstract "end devices", the totality of which is also referred to below in the end system as "end devices", i.e. non-human functional groups, such as LANs, WLANs, mainframes, databases, PBXes, RASes, firewalls, functional groups of all types of switches, and functional groups of network access, IADs, I/O devices. The (abstract or physical implementation of the) set of non-human functions in the terminal system is often referred to below as a "module".

■ the abstract individual "terminal devices" of the terminal system can be considered individually from each other, in particular:

"terminal equipment of a user terminal", with an electronic/physical/acoustic/optical/"logical"/… user interface (generally movable herein, e.g. in a mobile phone);

"non-terminating terminal equipment" with its network-specific "Terminal Adapter (TA)" for the "network termination" of the network, wherein;

the user terminal and the non-terminal devices of the terminal system interact with each other via interfaces of physical/communication technology and/or other terminal devices, wherein only some of the devices are usually standardized devices, and

the non-terminal equipment (and even its TA and related NT) can be integrated in particular into the terminal equipment of the mobile terminal (e.g. mobile phone), (so that the former is also mobile).

In order to divide the terminal system conforming to the OSI-RM into abstract persons and abstract devices, it is to be noted that the OSI-RM apparently avoids the division of the terminal system, but that the OSI-RM ultimately implicitly performs the division of the terminal system very clearly. The reason for this is the mental necessity of the division of communication applications, which are typically on L7 in the end system, in order to understand them substantially. In the specification for L7 (relevant international standard ISO/IEC7498 and the same ITU-T Recommendation x.200, in particular page 32/33, 1994, and international standards corresponding thereto, such as ISO/IEC9545 and the same ITU-T Recommendation x.207, 1994), this necessity leads to the definition of a functional structure of an abstract communication application that conforms to OSI-RM, which logically enforces a functional division of a terminal system containing the abstract communication application, corresponding to the functional structure, at least in the context of these applications contained by these terminal systems.

In the present patent application, the above-described division of the OSI terminal system is a specific and particularly simple functional division (with correspondingly simplified terms for this division described above/below) in conformity with OSI-RM, i.e. the division of the OSI terminal system into different types of people and terminal devices therein.

■ the abstract "server" (also known as "server end system", also known as end system of an unmanned TCP user) is a functional group in or on a network (with or without the management of its network operator), which are also considered herein as end systems/end devices, however the latter cannot be divided into end/non-end.

■ the abstract "system" is a terminal system/terminal device or a network integrated computer.

■ at least one of these non-end-terminal end devices of the end system and thus the end system has "access" (whereby the end device can perform a handover, see below) to more than one network (or network access point of a network or network functional feature at a network access point of a network), to be precise by means of a corresponding "access point" of a network. Since these two terms are often misunderstood, the meaning of both of them (known to the person skilled in the art) is first clarified here (at least in a range sufficient for the present patent application):

the professional definition of "access" (in simple terms) is: when a terminal system/terminal device can communicate at a certain time on OSI layers L1 to L3 of its connection to a functional access point of the network in the following sense: in particular, if the terminal system/terminal device is enabled to perform data transmission with all terminal systems/terminal devices of the network that also have functional access to the network at that time, the terminal system/terminal device is functionally "connected to its network" at that time. It follows that the end systems/end devices of the network do not need to have constant access to the network (as is generally known in the case of end systems/end devices of mobile networks).

The "access point" to the network is here the transition point from the operator of the network to the responsible person of the end system/end device and their data transmission part in the legal/commercial/technical responsibility (functional capabilities of these three layers on the data transmission parts (DTSs) for the connection). The abstract terminating device on the network side of the data transmission part at the access point is called a "network terminator", NT, and the abstract terminating device on the user side of the data transmission part at the access point is called a "terminal adapter", TA. In the physical implementation of the network access point, the two conceptual functional units NT and TA can be integrated as much as possible (as is usually the case in mobile phones). (it is stated in particular in the case of mobile telephones, which are often referred to as "fixed mobile telecommunications (FMC) telephones" at present when the capability of the mobile network telephone for direct mobile network handover (direct mobile HO) relates on the one hand to the GSM/CDMA/satellite network and on the other hand to the WLAN), the mobile network telephone then supports, in a telephone call, not only the WLAN/VoIP technology using what is currently known in spoken language as fixed network technology, but also the GSM/CDMA/satellite technology known as mobile network technology).

From the explanations of network "access" and network "access point" with respect to their legal understanding in general for a person skilled in the art (the person skilled in the art also knows that these terms have other concepts, however they require an explicit name for their corresponding "reference model" (see: j. schiller, part a)), it is clear that a mobile terminal system/terminal device, in particular a mobile phone, that can be directly involved in a handover HO usually comprises one terminal and at least three non-terminal devices:

the terminal device of the switched terminal is by definition mainly used to implement a functional acoustic/optical/mechanical user interface of the communication process;

three non-terminal end devices of the handover are usually necessary, whereby the end system/end device can interact with two different networks/access points/functional features in the handover: they are present in functional "switches" for the functional data exchange between the terminal equipment, on the one hand, of the switched terminals and the TA/NT, on the other hand, of the respective function to/for the respective mobile network.

Finally, in the present patent application, the explanation of the concept of access point will eliminate the concept confusion that arises from the concept "Wireless Access Point (WAP)" of the newer technology publications for internet mobility technology in two areas:

on the one hand, the concept "Wireless Access Point (WAP)" is misleading to be used as a synonym for "Integrated Access Device (IAD)", i.e. as a synonym for a device. However, devices (abstract or physical) are slightly different conceptually explicitly compared to the set of rights-related responsibility transition locations on Li of the OSI connection (i.e., "access points" of the present patent application).

On the other hand, the abbreviation "WAP" has for many years already represented an absolutely different concept in the field of wireless technology, namely "wireless application protocol" (this has nothing to do with the concept of "access point", since the application is located on L7, whereas the network access points of different possible meanings are usually located on layers L1 to L3 (and the physical medium located therebelow).

The "handover HO" of the terminal system and its TCP (and their two OCs), also known as the "handover procedure HO" (in a similar sense to the above mentioned TCP (see in particular the contents thereof)), is called:

"potential" when its handover measures have not yet been carried out in the terminal for the handover/handover procedure, but at least one further measure is for this purpose carried out in the terminal (for reasons and in a manner not relevant here) and/or has been triggered in the terminal system, and;

"current", when this exchange measure has already been carried out in the terminal device;

wherein the end system/TCP is referred to herein as being "involved" by the handoff and "handoff" represents a change in the network and/or network access point and/or network traffic characteristics used by the end system (and its TCP and their two OCs) during handoff. In this case, a potential handover becomes current as soon as at least one such change measure is "started"/"started" in at least one of its terminal devices for the handover procedure, and the current handover is then "run" until all such change measures (successful or unsuccessful) have been carried out.

■ the two end systems of the OSI connection of TCP may belong to two different networks (as shown in fig. 1), so that the abstract "OSI Transit System" relays the OSI connection between the two networks (i.e. "Transit"/"link"/…). This abstract "relay system" is generally considered by the present patent application to be the end system of both networks, and at least the "transit system" of the OSI connection through which the relay is made. 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 (in the case where there are a plurality of Li connections relayed by the OSI connection in the relay system, the relay of these Li connections is performed individually and/or collectively).

It is to be noted here that this relay function of the transit system can also extend to the (abstract and/or physical) implementation of at least one potential OSI connection, i.e. in particular to at least one of the at least 7 Li connections that result in an OSI connection.

An example of such a relay system is a VoIP gateway between the internet and the PSTN/ISDN/UMTS, which is generally known, through which a telephone call/conversation between a0 and Z0 is relayed (at least partly) when the a0 terminal system is on the internet and the Z0 terminal system is on the PSTN/ISDN/UMTS. The skilled person also knows that the Li connection of the OSI connection between a0 and Z0 can (temporarily or permanently) pass through multiple relay systems: in this example, for example via a SIP server in addition to the VoIP gateway.

Another example of such a relay system is WLAN-IAD over the internet. The WLAN-IAD communicates with the WLAN terminal system via the "WLAN air interface" protocol of the IAD on L1 to L3, while the WLAN-IAD uses the corresponding internet protocol on L1 to L3 for communication with the internet terminal system (which would require a huge "protocol and data conversion" in the corresponding Li connection of the OSI connection relayed by such an IAD, the IAD may or may not change the protocol and data at the time of relaying for the L4 to L7 connection of the OSI connection.

Those skilled in the art know everything and know in particular to this that a Li connection can have a "tunnel" in order to generate an "IP address End-to-End validity" (IP-address-End-to-End-signifince) "(despite the mobility of at least one of its End systems of the OSI connection, see section a). Giving up the end-to-end validity of the IP address opens up the possibility of: various functions can be located in the relays (for example for the users of the terminal systems, i.e. the subscs of these TCPs, "a joint mixing of multiple TCPs with different subss in the relay, for example 'a suitable superposition of the audio channels of these TCPs' (see below for more on) which is important for the invention), i.e. in the case of the terminal systems of the subss abandoning such" mixing capability "(in particular because even the present FMC phones or PDAs (personal digital assistants) etc. do not have such a function). It is therefore to be distinguished whether a (possible) Relay of an OSI connection relates to such a Tunnel or not, so that for this purpose a distinction is also made between "tunneling-Relay" and "Tunnel-free Relay" which are limited in terms of the functionality of the Relay. The system can include/use multiple relays of different types for one or more OSI connections and then implement both relay techniques in parallel, if necessary. Accordingly, a distinction is made between two types of MHOs, i.e. "tunnel-less MHO" and "tunnel MHO", depending on whether a tunnel-less relay or no relay at all or a tunnel relay is required for this by the MHO.

It has thus been implicitly mentioned that the invention essentially (just as described in the HOCIS method) mixes the end system a with at least one "secondary tcp (stcp)", usually at least one further system Y, into the "primary tcp (ptcp)", of the end system a and the terminal Z. The simplest example is IP-TV-TCP of a with TV server Z as PTCP and VoIP calls arriving at a from Y during this IP-TV-TCP as STCP. If it is desired to implement the method of web surfing with the aid of current FMC phones, i.e. in this case MHO, for example in another WLAN, the mixing must be transferred for PTCP into the above-mentioned and in that sense "tunnel-less relaying" (which does not exclude the use of tunneling techniques which provide a complete simplification by systems capable of this in the method of web surfing.

Finally it is noted that MHOM of IAD et al can be used as an alternative to internet access to other networks, e.g. access to another WLAN through one of its IADs or PSTN access. If the information exchanged over the network is packetized, tunneling is in principle always available (in particular independent of the switching technology of the network).

■ "controllable HO Specification, MHOS" all the time

Associated with exactly one real or virtual (see below) homeIAD or homeServer (the unified abbreviation "homemix" as a representation) in which the MHOS does not have to be contained (where a number of hometerminalalsystems belong to the homemix, only the administrator of the homemix may define this so that the abbreviation reminds the MHOS of its security/privacy aspects),

only the administrator of the homemix may define the MHOS and assign it to his homemix,

knowing at least two types of "controllable HO measures, MHO-Me", which are executed in its MHO by means of the homeTerminal System controlled by the MHOS, to be precise by the homeMIAD itself containing the MHOS or by another system under the control of the homeMIAD, wherein at least one type causes at least one user to communicate, and

illustrates the synergy of its MHO-Me execution in executing MHO, where hereinafter for simplicity, homeIAD (rather than "homemix") is occasionally referred to.

Each MHO-Me execution that causes at least one user communication is an STCP in the sense of the PTCP/STCP terminology/concept of the HOCIS method described above.

In the web surfing method application, not all HO of a TCP on which it is based must be MHO, but MHOs causes at least one MHO in the TCP. The MHO is always controlled by at least one MHOS (i.e., a plurality of MHOSs, which may be defined differently, may be correlated to the control of the MHO.

The task of an MHOS of a homeMIAD is to determine in which MHO the MHOS controls which of the hometerminalsystems of the homeMIAD with regard to which of these measures, i.e. how which of the measures for the terminal system in the MHO interact with the other measures for this purpose. FIGS. 6-8 in section D discuss the distributed implementation of the MHOS (and the previous MHOM) and its implementability aspects.

In this patent application, MHO-Me types belonging to MHOS are:

the optional type of MHO-Me, "MHO control measures, ConMe", controls and performs the admissibility monitoring of the use of the network x by means of the hometerminalanystem in MHO and, if necessary, the establishment or appropriate management of tunnel-free web surfing connections/relays to a0 and this network x (i.e. for tunnel-free MHO) (see above and below).

By means of another optional type of MHO-Me, by means of "MHO-HOCIS measures, HOCISMe" (HOCIS ═ HO convenience information support ", see section B), various support measures are controlled and generated for the user of the homeTerminalSystem with respect to the current and current HO aspects of the homeTerminalSystem.

For the so-called "Comme-MHO" (which can be implemented without a tunnel if necessary), at least one "MHO business measure, the Comme" type, of MHO-Me is indispensable, while this type is optional for MHO. In both cases, the homemix with ComMe execution control may implement various business measures, such as advertisement types, during MHO or ComMe-MHO for its operator (and if necessary the operator of shared IAD that is in commercial cooperation with the operator). Here, the execution of ComMe always enables communication with TCP-SUBC as follows: the hometerminalSystemof the TCP-SUBC is just involved by the HO, where the TCP-SUBCS must or does not have to know about the communication (i.e., acknowledge in some way).

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 controlled by anyone.

For reasons of simplicity, HO itself (i.e. the basic process of MHO) is also considered as an optional "MHO-HO measure, HOMe".

Individual, specific such MHO measures are generally identified below by a trailing "0" (e.g. as in "comem 0" or "HOMe 0") and are provided with the prefix "MHO" for reconfirmation reasons.

Each comem-MHO is "CI-related" (CI ═ convenience information) in the following sense: this ComMe-MHO feature represents the case where, during ComMe-MHO execution, execution of at least one MHO-ComMe to which the ComMe-MHO belongs is made in association (implicitly or explicitly) with execution of the optional MHO-Me. Comme in tunnelless MHO need not be CI-related, but may be CI-related.

The CI dependency features of MHO-ComMe executions with at least one optional MHO-Me execution in ComMe-MHO (i.e. for example "ComMe execution with execution of HOMe and/or ConMe and/or HOCISMe etc.), which appear to be intuitively possibly directly understandable, are more precisely described below for security reasons.

In particular, explicit and implicit such CI dependencies are to be distinguished, wherein the two CI dependency types are completely independent of one another. A particular MHO-ComMe0 (and thus the web surfing method using MHO-ComMe 0) is said to be at least one of these alternative MHO-Me0 (both in the same web surfing method):

"explicitly related" (no relation to the order of implementation of the ComMe0 explained below with respect to at least one optional specific Me0 implementation order), when at least one message transmitted by the ComMe0 or the Me0 (during its execution) to at least one subsc describes each type of such association or is itself related thereto, and;

"implicit correlation" when the following holds: there is a TCP for this web surfing method, such that the (potential and/or current) HO of the end system for one of the TCP's subsc and TCP:

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

and the starting time of the execution of the Comme0 and/or its display in SUBC:

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

not later than 30 seconds after the termination time of the latter,

where whether/when/how the SUBC undergoes the Me0 execution is irrelevant.

With this association of ComMe (the homemix operator (more precisely its MHOS) performs the ComMe for at least one terminal system (and its user) managed by this operator/MHOS), the belonging ComMe communication is "well" placed in TCP (possibly forming the basis of the application of the web surfing method in a VoIP call). And the most advantageous setting of such commercial communications (not originally requested by the subs and thus likely experienced as interference by the subs) is made during the HO procedure. Here, the commercial communication may be designed such that it not only interferes with TCP/subs "as little as possible" due to the commercial communication, but TCP-subs even feels the commercial communication helpful at that moment, which decisively improves the customer acceptability/effectiveness of such commercial communication. Causing such "favorable moments" at as many HOs as possible is the task of this properly designed HOCIS behavior. Based on its CI correlation feature, which accepts all optional MHO-Me as the basis for correlation, the web surfing method can then in a simple way achieve the translation of the imaginary possible interference of a HO in a VoIP call into the just depicted convenience and commercial possibilities of that HO. The CI dependency (its name) of CommE-MHO may be considered convenient to produce, even though a CI dependency may typically be a HOCISMe dependency for optimal "efficiency extension" (efficiency) in a web surfing method.

At the end of this discussion of CommE-MHO, it is stated that it is expected by the authors of the present patent application that most MHOs of future web surfing (i.e. also in cases where CommE or its CI correlation may be omitted (see claim 2)) may implement the commercial exploitation of HO for CommE discussed above, as the cost/usage balance of CommE-MHO accounts for all participants.

The latter is slightly more precisely: the MHOS-/ComMe-MHO technique implements two foundations of the W surfing method according to the invention:

one of them is an economic basis, especially in the context of VoIP calls, making the homeIAD inside the company a new and useful spring of economic activity for its operators (as far as possible in the presence of a public shared IAD), and

another social basis is that, in all densely populated areas, in short and at lower cost, any person is provided with a more comfortable and more powerful communication technology (in particular for exploiting IP-TV capabilities) for his future multimedia terminal systems, than this situation is achieved solely by means of the current mobile network technologies (based on GSM, CDMA, UMTS, Wimax, etc. and their derivatives), which are rather largely reserved everywhere as "fallback technologies" in places where shared WLAN technology is not available or can not be used cost-effectively.

Some simple examples of the CI-related MHOS-/ComMe-MHO technique and descriptions of the technique may indicate this. By means of:

o optional MHOS0/Function1, assigned to a homemix 0, which homemix 0 decides before or at the beginning of HO of WiFi phone a0(a0 is the hometerminal system of homemix 0), whether homemix 0 allows execution of MHO to IAD1 by means of its current TCP/OC0 to another phone Z0 (MHO-ConMe), where this TCP/OC0 is relayed by MHOM0,

optional MHOS0/Function2, which is also associated with homemix 0, notifies both subscs of TCP of potential and/or current HO execution before or at the beginning of the HO described above (MHO-hoticme),

obligatory MHOs0/Function3 for ComMe-MHO, which is also assigned to the homemix 0, the latter (or its MHOs) implements commercial measures such as communicating advertising hints to the user of the homemix 0-hometerminator system involved in the HO or to both of its TCP's subs (where the additional technology communicates one or more times before, during or after the previous decision (which is immaterial here) and at any time (which is immaterial here) (-MHO-ComMe)).

From this small example it is clear that the execution of the MHO-ComMe takes place best when correlating with the execution of the preceding MHO-ConMe (where the CI correlation does not require the execution of the MHO-ConMe to correlate with one of the TCP subscs), whereas the preceding MHO-hicisme is executed first, where Cl correlation in particular in VoIP calls now uses the rule as a fact: the implementation of MHO-HOCISe is a rule that in any case always communicates with two TCPSUBCs. However, this does not mean: 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 is also possible in content, and of these MHO, the CI dependency of MHO-CommE and MHO-HOCISMe is insignificant.

In this case, the amount of the solvent to be used,

such decisions of homemix 0 (based on such MHO-ConMe) and their definitely communicable HOCIS measures and business measures can be interactively designed in a sense such as is commonly known to IVR systems (e.g., the way to interact with end system users on shared IADs supported by homemix 0 and with other business partners of homemix 0).

The MHOS may be provided with at least one communication state and this state is recorded/modified/analyzed by the homemix 0 (e.g. by means of its MHO-Me) and is considered, for example, in the above-mentioned decision and may have an impact on this decision described below.

The MOHS-controlled MHO-Me of homeMIAD0 may be constructed context-sensitively (i.e., designed differently, for example, during a potential TCP/OC compared to during an ongoing TCP/OC) and/or multimedia (i.e., copied to the SUBCs' end system, for example, after or simultaneously with the audio signal to the SUBC, in parallel and if necessary without affecting the VoIP audio information).

In any abstract and/or physical implementation of all MHO-Me types, any MHO-Me types may be most closely interleaved with each other such that the end system users they are involved in cannot recognize these MHO-Me types as individual types, and

the homeIAD operator can determine and distinguish MHOS of the same or different content, respectively, at least for one and/or all entities of its homeTerminalSystem (e.g. entities of the OC of the homeTerminalSystem and entities of the homeTerminalSystem itself), and the corresponding complex or very simple design. The latter means that only insignificant restrictions (for example, "new MHOM home system" and "new end system") are always specified in the MHO-ConMe, and that only insignificant user communications (for example, "when there is a risk of HO in the end system Ax > '1 x short audio signal' and 'current shared IAD-operator ID flash' and 'signal strength flash') are always specified in the MHO-ConMe"

' at the start of HO of the terminal system Ax > ' 2x audio short signal ' and ' current shared IAD-operator ID-announcement bye ' and ' signal transmitter flash '

' 3x audio short signal ' and ' new shared IAD-operator ID-announce halllo (harlo) ' and ' new signal strength flicker ' at the end of HO of end system Ax '

"upon HO failure of the terminal system Ax > '7 x audio short signal' and '3 x audio long signal'").

The communication of audio short/audio long signals can be seen as a hotisa me, whereas shared IAD-operator ID-announced undoubtedly (preliminary) communication of advertisement information. This MHO-Me can be specified globally for all the hometerminalsystems in the MHOs or optionally for individual hometerminalsystems therein, and the MHOs can also be preset in a fixed configuration (however this is not relevant here, since 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 a virtual or actual homemix is in the physical implementation (implementation form) of the W-surfing method a specification in this homemix, which is partly or completely entered in some way by the operator of the homemix and/or already contained therein and configured only by the operator, and/or is fixedly preset therein, and that the MHO-Me (associated with this MHOS) of the homemix is realized by the interpretation of this MHOS by the homemix. The skilled artisan also understands that any particular MHO-ComMe and its particular CI dependencies are not essential to the invention, but only the following facts: both are present in each MHOS (according to claim 1), so that each ComMe-MHO is in any case characterized by very specific technical features: "CI-dependency-limited" communication between a user of an "MHO (controllably switched)" end system and the homeMIAD of its end system to implement such an MHO-ComMe (however other MHOs may also have this feature).

■ the attribute "homemix private" of the MHOS is only used to emphasize the "privacy" indicated above for the homemix and only for the operator's MHO management measures of the homemix. It is noted here that an abstract homemix operator may be implemented by two different physical persons, and an abstract "operator" may mean "physical operator-person and/or physical manager-person".

This privacy then excludes the following: the second one (except for the homeMIAD as the first one) learns or sets up or changes the private MHOS for its homeMIAD, while the first one does not know or agree. These MHOS are inaccessible and unintelligible to the second, if the second is, in particular, an operator and/or administrator of a network of some type (which is not a homeMIAD network) or a service (which is not a homeMIAD service). This privacy does not however mean that the second one does not know or is not allowed to know which MHOS the homeMIAD operator can allocate to him at all. The encryption of this last required and known SUBCS information is not discussed here.

■ there are two types of homemiads: the "real and virtual homemix" types, both of which are optionally implemented both abstractly and physically. There is conceptually exactly one "logical" administrator and "physical" operator for each homemix (actual as well as virtual homemix). In the actual homemix case, its administrator and its operator are the same (this need not be the same in both implementations).

■ the preceding language usage has suggested that the terms/concepts "MHO", "MHO method (method)" and "MHO process (process)" and "MHO PDU" and "PDU" (PDU ═ protocol data unit) are sometimes used herein as synonyms (the terms are then for example simplified in their slightly rough sense) respectively (although this is not allowed per se in the first case, since abstract "process" is always an abstract application of abstract "method", i.e. its abstract "application instantiation").

■ further terms/concepts matching the context of the present patent application are now finally explained.

O "homeWLAN" also known as "homeNet": in this context, the terminal system a0 is administratively assigned to the homeWLAN, also known as homeNet, and at least one actual or virtual homemix according to the invention thereof. A0 is "homeTerminal System" for the 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 homeTerminal System A0 (person with WiFi phone). The WiFi phone a0 can then take advantage of any shared WiFi-WLAN Wx, also known as Netx, in W surfing/web surfing according to the invention if a0 can only "check in" in Wx/Netx (see below) and the homemix of a0 contains MHOS/MHOM according to the invention (and the MHOS/MHOM is ready to take a W surfing connection by means of the IADx of Wx/Net).

This commonly known homeWLAN/homeNet concept is first extended in this patent application to the WLAN/Net concept used herein (see section B). Secondly, the concept extends to possible "unrealistically" related hometerminalSystems, such as the above-mentioned A0, a telephone, wherein this unrealistic "home" feature of the terminal system can be generalized by CS to any IAD/Server (see below), such as the CS of the terminal system's own CS or its OC, or the CS of the terminal system's TCP, or its other terminal system's CS, or of the entire homeWLAN, or of the IAD/Server, etc. The CS may then have the effect that the OC of the end system or TCP may or even must be relayed through the IAD/server (e.g. by means of the MHOM actually hosting it), even if the end system is not (in the above sense) the actual hometerminalanl system of the MHOM/IAD/server at all. In this patent application, its actual and unpractical homeTerminal System belongs to the family WLAN/family Net/family MIAD/MHOM.

"Checking in": a terminal system a0 receiving electronic signals of, for example, a WiFi-WLAN or other network available for communication, in particular via the internet, can generally use the network for communication only after the terminal system has applied for the usage rights of the network to at least one of the terminal system's IAD(s) or base station or the like. If the terminal system is given the usage right, a0 is registered in the network. Wherein the procedures or protocols between a0 and the IAD/base station according to which the application and the rights to use or to provide/accept the network are made are irrelevant for the present patent application.

However, it is to be limited: when a0 is registered or can be registered in Netx, then a0 is considered "reachable" on Netx. It is sufficient if necessary that a0 be "W surf-registered" there, as illustrated in section D (where possible circumstances and implementations of such registration restrictions or limited registration possibilities are irrelevant in the present patent application).

"Network Surfing Connection (NSC)": this is at least one L3 connection of one OC0 segment of OC0 between a0 and Z0, i.e. an OC0 segment in/on WLAN x/Netx between systems S0 and a0, which WLAN x/Netx is different from WLAN0/homeNet0 of a 0.

O "Communication Status (CS)": it has been explained above that the characteristics of the TCP/OC for a particular communication application based on the W-surfing method (such as in TCP with particular characteristics, such as emergency calls or all types of reduced cost calls from or at a certain time, or calls to be monitored, or juveniles' calls, or certain remote networks or WLANs or location or event calls, etc.) may be the following: these features lead to the end system being handled with priority in the W surfing of end system a0, for example in such a way that its OC can or even must be relayed, by whom, as long as he is technically suitable for this (where the necessity/meaning of the priority is not taken into account in the present patent application for commercial or legal or other reasons, but only the fact whether the priority can exist or not).

However, the CS may also contain differential or other relay handling of the OC (by which IAD/server and how, until relay is completely denied, i.e. the "home" feature of the entity is denied).

The CS of the method/device according to the invention or the CS of the entity of OC0 (see below) then compromises this feature set of relaying of OCs.

"entity of OC0 (Entities of an OC 0)": li entities of the Li connections of OC0 are understood here as well as the Li connections themselves, at least one network required for realizing OC0 and, if necessary, further devices required for this purpose.

The method steps of claim 1 are shown in the flow chart of fig. 4. Fig. 5 shows the hardware/software components of the abstraction means of the device according to the present invention according to claims 14-16. The bus (1) is generally connected to: a memory (2) for storing, in particular, MHOM-SW modules, which modules comprise an MHOS; a processor (3) for implementing the MHOM function, in particular according to the MHOS; an output/input device (4) for MHO-PDU transmission/reception through at least one network; an output/input device (5) for exchanging at least one MHO PDU between an MHOM and at least one local, functional, non-MHOM module (optionally realized by a local coupling device with the apparatus of the independent device claim).

Accordingly, this document especially considers the abstract web surfing device which is composed of abstract hardware/software functional components, wherein the allocation of the functional web surfing device components to the hardware/software is completely irrelevant. Importantly, the abstract implementation of the functional components of the abstract web surfing appliance is performed by means of:

■ independent functional web surfing device hardware/software component, or

■ end system/IAD hardware/software Components that are functionally identical and/or functionally appropriate, or

■ other systems (such as an operating system and the functional hardware components managed by the operating system) are functionally equivalent and/or functionally appropriate hardware/software components.

Irrespective of the first case, then "abstract hardware/software resource sharing" takes place between the W-surfing device components and the functional components of the other mentioned systems. This abstract 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 instance. That is to say: an abstract implementation of a web surfing device in an abstract web surfing device terminal system/IAD may there use together abstracted hardware/software components (and abstracted hardware components managed by the operating system) that are functionally identical or functionally appropriate, e.g. for the operating system, by abstracted resource sharing.

And the reverse: the implementation of the abstraction of the web surfing device, which should supplement the abstract terminal system/IAD to be supported by the web surfing method, may for this not require hardware extensions of the abstract terminal system/IAD at all, since the abstract hardware components of the terminal system/IAD are sufficient for the implementation of the abstract device, i.e. the implementation of the abstract device can be realized by means of "abstract hardware resource sharing" with the abstract terminal system/IAD to be supported. This then also applies to the physical implementation of the netsurfing device terminal system/IAD by means of the physical terminal system/IAD and its physical hardware components.

The above discussion regarding the modeling of abstract hardware/software components of devices of a web surfing apparatus is intended to indicate the purely functional nature of the devices according to the wording/meaning of the claims, by means of which the implementation of the devices it is possible to decide by means of a concrete "web surfing suspicious" implementation whether or not the "web surfing suspicious" implementation falls within the scope of protection of the present text.

The present patent application is now primarily directed to embodiments of a web surfing method/device which are fully implemented (i.e. generally comprise only additional physical software components (due to the web surfing device)) with respect to the hardware components of the physical terminal system/IAD which are (should be) supported by these embodiments.

The physical implementation of the web surfing method can be entirely by means of physical software components, which is essential to the person skilled in the art. It is also immediately obvious to a person skilled in the art that all means of the web surfing device claims may be physically implemented by means of software components, as long as they are not based on the abstract hardware components of fig. 5, which may be physically implemented by means of physical resource sharing (see above). The scope of protection of the present patent application is not limited to these particular embodiments, but may include web surfing-specific hardware components, if desired.

D. Further description of the invention

This D part will help to avoid: the meaning and/or scope of protection of the present patent application is determined and limited to this according to its very limited exemplary embodiment (which, although "patentlogically" is inappropriate and strictly prohibited especially in patent law, has appeared in the right debate in their other patents to the authors of the present patent application and has thus greatly influenced the writing of the present patent application (rather than the claim wording provided abstractly by the authors' meaning and thus quite broadly) in all patent statutes (in relation to all other possibilities of interpretation/meaning determination methods of the patent) the way a patent is interpreted (i.e. meaning determination methods) in accordance with the claim wording of the patent is definitively prescribed in all patent statutes.

For both reasons, section D also describes the essence of the invention of the present patent application below by means of a somewhat more complex description of its method claims. Accordingly, further and similarly sophisticated remarks of apparatus claims appear unnecessary. Part D is then part of the description of the method/apparatus according to the invention.

Three aspects (some of which have already been mentioned herein) are to be mentioned at the outset:

■ there are no limitations not mentioned herein, in particular no limitations that are caused by the "general context" of the features of the method/apparatus according to the invention, no matter what person imagines such "general context" and how he designs, since he cannot be discerned with the content herein.

■ in that all claim wording/meanings of the present patent application are unique and solely define the features of the method/device according to the invention in their substance, nothing herein is intended to describe a physical implementation version of these features in a certain implementation form of the invention (rather these features are "functionally" also named "abstract", i.e. "purely conceptual").

■ the syllables "one" (in the absence of "at least") and all combinations/tilts/versions thereof mean "at least one" in this context (including the claims thereof), as long as such substitution is somehow meaningful.

Now with respect to claims 1 and 2: their first paragraph defines the basic terms/characteristics of the telecommunication arrangement by which the W-surfing method works.

■ it is to be reminded that in the present patent application the OC0 (see section C) according to claims 1 and 2 need only be latent. One known example of this is the following OSI connection: the OSI connection is conceptually implemented at the latest as the subs decides to start calling any emergency call number (e.g., 911 or 112), i.e., the OSI connection exists (potentially) from the moment the (abstracted) subs (as part of the abstracted terminal system a0) thinks of calling the connection. Another example of this is a potential OSI connection between a T0 user and a potential Z0 user, for the former, the latter is expected to be reachable when calling him, wherein for the moment of MHO it is assumed that there is already such a Z0 user (an assumption that the reason is not relevant here, however not unreasonable). In the case of using an IP-TV communication application, its potential OC0 exists at the latest when the user of a0 makes a "program selection" thereon.

Abbreviations of wording that are not valid herein are also indicated herein: when referring to "TCP between a0 and Z0," this is always understood as "TCP between each of at least one of a0 and Z0.

■ in another aspect, features already mentioned herein

In claim 1, "MHO-ComMe" and

in claim 2, relays of A0-OC0 are mentioned,

it does not implement the prior art method of HO or the method of internet mobility: such HO management features are not known at all so far (see sections a and C for this).

A short description is also made with respect to steps a) -b) in claims 1 and 2, wherein it should be clear from the prior art that there are other steps (not mentioned in a) -b) but obvious to a person skilled in the art) and which are therefore not mentioned here in any way, which are required for web surfing.

■ the implementation of MHO a0 to network x according to claim 1/2 is started by its determination of the presence of a reachability signal a0 to network x in at least one execution of the checking step a). Since the preceding description of the invention is not restricted in any way to this, the meaning of the expression a) is just intuitively imaginable: the presence of a signal (of any type and wherever determined in whatever way) indicates that: since a0 is/can be registered there, a0 can communicate in network x with all end systems on the entire internet by means of the IADx or BSx of network x and the homemix 0 of a0 and can reach from these end systems into network x (see beginning of B and end of C).

■ the abstract or physical implementation of steps a) -b) may be any time overlapping (those skilled in the art will for example know that no separate pre-check in a) is necessary in order to perform a) and b). Especially the examination a) is performed one or more times according to the wording/meaning.

■ execution of MHO according to claim 1 or 2 may in a physical implementation (in addition to steps a) -b) require/imply/make use of further steps that can be implemented automatically if necessary and/or include further or alternative optional MHO-Me, for example for making use of IP-TV. That is to say claims 1 and 2 do not describe at all any problems with 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 achieved. It is clear to the person skilled in the art that it may not be necessary to perform any of the method steps required for registration, whereby the MHO may start and/or execute and/or end according to a) -b) (as would be possible, in particular, in case the internet IPv6 is implemented onto the end systems/IADs/BSs/. That is, the web/W surfing method can be run completely and preventively, although the web surfer or its terminal system does not register anywhere at all or at least preventively executes the actual or virtual distributed or locally implemented IADx/BSx of the web/W surfing method when necessary. It is also applicable that IADx/BSx establishes preventively a 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. any safety-related prompts to the safety authorities of its users and/or other locations) to a0 before a0 registers in the network x and/or keeps IADx/BSx establishing preventively a 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. any safety-related prompts to the safety authorities of its users and/or other locations) to a0 before a0 exits the network x, wherein a0 user and/or utilizes or uses such precautions.

The method according to this version of the invention is not excluded to the skilled person from the wording/meaning of claim 1/2 in this patent application and the description thereof, wherein only a few of such versions are explicitly mentioned by way of example. That is to say that 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 (tunnel-free relay and tunnel relay, see claim 3 for this), i.e. no "tunnel-free" limitation is included for this purpose. However, relative to claim 2, MHO of this method is limited by the necessity to implement ComMe and its CI dependencies. These limitations do not actually appear as such, but appear as an advantage of the web surfing method (see section C for advantages of ComMe and its CI dependencies in MHO).

■ abstracted relaying involves individual bits being transmitted in A0-OC 0. But it is also possible to do every physical implementation of the web surfing method such that it is only necessary to guarantee the implementation of this "tunnel-free" relaying feature under certain conditions (e.g. the capacity of the information transported by a0-OC 0). The person skilled in the art knows how this is done and under what conditions and why it is reasonable.

■ in respect of the wording/meaning of claim 1/2, it is finally stated that,

"management of MHOS0 performed according to HO", versions of abstract or physical implementations (in the case of controlling the actual and virtual homeMIAD0, local or distributed implementations, and in the case of controlling their respective MHOS shares) are known to the person skilled in the art at least from the preceding description and are thus immaterial here (so that the management of HO execution according to MHOS0 is not at all limited in terms of its abstract or physical implementation), and

this "additional commercial communication"

No additional PDU exchange is required (but additional commercial communications can be made with the PDU exchange that would otherwise be required);

there is no limitation in the network used by the additional business communication (i.e., a network different from the network originally used may be used).

In terms of the scope of protection of claim 1 or 2, this implies in particular: as soon as an embodiment finds the presence of the signal according to a) by means of certain (assumed) non-MHOMs (without any restriction in this description) and thus leads in some way to a successful implementation of step b), this embodiment (together with the non-MHOM) falls within the scope of claims 1 and 2

With the five fig. 6 a-6 e, several basic explanations are also made in terms of a telecommunication arrangement in which the web surfing/W surfing method can be applied, wherein the MHOM of the method and/or its virtual or actual homeMIAD and/or its MHOS are realized abstractly or physically distributed. For simplicity, what is based on in fig. 6a is: system S0 with one part of the virtual homemix can only control and execute ConMe when necessary, while system S1 with another part of the virtual homemix can only control and execute ComMe when necessary (both control as a whole and execute both when necessary). The three fig. 6 b-6 d differ from fig. 6a only in that in fig. 6 b-6 c one of the two is located in the actual homemix 0, while in 6d the two MHO-Me types are located in the actual homemix 0. It is noted here that S0 and/or S1 and their virtual homemix parts (in fig. 6 a-6 c) can be located in the TK network, whereupon the operator of the communication network supports the W surfing method, so that in these cases the additional actual homemix can be placed functionally more simply than in the case of fig. 6d if necessary, in particular can be a shared IAD currently installed (see below). Naturally, there are many mixed forms of prototype communication arrangements for web surfing methods/devices (these mixed forms are disclosed by means of claim 1/2 wording/meaning and the above description). In summary, all forms and structures of abstract and/or physical, distributed implementation of the method according to the invention will be apparent to the skilled person for the description of the wording/meaning by means of claim 1/2.

As already mentioned, an easily conceivable economic benefit in the context of the method according to the invention is the complete integration of homeMIAD in a network (which is a communication network or a large WLAN) or, for example, a web server, since then many "functional upgrades" of already installed IADs without W-surfing capability can be implemented simply around the web-surfing function (complete "virtual homeMIAD server"). Fig. 6e shows a communication arrangement with a large WLAN and a unique virtual homemix server. In order to obtain the desired "homemix privacy" in this case (i.e. to ensure that the network or server operator/manager hosting (hosted) the virtual homemix server cannot gain access to the hosted virtual homemix), the communication of such virtual homemix operator/manager remains unintelligible to the network/server operator/manager as to the MHOS stored in (based on) the virtual homemix. Those skilled in the art know how this can be implemented in an abstract as well as a physical, distributed or centralized implementation of the web surfing method/device, i.e. the homemix server of the web surfing method/device, the MHOS of the web surfing method, the MHOM of the web surfing method and the functional modules for execution.

Fig. 6 a-6 e thus depict only possible separations of ComMe functions (from those of other MHO-Me) that are required for MHOS (i.e., possible distributed implementations). Fig. 7 a-7 e depict, for each of these fig. 6, a possible separation of the homemix 0 control functions of the MHOS from the belonging, executed functional modules in another system (i.e. a possible distributed implementation), so that the implementation of the MHOS is not yet distributed in each case. Thus, fig. 8 a-8 e depict, for each of the MHO-Me functions, a possible separation of the homemix 0 control function of the MHOs from the part of the MHOs that controls at least one homemix 0 control function, by distributing the homemix 0 control function to both systems. In this sense, at least one part of the MHOS may itself be considered executable, which part is also interpretable.

Based on the method according to the invention, such a suitably distributed (eventually physical) implementation eases the operation of large network or internet servers, providing a vastly different innovative multimedia communication service in all possible co-operations, e.g. with shared WLAN operators and/or IP-TV program providers.

It is particularly clear hereinafter that "having" in the wording of the claims is not allowed to be limited to "now including/comprising", but that other meaningful interpretation possibilities of natural language also apply at this point to "having", such as "having relation to …" and/or "to pay attention to/comply", and this also includes the future.

Additional functions

Additional functional elements 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" (MHO) related information available in the home/shared IAD environment and provides it to the other end systems Ax in a controlled way to support their MHO decisions.

The information that may be collected and provided by the IAD may include, for example:

possible (potential) home/shared IADs in their reception area, as well as information about the services they provide (internet, VoIP, IPTV, etc.), quality features, security, etc.

Information about the support and design of potential MHO procedures in particular

Its location and the location of the neighboring IADs.

The determination of the information about the potential IADs inside the receiving area will be arranged in such a way that the active connection between the end system and the IAD is protected from being affected if necessary with the help of a second receiving unit or by using a parallel collection allowing for interference-free.

The retrieval of information in this process need not originate solely from the IAD, it may also obtain information from a suitable external source (e.g., user input or database query). The data now available to the home/shared IAD can be provided to other MHO-enabled end systems so that they can make handover decisions appropriate to their own requirements. In particular, time-consuming and expensive information collection by the terminal system should be avoided.

The provision of this information therefore does not have to take place completely, but can also be restricted according to different criteria, which can depend in particular on the terminal system using the information.

Cost considerations for switching decisions/settings:

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

Standby and reminding:

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 of convenience information, for example, can be provided. Via SMS containing information about the loss of the communication connection and/or a timely reminder to re-execute/establish the communication connection and/or convenience information in the event that the communication connection can be re-executed or re-established.

Controllable handover from one terminal device (e.g. mobile phone a0) to a second terminal device (e.g. mobile phone a1) of the first terminal system and/or the second terminal system:

to achieve cost reductions and/or in case of quality problems and/or to provide greater convenience (e.g. hands-free functionality), etc., performing a controllable handover from one terminal device (e.g. mobile phone a0) to a second terminal device (e.g. mobile phone a1) of the first terminal system and/or the second terminal system may be performed.

User specific information such as cookies:

user-specific information (such as cookies) for enabling storage and execution of important basic settings reflecting user behavior and/or decisions regarding past handover execution may also be implemented. Allowing these cookies to be stored and/or executed may be a user's preferences and may have future requests/information/provide results that will increasingly be relevant to the user and tailored to the personal needs and preferences of a particular user. Cookies may be implemented on IAD devices as well as 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