Patent Application
20090147750
This invention discloses an automatic and network-transparent “handover convenience information support” method (HOCIS method) for a subscriber (SUBC) of a primary communications process (alias primary telecommunications process alias primary TC-process, PTCP) in which an HO takes place—wherein this HO-process can comprise arbitrary times prior or after the “actual HO”.
“Convenience information support” thereby means inter alia that this PTCP-SUBC has not necessarily requested this HOCIS, but he nevertheless as a rule regards this then unasked-for support as convenient or helpful, such as for example a passenger on a flight regarding associated announcements/references/measures (=convenience information support) at the departure or arrival airport. As opposed to such often uniform measures the HOCIS is as a rule individually configurable by someone affected by it. The HOCIS of such a PTCP-SUBC takes place by transferring to him relevant information as regards this actual HO—which can be potential or current or retrospective—during the HO process which was supplied for this by at least one non-human module M(HOCIS) in at least one system of at least one secondary telecommunications process (STCP) for these SUBCs.
The state of the HO art regards an HO as a process reduced to its technical core, i.e. it considers
On the other hand the HOCIS method implements—for a potential or current or previous HO—inter alia the three features of an HO method identified in (a)-(c) and hitherto not considered.
Also the “service continuity” of an OSI connection to be acquired in an HO is by the
In the first case, the seamless MIHs aimed at by the state of the HO art, it would in some circumstances purely theoretically be superfluous in the case of an HO in a PTCP OSI connection to provide the users in their terminal systems with a HOCIS to guarantee the thus understood service continuity in order to thereby avoid any negative effect on these PTCP-SUBCs through this HO. However anyone knows what to make of “pure theory” in this technical engineering context—that it does in fact often stand on “feet of clay” (for this see also the third last paragraph in section B).
As opposed to this the HOCIS method according to the invention has the effect in the case of an HO in a PTCP that at least one PTCP-SUBC, i.e. a user of a terminal system involved therein (of the OSI connection of this PTCP), receives at least one HO-relevant information precisely for the purpose of the “convenience information support” via/with this HO—so that this HO would not have a negative influence on the PTCP, or the PTCP-SUBCs could configure it better, or totally avoid it, or . . . (see section B. for the terms just used).
In other words: The HOCIS method achieves the “service continuity” in an HO on the level of understanding of the PTCP-SUBC (and dispenses with the illusion-bearing need or the “wishful thinking” of a large part of the state of the HO art, to be able to always completely conceal the HOs from these SUBCs in a technical way) in that it uses this HO by means of at least one non-human M(HOCIS) module in at least one HOCIS server/IAD/terminal system for this purpose (see in particular section D.).
The HOCIS method, thus owing to its objective, therefore belongs to the future and only just developing field of the “convenience” technology of technical communications, i.e. in its intentions not to the standard field of “HO technology”. A HOCIS method technically has nothing in common with the HO technology since the HOCIS method
This great technical complexity of the HOCIS method is explained more particularly in section D., more particularly in the explanations there of
The HOCIS method wants to make HOs “convenient” when using wireless communications networks as they are today. In more precise terms: It offers the possibility of conveying to their users in a simple way the convenient certainty that the HOCIS method—it is nowadays as a rule to be positioned outside of these networks—will inform them and support them during their use as regards the possible “bumpiness” of the potential and current unavoidable HOs between them permanently and in a convenient way.
The charm of the HOCIS method thus follows alone from the fact that it cannot currently be foreseen
For a potential or current HO of a terminal system of a primary telecommunications process (PTCP) the invention includes numerous (network-transparent) possibilities of providing human or non-human users in at least one different terminal system of this PTCP with “convenient information support” with regard to this HO, particularly the at least one subscriber (SUBC) of a PTCP indirectly involved in the HO. In many cases this HOCIS starts for a PTCP-SUBC involved indirectly in an HO without a request by him, thus has “social” features In order to be able to describe this clearly, the terms and associated concepts required for this will now be explained.
The subject of the invention is a generic HOCIS method as well as a generic apparatus for its implementation (generic=permitting a number of variations of the inherent type). The descriptions of the two in this written specification are—like their terms and concepts—purely functional, i.e. totally abstract, thus absolutely independent of a concrete material implementation alias embodiment. For reasons of clarity however possible material implementations of this method, of this apparatus and of these terms/concepts will be explained from time to time. It should thereby be noted that the following explanations of these terms/concepts—throughout in the sense of the OSI RM—serve to explain the essence of the method/apparatus according to the invention, thus do not aim at a basic explanation of other communications technical questions, but explain at numerous places quite directly the practical significance of the claims wordings of this protection specification. Section D. provides detailed explanations of the following clarifications.
Firstly: An HO of a communications process takes place between at least two either communications networks or/and access points of a network or/and performance features at an access point of a network. The present invention thus not only considers “vertical” HOs, i.e. HOs between different networks, but also HOs between access points or/and performance features of the same network, so-called “horizontal” HOs, and any mixture between this two HO types.
Now regarding the terms and their concepts (=meanings=contents=semantics, more precisely: also communications technical pragmatics) of this patent application.
Conceptually (i.e. purely functional, totally abstract)—this is important—
Thereby:
This written specification differentiates between at least two types of communications processes alias telecommunications processes: primary communications processes alias primary telecommunications processes alias PTCPs and—belonging to each HO therein respectively—at least one secondary communications process alias secondary telecommunications process alias STCP alias HOCIS-TCP. Each TCP has its own OSI connection (see below). Both types of TCPs and their terminal systems can however use in their abstract and/or material implementation substantially the same or different abstract/material operating means.
These TCP terms/concepts thereby apply universally, thus also for an HO alias an HO process, if this is a communications process/TCP—then it is a third type of TCP. Whether an HO alias HO process is also a (tele)communications process depends on whether its telecommunications technology implies during an HO a communication between the SUBCs of the PTCP on which the HO is based, or not, which is however irrelevant here: the HOCIS method can be used in both cases—and can in the first case where necessary use the HO TCP and/or consider it as a PTCP, as is apparent for example from the explanations to the last
Right here it should be pointed out here that it is also apparent at the latest from the telecommunications configurations just mentioned that the claim 1 wording/meaning as regards an HO relates to one or more PTCPs and to one or more STCPs.
To clarify that which has just been said: The wordings of the HOCIS method/apparatus according to the invention in the two main claims 1 and 80 are based—despite their “pseudo-natural-linguistic” formulation—on the terminology/conceptual meaning defined in the OSI RM, thus have already undergone the communications technological precisions/restrictions of the OSI RM which eliminate many uncertain areas of their “purely natural linguistic” meanings.
The description of the HOCIS method/apparatus according to the invention uses still wider OSI RM terms/conceptions which are not used in the pseudo-natural-linguistic wordings/meanings of claims 1 and 80—and which belong to the “artificial” terminology/conceptuality of the OSI RM. Thus the description makes use of the unmistakeability of the capacity of the relevant person skilled in the art for articulation through OSI RM made-up words/made-up terms. The relevant person skilled in the art will consider this helpful for making sure to get the correct understanding of the pseudo-natural-linguistic description of the HOCIS method/apparatus in its respective main claim. For this use of the OSI RM made-up words/terms see also section D. For the following use of the OSI terminology/conceptuality and especially for the OSI RM made-up words/terms in this written specification it should be pointed out in advance that the latter
As regards terminology/conceptions in the sense of the OSI reference model there is in each “n-point-communications process”, n>=2, between any two of its terminal systems, for example A and Z, an abstract “OSI connection”—which extends to the communications application systems in these two terminal systems, as will be explained below.
Each OSI connection is according to the OSI RM basically always sub-divided into at least 7 abstract “Li connections” (1<=l<=7) “lying on top of each other”, by means of which this communications process takes place between these two terminal systems A and Z (wherein “L” stands for “layer”).
The OSI RM thus defines—on the basis of its “7-layers” of always in principle identical “abstraction-semantics” of its Li-connections in each OSI connection—the “OSI communications architecture” which in turn is based on this “7-layers-structure” of the basic abstraction semantic of all the OSI connections. The OSI RM calls each of these basic 7 abstractions layers of its communications architecture—quite independently of individual OSI connections—obviously “Li”, 1<=i<=7.
Several Li connections can exist for each “i” in any one individual OSI connection. Each such Li-connection must use for its implementation at least one Lj connection of the same OSI connection, wherein always j<l holds-apart from
An L7-connection of an OSI connection is often called a “communications connection” since in it of sole importance is the “communication” in the sense of the specific telecommunications process on which this OSI connection is based or of the “communications applications systems” supporting it (the latter located in at least the two terminal systems of the OSI connection). I.e.: An L7-connection abstracts entirely from the modalities of the information transfer (=L1 to L4 functionality) used in this communication, —of a communications applications system which where necessary human SUBCs operate in it—information sub-division (=L5-functionality) and information presentation (=L6-functionality): An L7-connection only knows the “interactions” in this “communications application” communication.
An OSI connection of a telecommunications process “exists”
Accordingly this OSI connection—owing to the start of the communication of its communications application system creating it, i.e. the beginning of the telecommunications process—exists at the latest from the moment in time at which some measure for it takes place in a terminal device of the terminal system of the (communications process) SUBC creating it in A or Z. However at this moment in time there need not yet any Li (1<=i<=7) of this OSI connection be (abstractly) implemented or possible to implement. The existence of a Li connection thus does not imply its (abstract) implementation or possibility to be implemented. And more generally: With any OSI connection its at least 7 Li connections also exist, of which however no single Lj connection—and its interaction with the other Li connections of this OSI connection—needs to be abstractly implemented (the OS RM does not consider material realisations/implementations anyway), An (abstract) implementation of a Li connection needs only to be given during its actual (abstract) use.
This implies that the OSI connection remains in existence between these two terminal systems A and Z for this TCP even if in particular its at least one L3 connection is not or cannot be implemented, as often happens in HOs of their terminal systems.
That in any case the L7 connection of a PTCP OSI connection remains in existence in an HO case can be ensured by means of the HOCIS method according to the invention (see Section A.) since it ensures that at least one PTCP-SUBC in A or Z always knows that this PTCP (i.e. the PTCP OSI connection) has not yet ended, although for example an L3 connection interruption is occurring in it—wherein this SUBC anyway sometimes knows this about this L7-non-termination, also without any HOCIS method, because this non-termination arises for him from his application communication which he executed in the seconds preceding the L3 connection interruption. The HOCIS method confirms in such a case the corresponding SUBC assumptions or corrects them. The latter for example if the SUBC involved directly in the HO ends during the HO—thus during an L3 connection interruption—the OSI/L7 connection (i.e.: the associated PTCP) unilaterally.
It should again be pointed out here that a PTCP OSI connection in the method according to the invention need not connect the same terminal systems as an STCP OSI connection associated with it: In both however the SUBC considered at the time is the same (which section D. emphasises).
The claim 1 of this patent application implies the existence of at least one functional module “M(HOCIS)” in a terminal system of a HOCIS-TCP alias STCP. This M(HOCIS) is functionally sub-divided further, as explained in detail in section D. in order to make it easier to obtain the precise understanding of the claim 1 wording/meaning. Regarding this sub-dividing of an OSI RM-compliant terminal system into modules (as further explained particularly in section D.) it is pointed out that the OSI RM at first sight avoids sub-dividing terminal systems, but does actually undertake this. The reason for this is the notional necessity for sub-dividing communications applications (such as the abstract HOCIS communications application, which is notionally indispensable for the abstract implementation of the HOCIS method, which as a rule are located on the L7 in the terminal systems) in order to understand them. This necessity led in the definitions for the L7 (in the relevant international standard ISO/IEC 7498 of 1994 and the identical ITU-T recommendation X.200, inter alia page 32/33, and more specifically in the international standard ISO/IEC 9545 of 1994 and the identical ITU-T recommendation X.207) to the definition of the functional structure of an OSI RM-compliant abstract communications application which logically implies the functional sub-division corresponding to it of the terminal systems containing them—namely in their area of the OSI RM-compliant abstract communications application contained by them.
The starting points of the PTCPs, their HOs and their STCPs in a HOCIS method—unless stated otherwise—are/can be arranged chronologically in any sequence.
A HOCIS TCP alias STCP alias its STCP OSI connection—for a potential or current or retrospective HO of a PTCP—can in particular have something to do with this PTCP insofar as for its (abstract and/or material) implementation, i.e. for the implementation of its STCP OSI connection, thus its STCP Li connections, it can use one or more of the Li connections of the PTCP OSI connection (i.e. its abstract and/or material implementations at their end points in the PTCP systems). However the implementations of both OSI connections (in the abstract and/or material implementations) can also take place completely independently of one another.
It is thereby only important that the HOCIS method is based on a transfer of HO-relevant information from a HOCIS system (of a certain modality) to a SUBC—however the HOCIS OSI connection which is essential therefor (according to claim 1) is implemented. This is also not conflicted with the start of the HOCIS/STPCP of this OSI connection being carried out through the presence of a (HOCIS) signal in a PTCP and/or HOCIS secondary system.
This “attempt at transfer” means (see
This is the “core” of the present invention on which the claim 1 wording/meaning is based—which will be explained again and in more detail below (particularly in section D.).
It ultimately corresponds to the “HO convenience information support suitability” of the HOCIS method regarding a PTCP-SUBC who is involved in an HO (and is as a rule human in the examples of this patent application). It is ultimately designed/articulated/coded/pre-sented/located for/on the abstraction level of its “automated” and/or physical and/or syntactical and/or semantic and/or pragmatic/mental perceptibility:
This implies configuration/display variants of an HO-relevant information
This written specification simplifies this OSI terminology insofar as it likewise regards the SDUs as PDUs. Consequently an HO-relevant information is in this patent application always a HOCIS-PDU understood in this way.
In order to simplify the illustration of that which has been mentioned above regarding the OSI RM it should now be explained:
Features of a material implementation alias embodiment of a HOCIS method are not however even considered in this patent application.
I.e.: In the following the terms “HO=relevant information”, “HOCIS” and “HOCIS service” are ultimately synonyms insofar as they model the ultimate material information of a material SUBC of a (current or potential or retrospective) material PTCP as regards one of its (current or potential or retrospective) material HOs in an OSI RM-conforming way.
The difference is also to be noted which there is between a rudimentary HO of a terminal system to a network compared to the checking in of this terminal system into this network: The former is a necessary telecommunications measure of this terminal system as regards this network so that this terminal system can then carry out its check-in at this network. The check-in of a terminal system into a network thereby needs to imply not yet a more extensive possibility of usage of this network through this terminal system, particularly no internet connectivity of this terminal system—of which the relevant person skilled in the art is fully aware.
In the HOCIS method special importance is placed on the discovery of the rudimentary connectivity of a terminal system to a network: It implements its starting time point.
The fundamental novelty in the HOCIS method described basically in many words in section B. will be repeated below with few words and practice-orientated: The HOCIS method supports, as regards a—potential or current or earlier—HO of a terminal system of a PTCP, at least one PTCP-SUBC through at least one HOCIS alias one HOCIS measure, It is started by the discovery of the presence of at least one HOCIS signal in at least one PTCP or STCP terminal system. As a result of this an HO-relevant information relating to this is transferred to at least one PTCP-SUBC (either after its STCP terminal system received this over a network or as a substitute it construed itself). This SUBC receives this HOCIS however not because he had requested it but because he was to experience as little negative interference as possible by this HO. The HOCIS method is thus “socially” founded.
The HOCIS method thus endows PTCP terminal systems with a behaviour which as regards its potential and/or current or retrospective HO was up until now never once thought of. More precisely: It imparts to PTCP terminal systems/devices as regards HOs—in order to support their SUBCs—a completely novel type of “social behaviour” in respect of these SUBCs: Up until now there was never any trace of such an idea.
For just that reason it differs fundamentally from the present state of the HO art (see section A.): it is namely totally unaware of the “interpersonal” HO problem—that namely with an HO at least one subscriber of a PTCP indirectly involved therein is left in the dark about this HO and its continuation at least temporarily and thus becomes possibly considerably irritated, let alone that there would be some reaction possible to it for him. It not even regards its total “neglect of user interests regarding HOs” as a problem.
The HOCIS method is the technical core of a solution to this actual problem: this written specification thus reveals a basic principle of a technology by means of which any PTCP-SUBC (according to his needs) can be informed about/supported by a (potential or current or earlier) HO in this PTCP—thus also a SUBC not directly involved in an HO.
The HOCIS method is also suitable to support subscribers with seamless MIHs. An example for the meaningful purpose of such support: When downloading a large data file by WLAN technology onto a PDA its user moves out of the WLAN used for this. Is a MIH method to engage here and let the download continue over a more expensive and/or significantly slower GSM network or should it be continued only with the availability of another WLAN, or is it now to possibly be totally broken off? To want to not inform the user about these alternatives—as is provided with seamless MIH—must by-pass market needs.
Whereas it is strikingly obvious that the HOCIS method according to the invention is reasonable in an HO between a WLAN/Femtocell and mobile network, this can also apply with all other networks/part networks/network types which are all covered by the claims wording/meaning, particularly “HOs with mobile network/mobile network roaming”—even if the examples/figures in this written specification only concretise the first-mentioned case.
The HOCIS method is a fundamental further development of the known support of a user during his work with his real or virtual local application system, possibly MS word or MS explorer or also the navigation system of his car. It is a fundamental further development of this support because a user during this work up until now is supported only as regards determinants of his current actions, which reflect his sphere of influence which is known to him and does not change automatically, whilst the HOCIS method supports him in a novel way additionally as regards novel determinants of his actual actions which reflect an area unknown to him and changing automatically from his viewpoint and impossible to be influenced by him (here: as regards events of all kind which are HO-relevant there). The fundamental innovation of the HOCIS method thus consists in its novel “convenience information support” of the SUBCs of a PTCP as regards their novel determinants of their actual actions in HOs.
To conclude this section B. the following should be noted. In the descriptions up until now of the HOCIS method its support of a PTCP-SUBC or his FMC telephone indirectly involved in an HO is in the foreground, and this also applies for most of the following sections of this written specification. Since the section B. inter alia should make the essence of the HOCIS method clear, it is now expressly pointed out and substantiated briefly that and why it can also support a PTCP-SUBC directly involved in an HO—namely in the generally known practical example of an FMC telephone and its discovery of its rudimentary IAD connectivity (wherein claim 1 knows neither this “FMC”—nor this “telephone” nor this “IAD” restriction).
The HOCIS in this special application example of the method according to the invention (for a PTCP−SUBC=FMC telephone user directly involved in an HO) demonstrates the market relevance of the HOCIS method by in particular explaining its practical FMC usage simplification potential. An “HO convenience information support” of this type namely differs clearly—after the FMC telephone has established its rudimentary IAD connectivity (see above)—from the
A one-touch HO of this kind (implemented by HOCIS method) or even zero-touch HO or another (such as possibly configured by the telephone user for this HO) causes the use of an FMC telephone to be much more convenient and as a rule additionally more cost-effective than this is possible without the HOCIS method—so that it is also regarded as welcome by this PTCP-SUBC directly involved in an HO.
Thereby this HOCIS (for example by one-touch HO) can seamlessly complete for a user of a telephone directly involved in an HO the HOCIS explained further above for a PTCP-SUBC indirectly involved in the same HO. The sub-section D., more particularly D.4.9. and the associated
The HOCIS method outlined in this section C. and the associated
These outlines are thus only to explain some of the anticipated frequent “mobility-conditioned” HOs in telecommunications arrangements in which the HOCIS method can be helpful. They are to show in particular that its implementation—by means of at least one non-human M(HOCIS) module—can be located completely or partially especially in:
Since in the following discussion the term “access” to a communications network of a terminal system of this network is of crucial importance, its meaning—which is known to the relevant person skilled in the art—will first be explained (to an extent adequate for this specification): Its thus constructed definition according to a person skilled in the art reads: An (abstract) terminal system of a network (which is thus checked in with it, see above) has at a point in time “access” to this network if it at this time in point can carry out L3-data transmission to the OSI layers L1-L3 of its connection with
It follows in particular from this that a terminal system of a network does not need to have permanent access to the latter—as is often the case with terminal systems of mobile networks as is known.
The “access point” to this network (particularly in the case of its potential or actual use for a data transmission in/from this network) is thereby the point of transfer (from the operator of this network to those responsible for this terminal system/terminal device) of the legal/commercial and where applicable technical responsibility for the operational capability of the layers L1-L3 on the at least one “data transmission section” (DTS) between terminal system/terminal device and network. The network-side (abstract) terminating device of a DTS at the access point is called “network terminator” (NT), the user-side (abstract) terminating device of this DTS at the access point is called “terminal adapter”, TA. In a material implementation of a network access point these two (abstract) functional units, network terminator (NT) and terminal adapter (TA), can be as far as possible integrated—as is the case generally with mobile telephones.
After clarifying the two terms network access and network access point it is also clear that a mobile (abstract) terminal system/terminal device which can be directly involved in an HO, nowadays more particularly an (abstract) mobile telephone, can contain for example one terminal and three non-terminal (abstract) terminal devices:
If this capacity of a telephone for the “direct HO” relates to a GSM/CDMA/UMTS/satellite/Wimax/ . . . -network on the one hand and an internet-connected WiFi or Femtocell-WLAN on the other hand then it is occasionally called “FMC telephone” (FMC=Fixed/Mobile Convergence): It then supports indeed the convergence of the usability both of the landline technology of the internet and the mobile network technology of the GSM/CDMA/UMTS/satellite/Wimax/ . . . networks, here when telephoning.
It should be noted that the IAD contains at its air interface-side (=not internet-side) a “switch” (just like the FMC-telephone at its air interface side): As can be seen from
A GSM-/CDMA/UMTS feature can be seen from the above: With these networks all the base stations—conditioned technically/in regard to copyright/financially, since they are operators of large cells—have to be under the legal and commercial responsibility of large operators and are thus slow to introduce innovations into the practice. On the other hand IEEE802.xx-IADs/-APs are under the legal and commercial responsibility of their respective much smaller operators so that they offer a technical platform on which innovations of all kinds such as those of this written specification can be brought into use at short notice.
Furthermore an FMC telephone—as shown in
By the way the terminal device of the subscriber directly involved in an HO is depicted on the left in the following figures. The illustration on the right, too, is a reminder that the HOCIS method is provided particularly for subscribers of a communications process who are only indirectly involved in this HO.
In
Network-II. has no significance on the costs of a primary communications process between A and B, but rather Network-I. and Network III. so that these are also relevant for HOs. In view of this the complete HO terminal device in the primary communications process between the subscribers A and B consists as regards
If one starts from network III., then the complete HO terminal device is thus the IAD+FMC telephone.
If one starts from the FMC telephone, then
If one starts from the primary communications process, then it is possible to regard as the complete HO terminal device both the FMC telephone alone and also the FMC telephone+IAD.
In
In
In the initial phase of the market introduction of the FMC technology
The HOCIS method according to the invention can start/start running/terminate in an obvious number of further potential or current HO situations. It is also not exemplified how a subscriber information/support takes place.
In section C.1. solely the FMC telephone A—possibly with support through the telephone B—is entrusted with the execution of the HOCIS method according to the invention. This has the result that the “internet connectivity” between the FMC telephones A and B breaks off for its execution as soon as A quits the reception area of his WLAN.
The HO telecommunications arrangement of
Here again we start from the HO telecommunications arrangement in
For example in the above case A) the IEEE802.xx-IAD A would be able to provide its L3-connection to the FMC telephone B over the internet to the HOIS method during this telephone conversation so that it can inform the B-user via this that the A-side IEEE802.xx-connectivity has ended. And further: In several of the above cases the IEEE802.xx-IAD A can enable in all critical phases of potential and/or actual HOs of the telephone call/conversation HOCISs thereby to both communications partners—particularly thus the communications partner B only indirectly involved in the HO of A, who otherwise knows nothing of the technical HO-danger/necessity of the HO of A. An IAD directly involved in an HO can thereby start significantly earlier with the HOCIS method and/or work longer thereon than is possible/advisable for a terminal terminal device directly involved therein.
The FMC telephones and their IADs/APs can be arranged exactly as seen in FIG. 1—the latter would here be expanded only by a server at the internet—so that no further figure is necessary.
The great importance of using this telecommunications configuration for implementing the HOCIS method arises from the fact that most of the present day millions of already installed IEEE802.xx-IADs/APs and their IEEE802.xx-/GSM-/CDMA-/ . . . telephones themselves—as a result of their technical inadequacies—cannot perform any HOCIS functionalities, but a suitably designed “HOCIS internet server” (e.g. a suitable HOCIS expansion of a SIP or announcement or . . . server already used in control operation) can act very well for them, by observing the quality of their relevant connectivity as regards an HO and providing by means of this HO-relevant information, which it supplies instead of and by the telephones, HOCIS services derivable therefrom for their users.
As can be easily seen, the qualities of the HOCIS functionalities of the method according to the invention can be improved in detail in many respects if use can be made of all 3 previously outlined abstract “design variations of a HOCIS service”. The method-1-claim wording takes into account this “mixed design advantage aspect”: Its wording/meaning is independent of all “functional distribution aspects” in all three types of processes (see section B.) of the HOCIS method.
The HOCIS method is also not restricted in its interaction with any other service—by whomever this is offered and/or provided possibly with a MIH service. In order to explain such functional distribution and cooperation possibilities there is now an example:
A GSM network operator could reserve for WLAN calls from FMC telephones on his GSM network a kind of (attractively tariffed) “stand-by” connections in his own GSM network, on which such a WLAN call can carry out at any time and delay-free a “local GSM fallback” (for the L3-connection between FMC telephone and its IAD) or a “global GSM fallback” (for the L3-connection between FMC telephone and the second telephone apparatus)—provided the mobile network operator was in a position to cost-effectively solve the problems involved with such a “pre-HO-service”. Only its interaction with a HOCIS method according to the invention would make it in effect user-friendly and thus attractive on the market. Such a GSM fallback (alias HO) of a telephone conversation would namely in no way guarantee the desired quality of the “service continuity” without the user-friendly-enhancing HOCIS method:
This example shows that—in order to obtain high quality of the service continuity in an HO—even a “seamless MIH” in many cases will require the support through a user-friendly HOCIS-method whereby this concrete implementation is in no way limited as regards content, functional distribution and cooperation with other services.
Whereas in the previous sections on HOCISs the aspect of their contextual user-information in real time in an HO was at the forefront, it should now briefly be reminded that the HOCIS method also enables the configuration of important other aspects: It allows at least one user in a HOCIS process the capacity by means of his HOCIS at any time:
Some examples for the functionalities of the HOCISs mentioned here and which can be determined by the user and their local—even temporary—display were/are mentioned at several places in this written specification. According to this the contents details of these functionalities and their local displays are not the subject of this written specification. Its claims deal only with the basic fact of such functionalities of the HOCIS method according to the invention, i.e. the “social” functional reaction extensively shown in section B. of a terminal system/device directly involved in an HO (with the presence of a HOCIS signal in one of the terminal devices of a communications process), but not however impose any restriction on the configuration as regards content and illustration.
The principles of the OSI RM-based modelling of the abstract HOCIS method/apparatus according to the invention were discussed in section B. The application of these principles leads in this patent application to abstract HOCIS method systems and abstract HOCIS apparatus systems which are called uniformly in Section B. HOCIS systems (alias STCP systems). According to the OSI RM both types of HOCIS systems contain abstract functional components (=functional groups) which it names “entities”. It considers these entities alias functional components only insofar as they are relevant for the abstract realization of OSI connections of communications applications and their services.
The communications application at hand here is according to the invention split in two parts and consists of the HOCIS method and the HOCIS apparatus—therefore the two aforementioned types of HOCIS systems. Their aforementioned entities alias functional components are unavoidably found again in a material implementation (=embodiment) of the HOCIS method or HOCIS apparatus in the software and/or hardware components of this embodiment.
Accordingly this written specification in particular considers its abstract HOCIS apparatus—it calls it also “STCP apparatus”, see claim 80—as consisting of abstract HW/SW functional components, wherein this association of a functional HOCIS apparatus component with the HW/SW is completely irrelevant. It is only important that the abstract implementation of the functional components of an abstract HOCIS apparatus can take place by means of
Apart from the first case an “abstract HW/SW resource sharing” takes place between the HOCIS apparatus components and functional components of the other systems mentioned. This abstract HW/SW resource sharing can be found again or not in a material implementation alias embodiment of this HOCIS apparatus and in the first case is called “material HW/SW resource sharing”. I.e.: An abstract implementation of such a HOCIS apparatus in its functional HOCIS apparatus terminal systems at PTCP-SUBCs to which HOCIS is to be granted, can co-use there each time functionally similar or functionally suitable HW/SW components of a PTCP and/or operating system (and functional HW components managed by same) of the SUBC per abstract resource sharing.
Conversely: An abstract implementation of a HOCIS apparatus terminal system of a SUBC requires in some circumstances no independent abstract HW expansion at all of its at least one PTCP terminal system since the abstract HW components of the latter are sufficient for this abstract implementation by means of “abstract HW resource sharing”. This can then also apply for a material implementation of this HOCIS apparatus terminal system by means of this material PTCP terminal system. This is however not a necessary feature of an embodiment alias material implementation of a HOCIS apparatus terminal system so that it could embody claim 80.
An abstract HOCIS apparatus terminal system—the HOCIS method main claim is only concerned with certain functional HOCIS SW components which it regards as executable and calls collectively M(HOCIS)—contains the following abstract HW/SW components (see
This written specification is currently primarily directed at embodiments of the HOCIS method/apparatus which are embodied completely by means of the material PTCP terminal systems and/or material PTCP servers/IADs which exist in any case at a PTCP-SUBC, in that additionally at least one HOCIS module was located each time thereon (which makes special material PTCP and STCP systems out of them). Its protection range is however not restricted to such embodiments, but it comprises—according to the claims wordings/meanings 1-91—also a number of embodiments of the HOCIS method/apparatus which these above-mentioned material PTCP systems of a SUBC supplement for example each time by at least one additional material HW device.
The above discussion about a modelling of the abstract HW/SW components of HOCIS systems—essentially sublimated in section D.—serves only for the elementary clarification of the purely functional type of the HOCIS features (according to the claims wording/meaning) from the implementation of which through a concrete HOCIS embodiment it is to be decided whether the latter encroaches upon the protection area of this written specification or not.
An abstract/concrete realisation/implementation conception of the HOCIS method according to the invention which is of interest to the mass market, more precisely: of an M(HOCIS) therefor, is a HOCIS-ISR server (see section D. and its
The login and/or enquiry of a primary communications process subscriber at a HOCIS-ISR server for example can take place vocally and/or through the input of a key combination or an SMS or without any input from his side, but possibly on the side of his ISP or MSP or a third party. The “HOCIS signal response” from the server—if it detects the signal sought by it in the data stream to be observed by it—to the subscriber who is to be informed about it can likewise take place over any network from which the telephone of this subscriber can receive a message.
This section D. is to help avoid the meaning and/or protection area of the present patent application from being determined from its descriptions of very limited concrete examples and being restricted to them—which is indeed “patent logically” absurd and more particularly in terms of patent law strictly inadmissible, but which has happened nevertheless to the authors of this written specification in legal disputes in the case of others of their patents and therefore has a very strong impression on the wording of this patent application—and not from its intentionally more abstractly formulated and therefore clearly wider reaching claims wording. The prime point of the method of interpretation, i.e. of the method of determining the content, of a patent from its claims wordings (compared to all otherwise possibilities of a method of interpretation/method of determining content of a patent) is namely fixed unmistakably in all patent law standards.
For these two reasons section D. will explain/clarify below the essence of the invention of the present patent application particularly with reference to its method main claim 1 as well as in particular by means of several dependent claims—namely by deliberately setting out the individual essential features of the (generic) HOCIS-method according to the invention in dependent claims groups. The precise essence of such a technologically complex method (as the HOCIS method according to the invention) can—as the relevant person skilled in the art knows namely not be concluded simply from the standard patent specification constituent parts
Such a simplification of obtaining this precise understanding of the essence of the claim 1 wording/meaning however is provided by fanning out this meaning by means of a number of dependent claims, namely split into groups of dependent claims illustrating method features (as explained in D.1.). It can thereby remain to be seen whether this procedure also contains a specifying of the single method main claim meaning (which is determined by the aforementioned interpretation according to European Patent Law of (a) by taking into consideration (b)).
A separate explanation of the fanning out of the description of the apparatus main claim meaning of claims 80 and 82 for the purpose of specifying the understanding by means of comparable dependent claims and groups of dependent claims thereafter seems to be unnecessary.
Firstly however there should be a reminder of two aspects—already mentioned in part in this written specification:
Taking into account that which has just been said, this written specification makes it easier to specify the understanding of the claim 1 wording/meaning by depicting it fanned out into dependent claims 2-79 and sub-dividing this complete fan into 11 “dependent claims groups”: In each such dependent claims group the features explained therein and/or their variations are displayed (by means of the individual dependent claims of this group) namely very much more clearly in their direct comparison than without their being highlighted in such a dependent claims group—so that a key-word description of the “meaning focus” of each dependent claims group in the following already explains the precise understanding of the features/feature-variations/feature-combinations (of the claim 1 wording/meaning determined according to European Patent Law). This dependent claims group technique thus makes it quite considerably easier to obtain this precise understanding.
More precisely and again in other words: The understanding of the individual features or their variations of embodiment according to claim 1 is made unavoidable and focussed through these dependent claims groups and their respective brief description. These dependent claims groups (and their brief descriptions in this section D.) thus make it easier to obtain the precise understanding of the claim 1 wording/content by fanning out their two descriptions—compared to obtaining it solely from the conceptually yet absolutely clear but however mentally complex claim 1 wording/meaning. It is thereby trivial that making it easier in this way to obtain the necessary precise understanding of the claim 1 wording/content—namely by fanning it out by means of dependent claims—in no way changes this. It is therefore irrelevant that such fanning out can as a rule be carried out neither systematically nor totally (even if only because the terms “systematic” and “completeness” are as a rule not definable for this area), but that it can show only some examples of the possible interdependencies which are to be considered between the respective features/feature variations.
This advantage of the subsequent formation of the dependent claims groups is proved by using the example of dependent claims group 10-19 (see also sub-section D.5.): These dependent claims display the feature of the “temporality of a process” in a HOCIS-method and particularly show in which combinations it can implement these feature variations—so that from this follows quite directly a simplification of obtaining the precise understanding of these feature variations and their significance in the claim 1 wording/meaning.
As is seen, this group with regard to the variations of the feature “temporality of a process” consists of at least 10 combination possibilities which are shown here fanned out as 10 “overlapping” dependent claims. This dependent claims group of the HOCIS method main claim does not indeed disclose all chronological overlapping possibilities of the three processes according to claim 1 (PTCP, STCP and HO) explicitly, thus not the entire amount of all “special cases” of the HOCIS method regarding these feature variations, i.e. overlappings of this kind. The entire “special cases group” of the HOCIS method belonging to this feature is however described contents-wise so close-meshed by means of these 10 dependent claims that based on the thus produced specified/focussed overlapping possibilities understanding any further such overlapping possibility (alias feature variations combination) is for the relevant person skilled in the art only an obvious variation of the overlappings/combinations of this type explicitly shown in this dependent claims group.
Based on this specified/focussed overlapping possibilities understanding a HOCIS-process with such overlapping—just because it is not explicitly shown in this special dependent claims group—can thus not be regarded as not belonging to the protection area of the present HOCIS method according to the invention.
Now again independently of the special claims group 10-19: In the following use will be made of this dependent claims grouping technique throughout to specify the understanding of the claim 1 wording/meaning. The grid of such a dependent claims group in fact already reveals to the relevant person skilled in the art all the elements according to the claim 1 wording/meaning of the “special cases group” belonging to it. Each such claims group grid identifies
Logically therefore the complete “special cases group” of the HOCIS method belonging to a considered dependent claims group—more precisely: the one belonging to the understanding of the claim 1 wording/meaning depicted fanned out by means of this claims group—consists accordingly of all those of its special cases which correspond to all combination possibilities of this set of feature/s and feature variations. Determining all these combination possibilities is thereby an indeed sometimes extremely complex but nevertheless as a rule trivial “mechanistic” activity after the dependent claims group considered has fundamentally shown up the combination possibilities of this/these feature(s) and its/their variations. However see the disclaimer below to such dependent claims groups.
Thus a special case of the HOCIS method according to the invention with its feature/feature variations combination, which is not explicitly listed in at least one dependent claim of the dependent claims groups displaying this set of features/feature variations, cannot be regarded as not disclosed by the claim 1 wording meaning—only because one of these dependent claims groups does not exhaust all combination possibilities of the set of features/feature variations identified by it (by detailing explicitly all associated special cases). Rather such a special case of the HOCIS method according to the invention must as a rule be regarded as disclosed by this dependent claims group since from it can be derived elementarily—for the understanding of the claim 1 wording/meaning which it clarifies/specifies—both its special features/feature variations and combinations thereof (as shown by way of example by this dependent claims group).
If one wanted to forgo this dependent claims group technique and only regard those special cases of the HOCIS method, which are explicitly revealed in at least one of its dependent claims, as belonging to the claim 1 wording/content and/or protection range, then such a definition of the same protection range would require an unending number of dependent claims. Such forgoing would however not only be impractical but would also contradict the legal concept of the “relevant person skilled in the art” whose capacity to recognise the features/set of feature variations relevant to the dependent claims group and the combinations thereof would be called into question.
Moreover there is not one uniform system for the identification either of dependent claims groups, or of all their features and/or feature variations or of all their reasonable combination possibilities, as already stated above. These steps for to forming/focussing/specifying an understanding regarding the claim 1 wording/meaning must rather each time be carried out independently, but are however as a rule quite simple, and take place
The last two bullet points contain a clear disclaimer regarding the “many dependent claims technique”/“dependent claims group technique”: They imply that even by means of this technique the claim 1 wording/meaning cannot be provided with the predicate “explicitly shown by dependent claim” in all of its ramifications and in its entire scope. Rather this technique serves only to provide a type of “hard core” of all these ramifications and this entire scope with the predicate “explicitly shown by claim”. Insofar as the claim 1 wording/meaning extends beyond this hard core—either as regards its ramification refinement or as regards its overall scope—it remains ultimately up to the relevant person skilled in the art to ascertain this.
Nevertheless carrying out these perception/analysis steps which are indispensable when forming the dependent claims groups, brings about a great advantage: These dependent claims groups provide clarity for the large number of features and feature variations and their combinations of the claim 1 wording/meaning which have to be explicitly addressed by the unavoidably numerous dependent claims and dependent part-claims in order to achieve the intended simplification of obtaining the precise/focussed claim 1 wording/meaning understanding.
So far the general justification—if not even the proof of necessity—for using this dependent claims group technique as soon as the technical method on which it is based extends into the field of software engineering, which is the case in this specification. The following repeated summary of its advantages therefore appears appropriate.
In the present concrete case of the HOCIS method the display of its claim 1 wording/meaning “hard core” by means of this technique is indeed already quite voluminous. The relevant person skilled in the art immediately recognises however that it is nevertheless not exhaustive—i.e. the claim 1 wording/meaning extending beyond this hard core is both more differentiated and also more extensive. This explicitly disclosed “hard core” of the claim 1 wording/meaning—by many dependent claims and their dependent claims groups—only represents a “signpost system” in the latter, but in no way characterises it exhaustively. This only achieves its precise/focussed understanding which was induced/obtained by means of this hard core.
Before the individual claims or dependent claims are explained in sub-section D.5., the conceptual equipment is supplied in the sub-sections D.2.-D.4. for understanding in detail the claim 1 wording/meaning:
The relevant person skilled in the art knows all the methods and procedures provided in D.2.-D.4. for obtaining a precise understanding of the claim 1 wording/meaning which support the interpretation of this patent application—the explicit explanation of the former in this specification is only of use to him to simplify its application.
After these explanations in the sub sections D.2.-D.4.—regarding the precise understanding of the features of the HOCIS method according to the invention, on which the claim 1 is based—the precise understanding of the method of dependent claims groups in sub-section D.5. can be readily achieved through few words.
The claim 1 wording is of a natural linguistic type, its meaning immediately clearly understandable and distinct. The flow chart of
That the meaning of pseudo claim 1′ is not larger than that of claim 1, is clear to the relevant person skilled in the art since the wording of the former opens no room for any generalisation causing this.
However conversely it is to be ruled out that by specifying the meaning of claim 1 in pseudo claim 1′—by its wider use of the terminology/conceptuality of the OSI RM for describing the meaning of the HOCIS method—no limitation of the claim 1 meaning is undertaken. In this case the pseudo claim 1′ meaning/protection area would be smaller than that of the claim 1. Pseudo claim 1′ would then be a genuine dependent claim of claim 1.
The following pseudo claim 1″ explicitly shows the hypothetical restrictions of the pseudo claim 1′ in respect of claim 1: A HOCIS method according to pseudo claim 1″ would indeed logically be according to claim 1 but not according to pseudo claim 1′—(because it does not meet its restrictions).
The evidence for the fact that there are no HOCIS methods according to pseudo claim 1″—that thus pseudo claim 1′ contains no restriction in any way in respect of claim 1—is trivial: The assumption of the existence of a HOCIS method according to pseudo claim 1″ is immediately reduced to absurdity because it proves to be for the relevant person skilled in the art according to pseudo claim 1′ and thus not according to pseudo claim 1″, which contradicts this assumption.
An initial understanding of the claim 1 wording/meaning in this way is specified in this section D. through many further explanations. It thereby applies that all these explanations about claim 1 also analogously apply for pseudo claim 1′.
The following specifications for understanding the essence of the HOCIS method sometimes use its description through the pseudo claim 1 wording, i.e. the wording based on “OSI RM made up words/terms” familiar to the relevant person skilled in the art. However any explicit use of “OSI RM made up words/terms” is redundant insofar as just solely the natural verbal descriptions of the HOCIS method/apparatus according to the invention and the associated claims wordings clearly and unmistakably define the meaning thereof, i.e. rule out their double meaning interpretation, i.e. correspond to the concerns of the OSI RM. Such explicit references to the OSI RM made-up words/terms—for example in the explanation of the participation structure of an STOP according to claim 1, i.e. more precisely: the STCP OSI connection—are only meant for the relevant person skilled in the art, for his self-ascertaining of the correctness of his understanding of the following specifications of the natural verbal claim 1.
Present day telephones are unable to provide a HOCIS according to the invention in the latter way but can very easily do so in the former way (see the explanations re
According to claim 1 a concrete embodiment of a HOCIS method thus encroaches into the protection rights aimed at by this patent application as soon as it—after the just discussed checking for the existence of some HOCIS signal in any terminal system as regards a potential or current HO—starts the transfer of an information relevant to this HO (to a SUBC suitably involved in this HO). I.e.: the success of this transfer to the SUBC in any extent is irrelevant for this encroachment.
As regards the dissimilarity/identity of/with each other of the terminal devices of a SUBC for its PTCP and at least one STCP, as regards the (non-human) functional module M(HOCIS) and as regards the originarity/transfer of HO-relevant information in claim 1 that which has already been said about this in the preceding sections and also that which will be explained on this in this section is to be taken into account, more particularly:
That which has been said above particularly does not rule out that at least
The basic specifying of the understanding of the claim 1 wording/meaning took place in the previous sub-section by using the OSI RM as the basis. The sub-sections D.3.-D.5. now show that there are HOCIS TCPs whose specifying/simplifying the understanding thereof suggest that their explanations are based on a common “HOCIS reference model” (HOCIS RM)—because this makes many of the explanations superfluous which otherwise each of these HOCIS TCPs would require.
In view of the lesson described at the start of this section D. which the author of this written specification annoyingly received on account of others of his patents relating to communications technology, this effort in simplifying creating/specifying the meaning for claim 1—which under normal circumstances would be regarded as excessively long drawn out—is justified. Normally the relevant person skilled in the art would base the reading of claim 1 on his own on such a model.
The HOCIS RM is compulsorily apparent from the general principle on which the OSI RM is based (particularly its above mentioned L7 standard) for the analysis of a TCP alias of a communications application. The special module sub-division shown below of its M(HOCIS) is thereby HOCIS-method-specific. This special module sub-division of the M(HOCIS) and its use in the
The detailed nature of the following explanations of the HOCIS RM and 18
Now to the structure of the HOCIS RM. Only for the purpose and area of these
For the purpose of illustrating the HOCIS RM we will now consider the most important structure elements of
The HOCIS RM undertakes as regards the abstraction level and meaning contents of the layers 4-7 according to the OSI RM, and thus with regard to the M(HOCIS), one of the nowadays often practiced simplifications (see for example J. Schiller, Mobile Communications, page 17, ISBN-13: 978-0-321-12381-7): By “L7” is meant here the entirety of L4-L7 of the OSI RM—wherein the bold type of L7 is meant to indicate this oversimplification of the OSI RM terms/conceptuality for the purpose of simplifying the following explanations. This notation simplification thus implies no modification of the terms/conceptions of the OSI RM—which are used furthermore and without bold type—and no change of meaning of the claim 1 wording.
Corresponding to this simplification the
Some explanations about the (initially two each) L7-HOCIS terminal system boxes: Their two inner columns show the respective L7-M(HOCIS) whilst their two outer columns show the site of the (abstract) implementation of the respective L7-M(HOCIS) in its terminal system, i.e. an abstract telephone apparatus or IAD or its abstract user alias SUBC (insofar as this is present).
The latter divides an L7-M(HOCIS) into abstract realization alias abstract levels:
The lower abstraction level models the entity of the abstract interactions of the L7-M(HOCIS)—with whomever—for the purpose of detecting/modifying/evaluating/generating/. . . the HO-relevant meaning of at least part of this information, thus the supplying of HO-relevant information, prior to the transfer according to claim 1 (as well as the L4-L6 OSI RM meanings which are to be added through the above L7 oversimplification).
Accordingly, in the HOCIS RM each L7-M(HOCIS)-entity/module consists of an “L7-M(HOCIS)-Hi”-entity/module and an “L7-M(HOCIS)-Lo”-entity/module.
In the following the prefix “L7-” and the suffix “-entity/module” are mostly omitted—as also increasingly the character strings “(HOCIS)” and “HOCIS”, particularly in the module identifiers.
The question of whether a HOCIS TCP is according to claim 1 or not is decided by the “participation” of the M-Hi and M-Lo modules in the HOCIS TCP terminal systems in supplying and transferring HO-relevant information to one of their SUBCs. In OSI RM terminology/conceptuality: is decided by the participation of the M-Hi and M-Lo modules in at least one L7-HOCIS-OSI connection of this STCP (as will become apparent shortly).
Accordingly in the HOCIS RM of an STCP generally only its at least one L7 STCP-OSI connection is considered wherein it models its interaction with a
In other words: In the HOCIS RM a PTCP-/STCP-SUBC is modelled in a PTCP/STCP terminal system by an M-Hi, and the M-Lo therein models its supplying-functionality of HO-relevant information. These pairs—(last mentioned functionality, M-Lo) and (SUBC, M-Hi)—are thus respective synonyms in the HOCIS-RM. The semantics of the interactions inside each of the two synonym pairs is outside of the HOCIS RM.
In the HOCIS RM the term/conception of “participation” of an M-Lo and M-Hi respectively in the supplying and transferring of HO-relevant information has prime importance. It means: An M-Lo or M-Hi is “participating” in the transfer according to claim 1 of HO-relevant information if this is generated and/or detected and/or modified as regards contents or display and/or is supplied and/or is forwarded and/or received and/or consumed by it partially or totally in some way. This participation of an M-Lo or M-Hi respectively stands for the participation of its respective M(HOCIS). It takes place as a rule automatically, but can however also be initiated where necessary by the SUBC.
A thus participating M-Lo or M-Hi of the HOCIS RM is also called in this printed specification a “relay” alias “L7-relay”. (An L7-relay is thus a conceptual coarsening of at least one OSI RM type Li-specific relay—following the conceptual coarsening shown above of the higher Li-connections to an L7 connection). The two relays in the initiator and addressee modules respectively of a transfer of HO-relevant information are called “terminal points” of this transfer, wherein (according to claim 1) the addressee module is always an M-Hi and at least one M-Lo always participates in the transferred HO-relevant information. In order to distinguish these two initiator and addressee HOCIS terminal points of a transfer of HO-relevant information from further “relay points” of this transfer, in
In simple cases only one M-Lo directly involved in the HO and one M-Hi indirectly involved need participate as terminal points in a transfer according to claim 1 of HO-relevant information between two STCP terminal systems. It can be “relayed” by the telephone-resident part (see below) of the directly involved M-Hi, which causes these two to be participated, or through the indirectly involved M-Lo, which causes this to be participated—if these are present in the two terminal systems.
The dotted lines of the 18
The HOCIS RM makes the precise understanding easier of the claim 1 wording/meaning—which for reasons of simplification is by way of example restricted in
Now for facilitating the precise understanding of the claim 1 wording/meaning by means of the HOCIS RM and the 18
An M-Hi or M-Lo of an M(HOCIS) respectively is thus in the HOCIS method—and therefore the HOCIS RM—not restricted to its respective “actual” abstraction level: Rather in the HOCIS RM parts of both the M-Hi and of the M-Lo functionalities are located on the respectively other abstraction level and these parts are then sometimes called “non-actual” M-Hi or M-Lo.
Dividing up these entities/modules of the M(HOCIS) into the two abstraction levels of the HOCIS RM facilitates a specific and very technical manner of specifying the understanding of the claim wording/meanings of this patent application. However it is possible to dispense with this division: None of the claims namely makes use of it. They all dispense with a rigorous sub-division of an M(HOCIS) and use instead some M(HOCIS) attributes—which compared to it are more colloquial, simpler and entirely adequate—which sub-section D.4.12. summarises/defines.
It should be noted however that it does not interfere in an STCP OSI connection according to claim 1 if this additionally contains a Hi-connection and/or Lo-connection.
These pragmatically therefore important participation structures according to claim 1 of these four HOCIS OSI connections incidentally display as regards the HOCIS for a PTCP-SUBC indirectly involved in an HO the central message of the invention according to the claim 1 (the significance of the HOCIS method for the directly involved PTCP-SUBC will be considered further below). In order to graphically emphasise which of the two PTCP-SUBCs is the most favoured each time in the following
More precisely: Once one is conversant with these four participation structures then the “participation structures according to claim 1” reveal no more misunderstandings up to
In these four figures it is only assumed that the indirectly involved telephone user correctly understands the HOCIS transferred in natural speech (and transferred by “voice channel”) to him, This articulates the modelling of this user—thus that he knows how to correctly interpret this HOCIS—by allowing him an M-Hi. I.e.: The modelling of an absolutely “unable-to-understand-HOs” or absent indirectly involved SUBC would provide no M-Hi.
It can be seen in the participation structures of these figures that
With regard to the four figures previously explained, it can be noted that they in no way list all the participation structures of the transfer according to claim 1 of HO-relevant information in HOCIS processes in which the indirectly involved telephone cannot support a HOCIS process (because it contains no M-Lo functionality, as modelled in them). The relevant person skilled in the art namely immediately recognises that for example all 4 types of HOCIS OSI connections just explained can as well be initiated by the indirectly involved PTCP-SUBC—possibly by typing in a DTMF code or by his input of a natural-language command or by transmitting an SMS message or another signal over any network (which can be modelled by its correspondingly functionally specified M-Hi), to the receipt of which the directly involved M-Hi and/or M-Lo suitably reacts. The associated participation structures are in the meantime obvious—thus need not be demonstrated or discussed further here.
It would be equally superfluous to discuss the fact that the claim 1 wording/meaning also covers HOCIS methods which provide before/at the required transfer there of at least one HO-relevant information some other information exchange and/or some interaction between whomever.
This biodiversity of already the most elementary “participation structures” according to claim 1 is considerably increased in that the left or both of the telephones just considered is/are (an) FMC telephone(s) in which the GSM/CDMA—and WLAN/Femtocell-functionalities have different HOCIS functionalities. Since the new participation structures made possible thus are “straightforwad derivable” fixed-mobile combinations of the previously shown participation structures, they are not elaborated on further in this written specification—because they can be identified by the relevant person skilled in the art without problem. I.e. the exemplary HOCIS configurations of
To conclude the discussions up to here about participation structures in “server-free” (as a rule “subscriber/subscriber”) transfers of HO-relevant information it should be noted that in these exemplary scenarios a terminal device without M-Lo directly involved in an HO—i.e. a current “GSM/CDMA only” telephone—cannot initiate the HOCIS method, more particular: an STCP, by itself. But in the case that it cooperates with a HOCIS server/IAD (or HOCIS telephone) this can change insofar that these HOCIS terminal systems realise a “virtual M-Lo”, as will become clear below.
The relevant person skilled in the art can ascertain without problem at the latest on this understanding basis—covering the following comments on the 10
In 5i the HOCIS IAD can therefore—as regards the at least one STCP supported by it—contain at least the following three different M(HOCIS):
A virtual M-Lo of a PTCP/STCP terminal system or its user will be discussed from time to time further on and then—for the reasons mentioned in sub-section D.4.12.—is called its “virtual M(HOCIS)”. It can execute the M-Lo-information detection/transfer better in some circumstances than a telephone-internal M-Lo: It can for example still have access to the voice channel between the M-Hi of the two telephones, whilst a telephone-internal directly involved M-Lo has already lost this access to the indirectly involved M-Hi.
Right here reference is made to the special features as regards connectivity of a virtual M(HOCIS)/M-Lo of an STCP system: The transfer of an HO-relevant information from/through this virtual M-Lo to the PTCP-SUBC can
The relevant person skilled in the art knows that in all these cases it need not follow from this that this HO-relevant information can be offered to the SUBC only in the information display of this PTCP data channel. For example: If this PTCP data channel is a voice channel, if the terminal device has suitable DTMF functionality, and if it can be programmed sufficiently flexible—which is e.g. is the case in many of the standard telephones of the present day—then it can also be offered for example textually to him. By the way, by dispensing with such an information display-conversion (when using the voice channel just mentioned to the SUBC) obviously a relay can be dispensed with in the SUBC terminal system—which makes possible the HOCIS of the users of present day standard telephones through HOCIS IADS, thus without having to modify these telephones in any way. The great economic significance of such IAD-supported HOs is apparent from claims 70-79 and the comments thereon in sub-section D.5.
Thereby not all HO-relevant information ultimately transferred to the SUBC need be made available to the virtual M-Lo in the IAD as regards a potential or current HO of its directly involved WLAN-/Femtocell telephone. Rather the definition of “HO-relevant information” allows for the fact that this M-Lo (e.g. its detection of HO-relevant information regarding the directly involved PTCP terminal system) is relocated totally or partially to at least one HOCIS server/IAD/telephone and the M-Lo information thus collectively obtained where necessary is transferred to a SUBC—thus even if HO-relevant information is contained in it which was not detected by the M-Lo of the directly involved terminal system. For claim 1 a virtual M-Lo for a directly involved STCP terminal device—in for example an STCP server/IAD—is therefore of equal value to an STCP terminal device-internal M-Lo.
I.e. more particularly: Even if a directly involved SUBC STCP terminal system of an STCP actually contains no internal M-Lo, but has however a virtual M-Lo (for example in a server/IAD/telephone) then this STCP participation structure however starts in this SUBC STCP terminal system—thus not in an STCP terminal system which contains this virtual M-Lo as a whole or in part.
The focus will now be in the following on the fact that in 51 no HOCIS-TCP/method (and its participation structure) according to claim 1 was explicitly shown between the HOCIS server/IAD and the directly involved telephone—but based on the significance especially of these thus structured HOCIS TCPs alias STCPs for this written specification, these require clarification of understanding. This is now provided by the 5
It should be noted in both figures: Each M(HOCIS), for the transfer of its HO-relevant information to a telephone user, if the two are not located in the same terminal system, can use a different network from its PTCP—which naturally also applies for all previous figures.
These four cases 5o-r therefore and moreover only explain
The cases complementary with this—that thus at least one of the three conditions is not met—are not explained here: The HOCIS methods according to claim 1 suitable for them are equally apparent “straightforwardly” from the discussions of this section D. if they are not already shown by its figures and their obvious combinations.
The considerable importance of individual ones of these HOCIS variations was already emphasized at the end of section B. These four associated figures and their explanations now clarify the somewhat different and/or additional technical complexity which here underlies the HOCIS method, compared to the “telecommunications configurations” previously discussed. This technical complexity thereby remains fundamentally unchanged: namely directed to the assistance of the telephone user as regards an HO situation—and not to the solution of a technical problem of this HO situation (see end of section B.).
o: New rudimentary connectivity whilst the telephone is checked in elsewhere and supports a PTCP. Basically it is possible to proceed here from any of the previously discussed telecommunications arrangements and their HOCIS participation structures—to which now the discovery of the new rudimentary connectivity is added. 5o stems especially from 5m, shows the new HOCIS-IAD (below the 5m telecommunications configuration) and the participation structure of the STCP OSI connection which the telephone establishes to the new HOCIS-IAD (as new STCP terminal system). It should be noted that the PTCP OSI connection—more precisely the routing of its L3-connection—remains untouched by whether it in future is routed over this new HOCIS-IAD or furthermore over the HOCIS-IAD of the telecommunications configuration from 5m.
Any HO-relevant information transferred to the STCP-/PTCP-SUBC in the directly involved STCP/PTCP terminal system is in accordance with claim 1 if it is supplied by the real or a virtual M-Lo (i.e. by the M-Lo in this telephone itself or an M-Lo which for example is located in an IAD suitable for current or potential routing of the PTCP, as in 5o). It should thereby be noted in particular that this HO-relevant information also
p: New rudimentary connectivity whilst the telephone is checked in elsewhere and supports no actual PTCP. Seen more precisely, here the terminal system directly involved in the potential HO can perfectly support a PTCP (as in 5o)—if it is namely capable for this, while checked into two networks at the same time, of supporting at the same time two PTCPs, e.g. one each over one network (which where necessary is already to be considered for the understanding of 5o. In particular one of these two PTCs can be an “IPTV”-TCP or “IPRadio”-TCP or another “IPbroadcast”-TCP or similar, which uses a different network or a different networks feature than the other PTCP).
It should rather also be explained here in particular about the possible consideration of the new IAD connectivity in a HOCIS method as regards a not yet existing PTCP if the terminal system indirectly involved in the potential HO does not have this aforementioned capability.
Accordingly 5p need only consider the IAD in which this terminal system is just checked in (and which where necessary also stands for a base station of some GSM/CDMA/UMTS/Wimax/satellite/ . . . network) as well as the new IAD.
First here the understanding is required that the telephone directly involved in an HO also already supports a PTCP according to claim 1 in this situation—when therefor there is not or not yet an “actual” PTCP between human SUBCs, as was as a rule implicitly assumed previously: That is the “admin PTCP”, which the human telephone user has produced when checking in his telephone at the IAD (shown at the top right in 5p) between him and the automaton-SUBC of this IAD (with which since this checking in until checking out from this network he interacts explicitly and/or implicitly) and which expands the original rudimentary connectivity of the telephone (on the L1) where necessary to its internet connectivity (on the L1-L3).
Thus in this patent application an actual PTCP with a SUBC can often only start—as a rule if he is mobile—after there is for him a running admin PTCP with for example an IAD (see section B.), i.e. after successfully checking in with this IAD by means of this admin PTCP.
According to this there is already in all the previously explained
Even more simply/clearly apparent/given is this a priori existence of the admin PTCP according to claim 1 (where necessary already running and then possibly in addition to an actual PTCP set up with its assistance) if it already starts a further “admin-end-to-end communications application” immediately after the checking in at the IAD (shown at the top right in 5p) and before the start of the first actual PTCP, in order to start if necessary only with the aid thereof at least one actual PTCP—for example a “netsurfing connection” (as this admin-end-to-end communications application) between the directly involved telephone and one of its “home IADs”.
Furthermore the last paragraph (with its 3 bullet points) on the explanation to 5o also applies for this telecommunications configuration.
q&r: New rudimentary IAD connectivity whilst the telephone is not checked in. Seen more precisely, here the terminal system can be checked in definitely somewhere if it has the capability to be checked into two networks at the same time (so that it can support two concurrent admin PTCPs with their two IADs, one each per network at least). This terminal system—deviating from 5p—now does not need to be suitable to operate an actual PTCP respectively additionally at the same time over both networks, independently of one another or not.
Rather explained here is the HOCIS for a terminal system, which does not have the previously described capability, immediately after its discovery of its new rudimentary IAD connectivity (wherein the IAD in turn stands where necessary for a base station of some GSM/CDMA/UMTS/Wimax/satellite/ . . . network), i.e. with its potential and/or current checking into this IAD immediately following this discovery—whereby the terminal system expands its rudimentary connectivity to the internet connectivity of its user (and supported the same straightaway for example per netsurfing communications application), as is now explained.
In order to explain this, 5q shows a terminal system with rudimentary connectivity only to one IAD over which (i.e.: over whose network) the former can enable internet connectivity for its SUBC—whilst 5r shows that it can have rudimentary connectivity to several IADs, but it can enable the internet connectivity for its SUBC nevertheless only over one of these IADs (although before actually producing this internet connectivity over just one of these IADs it discovered the production-possibility/impossibility of its internet connectivity over at least one further IAD, possibly concurrently).
After the explanation on 5p it can be easily seen that a terminal system even in this situation—when it is not yet checked into any network, but has already detected a rudimentary connectivity to a network—already supports a PTCP according to claim 1, namely the admin PTCP which was already explained in 5p. This admin PTCP exists by definition for the SUBC of this terminal system from the moment of the discovery of this rudimentary connectivity for/in this terminal system (see section B.). As a reminder: This admin PTCP has the objective to establish by the automated SUBC of the new IAD the internet connectivity for the (as a rule human) SUBC of the PTCP terminal system involved in the rudimentary HO—and in cooperation with this subscriber —, to maintain it and to terminate it with his checking out from this IAD.
The HOCIS according to claim 1 during this establishing of the internet connectivity through the admin PTCP offers to the SUBC (in the PTCP terminal system which is involved in the rudimentary HO) in fact as a rule an important orientation and decision aid. This is immediately understood if one thinks that (see section B and for example dependent claims 70-79)
The previous explanations show unmistakably that the HOCIS method provides the users for example of a telephone with actually important orientation/decision aids and simplification if he wants to use the HOs of the different variations or wants to evaluate them or avoid them or question them or . . . or has to accept them which are outlined in the
I.e. that the M(HOCIS) of its PTCP/STCP terminal system (or its virtual M(HOCIS)) sent out at least one PDU to the latter system in order to improve its current connectivity to the latter. The result of such an active communications attempt of this M(HOCIS)—in order to ensure the receipt of HO-relevant information—can happen quite differently: E.g. it can
In all cases a transfer of an HO-relevant information—originating from this M(HOCIS)—and containing this result to the PTCP-SUBC can take place.
The text passages in brackets in the previous paragraph thus explicitly refer to the fact that a virtual M(HOCIS) of a SUBC PTCP/STCP terminal system or one of its at least one PTCP-SUBCs can have started a HOCIS attempt. It is then called “virtual HOCIS attempt”, otherwise “real HOCIS attempt” of this system/SUBC. In a virtual HOCIS attempt the virtual M(HOCIS) can be located for example in an IAD, in whose WLAN a non-HOCIS FMC telephone is currently checked in—and the “direct transfer” of the HO-relevant information to the PTCP-SUBC (telephone user) would then as a rule take place over its voice channel. (These transfer aspects are dealt with again and in more detail in the comments on claim 80.)
The demarcation between both functionalities is important: Any M(HOCIS) function in the execution of which no human participates or needs to participate—which in any case the relevant person skilled in the art can judge—may be regarded in this patent application as M-Lo function (even if the type of its intelligence should be assumed somehow “human” to one or the other) and then belongs to its non-intelligent M(HOCIS). “A non-human M(HOCIS)” is thus a synonym for “a non-intelligent M(HOCIS)”.
These “intelligent/non-intelligent M(HOCIS)” terms can replace in all the preceding explanations the “M-Lo/M-Hi” terms 1-to-1.
To conclude these sub-sections D.2.-D.4. it is pointed out that the wording abbreviations practiced in the dependent claims compared to the claim 1 wording are only to simplify reading them—particularly by leaving out sometimes the obtrusive set phrase “at least”—thus have nothing to do with a generalisation of the claim 1 meaning. The same applies appropriately for the following claims groups comments which become shorter as a rule as the claims groups numbers rise: That which has been said once in comments on claim 1 remains valid also for the following comments, thus does not need to be constantly repeated, but also permits linguistic imprecision which makes it easier to read and understand them.
Re claims group 2-9: Here some implicitly assumed different features of the PTCP underlying the HOCIS method according to the invention and/or the at least one terminal system thereof are disclosed in explicit detail.
Re claims group 10-19: It was already discussed in detail in sub-section D.1. “It identifies the features of the special cases class of this HOCIS method characterised by overlappings of the start and/or execution and/or termination of the 3 different processes therein and their combination possibilities by means of the special cases explicitly revealed by it of the HOCIS method according to the invention”.
The following comments on the individual claims groups would have each time to start with the same introductory set phrase independent of the claims groups—written in apostrophes and in italics just above —, with the exception of its part written in bold which is specific to the claims group. This stereotype passage independent of the claims groups is however only alluded to each time in the following by the respective introductory 4 dots “ . . . ”, followed by an analogy to the above bold text which is specific to the claims group written in bold in italics and inside apostrophes.
This claims group shows that it is practically impossible to list fully in this patent application all possible variations thereof (according to sub-section D.1.) or even only to show succinctly in an easily understandable way “variation characteristics” underlying them—simply because of their large number and complexity. In particular it should be noted that this claims group refers to the fact that the claim 1 contains no restriction to PTCPs with only one HO and/or with only one terminal system directly or indirectly involved in an HO (see section B. on this).
The application scenario types of the HOCIS method addressed in this claims group are further explained in the last method claims groups.
Actually these are two claims groups, as will become apparent shortly. For both it applies that there is only one—albeit very structured—restriction of the meaning of the dependent claim 70 over that of claim 1 and that this is undertaken in its wording passage
The above restriction +) makes it necessary—indeed only by means of the dependent claims 71-79 to which however reference is previously made here—for this aforementioned clarifying of understanding insofar as it makes it necessary to recognise the inadmissibility of some restricting assumptions about the claim 1 wording/meaning, even if these faulty assumptions appear “naturally” on first notice. By way of example it is easier to be seen on the basis of this restriction.
Incidentally the restrictions of claim 70 change nothing to the fact that it furthermore relates in an HO to as a rule all its PTCP-SUBCs, both the SUBCs involved directly and those also involved indirectly in same. This also applies in the two following claims groups—even though in particular the directly involved SUBCs and their PTCP/STCP terminal systems are considered in the associated
It fans out claim 70 corresponding to
It fans out claim 70 corresponding to
Re claims group 80-82: Claim 80 discloses a (generic) abstract HOCIS apparatus for implementing an abstract HOCIS method, which in some circumstances is more general than the HOCIS method according to claim 1 (see below). Dependent claim 81 restricts the functionality of this HOCIS apparatus according to claim 80 to that which is required for the abstract implementation especially of a HOCIS method according to claim 1 or according to at least one of the dependent claims 2-79.
The model of the abstract construction of an abstract HOCIS apparatus and its HOCIS-apparatus terminal systems with PTCP-SUBCs is already described in sub-section C.6. On the basis of the abstract resource sharing—functionally naturally always conceivable and therefore possible—explained there it is in the abstract irrelevant whether STCP apparatus components use or not use PTCP apparatus components which are essentially provided anyhow.
It should be noted: This abstract construction of an abstract HOCIS apparatus and its terminal systems at PTCP-SUBCs also permits material implementations alias embodiments of an abstract HOCIS apparatus terminal system at a PTCP-SUBC wholly or partially in a there independent material HOCIS terminal device (i.e. need not be located in at least one physical PTCP terminal system provided there anyhow). Such a separateness of material PTCP and/or HOCIS terminal devices can—but need not—be traced back to the fact that they would be incapable for material technical reasons of resource sharing (This is e.g. the case as a rule with a present day “only WLAN telephone” and an “only GSM telephone” isolated therefrom, between which a PTCP changes in an HO). Other reasons for this separateness can be incompatibilities of all kinds between PTCP and/or STCP modules, but in the future possibly also be the wish of a SUBC to receive all HOCIS and all HO-relevant information about all of his PTCPs in an appropriately integrated way at at least one HOCIS device which is particularly suited for this, which for convenience reasons therefore should be separated from the at least one as a rule differently designed PTCP terminal device (which in turn can maintain several simultaneous different type PTCPs via possibly different type networks/access points/services features).
It should next be confirmed that the two functions of a HOCIS apparatus “indirect or direct transfer (of an HO-relevant information through any means to a SUBC)” and “direct use (of the means transferring an HO-relevant information by a SUBC)” each cause that which they intuitively suggest:
Otherwise—namely the SUBC and means do not belong to the same OSI terminal system and the means is not a virtual M(HOCIS) of the SUBC OSI terminal system—its transfer by the means to the SUBC requires to switch a paired means between the two in the SUBC OSI terminal system and is therefore an “indirect transfer”.
Finally the principle of the apparatus main claims will be explained—and its fundamental difference from the principle of the method main claim. Accordingly a HOCIS apparatus according to claim (80-82) contains a set of means according to claim (80-82). These means are connected at least means-internally and to one another by means of at least one network which however was not included as an obvious feature into the aforementioned apparatus main claim wordings, like the computer systems realising these means. The means of this set are suitable for providing in their interaction—suitably controlled—with one another and with the PTCP-SUBCs for the latter a desired HOCIS as regards an HO in these PTCPs, An apparatus which contains such a set of means is called a HOCIS apparatus. It should be noted that of a HOCIS apparatus alone, thus without such a control, it is not known that it would work appropriately.
Rather a HOCIS provision for the SUBCs using a HOCIS apparatus only happens by means of a suitable control of the interaction of its means and SUBCs. A process of HOCIS provision thus controlled is called in this written specification HOCIS TCP alias STCP. A method according to which this control of the means use in this interaction takes place is called HOCIS method. It should be noted that such a control method need not refer explicitly to the means itself, but can control the use of the respective functionalities (and thereby thus implicitly relate to the means)—as happens in this written specification.
For each control method of a HOCIS apparatus—for realizing a desired HOCIS-provision/STCP as regards at least one HO—the apparatus main claims which this HOCIS apparatus implements, impose clear restrictions as regards the exchange (of the apparatus means with one another and with the PTCP-SUBCs using the HOCIS apparatus) of HO-relevant information in an STCP being based on its control. These restrictions extend so far that most of all (despite this still possible and of practical interest) control methods implement the main claim 1, thus are HOCIS methods according to the invention. And conversely it can be easily seen that every HOCIS method according to the main claim 1 is actually suitable for controlling any HOCIS apparatus according to an apparatus main claim so that it provides a desired HOCIS for PTCP-SUBCs using it.
The three paragraphs above have explained the aforementioned fundamental difference between a HOCIS apparatus according to the invention and a HOCIS method according to the invention.
These dependent claims explain explicitly some features and features combinations which are typical of the apparatus.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2006 057717.5 | Dec 2006 | DE | national |
| 10 2006 059142.9 | Dec 2006 | DE | national |
| 10 2006 059207.7 | Dec 2006 | DE | national |
| 10 2006 062662.1 | Dec 2006 | DE | national |
| 10 2006 062675.3 | Dec 2006 | DE | national |
| 10 2007 001321.5 | Jan 2007 | DE | national |
| 10 2007 001474.2 | Jan 2007 | DE | national |
| 10 2007 003640.1 | Jan 2007 | DE | national |
| 10 2007 003646.0 | Jan 2007 | DE | national |
| 10 2007 005224.5 | Jan 2007 | DE | national |
| 10 2007 006459.6 | Feb 2007 | DE | national |
| 10 2007 008318.3 | Feb 2007 | DE | national |
| 10 2007 010852.6 | Mar 2007 | DE | national |
| 10 2007 012683.4 | Mar 2007 | DE | national |
| 10 2007 016775.1 | Apr 2007 | DE | national |
| 10 2007 019752.9 | Apr 2007 | DE | national |
| 10 2007 022874.2 | May 2007 | DE | national |
| 10 2007 053363.4 | Jun 2007 | DE | national |
| 10 2007 027627.5 | Jun 2007 | DE | national |
| 10 2007 030580.1 | Jun 2007 | DE | national |
| 10 2007 031414.2 | Jul 2007 | DE | national |
| 10 2007 032806.2 | Jul 2007 | DE | national |
| 10 2007 034892.6 | Jul 2007 | DE | national |
| 10 2007 034290.1 | Jul 2007 | DE | national |
| 10 2007 039872.9 | Aug 2007 | DE | national |
| 10 2007 055022.9 | Nov 2007 | DE | national |
| 10 2007 057274.5 | Nov 2007 | DE | national |
| Number | Date | Country | |
|---|---|---|---|
| 60868159 | Dec 2006 | US | |
| 60892272 | Mar 2007 | US | |
| 60943347 | Jun 2007 | US | |
| 60950069 | Jul 2007 | US |
