Methods for identifying terminal devices and / or their data in networked messaging connections and / or for establishing a messaging connection between terminal devices and a server or server network.

Abstract

Procedures for setting up a messaging connection and / or logging into a messaging connection, which includes the purpose of synchronizing server or data processing processes, which obtain data from the end devices assigned to these processes and / or output data to these end devices, whereby a) by the aforementioned method, a first terminal device and a second terminal device are to be assigned to establish a connection, to a message connection belonging to the server or data processing processes, and the two terminal devices are each networked via their message connections with facilities through which the server and / or data processing processes run or are to run, and the data sent and / or received by the terminal devices are or are to be automatically assigned to the processes present in the server or data processing processes via the aforementioned synchronization, wherein b) the aforementioned terminal devices each have and / or can establish a messaging connection, corresponding to the type of connection established by the respective terminal device, to a facility belonging to the respective terminal device that provides the messaging connection of the terminal device in question, wherein each terminal device communicates with the facility belonging to it and the facilities providing the messaging connection of the terminal devices are networked with one or more servers or an equivalent facility, or form or establish such a network, and this network may involve a server jointly assigned to the terminal devices or may involve servers separately assigned to the terminal devices that are networked with each other, or an equivalent facility, for all variants referred to below as "server network". c) the aforementioned network enables the establishment of a communication connection between the terminal devices and the aforementioned server network, including the server or data processing processes running on the server(s) or an equivalent facility, characterized in that d) a data loop DS is formed via the terminal devices and their respective associated message connections, including the aforementioned server network, whereby, for the purpose of establishing a message connection relating to the aforementioned connection establishment and / or the login process, a data transmission is carried out directly between the terminal devices on the terminal device side, solely for the purpose of establishing the message connection, by means of a signal coupling (DS) temporarily carried out directly between the terminal devices. e) within the said network a CODE is used which contains data of a CONNECTION CODE for dialing or addressing the said server network, wherein the CODE is transmitted from one terminal device to another via the signal coupling (DS) carried out directly and temporarily on the terminal device side between the terminal devices (Fig. 1a; Fig. 5; or Fig. 12a), wherein f) the aforementioned CONNECTION CODE is used as a regulation for establishing a connection in order to establish a connection at the terminal device which receives the CONNECTION CODE from the other terminal device via the direct signal coupling (DS) between the terminal devices (Fig. 1a; Fig. 5; or Fig. 12a) to a subscriber line or subscriber address designated by the CONNECTION CODE via the device providing the message connection of the terminal device and the associated server network, wherein (g) on ​​the terminal device which establishes a connection to a subscriber line or to a subscriber address designated by the CONNECTION CODE via the device providing the terminal device's message connection and the associated server network, the established connection is maintained even if the aforementioned signal coupling (DS) between the terminal devices, which is only temporary for setting up the message connection, no longer exists. h) and / or the data contained in the KODE are used for the synchronization and / or networking of the server processes and / or data processing processes at the aforementioned facilities where these processes take place, whereby h1) Data associated with these processes are transmitted via the communication link between the aforementioned terminal devices and their facility(ies) providing the communication link of the terminal devices, including the aforementioned server network or an equivalent facility, h2) and the data transmitted between the terminal devices and their facility(ies) providing the communication link between the terminal devices are assigned to the server or data processing processes running via the aforementioned server network using the code transmitted by the aforementioned facility providing the communication link between the terminal devices, even if the aforementioned direct signal coupling (DS) between the terminal devices, which is only temporary for the purpose of establishing the communication link, no longer exists.

Description

[0001] The invention relates to a method according to claim 1 and / or a method according to claim 10.

[0002] This patent application covers the following priorities: (01) DE 10 2004 046 413.8......... 09 / 24 / 2004 (02) DE 10 2004 059 168.7......... 08.12.2004 (03) DE 10 2005 007 379.4......... 02 / 17 / 2005 (04) DE 10 2005 008 086.3.......02 / 22 / 2005 (05) DE 10 2005 009 367.1.........03 / 01 / 2005 (06) DE 10 2005 010 414.2.........03 / 07 / 2005 (07) DE 10 2005 012 989.7......... 03 / 21 / 2005 (08) DE 10 2005 015 619.3......... 04 / 05 / 2005 (09) DE 10 2005 016 304.1......... 04 / 09 / 2005 (10) DE 10 2005 029 025.6......... 06 / 22 / 2005 (11) DE 10 2005 045 947.1-31........ 26.09.2005 .. (filing date of 10 2005 045 947.1-31) and concerns a method and a circuit measure taken to carry out the method in order to fulfil the following technical task:

[0003] The overarching technical task can be viewed as the technical requirement to use the coding (addresses, telephone numbers, radio channels, etc.) of the subscriber connection points of communication links in hierarchical networks (e.g., telephone connections) for the secure addressing of data connections in any network, in particular for the synchronization and networking of server processes that run simultaneously or consecutively at any time intervals. Depending on the application, this synchronization can encompass both hierarchical networks (telephone, mobile phone, etc.) and, in particular, non-hierarchical networks (e.g., the Internet), in order to make data connections more secure in non-hierarchical networks. For example, to link the addresses of non-hierarchical networks (e.g., the Internet), even if they only exist temporarily, to the coding of hierarchical networks (such as telephone numbers in landlines and mobile phones), etc.This can be done not only to verify temporary addresses, but also to securely address the data transmitted over these insecure networks, as well as the data written into or read from relevant databases via these networks, using the coding of hierarchical networks (such as landline and mobile phone numbers). This means, for example, that data transmissions from mobile phone to mobile phone, or from mobile phone to landline, or landline to landline (even within conference calls) of any different or identical networks can be linked using their coding (e.g., telephone numbers), and the data can be addressed independently of the actual connection addresses of servers and end devices, or even just end devices (e.g., in conference calls). This ensures that a data connection established between the respective participants (e.g., internet participants, servers, mobile phones, etc.)) actually concerns the correct subscribers and the dialing cannot be manipulated (e.g. by Trojan programs, etc.). In further development, this new method is used in many different applications, such as cashless payment, secure server login, proof of user identity, etc. Although the basic idea appears simple at first, it opens up a wide range of new application possibilities that will initiate a rethink in the entire field of electronic communication. Many of the state-of-the-art measures used exclusively with complex programs to close security gaps in operating systems are made superfluous by the present invention, while security is significantly increased, because the method proposed here is extremely transparent, simple, but more efficient than anything that has existed to date on this topic.Due to the wide range of possible applications of the invention, the application has also become somewhat extensive.

[0004] Another objective of the present invention is to simplify the connection of a terminal device using another terminal device. The invention also significantly improves the ease of use for a wide variety of applications, as described in the examples below, while significantly increasing security against misuse. State of the art:

[0005] The state of the art cited here is, firstly, the common method of using a name generator, in which one device sends an address that is recognized by the other device in a two-point connection, e.g., when displaying a caller's telephone number to the called party. Furthermore, the common method of transmitting a code to a user, e.g., using a number received when purchasing a mobile phone top-up. Or, for another application: after payment via mobile phone, the sending of a code number via SMS, which must be manually entered into a machine in order to operate the machine. The machine stores the numbers in reserve, comparable to transfer numbers for online accounts, which will also be cited here as state of the art.All of these systems have the main disadvantage that security depends directly on the network operator, as does the feasibility of complex processes (e.g. dependence on the network operator for cashless payments, etc.).

[0006] All of these methods are therefore imperfect and vulnerable, and completely unsuitable for the high security requirements and required level of automation of the applications specified in the invention. Therefore, the aforementioned applications have not been reasonably feasible in practice to date. For example, the input of a number could be transmitted at any time via a different data channel and used by a third party. This would make it impossible for the provider of a website to reliably use the method as access security, etc.

[0007] From DE 199 38 201 A1 a method is known for carrying out and invoicing a purchase made by a buyer over the Internet from a seller of products or services, whereby for a purchase requested by the buyer over the Internet, mobile phone subscriber identity data representing his mobile phone subscriber identity are transmitted by him to the seller via a mobile phone network and are then transmitted by the seller to a security device.

[0008] The solution is provided according to the two independent claims 1 and 10. The associated subclaims relate to advantageous developments of the invention. Wherein a data loop DS (provided by the user) is closed via the relevant networks or data connections, via which a corresponding CODE is transmitted for testing, addressing, or assigning the relevant subscriber connections of the networks (or data connections). In a further development, this CODE is randomly generated as a security code. The code packet can be further secured using a hash code in accordance with a digital signature. The digital signature is incorporated both in the security codes CODE transmitted via the data loop DS and in the data transmitted via the data loop DS. In a special further development application, when forming the data loop DS transmitted via the terminal devices ( Fig.1a) the individual terminal connections (telephone connections, Internet connections, etc.) are not selected simultaneously, but sequentially with the code (KODE) being temporarily stored in the individual terminal devices.

[0009] The specified measures for technical action, relating to the formation of a data loop DS by the user on the client side (user side) using two communication networks or connections or channels, and the transmission of a code KODE which is in principle arbitrary (e.g. also randomly generated) and which is integrated into the transmission protocol of the data connection, solves the specified, very extensive technical tasks and problems and, above all, enables the development of a wide field of the most versatile applications, as further claimed in the corresponding subclaims as preferred developments of the invention. In this development of the invention, precautions are taken to ensure that the user cannot manipulate this data connection to another terminal (using another communication connection) and thus transfer personal access to a third party.

[0010] In order to adapt to the many different possible applications, two basic variants are provided for the formation of the data loop DS of two communication networks or channels: a) a variant which shall be called a serial data loop ( Fig. 1a), and in which the data loop DS is connected via a corresponding coupling of the terminal devices ( Fig. 2a, Fig. 2b) the communication networks at the client (user) is carried out in such a way that the server sends the security code KODE via one communication network (1) to the relevant terminal of the communication network and receives it back via the coupling DS of the terminal to the terminal of the other communication network (2), whereby a check of the security code KODE takes place in the server, b) and a second variant, or supplementary variant, which shall be called parallel data loop ( Fig.1b), and in which the data loop DS is implemented via a corresponding coupling of the terminal devices of the communication networks at the client (user) in such a way that the server transmits the security code KODE via both communication networks (1, 2), whereby a check of the security code KODE is performed on the user's terminal device. This can be a terminal device that is connected to both networks, or it can also be terminal devices that communicate with each other via the preferred coupling DS, which is generally the case here. An example of such a coupling is shown in Fig. 2a, Fig. 2b and Fig. 4. For special applications, the parallel data loop is used for the present invention as a supplementary variant to the serial data loop, whereby the serial data loop provides the advantages mentioned for the serial loop, and the parallel data loop provides the additional advantages for the respective application. Fig. 1a, Fig. 1b we obtain this variant by bidirectional data transmission via data path 2, whereby for further requirements data path 1 can also be implemented bidirectionally if necessary.

[0011] Both variants, serial data loop and parallel data loop, can also be used in a common procedure if necessary, whereby the server then checks the security code KODE it sends out, and the terminal devices check the KODE, whereby one terminal device then informs the other terminal device (of the relevant communication networks) via the DS coupling of the KODE received from the server.

[0012] In both cases, with the serial data loop and the parallel data loop, the code (CODE) can be checked either by a direct (immediate) comparison or by querying how the CODE has changed during transmission over the two networks according to a rule (or algorithm). For example, in the later Fig.12c, or if the code sent to a mobile phone is provided with a digital signature in the mobile phone (i.e. encrypted), and also contains a further encrypted code portion, which is further modified in the corresponding computer of the Internet access (e.g. at the client) upon recognition, whereby the server decrypts the code once in order to be able to check it, and further checks the manipulation of the CODE carried out in the corresponding computer of the Internet access, e.g. in order to be able to determine whether the data connection is actually made directly between the mobile phone and the corresponding computer of the Internet access, or whether another data connection (e.g. via the Internet, or another telephone connection, etc.) is connected in between, via which a computer of the Internet access located at a completely different location sends the security code CODE back to the server via a connection, e.g.to conceal an unauthorized login process, in which the data loop DS must be closed via a specific telephone connection. Embodiments and developments of the invention are described in detail below with reference to the drawings. Examples of acoustic coupling of the data loop DS are shown, for example, in: Fig. 2a, Fig. 2b, which will be explained in more detail later.

[0013] A further development of the invention relates to the allocation of the terminals used to form the data loop DS by scanning the simultaneously active connections on the server, as they are provided for sending and receiving the KODE using different networks (for sending and receiving), in order to form those pairs of connections via which, with regard to the generation in the server (in particular in the case of the serial data loop), the KODE is sent on one connection and received back again via another connection (corresponding to a pair of associated connections). If a change (e.g.If the encryption is performed (e.g., as part of an encryption procedure or a digital signature), then a portion of the code remains unencrypted, or is only encrypted for all participants in general, so that the code can be scanned and the corresponding connection pairs can be found. During random generation of the code on the server, each generated code is checked to determine whether a similar code has currently been assigned, i.e., whether it has been sent but not yet scanned. If this were to happen by chance (despite the extremely low probability of it actually happening once), the generated code is not sent but discarded.

[0014] What can you do with the invention?

[0015] The examples given in the preview below show the technical measures that are particularly important in the present invention. ACCESS SECURITY:

[0016] For the first time, a temporary address of an Internet subscriber, assigned by the provider, can be linked to a landline telephone number or a mobile telephone number in order to only allow access to protected websites or data using a data loop DS formed via this telephone number. In addition, the security code KODE can be provided with a digital signature by the user on one of the corresponding end devices (or at the coupling point for forming the data loop DS) via the relevant end devices (landline telephone or mobile phone) in conjunction with the security code KODE, which is in principle arbitrary (e.g. generated randomly). The digital signature is integrated both in the security code KODE transmitted via the data loop DS and in the data which is further transmitted via the data loop DS. This means that it is unique in the server, for example the mobile phone of a certain telephone number (orchip card) and the associated digital signature of the subscriber registered to this telephone number (or chip card).

[0017] For the first time, a secure login process to a computer (or network, etc.) can be performed without further entry of the password, instead of the usual one using a password. The automated login process is derived from the password, which, however, is no longer available on the user side upon repeated login (not even in stored form).

[0018] When logging in for the first time using the password and the preferred data loop DS (via which the verification code KODE is sent for testing or assigning the phone numbers of the mobile phones), the phone number of the telephone connection (landline or mobile phone) used to create the data loop DS, which has been verified by the server, is saved in the server and, if desired, the associated digital signature of the subscriber registered to this phone number (e.g. chip card) is included in the verification code KODE.

[0019] This means that the password, or a CODE corresponding to the password, can only be entered once (or, if necessary, several times in succession) in a session. After this entry has been recognized as the correct password, access in subsequent sessions is only possible using the preferred data loop DS (through which the verification code CODE is sent for testing or for assigning the mobile phone numbers). It is obvious that several different passwords can be provided, each of which can be used to change the telephone number under which the data loop DS is formed. Similarly, according to the same principle, the formation of the data loop DS (through which the verification code CODE is sent for testing or for assigning the mobile phone numbers) cannot be carried out via the computer (or not via the network, etc.).), but via another telephone connection, whereby the server then closes both telephone connections via the serial data loop and changes the user's telephone number to the new telephone number in the server upon detection of this connection (by means of the check code KODE which is identical for both telephone connections). SERVER IDENTIFICATION:

[0020] For the first time, a web user can securely identify a provider or server, or determine at any time whether a web page accessed on the Internet is actually authentic. For this purpose, the user dials a telephone number, which corresponds, for example, to a registered secure telephone number of the provider, and receives the server's data line via a corresponding extension of the telephone network, independent of their Internet access IT, via the telephone line Tel, via which the serial data loop DS, e.g., by acoustic coupling, or infrared coupling of their telephone / mobile phone T via the interface to the Internet connection IT (e.g., a computer CL) is to be established by the user ( Fig. 2a, Fig.2b) to form the serial data loop DS, during which the server tests the verification code KODE. Since, in this test, the serial data loop DS is formed over the telephone line Tel that the user has dialed via their telephone or mobile phone T as a secure connection of a hierarchical network, a correct test result from the server guarantees that the user is connected to the correct server and the correct web page.

[0021] The correct test result is then communicated to the user via the secure connection of the hierarchical network (here, a landline telephone or mobile phone). The user triggers the sending of the code on the server side, e.g., by clicking a button on the website. After the test is complete, the corresponding button on the website changes its function and displays the "Pick up the receiver" request (to hear the message over the telephone line). After clicking the button, the server sends a positive acknowledgment or a negative warning via a computer voice announcement over the telephone line. The language of the message can still be selected, e.g., on the website. ANONYMITY, NOW ALSO FOR WEBSITE PROVIDERS:

[0022] For the first time, a provider's website can not only be accessed anonymously by a web user, but the provider itself can also publish its website anonymously. A practical example is described below. To establish the preferred data loop DS, the web user dials the provider's telephone number again. In this case, the data loop is not accessed via the provider's website, but via a general data service website, where any page on the network can be displayed, e.g., within the provider's website. The actual page desired by the web user is not accessed via the Internet, i.e.Not via a link, but via a telephone call from the web subscriber. The server accesses a web page corresponding to the extension number received from the caller and, using the caller's telephone number (verified or provided during the call), creates an address for forwarding the web page. The web page in question is then imported from an anonymous server into the provider's web page. The telephone number, secured by the DS data loop, again provides the web subscriber with the assurance that they are actually on the desired web page.

[0023] • In this case, a web page can be called directly via a telephone number by directly dialing the server in question, or via Internet telephony using an anonymous call, whereby this telephone call is then secured by establishing the preferred data loop DS using a regular telephone connection in a hierarchical network. This ensures that the number dialed by the user (via the anonymous IT connection, voice over IP) does not go through the hierarchical network, but only the internet page used for this dialing is secured by another, more general telephone number. This means that the user can really call up a web page from an anonymous provider anonymously, making full use of all the possibilities. The registration, display and transmission of a web page from an anonymous provider is explained in more detail below with the figures. Cashless payment and general data storage:

[0024] A basic idea of ​​using the present invention for cashless payment is to use the usual terminal devices for message communication that are widely used in the population, such as landline telephones, mobile phones, and various Internet terminals (notebooks, PCs, terminals, etc.) by using the principle of a payment method via these terminal devices, orthe data loop DS closed by the message connections belonging to them and the security code KODE transmitted via it, to connect two servers and the associated terminal devices of two message connections simultaneously and to be able to establish from the server side an unforgeable proof, which can also be provided with digital signatures (in this case of the buyer and the seller), via this connection, in further association with corresponding data belonging to this proof which is exchanged via the data loop DS between the users of the terminal devices and their own servers, or also to the other server (in each case related to the terminal devices).

[0025] This principle is also versatile for other applications; if necessary, the data loop DS can also be closed via just one terminal (in a conference call) and via two or more servers, for example if several exchange lines are available simultaneously via a single telephone. In this case, the seller's server and the buyer's server (or, if applicable, the servers of the banks involved whose accounts are to be used) are connected to each other via this telephone connection. A mobile phone, for example, belonging to the buyer, can also be included in this conference call, so that the servers of two banks (via the conference call of the seller's mobile phone) and the buyer's mobile phone, which is linked via the data loop DS, are connected to each other as a star connection.This would be an example of how the data loop DS can also be formed across more than two networks, whereby time windows for the transmission of data from different participants can be defined by the protocol using appropriate control characters. In the later description of the figures, an example will be given of how the code passed through the data loop can also be generated independently by each of the participating servers (see later on KODE(1) and KODE(2). Alternatively, only two mobile phones are provided (. Fig. 5), through which the data loop DS of their networks is closed, or an IT network terminal can be used instead of the seller's mobile phone ( Fig. 4), etc.

[0026] In this way, cashless payment transactions or similar actions can be processed via the secure link between the two servers using the preferred serial data loop DS and the code KODE transmitted via it. These actions can generally be understood as data deposits verified by a digital signature, which can be used for any desired application. For example, in addition to payment transactions, this data deposit can correspond to a voucher paid for over the Internet, which can be used to collect goods (theater tickets, etc.) at the box office. Or the data deposit, in conjunction with a digital signature added to this data deposit, i.e. to the code KODE transmitted via the data loop DS and the associated data, corresponds to an email, with the data loop DS being closed via the server of a notary or certification authority.This example will also be described in more detail below, particularly with the use of multiple interconnected servers.

[0027] Another application involves equipping the mobile phone with an RFID (Radio Frequency Identifier) ​​detector. This allows the customer to monitor and check the amount to be paid at the checkout while shopping, with payment being made using the preferred method on the mobile phone.

[0028] Top-up: By linking data access via a code, which can be easily entered into a mobile phone as usual, or via an internet connection (or an ATM connected to a telephone network), through which the preferred data loop (DS) establishes the association with the mobile phone being topped up. The amount deposited into the ATM, e.g., a bank's, is credited via the data loop directly to the mobile phone user, i.e., the phone number corresponding to the chip card inserted in the mobile phone and the holder of the digital signature of the code (KODE) certified by the mobile phone.

[0029] Certification: The identification of the person paying via the mobile phone, or if applicable, the person paying into the server, when paying or topping up via the mobile phone, is carried out by server-side verification of the data sent via the data loop DS (from the mobile phone via another mobile phone, cf. Fig.5 or from a mobile phone via a corresponding interface device at a cash register or ATM, cf. Fig. 4, etc.) is carried out, which can be further encoded on the user side (via the mobile phone) with a digital signature, comparable to a document. Here, the document corresponds to the CODE returned to the server, supplemented with further data, such as the amount, the purpose of payment (if applicable), and the identification data (recognition data) of the person(s) making the payment. In addition to the usual PIN number, a fingerprint sensor or a 3D camera built into the mobile phone can also transmit the face of the person in question for image analysis (iris analysis).

[0030] • To prevent any possibility of manipulation during image analysis (e.g. iris analysis) or, where appropriate, speech analysis, the server sends an event prompt which the user must follow immediately. For example, by visually displaying an SMS, sending a broadband image, etc., or by making an acoustic announcement, the user is told what to do: e.g. which text to speak or when to blink (e.g. after a predefined tapping rhythm). The server then evaluates the user's input in relation to the predefined real-time event (by measuring the delay time and / or whether the correct input was given, e.g. a voice announcement for a predefined text, etc.).

[0031] In all cases, the relevant sensors (camera optics, etc.) on the mobile phone or on the device connected to the mobile phone via the preferred data loop DS are ergonomically arranged so that the identification data of the person using the mobile phone, detected by the sensors, can be scanned simultaneously with the code KODE transmitted to another device via the data loop DS, using the digital signature stored on the mobile phone's chip card during pairing (the data loop DS). Positive recognition by the sensors then triggers the addition of the digital signature stored on the mobile phone's chip, possibly supplemented by the entry of a PIN.

[0032] During a voice check, the other device, e.g. a support surface for the mobile phone, can Fig.4, or an ATM, etc., can also use an additional microphone located on the machine, and the digitized audio signal from the microphone can then be integrated into the data stream of the data loop DS; the same applies to any 3D cameras that may be present to record a person's face in three dimensions, etc. COMBINED SIGNATURE WITH DIGITAL SECURITY:

[0033] The process uniquely enables the combination of a digital signature with a conventional handwritten signature. This is illustrated in Fig. 19b. It is state of the art to digitize a signature made on a digitizing pad in real time not only according to the coordinates x and y as a function of time (t), but also to digitize the contact pressure p as a function of time (t) or also the coordinates x, y and to assign it to a person via a digital pattern check.

[0034] As has already been explained and will be explained in a number of examples below, the preferred verification code KODE can be manipulated by all methods known in the state of the art for the purpose of personal coding of the user and can be decoded accordingly in the server.

[0035] In the example after Fig.19b, a digitization pad PAD is used for this purpose, as a component of a dedicated device 300 inserted into the data loop DS, or integrated into the mobile phone (T#) used to form the data loop, etc., or connected to the client computer CL. The SERVER receives the check code KODE via the data loop DS, which is then manipulated, or via another check code KODEn, according to the PAD data using a secret algorithm (e.g., a formula in which the data of the PAD and the KODEn are inserted to obtain a new KODE) and is referred to here as the linked code pad*KODEn. The algorithm for linking the current PAD data with the random code KODE sent by the server can, for example, be distributed, loaded, retrieved, modified, etc., via the telephone line Tel, or via the Internet IT, or via both networks in blocks (see also later on Fig. 29).

[0036] This process thus makes it absolutely clear which signature is being made for which document, payment transaction, etc., as a real-time event. It would be pointless to feed a digital copy into the data loop DS, regardless of its location, because the code KODEn modulated by the signature via the secret algorithm is a random code spontaneously generated by the server. Upon receipt, the server can then reconstruct the PAD data by applying the algorithm in reverse. This data corresponds to the x,y coordinates recorded as a function of time during the signature's execution and the pressure p exerted on the writing instrument. This data is then used for pattern matching to verify the digital signature.

[0037] Of course, the code packet can be further secured using a hash code, based on a digital signature. The digital signature is then located, for example, in the cell phone's chip card and has its own PIN number for unlocking and / or uses a fingerprint sensor for unlocking, etc.

[0038] In particular, this results in advantages when using a digital signature, which can be supplemented with a digitized handwritten signature (scanned via a PAD) for additional security. This is also monitored as a real-time event by the random code sent via the data loop. This achieves the same effect as if the user had signed under the supervision of a notary, except that the notary is implemented using an electronic process. In the code, which is converted into the code via the PAD's data pad: New CODE=f(CODEn*pad), If the document is changed, an additional code, KODE_dig, may be included, which results from the digital signature with a document, thus certifying the handwritten signature, document, and verification code sent by the server. The verification code serves as real-time proof and specifies the data loop DS within which the handwritten signature was made. If the server does not have the document (depending on the application, see later), an additional new code is created without including the KODE_dig, so that the server can recreate the user's handwritten signature, and the new code is saved with the KODE_dig as proof.

[0039] It is evident that the procedure shown here is also very suitable as a supplement to an ID card, etc. THE CODE TRANSMITTED VIA THE DATA LOOP DS as EVENT:

[0040] The invention corresponds to a common denominator for as many applications as possible if the event of the data connection established by the user (to establish the data loop DS), which is determined in time by the code KODE transmitted via the data loop DS, is linked with the data further transmitted via the communication networks relating to the (here serial) data loop DS; as has just been described, for example, for a handwritten signature. In this case, the preferred serial data loop DS is constantly maintained not only during logging in, but also during data transmission, e.g. in a very broadband, fast data network, and the constantly changing code of the security code KODE of the data loop DS generated during data transmission is incorporated into the data. The data loop DS can be formed from the coupling of a low-bandwidth telephone connection and a high-bandwidth Internet data line.Thus, with this procedure, the security against manipulation of a data transmission no longer depends on the protocol used (e.g. Internet Protocol) of the data connection, but is constantly protected by the security code CODE of the data loop.

[0041] Another EVENT APPLICATION is to use the GPS system of a cell phone in such a way that when two cell phones, e.g. a hitchhiker and a driver, form a data loop, the mileage of the vehicle is transmitted as data. In order to implement a ride sharing center, this data is transmitted to the server during the data linkage, along with important information about the data (insurance, etc.) of the willing hitchhiker. The willing ride sharer sends an SMS of their destination to the center (or the corresponding server), which receives the willing ride sharer's location and can thus notify all driver members who are taking the same route as the hitchhiker. The drivers can also enter their destination (optional). When the vehicle is left, the mileage is transmitted back to the servers due to the detected data linkage event.Both the driver and the passenger can call the same server (which also optimizes the passenger's desired routes) using different numbers on their mobile phones. The data transmission of the mileage to the mobile phone (e.g., the driver's mobile phone) is realized via a Bluetooth interface, for example. ANOTHER EXAMPLE TO EXPLAIN AN EVENT LINK:

[0042] If, for example, a mobile phone is used to pay at a petrol pump, the user can only pump fuel once they have briefly formed a data loop with the server (via a suitable coupling point, e.g. to a loudspeaker on an IT connection at the pump) and the server has determined the server's transmitted mobile phone number. If the server calls back to verify the number, it can also be via an SMS, which shows the user a number which they then have to enter using the keypad on their mobile phone during the telephone connection to the server, or if an SMS to audio converter is available, the number can also be sent back automatically via the mobile phone. The same naturally applies to the optional use of a conference call, when an acoustic code from the server is sent directly back to the server via the additional line.

[0043] Once the user has filled up, they repeatedly form the data loop (with the IT connection to the pump), which triggers the payment by debiting their account. A conference call can also be used to connect to another bank server (such as Fig. 12c) are included in the data loop DS. There is the option of adding another code to the data loop by the bank server in addition to the random code (KODE) to indicate to the gas station's billing server, which is integrated into the data loop DS, from which account the amount will be transferred. The billing server's data is then inserted as the beneficiary (payment recipient) using the transmitted code address and verified using the random code (KODE). The user can then request their bill at home via the gas station's website, which also includes their mobile phone number as a reference.

[0044] Fig. 1a and Fig. 1b illustrate the difference between serial ( Fig. 1a) and parallel ( Fig. 1b) Data loop DS, which refers to the loop check by the security code KODE, including optional encryption. DS symbolizes the terminal devices connected by coupling at the client (user) of the otherwise independent data paths 1 and 2. In the serial data loop DS ( Fig. 1a) the code sent from the SERVER to the terminal device (= part of DS) of data path 1 is encrypted in the respective terminal device (depending on the application in the terminal device of data path 1 and / or in the terminal device of data path 2) and sent back to the server in encrypted form.

[0045] Depending on the application, this encryption can serve different purposes: If the incoming code signal CODE (here 1) is encrypted at the terminal device and the outgoing code signal CODE (here 2) is decrypted, then a simple code comparison of the outgoing code CODE from the server with the one received back can be performed, and tampering will still be detected if the outgoing code (2) to the server were sent back from another terminal device (e.g., a different telephone line than 2). In this case, the incoming code 1 is encrypted in such a way that it does not correspond to any other code sent by the server, but remains identifiable for the server (which uses the same encryption algorithm).Thus, the server can determine exactly which participant, for example, is trying to send the security code KODE sent by the server to the coupling of the terminal devices back using another message path via an unauthorized terminal device in order to bypass the direct coupling DS to create the data loop.

[0046] The same applies if only the outgoing code signal KODE (here 2) is encrypted, which is then decrypted again in the server before the code is compared.

[0047] Another application is the previously mentioned encryption of the security code KODE, including additional data and a digital signature.

[0048] An application example for a parallel data loop ( Fig.1b) is, for example, the operation of a lock or barrier, or a safe, which is to be opened, for example, via a mobile phone or even a radio telephone located within the range of a home telephone exchange. The lock is opened using a code that is sent as an SMS from the mobile phone or radio telephone to the relevant server, which then sends an Internet connection to control the lock or barrier. To prevent hackers from operating the lock via the Internet, a security system is provided according to the preferred data loop DS, here implemented as a parallel data loop. The security code is also transmitted from the server to the mobile phone and compared at the lock via the parallel data loop. At the same time, however, a serial data loop is also formed (previously for initialization), e.g., as shown in Fig.2b, to feed the code signal Tel = KODE transmitted from the server to the mobile phone via the coupling DS (here, for example, acoustic) into the microphone of the lock (here CL). After a positive test of this serial loop (according to Fig. 1a), the server generates another random code and, according to the figure, Fig.1b forms a parallel loop, with the previously transmitted code in direction 1b in the opposite direction, now corresponding to direction 1. It is evident that through bidirectional data transmission via data path 1 (e.g., the IT internet connection) of the lock, both the serial and parallel data loops with the corresponding checks (and, in principle, any number of repetitions with differently generated codes) can be formed virtually simultaneously. Eavesdropping on this lock, e.g., a garage door opener, would be ineffective, since the server generates the code as an arbitrary random code.

[0049] Fig. 2a and Fig. 2b illustrate the two possibilities for the formation of the serial data loop by an acoustic coupling, where in Fig.2a the microphone of the telephone or mobile phone T is held to the speaker of a notebook CL, which displays a web page via a browser, whereby the browser generates the acoustic tones of the data encoding. In Fig. 2b, the transmission direction of the code KODE is reversed, where the handset of the telephone or mobile phone T is held to the microphone of the notebook CL. The designation IT refers to the data path of the Internet between client and server, where, for example, a notebook is used as the terminal on the user side (client); the designation Tel refers to a telephone connection (landline or mobile) with a corresponding telephone or mobile phone T as the terminal on the user side (client). TELCOM refers to the data paths to the server, where, in symbolic representation, the left half refers to the Internet connection, and the right half to the telephone network. The server is connected to the telephone network for each exchange line connection via an audio signal card, in Fig. 2a as input, in Fig. 2b as output, or both (bidirectional).

[0050] Depending on the application, only the CODE and some important data (e.g. encryption parameters, etc.) and acoustic security messages (voice announcement, etc.) can be transmitted via the telephone line Tel, or the telephone line Tel can also be used as a kind of auxiliary channel to transmit (possibly bidirectionally) parameters that support the verification / security / encryption of the data transmitted via the Internet connection IT.

[0051] For a bidirectional connection (for the direction in which the server transmits its audio signal via the telephone connection Tel to the client), the handset of the mobile phone or telephone is also held to the notebook's microphone, and the notebook's speaker volume is turned up just enough so that the mobile phone's microphone receives a sufficient sound level. This can be displayed on the user's website (since the server is also connected to the mobile phone), or the server can automatically detect by increasing the volume (or decreasing it again if feedback is detected at the CL). As long as the server searches for or scans the paired assignment of the connections (to determine which telephone connections Tel belong to which internet access IT), the code signal KODE is transmitted (in the acoustic coupling variant) only in one direction to avoid acoustic feedback (whistling) at the client CL.

[0052] In the server, all lines that are currently in use and have not yet been assigned are scanned as follows: for each new line assignment of a telephone connection, a corresponding flag is set, which is then deleted again after the line connection has been assigned.

[0053] With this assignment, two independently operating processes (web pages, mobile phone server connections, etc.) that run on the same server, for example, can be linked using the preferred method via a telephone number—more precisely, via an address of a line connected by the address (= telephone number). This process can also be performed across multiple networked servers.

[0054] The server which sends out the code signal compares the sent code signals (SO1, S02, ....S0n) with the received code signals (SI1, SI2, ....SIn) for all currently sent code signals (these are all those which are not yet fully taken into account in this comparison) in a pairwise comparison using a corresponding program loop construction. Example: currently transmitted code signals: SO1, SO2, SO3, currently received code signals: SI1, SI2, SI3.

[0055] Thus, S0* in the outer loop (advanced) and SI* in the inner loop (advanced) are compared pairwise: SO1 / SI1; SO1 / SI2 ; SO1 / SI3 SO2 / SI1; SO2 / SI2 ; SO2 / SI3 SO3 / SI1; SO3 / SI2 ; SO3 / SI3 and the couples SO1=SI1, SO2=SI2, SO3=SI3 receive. SO1, SO2, SO3 ... are assigned, for example, the telephone numbers 100000, 200000, 300000 (which is verified by the server's callback, or if necessary, decoded via the chip card of a calling mobile phone, or transmitted to the called server via the telephone network, etc.), ie SO1 is sent to (or via) telephone number 100000, SO2 is sent to (or via) telephone number 200000, and SO3 is sent to (or via) telephone number 300000.

[0056] The code signal is received back under the Internet addresses (here only symbolically) I, II, and III, where for example: at Access I the code signal SI2 is found; to Access II the code signal SI3 is found; at Access III the code signal SI1 is found.

[0057] By substitution (via the tables created by the program) we obtain the following assignments of access to the telephone number: Access I with all associated data information, the address or Tel. No. 200000 Access II with all associated data information, the address or Tel. No. 300000 Access III with all associated data information, the address or Tel. No. 100000.

[0058] As always, it is common practice for providers to only assign temporary addresses for accesses I, II, and III. However, since the data processed via the accesses during a session is directly assigned to the telephone numbers used as addresses (or keys) (which form the data loop DS), the assignment is unique for each session, even with constantly changing absolute addresses of the participants connected by the provider.

[0059] A type of FIFO register is implemented before the loop, into which newly added signals (as string vectors to be compared, or pointers to SO*) are written. If the returned signal SI* corresponds to a transmitted signal (to which the pointer points), they are deleted from this register (or controlled by flags). The SO* signals compared in this way, according to the order of their occurrence or generation, are therefore never compared multiple times unnecessarily, preventing unnecessary overload of the comparison loop(s). Moreover, such statistical comparisons are state-of-the-art programming techniques.

[0060] How the comparison itself is carried out when decoding the KODE, which is encoded as a string of frequencies of an audio signal (for acoustic coupling via DS), is described in more detail in an example below.

[0061] Another example is when a user pays for a movie ticket via an online account, creating a data loop (DS) when paying with their mobile phone, and the phone number of the mobile phone is read by the server, or assigned and / or verified via the data loop code. Thus, the paid movie ticket can be retrieved in the server's database under the mobile phone number.

[0062] At the box office (which can also be a ticket machine with a printer) the user will find a support surface 1 ( Fig. 4) with a microphone (MIC) which is networked with the web server via a client computer, whereby the mobile phone 2 with its earpiece HK is to be placed on this support surface.

[0063] The user calls a special number on their mobile phone, which establishes a connection with the web server, or sends an SMS to the web server, which then decodes the caller's telephone number, asks the subscriber to hang up, and then immediately calls back the decoded telephone number. An acoustic signal is then sent back to the server via the acoustic coupling DS using the client computer's microphone. If the server cannot recognize the telephone number of the calling mobile phone, it issues an appropriate error message, e.g., as a voice message requesting the user to deactivate the suppression of the caller ID. One option is to use an SMS converter on the mobile phone, which converts a received SMS into an interface signal for data connection (if this can save telephone charges), e.g.,into the corresponding frequencies of a serial code, or into a serial infrared signal (or Bluetooth interface, etc.). This converter can also include the option of transmitting the phone number via the cell phone's acoustic coupling.

[0064] The server callback ensures that the user cannot tamper with the payment method they have paid for during the subsequent transaction (e.g. receiving multiple cinema tickets even though they only paid for one, etc.). The same procedure can be followed if the user previously paid for the cinema ticket via their online account using the data loop DS created with the mobile phone. In this case, several mobile phones or even a landline phone can each be assigned to the same user, who then uses one of these mobile phones to collect the ticket from the box office. The coding of the mobile phones or telephones belonging to a particular user can generally be carried out in such a way that different mobile phones or telephones can be used one after the other in the same session.Telephones which close the data loop DS, and whose telephone number is then assigned in the database to the user for whom a number (of a telephone used in the data loop DS) is already stored.

[0065] As an alternative to entering the callback number via SMS, the mobile phone can be further modified so that at the touch of a button, or by encoding an initialization code received via the data link, the mobile phone's telephone number is first sent via the link, which is otherwise used to form the data loop DS (via the client computer's microphone), to the server (via the IT connection). The server then dials the mobile phone after recognizing the telephone number so that the user can receive the acoustically transmitted signal from the server and form the actual data loop via the link. If necessary, the process is aborted by the server after a certain time has elapsed if the server does not receive the code KODE after a certain time. If a mobile phone has an MP3 player, it can also send a melody as encoding of the telephone number (which the server then has to dial) via the (e.g. acoustic) link of the data loop DS.

[0066] Using the data loop DS, the server compares the signal sent back to the client computer via the (e.g., acoustic) connection between the mobile phone and the client computer with the signal sent to the mobile phone in order to determine the connection to the mobile phone. As always, the acoustic connection could also be reversed, e.g., from an earpiece on the support surface to the mobile phone's microphone. • If you use the option of sending the phone number of the mobile phone to the server in advance via the IT connection, then the scanner process is unnecessary, since the server then no longer has to search for the connection for the IT connection.

[0067] In the following, a detailed example of the coding of the test and / or detection CODE for an acoustic coupling transmitted via the data loop DS will be explained.

[0068] Example of the creation and recognition of a code signal encoded as an audio signal: In this example, the serial encoding of the KODE signal is carried out in such a way that it is not noticeable as a coded signal at all, by using any melody, or even a voice announcement, etc. as the recognition signal, and this can also constantly change from use to use, so that with each login process a different KODE can be used to recognize the data loop DS, or to recognize the location of the terminal device pair identified by the formation of the data loop (e.g. telephone or mobile phone T to Internet Client CL or mobile phone to mobile phone).

[0069] The KODE code is prepared by analyzing a short section of any melody from the server using FFT (Fast Fourier Analysis) software to obtain the frequency spectrum corresponding to this section as a function of time as a recognition pattern. Not all frequencies need to be used for later recognition, but only the frequencies within the transmission bandwidth of the telephone channel used for the DS data loop, which are saved as the recognition pattern of the KODE signal. Or, for example, only those frequencies are used for which there is a clear assignment to notes of a scale, i.e. which are not directly on the boundary to another recognition note, etc. This boundary can be dimensioned as desired depending on the application (recognition of the frequency-time pattern of a melody or a computer voice announcement).

[0070] For each stored frequency value (as a result of the FFT), the time value of the period of time that elapses until the next frequency value used in the recognition pattern occurs is also stored.

[0071] Conversely, when testing an incoming audio signal according to the recognition pattern, the audio signal is first analyzed again with an FFT, whereby in the character-by-character test (see following explanation) the time intervals between the characters are also checked and evaluated within a tolerance window.

[0072] The symbols then correspond to frequencies that must correspond to a specific amplitude value (relative to the maximum value). For both the time intervals and the amplitude values, corresponding tolerance windows are then provided within which the tests are carried out.

[0073] Example: if the beginning of the melody Silent Night, Holy Night played in D major is output by the server as a code and analyzed by the FFT upon receipt, then we receive the following decoded frequencies as musical notes (of the relevant octave): a, b, a, fis; a, b, a, fis; e, e, c-sharp, d, d, a, where the time values ​​t* between the decoded frequencies (or tones in this case) are stored along with the recognition pattern. The frequencies detected via the FFT within a certain tolerance grid then result in the specified notes. a(t1) , h(t2) ​​, a(t3), fis(t4); a(t1), h(t2), a(t3), fis(t4); e(t5), e(t6), cis(t7), d(t5), d(t6), a(t7);

[0074] Thus, the section of music playback is saved for output by the server and the corresponding recognition file, e.g. according to the example above, is also saved (in order to compare the CODE received back via the data loop DS).

[0075] When the user closes the DS data loop on the client side (by holding the telephone / mobile phone to the computer's speaker or microphone), the server receives the output audio signal back via the connection established at the computer / telephone interface. If the CODE is to be encrypted via the client-side end devices before being sent back to the server, this can be done, for example, by transposing individual notes or the entire piece of music.

[0076] The music playback may contain a multitude of additional tones or frequencies that are not included in the recognition pattern: e.g. intermediate tones (in a violin, etc.) or, above all, additional noises that are picked up via the open acoustic coupling at the computer (client) / telephone interface and that are particularly prominent in quiet passages or pauses.

[0077] This circumstance is particularly taken into account in the particularly preferred development of the recognition method, whereby the method differs from a conventional character recognition, e.g. the recognition of a $string, as follows: For example, if the character string is to be recognized from an arbitrary input string (e.g. $String = "g, a, h, a, g, a, h, a, f") according to the given pattern "a, h, a, f", then according to the usual procedure for each incoming character ZE of the input string, the given pattern ZM is compared character by character as the comparison result VGL as follows: 1) ZE ="g" ≠ "a" = ZM results in VGL = no, ie reset of the pattern string ZM to the first character "a" for the next comparison, 2) ZE ="a" = "a" = ZM results in VGL = yes, ie switching from ZM to the next character; 3) ZE ="h" = "h" = ZM results in VGL = yes, ie switching from ZM to the next character; 4) ZE ="a" = "a" = ZM results in VGL = yes, ie switching from ZM to the next character; 5) ZE = “g” ≠ “f” = ZM results in VGL = no, ie reset of the pattern string ZM to the first character “a” for the next comparison, 6) ZE ="a" = " a“ = ZM results in VGL = yes, ie switching from ZM to the next character; 7) ZE = "h" = " h “ = ZM results in VGL = yes, ie switching from ZM to the next character; 8) ZE ="a" = " a “ = ZM results in VGL = yes, ie switching from ZM to the next character; 9) ZE = “f” = “ f “ = ZM results in VGL = yes, where ZM is recognized as the last character of the pattern string, ie the string was successfully recognized.

[0078] Thus, with steps 6).....9) the character string a, h, a, f, contained in the input string is recognized.

[0079] In conventional procedures, the pattern string is checked character by character for each incoming character of the input string, as shown. This means that the pattern string is advanced if the character is recognized, or reset to the first character of the pattern string if the character is not recognized, and the check is restarted. Similarly, if the pattern string has been advanced or checked to the last character, the recognition of the character string to be checked is output. This string may occur within any section of the input string.

[0080] If this method were applied to testing the audio signal (incoming to the server) and analyzed with an FFT (or a filter), the problem would arise that, despite the correct sequence of tones corresponding to the recognition pattern, the pattern string would not advance to the last comparison character, but would be reset beforehand. This is because, between the correct sequence of tones, the FFT delivers additional frequencies or tones (such as the transition of notes played by a violin or a vocal piece, or ambient noise at pianissimo points or pauses, etc.) that are included in the input string S$string but do not appear at all in the pattern string. To avoid this, before each execution of the comparison procedure specified above, in this case through comparison steps 1...9, in which, according to the usual procedure, the character-by-character comparison of the currently incoming character ZE (of the input string S$tring) with the character of the pattern string ZM, which is currently incremented or reset to the first character depending on the previous comparison result, is performed. The prior check determines whether the currently incoming character ZE of the input string $String is even a valid character. This is the case if it is contained in the set of characters of the pattern string as a single character ZM.

[0081] In the program, this is implemented by checking, within a loop, for each new character ZE of the input string ($String), all characters contained in the pattern string to see if any of these characters match the new character ZE of the input string ($String). If this is not the case, the program proceeds as if no new character ZE of the input string $String had been received at all. If, however, a character is identified as being present in the pattern string, the test procedure is performed according to the comparison steps specified above.

[0082] In this way, the server can detect whether the returned audio signal corresponds to the one sent out, whereby the location of the pair of terminal devices used to form the coupling or data loop DS (e.g. coupling between IT computer and telephone connection, or from mobile phone to mobile phone) is indicated to the server.

[0083] The time intervals between the incoming characters ZE of the input string ($String) recognized as valid are checked simultaneously with the check to determine whether ZE = ZM. For ZM, the time value (of the previous character in the pattern string) is also checked. Therefore, ZE (t*) = ZM (t*) is checked. t*... is evaluated within a corresponding tolerance grid to obtain reliable results (i.e., whether t* lies between tmin and tmax).

[0084] If the test according to the measured time value t* produces an incorrect result, then even if ZE=ZM agrees, this result is evaluated as incorrect, ie as ZE≠ZM.

[0085] It is evident that instead of a melody, the frequency spectrum of any voice announcement can be used for encoding / decoding the check code (KODE), or any audio signal can be used. It is advantageous to generate the code signal if an audio signal source (MP3), etc., whose playback speed can be controlled by a control signal, and which can change the playback speed while maintaining a constant pitch (frequency position). Encoding occurs at frequencies selected from the spectrum of the audio signal with a time duration t*, after which the next selected frequency ZM (t*) occurs, or switching algebraic combinations (e.g., or functions) of several frequencies of a spectrum (as a frequency pattern) can be defined to form the value ZM (t*). The control signal of the audio signal source (MP3) then varies the tempo so that, for example,about the speaking duration of vowels, the time period t* lying between a pair of values ​​ZM with subsequent ZM is set to its target duration, which then forms a series element of the serially coded check code KODE in coincidence with the value ZM (a frequency or a frequency pattern).

[0086] In addition to the following Fig. 6a and Fig.In addition to the time measurement explained in section 6b to detect an attempt by a local terminal device to circumvent the formation of the data loop DS, this can also be prevented by further encrypting the code KODE transmitted via the data loop DS at the terminal devices in order to detect any unlawful interposition of a connection inserted into the data link DS. Another alternative is to detect such a case by bandwidth measurement. This option is based on the further inventive idea of ​​continuously varying the frequency spectrum of the audio signal used to encode the code signal KODE according to a time function and evaluating the returned spectrum accordingly.Since the usual automatic level correction (gain control) in telephone or data networks is controlled by the average signal level, the frequency-dependent attenuation of the transmission line can be measured. This is particularly true through a bandwidth measurement performed between the terminal devices used to connect the DS data loop, which can be performed in addition to, or in addition to, encryption between the terminal devices.

[0087] Option: In order to determine in the server, for example, whether only approved terminal devices are used to form the data loop DS, it is intended in this case that the server adds a harmonic component transmitted via the network to the audio signal (see signal via telephone line and mobile phone network Tel in Fig.10), whereby the authorized terminal device (here the mobile phone) then filters the harmonic component from a certain frequency (via a low-pass function TP), whereby the low-pass TP is not constantly keyed, but according to a serial data signal (coded) (via mod, Fig.10) is achieved, here by switching either the output of the low-pass filter or the direct (unfiltered) line accordingly, to output the audio signal via the telephone or cell phone handset (from TL) and send it to the microphone of the client CL (from A to B) via the acoustic coupling. In addition to a start-stop method, a modulo 2 method can be used, for example, to modulate the data via the harmonic component in the signal. The client CL sends the harmonic-modulated signal (IT) back via the Internet IT or, if another cell phone is used as a client, via the additional cell phone connection, etc. The server then demodulates the serial signal by decoding the missing harmonic components (compared to the originally sent signal Tel), and from this determines the authenticity of the device used in the data loop (here A).Furthermore, the server can also determine whether a data line is connected between the telephone or mobile phone (A) and the microphone of the client CL (here B) by measuring the attenuation.

[0088] For the given example of frequency coding, this measurement is most easily performed by the server also performing further manipulation of the harmonics during transmission; at specific points that do not influence the previously explained data signal, or at points that are not weighted during decoding of the data signal. This manipulation of the harmonics is also performed in the server by a low-pass filter controlled according to a time function at the limiting frequency.

[0089] When the audio signal used for bandwidth measurement is received back, the server analyzes the audio signal using an FFT filter. This way, different harmonic components are obtained over the signal's time course. The returned audio signal is evaluated to determine how the broader-bandwidth portion of the audio signal is attenuated relative to the narrower-bandwidth portion of the audio signal over the line, in order to obtain information about the line's bandwidth.

[0090] The described decoding of a recognition pattern within any audio signal section can also be performed in such a way that, for each currently received character ZE (as the frequency detected via the FFT) of the input string, several different pattern strings (with respective switching of ZM1, ZM2,...ZMn) can be checked sequentially and alternately. Some pattern strings encode the section (beginning / end) as a control character, in which the part of the audio signal for the bandwidth test is located, or ditto, in which the part of the audio signal corresponding to the code to be recognized is located.

[0091] The described method is suitable for any type of analog interface, including acoustic coupling, infrared coupling, etc.

[0092] For an exclusively digital evaluation of the signal transmitted via the data loop, a preferred variant is to transmit the code (KODE) via the data loop DS from one terminal (A) to the other terminal (B), immediately ( Fig. 2a, Fig. 2b, Fig. 5) or via a third-party device (see 300 in Fig. 3), encrypted in a terminal device (A) authorized for transmission and further encrypted in the other terminal device (B) in such a way that the server can perform further decryption upon receipt of the code (KODE). The server applies the encryption parameters across both data directions (corresponding to a parallel loop Fig. 1b), which can be passed to the end devices. However, in this variant, the statement as to whether the data loop DS has been manipulated is tied to the end device returning the code (KODE).

[0093] Fig.Figure 3 will be explained in more detail later and shows the basic possibility of networking multiple servers (here Server I and Server II, but in principle any number of them) via which the preferred data loop DS can be closed. Each server can send its own code KODE(1), KODE(2) via the loop DS, which can be manipulated with different priorities in the servers, as well as at the coupling point DS by encryption / decryption as required. For example, as explained in more detail below, to store certified applications, such as notarial deposits as proof of sent emails, or any other sent digital contracts with a digital signature, etc.This is especially true as proof of the time, sender and recipient, since this data, in addition to the content, which can be clearly assigned to the signatory through the digital signature, must also be stored electronically, if necessary notarised.

[0094] In Fig. Figure 3 also shows the option of implementing the coupling loop DS, in this case between the mobile phone and the client CL (e.g., a standard internet connection), via a Bluetooth (HF) interface. A watch (300) with a corresponding Bluetooth (HF) interface is connected in between to loop through the data in a bidirectional direction if necessary. The looped data is then further encrypted or decrypted in the watch as needed.

[0095] Fig.4 refers to a support plate connected to an Internet connection or to an IT computer, with a microphone MIC, possibly also with an infrared interface IF, for placing a mobile phone 2 with the earpiece HK against the microphone MIC, or possibly matching the infrared interface b of the mobile phone. The MONO component refers to a possibility for automatic switching from acoustic coupling to infrared, as will be explained in more detail later (cf. Fig. 12a).

[0096] In Fig.5, the data loop DS is closed via two cell phones (each with a microphone (MIC) directed toward the earpiece (HK)) via an acoustic coupling. The additional option of incorporating a third device (MIC ext., LS) into the acoustic coupling is provided. This third device can be a notebook or a very small, standalone device with a fingerprint sensor for embedding a digital signature into the transmitted code (KODE). It is obvious that a fourth external device could also be used, one for each cell phone user (held in the right and left hands).The individual connection routes in which several devices or pairs of devices are involved at the coupling point DS are then separated by time division multiplexing / half duplexing (also according to a mandatory sequence in which the order of the blocks sent by different devices is fixed or agreed upon beforehand by protocol), or by filtering means (if full tuplexing) with regard to their message contents.

[0097] The following example concerns the use of multiple servers: see Fig. 3, Fig. 13a, Fig. 13b, also Fig.33 and will be discussed in more detail later in the description. In addition to the certification applications already mentioned, this also includes the possibility of initializing a server by telephone call, which, if necessary, also via another auxiliary server, calls up registered web pages under the telephone number and copies them to a host website that is not assigned any specific content but is used only as a general data channel (e.g., of a provider). The authorized user can determine the authenticity of the page via the preferred data loop DS, but the provider can remain anonymous. This authenticity check can also be further tested by retrieving further information from other anonymous web pages using the preferred data loop DS.

[0098] Another example, which will be explained in more detail below, concerns a notary seal with a chip, which is printed on a roll ( Fig.15, Fig. 16, Fig. 17, Fig. 18) and is further integrated into the process for the use of a preferred application of the data loop DS. A suitable interface device is also provided for this purpose (see later on Fig. 17), which is designed as a stamp and can be placed on the chip seal in order to make the digital signature of a document, which is also available as a written document (e.g. at a notary), verifiable for a layperson, ie for the first time there is an indissoluble connection between a document signed with a digital signature and a document available as a hard copy, which corresponds to the digital document, whereby this indissoluble connection is created by a stamp movement (of the device according to Fig. 17) is verifiable.

[0099] The following example concerns a variant in which a conference call is used to create the data loop DS and will also be discussed in more detail later in the description. This application concerns the possibility of establishing the data loop DS with the same mobile phone or telephone simultaneously using additional connections, e.g. in order to bill a telephone call made to a specific area code not via the subscriber's contract partner (TELECOM, etc.) but directly to the subscriber. Instead of entering the code number normally used (to prove payment), the data loop is closed via the server of the relevant telephone company in order to use a credit balance to which payment was previously made from an ONLINE bank account using the data loop DS or a mobile phone.This means that all transactions are marked by the mobile phone number or, if necessary, by an additional digital signature, which can also be made with an additional device, and can thus be assigned to different databases (via different server processes).

[0100] Another example shows Fig.12b: Using a mobile phone with a conference call function that allows two connections (Tel1, Tel2) to be dialed simultaneously (the dialing of which can also be initiated simultaneously via the phone book, if necessary, by pressing a key), the user sends an SMS via a standard mobile phone connection or dials the bank's server directly (Tel1). The server then decodes the phone's phone number via the SIM card in the mobile phone and establishes a connection. If the procedure is not continued, the connection is terminated after a measured timeout with a server abort. This timeout is a retriggerable function that is extended (retriggered) whenever the procedure proceeds a step further.The second connection of the conference call concerns the connection between the mobile phone and the client computer (client IT), which may be located, for example, at the user's home or office, and is constantly accessible by the user via the mobile phone connection (via a suitable interface). The interface of the client computer (client IT) also implements the downtime monitoring for this connection and is designed to have call number decoding to recognize and decode the call from the user's mobile phone. It is evident that the client interface of the client computer (client IT), with its minimal functions, can be integrated into a landline telephone and have a corresponding cable or Bluetooth connection to the client computer (client IT).

[0101] If a call (ARU) is detected by the interface via the user's mobile phone, an initialization signal is sent to the switched-on computer (client IT), or if the computer is not switched on, a wake-up signal from standby to operation, or a power-on signal to boot the computer and then call up the relevant software. When this software is called up, the computer establishes an internet connection (IT) to the bank's server, which decodes the provided user identification (user ID) and then sends the randomly generated verification code (CODE) to the client computer (client IT), which in turn sends it to mobile phone A via the telephone connection to the mobile phone. Mobile phone A then sends the verification code (CODE) via the conference call to the bank server, which can then verify the authenticity of the client computer and mobile phone user independently of the user ID of the client computer (client IT).The manipulations of the verification code (CODE) proposed in the present invention can optionally be performed by the devices located in the serial data loop DS (client computer, mobile phone). In particular, the CODE initialized by the server can also be passed through the data loop multiple times and manipulated accordingly during each pass, e.g., by adding a digital signature to the mobile phone, which marks the CODE initialized by the server.The variant described could, in principle, also be implemented without a conference call. By dialing the individual telephone connections Tel1 and Tel2 from the mobile phone not simultaneously, but sequentially, with the respective codes buffered. However, in this case, the direct security dependency of the client-computer server connection to the bank's server (via IT) initiated via a remote control function on the mobile phone cannot be achieved, as is the case with a direct conference call with its many possibilities. Once the server has recognized the authenticity of the mobile phone user, the mobile phone telephone number, and the client computer client-IT, the client computer begins to transfer the amount of money specified by the mobile phone (as a symbol or sent SMS, etc.) via this connection from one online account to another account, from which, for example, a service is paid.Because the mobile phone user also has a direct connection to his computer, he can, for example, send the amount of money or any other data (bank details, beneficiary, purpose of payment, etc.) initially via SMS (during initialization ARU, . Fig. 12b) to the client computer (client IT) so that the client can then use its software to insert the relevant data into the bank's standard form.

[0102] The circulating code loop DS allows the authenticity of each device in the loop to be verified by the device in question changing the code and verifying the change upon receipt. It is clear that a landline phone can also be used instead of a cell phone. The user then enters, for example, a long PIN code and a predefined transfer code via the keypad to make an online transfer via their home PC. Thus, via the data loop DS, the home PC functions similarly to a PC controlled via remote control (= telephone).

[0103] Example: In Fig. 12b are the device interfaces of the devices Handy, SERVER BANK, Client-IT located in the serial data loop DS, designated A, B, and C: Step 1: The code (CODE) sent by the SERVER BANK (interface B) via C and A and received back from A to B is compared in the SERVER BANK (interface B) to verify the authenticity of B and C; Step 2: The code (KODE) circulating in the serial data loop DS is manipulated in client C and, upon receipt, the previously performed manipulation is checked in client C in order to verify the authenticity of A and B; Step 3: The code (KODE) circulating in the serial data loop DS is manipulated in mobile phone A and, upon receipt, the previously performed manipulation in mobile phone A is checked in order to verify the authenticity of C and B.

[0104] This allows all participants within the serial data loop DS to verify the authenticity of the other participants. It is also possible to perform steps 1...3 simultaneously, whereby each of the three devices A, B, and C generates its own autonomous code CODE_A, CODE_B, and CODE_C according to a controlled protocol. This code can optionally be manipulated by the other devices after an agreement has been reached (option). A corresponding protocol places these code elements CODE_A, CODE_B, and CODE_C in corresponding time slots or block positions.

[0105] In Fig.In Figure 12b, the "Option" line is drawn at server interface B to symbolically indicate that the generation, verification, and assignment of the codes sent and received by the server (KODE) can be performed using additional hardware and software without modifying the existing server software. The actual software for an online account is then simply extended by queries provided by the add-on package (to prevent the transaction in case of attempted fraud, etc.).

[0106] Fig. 12c concerns the implementation of a telephone exchange where a connection server can be called from a mobile phone to establish a direct dial connection, which may also involve forwarding to another exchange line (Tel1, Tel2). It is shown in dashed lines that the use of the Fig.12b explained conference call offers advantages, firstly, to top up the account to pay for such a service, and furthermore, to be able to transmit the connection data immediately via IT to the home IT computer (client IT) from the connection server, etc.

[0107] Another example of Fig. 12c (Bank server option): If a bank server (parallel to the connection Tel1 of the connection server) is selected in the conference call for the mobile phone connection Tel2 instead of the client computer (of the user), then the procedure is such that the bank server, based on the connection number (or extension number) dialed to it, establishes an Internet connection IT to the connection server corresponding to the connection number (or extension number), if such a connection does not already exist.

[0108] The code (KODE), which is still generated by the bank server and passed through the data loop DS (connection server / client IT / mobile phone), is first manipulated in the connection server according to a specific algorithm. This manipulation is verified in the bank server (according to a protocol agreement that can be made via the internet connection IT). Only if this verification is positive is the code further manipulated in the bank server, which is recognized in the next iteration of the loop DS in the connection server in order to actually dial the connection (Tel1...Teln) dialed via a mobile phone extension number (via the network connection Tel1). This does not occur if the verification of the code (KODE) in the bank server (in the previous first step) or in the connection server (in the current second step) is negative.

[0109] Depending on the charge rate received for this connection, this information is incorporated into the further code that is sent from the connection server to the bank server (via IT), whereby the bank server immediately debits the currently accruing charges from the user's account or checks for funds. The bank server can use the IT internet connection to immediately terminate the connection established by the connection server (Tel1...Teln) if the call no longer has funds. The user can also keep a telephone charge account as a second account in order to limit the accruing charges. The user can then query the cost of the call via their ONLINE connection to the bank server or via an SMS. Once the connection has been established (Tel1) between the mobile phone and the connection server, no tax data needs to be transmitted over the call line during the call.This process for real-time debiting of call charges from any online account (server), controlled by an independent connection server, can therefore be integrated into any mobile phone connection as a third-party provider for connection setup (Tel1 via connection server) and as a fourth-party provider for collection (bank server). The telephone call (Tel1, Tel2) from the user's mobile phone is used to initiate the Internet connection IT between the two servers using a corresponding protocol between the connection server (SERVER) and the bank server. All necessary protocol and security check data, such as for manipulating the check code KODE circulating via the data loop, are transmitted via this connection in order to agree on consistent manipulation and verification rules between the bank server and the connection server. The charge cycle is also transmitted in the same way.The assignment of the data can then be carried out independently of fixed addresses exclusively under the telephone number assigned via the data loop DS and the check code KODE, and provided via the call to the mobile phone, or if necessary further checked by calling back to the mobile phone.

[0110] After this short preview, the following pages of the description will describe the examples mentioned under the further designation Example 1.0 to Example 10 using the Fig. 11 to 38 are described in more detail.

[0111] In the further appendix at the end of the description of the further examples, a list of features is given which summarizes the invention in 251 features (feature 1 to feature 251) in order to further underline the special performance of the invention.

[0112] Further detailed examples: (partly summarized from previous explanation): Example 1.0:

[0113] Fig. 11a and Fig. Figure 11b illustrates the principle for establishing the acoustic coupling loop between the IT-networked computer (client CL) and the telephone T. The arrows of the transmission paths indicate the transmission direction of the audio signal. In both variants, the server dials the telephone number of the client (telephone or mobile phone T) upon request (pressing a button) from a corresponding web page. However, this can also involve entering a password or a transfer number that changes from session to session. Only after successful entry does the server then dial the user's telephone number.

[0114] In Fig. 11a, the microphone of the telephone T is held to the loudspeaker of the IT networked computer CL, in Fig. 1b the handset of the telephone is held to the microphone of the computer CL.

[0115] TELCOM is the telecom network complex through which the computer CL obtains its Internet connection IT to the server of a provider, and the user's corresponding telephone connection is dialed through the server.

[0116] In some of the examples explained above, in addition to other security applications, it is important to identify an IT computer (or client computer, etc.) connected to the Internet via a provider, which is usually only assigned a temporary address, as belonging to an end device in another network (e.g. a telephone, mobile phone, etc.) by a server that, for example, displays a web page on this computer via its browser. For this purpose, the end device in the other network, e.g. the mobile phone of a telephone connection, is called by the server in question, whereby the server, for example, transmits an acoustic code signal (melody, etc.) via the loudspeaker output of the device used to display the web page (client computer).) that it receives back via the called telephone connection (acoustically coupled) and checks whether it is actually the code signal sent by it to the relevant web page. Only if the result is positive does it consider the assignment of the relevant web page to the telephone number used for the call as a passed security check. The process can also be applied in reverse, with the server sending the acoustic code signal to the earpiece of the mobile phone via a telephone connection, whereby the code signal is acoustically coupled via the microphone of the client computer and sent back to the server. Furthermore, the telephone can also independently enter the telephone number into the microphone of the client computer with acoustic coupling. Example(s) 2.0:

[0117] In this example, without any additional technical equipment, i.e. without a special service that uses these additional equipment, a mobile phone that can be topped up with monetary value in advance or immediately before payment is made is to be made, with which the payment can be made into an account via an online account at essentially any location (if necessary also at the location of the payee) and this payment can be proven at the payee's location directly by the mobile phone using the payee's telephone connection or telephone number.

[0118] By creating a preferred data loop via the mobile phone as a temporary connection via a server or a terminal connected to this server, the previous transfer (payment) is recognized by a code signal transmitted via the data loop or is booked upon receipt of the payment (goods, services) (via a cash register connected to the server or a vending machine, etc.). Of course, it makes no difference whether the previous payment was made via an online transfer or a cash deposit (e.g., at a bank counter, cash register, etc.) using the preferred data loop to identify the mobile phone's telephone number.

[0119] This technical problem and the associated solution can be applied to several variants, some of which are described below under the designations A, B and C. Application A:

[0120] In this application, we have a station for topping up a sum of money, e.g., via access to an online bank account (or even a cash deposit), where this top-up can be assigned to a single bill to be paid directly by the beneficiary or to any number of future services to be provided by different account holders. And we have a station for payment, where the mobile phone serves as the transmitter of the security code, which is defined during the top-up process and assigned to the relevant mobile phone number. This code is then transmitted by the mobile phone user as a means of payment via the payee's still-connected device.This procedure is comparable to a code created during the deposit using the web page concerning the payment, which must be delivered by the user to the payment recipient so that the latter can allocate the amount of money already allocated to him during the deposit to the depositor.

[0121] For this application A, the association between the web page accessed by a user and the mobile phone number, as recognized by the process, is used to allow the user to identify themselves as the depositor to the payment recipient. Or, in technical terms, the mobile phone's chip card with the associated phone number is used as an address to assign an amount deposited into a specific account of the payment recipient to the payment recipient.

[0122] The advantage of the system is that no service is required that requires a deposit account from the mobile phone operator, and that the server that processes the payment made by the mobile phone via its software is completely independent of the operator (or the communication provider) of the mobile phone network used for the payment.

[0123] The independent server that manages the payment transaction is assigned to the website in question and is therefore referred to below as the web server. This web server can be the server on which the website in question runs, or it can be a separate service that provides this service for a variety of different providers, e.g., as a server for a provider, etc.

[0124] Example: On the web page of the web server, for example, cinema tickets are offered which the user not only wants to order but also wants to pay for immediately so that he can pick them up at the box office immediately before the performance (or even shortly after it starts).

[0125] To do this, the user proceeds in the following sequence: An assignment is made to a mobile phone number for the web page accessed. This can occur in two ways: the user calls the server or the server calls the user. In the first variant, the user enters their telephone number into the web page (e.g. via a copy of the clipboard), whereupon the web server calls the user so that the acoustic signal emitted via the web page and the loudspeaker output can be sent back to the server via the mobile phone's microphone. The server then assigns the telephone number in question to an expected incoming payment for this web page access. However, if the web page is left again without the expected incoming payment being detected, the assignment to this telephone number is deleted.

[0126] In order to make a payment for a variable selected by the user on the website (e.g. relating to a specific cinema ticket, etc.), the user, in addition to accessing the website offering cinema tickets, accesses his or her online account via his or her bank's server, copies the beneficiary's bank details along with the payment purpose also indicated on the website (which, in this example, refers to the cinema ticket for the screening in question) and then copies the amount using drag & drop (via the clipboard copy), or, where appropriate, this copy (inserting the data into the bank transfer form) can also be made using a standardised format of additional software supplied to the user by the bank or via a service provided by the bank's server, etc., which can also be done by clicking a single button on the website in question.The user then submits the online transfer form to the bank's server. The bank's server recognizes the beneficiary (payee) and the associated web server (directly or via a database, etc.) and immediately reports the receipt of the payment to the web server, stating the beneficiary, the purpose of the payment, and the amount.

[0127] This incoming message, sent from the bank's server to the web server, is then assigned to the previously verified website phone number based on the specified beneficiary and the payment purpose. This effectively tops up the phone for this transaction. It's obvious that the user can do this for any number of transactions, specifying the payment purpose. For example, they might have ordered another pizza, or they intend to go to the dry cleaners, or visit various shops, etc.

[0128] One variant also provides for the special case (as an option) where the bank's software, or the server used by the customer to transfer money from their online account, also uses the preferred method to link the phone number of the mobile phone being topped up with cash, and this phone number is entered into the database as the payment purpose. If the web server queries the bank server regarding the payment, it can allocate the deposit to the account assigned to the web server even without the user explicitly specifying the payment purpose. This means that through the preferential use of the data loop using a code signal, two web pages displayed on the user's client computer by completely independently operating servers are linked to one another via the telephone connection or telephone number used to set up the data loop to the respective web pages, so that from a form on one web page to the form and its data content on the other web page can be accessed mutually by the respective servers. It makes no difference whether the web pages linked together by the telephone number of the telephone connection used for assignment (or formation of the data loop) are displayed simultaneously on a respective client computer, or are displayed independently of one another at any time via any internet access point or computer. It also makes no difference which end devices, networks, formats, etc. are involved. This means that instead of web pages, any other formats from cell phones, etc., can be linked together for general application purposes using the telephone number of a connection used. Instead of a telephone connection, another radio network with appropriate addressing equipment can be used to establish a subscriber connection for networking, etc. It is evident that instead of two independently operating servers, two independently operating processes (web pages, etc.) running on the same server can be linked together by the preferred method via a telephone number, ie more precisely via an address of a line switched by the address.

[0129] The server which sends out the code signal compares the sent code signals (SO1, SO2, ....SOn) with the received code signals (SI1, SI2, ....SIn) for all currently sent code signals (these are all those which are not yet fully taken into account in this comparison) in a pairwise comparison using a corresponding program loop construction. Example: currently transmitted code signals: SO1, S02, SO03, currently received code signals: SI1, SI2, SI3.

[0130] Thus, S0* in the outer loop (advanced) and SI* in the inner loop (advanced) are compared pairwise: SO1 / SI1; SO1 / SI2 ; SO1 / SI3 SO2 / SI1; SO2 / SI2 ; SO2 / SI3 SO3 / SI1; SO3 / SI2 ; SO3 / SI3 and the couples SO1=SI1, SO2=SI2, SO3=SI3 receive.

[0131] For example, SO1, SO2, SO3 ... are assigned the telephone numbers 100000, 200000, 300000 (which is verified by the callback of the server to which the code signal is verified), ie SO1 is sent to 100000, SO2 is sent to 200000, and SO3 is sent to 300000. The code signal is received back under the Internet addresses (here only symbolically) I, II, and III, where for example: at Access I the code signal SI2 is found; to Access II the code signal SI3 is found; at Access III the code signal SI1 is found.

[0132] Through substitution (via the tables created by the program) we obtain the following assignments of access / telephone number: Access I with all associated data information, the address 200000 Access II with all associated data information, the address 300000 Access III with all associated data information, the address 100000.

[0133] As always, it is common practice for providers to only assign temporary addresses for accesses I, II, and III. However, since the data processed via the accesses is directly assigned to the respective telephone numbers used as addresses (or keys) during a session, the assignment is unique for each session, even if the absolute addresses of the participants connected by the provider constantly change.

[0134] A type of FIFO register is implemented before the loop, into which newly added signals (as string vectors to be compared, or pointers to S0*) are written. If the returned signal SI* corresponds to a transmitted signal (to which the pointer points), they are deleted from this register (or controlled by flags). The S0* signals compared in this way, according to the order of their occurrence or generation, are therefore never compared multiple times unnecessarily, preventing unnecessary overload of the comparison loop(s). Moreover, such statistical comparisons are state-of-the-art programming techniques.

[0135] How the comparison itself, e.g. of the code signal used as a string of frequencies of an audio signal for acoustic coupling, is carried out has already been explained in detail.

[0136] At the box office, the user will find a support area ( Fig. 12a) with a microphone which is networked with the web server via a client computer, whereby the mobile phone with its earpiece is to be placed on this support surface.

[0137] The user first calls a special number from their cell phone, which establishes a connection with the web server. The web server then decodes the caller's phone number, asks the subscriber to hang up, and immediately calls back the decoded phone number. An acoustic signal is then sent back to the server via the acoustic coupling using the client computer's microphone. If the server cannot recognize the phone number of the calling cell phone, it issues an appropriate error message, e.g., a voice message requesting that the caller deactivate the caller ID suppression.

[0138] The server callback ensures that the user cannot tamper with the payment method he has paid for in the subsequent transaction (e.g., receiving several cinema tickets even though he has only paid for one, etc.).

[0139] As a variant, the reverse approach can also be used, in which the mobile phone sends its own number as an acoustically coded signal at the touch of a button, which the server receives via the microphone of the client computer and, after recognizing the number, dials the mobile phone so that the user can receive the acoustically transmitted signal from the server.

[0140] In both cases, the server compares the signal sent back to the client computer via the phone's acoustic coupling with the signal sent to the phone itself to determine its association with the phone. As always, the acoustic coupling could also occur in reverse, e.g., from an earpiece on the surface of the device to the phone's microphone.

[0141] The acoustic coupling of the mobile phone to the client computer is achieved, for example, by the support surface Fig. 12a.

[0142] If the telephone number, already decoded by the web server when the user calls, is confirmed by the transmitted code signal when the server calls back, a corresponding confirmation signal is sent to the client computer via the web page that sends the code signal to the server. For example, this signal is displayed to the cash register staff on a screen, or possibly also sent to a machine as a command to print a ticket issued via a tear-off strip (e.g., based on the principle of a receipt printer) or directly open a turnstile, etc. Or even to open a locker to retrieve a DVD from an automated video store, etc.

[0143] The allocation to the payment purpose is therefore done via the mobile phone number. This procedure is used twice: once to allocate the mobile phone number when transferring the money to the beneficiary (web server) with the assigned payer and the payment purpose, and a second time to find the payer and the payment purpose using the mobile phone number.

[0144] It is evident that by using a shared service server networked with numerous web servers of different cash registers or even different providers, the mobile phone can be loaded with numerous payment orders. Alternatively, a telephone number can be displayed at the cash register, for example, which the user must dial for each payment transaction and which directly relates to the beneficiary's specific web server, thus eliminating the need for a shared service server. After the connection is established, the user can also be required to enter a password (optional), which the user could have specified on the website when loading the mobile phone with the amount of money (transfer).

[0145] A shared service server is also useful, for example, if a complex additional service is to be offered as an additional security measure, such as voice recognition of the user, who in this case can also repeat a random text sent via SMS. A combined analysis of the acoustic signal and text is then performed: once via text recognition to determine whether it is the SMS text, and once via FFT analysis to identify the voice.

[0146] Or by querying special data known only to the person concerned via SMS, or by analyzing images of the iris using the built-in camera (possibly with magnification provided by extending the lens, etc.).

[0147] Options for code transmission to generate the activation signal when redeeming the paid purpose: If, for example, a turnstile is to be controlled for access control, e.g., at a ski lift or a football stadium, etc., it may also make sense to combine the preferred method with the familiar method in which a watch is held up to a sensor, which is used to open the device (generate the activation signal). The watch can have, for example, a microphone, an earpiece, or an infrared interface to enable data transmission between the watch and the mobile phone.If necessary, the watch can also communicate directly with a PC via a data connection, allowing the PC to write the digital receipt received as a data code when making a deposit via an online account directly into the watch's memory. The watch, in turn, generates the corresponding activation signal via a corresponding interface, which is temporarily linked to a computer and thus to a server via another interface when the payment is redeemed. The encrypted data then contains the code issued by the website when making a deposit into the online account. Internal bank transfer for an instant transfer:

[0148] In application C, which will be described later, the mobile phone is not charged, but rather the money is immediately debited from the bank each time a payment is made.

[0149] When a user deposits money into an account, there is usually the problem that the receipt of payment cannot be determined immediately. This is because the bank receiving the money does not credit the account immediately, or the bank server that receives the order online does not execute the order straight away. However, it is desirable that when a mobile phone is topped up with a certain amount of money, this process takes place immediately, practically in real time with the transfer process. For example, while the user is still viewing the bank's website and the relevant customer page of the web server is also being used in the browser, the web server is "informed" that the user has initiated the transfer.receives a corresponding notification signal in order to be able to immediately activate the payment for the transaction later by identifying a telephone number, even if the transferred amount of money does not actually arrive in the relevant account until two or three days later.

[0150] This is done by the bank with which the user holds an account checking, when a payment order is placed, whether the transfer is directed to an account belonging to a specific web server (registered for this purpose). Both the user account and the account corresponding to the web server belong to a type (coded by a number range) that is immediately identified by the account number to speed up this check. If this is the case, the bank server first checks upon receipt of the transfer order whether the amount is covered. If so, a reversal of this amount is blocked (until it is actually posted), and the web server immediately receives a message that an amount of the relevant amount has been irrevocably transferred with the relevant payment purpose and to the relevant originator (since the bank has blocked the possibility of reversing the amount).With this message, the web server can then generate the release signal via the web server for the relevant data record, which also contains the assigned mobile phone number, during later redemption (for the paid item or for the paid service) (in order to display it at the cash register on the client computer, or to generate the output signal for a machine connected via the Internet, etc.). Application B:

[0151] If the option of linking two websites via a telephone number (which can be a mobile phone or a landline) is used when making a deposit, this has the decisive advantage for online banking that the data supplied by this additional software can be linked to the data required for online banking without the need for a direct connection between the online banking website and another software program, which is only called up later when paying.

[0152] This will be demonstrated in the example described below, in which the mobile phone is charged with a certain amount of money. Example of a charging option:

[0153] Overview of the servers and computers involved in the payment process: Cash Server: This server has access to transfer funds to a top-up account, which corresponds to the current value of money that can be paid with the mobile phone as cash. The Cash Server manages a top-up account for each user, although in practice this account can also be a shared account for all managed users. This account is managed by a database that manages this account as if each user had an account accessible at the address of their mobile phone number. Bank server: This corresponds to the bank's server through which the user can transfer an amount from their regular account to the top-up account via online banking. It's best to have both accounts at the same bank to achieve faster transfer times, but this is not required. Client computer: The client computer here is the server connected to the cash server via the Internet, through which the payment is made using the mobile phone to form a data loop (from the cash server to the mobile phone and from the mobile phone back to the server). In special cases, however, this client computer can also be a server, e.g. the cash server, which forms the end device of the data loop via another mobile phone. This means that the mobile phone used for payment is then temporarily linked to the end device of the client computer (or in this case, the cash server) to form the data loop. Thus, in this case, the second mobile phone is essentially used as a client computer (for acoustic coupling or coupling via infrared interface, etc.). Procedure for topping up your mobile phone with cash:

[0154] The user transfers a certain amount from their online account to the top-up account with which they wish to top up their mobile phone. If they make the transfer via an internet browser on their computer, they then also call the bank server with their mobile phone. The bank server decodes the telephone number and calls back so that the user can transmit their mobile phone number to the bank server via the data loop and the code sent via the loop from the server via the mobile phone and the web page of the online account (the bank server). The bank server uses the user's telephone number, decoded and verified in this way, as the payment purpose for the amount transferred to the top-up account so that the payment can be credited to the mobile phone corresponding to the telephone number by the cash server. In the cash server, this telephone number is used as the address for access by the mobile phone orThe user's assigned charging account is used, including the user's personal data as it is transferred from his account to the charging account. Procedure for cashless payment with mobile phone:

[0155] To pay without cash, it is sufficient to temporarily close the preferred data loop (from the cash server to the mobile phone via the connection back to the cash server) on any device. This device can either be a direct input device connected via the internet or another mobile phone connected to the cash server via another telephone connection.

[0156] If the terminal device is a cash register connected to the Internet or a client computer connected to the Internet as the cash register, or a (further) mobile phone that is used as a cash register, for example, then the following protocol is appropriate: The price to be paid is displayed on the terminal device corresponding to the cash register (on the display), ideally also visible to the customer. The customer has already called the cash server (to avoid waiting times) and sent an encrypted PIN code to the server via the dial pad. This PIN code can be changed as required, for example, via the website when assigning their mobile phone via the preferred data loop. During this PIN code transmission, the cash server decodes the mobile phone number (if this is not possible, the call is aborted and the subscriber is asked to deactivate the number suppression and dial again) and registers the call by switching a specific initialization status to this phone number. If another call follows from the mobile phone to this phone number in this initialization status, which can be done by simply pressing the redial button or by sending an SMS, etc., then a call back is made immediately, with the code signal being sent from the cash server to the mobile phone.

[0157] In addition to transmitting the code signal for the data loop, the cash register also sends the received amount to be paid via the internet connection, just as it is shown to the customer on a display. This amount is directly assigned to the code signal due to the format used.

[0158] The Cash Server continuously checks all transmitted code signals. The Cash Server can either send the code signal directly to the mobile phone and receive it back via the client computer's internet connection, or send the code signal from the Cash Server to the client computer and receive it back via the mobile phone. Furthermore, it is possible to replace the client computer's interface for the data loop created by a temporary connection via the mobile phone with another device, e.g., another mobile phone connected to the Cash Server via the other telephone connection (of this mobile phone).

[0159] If the cash server recognizes a code signal that has been sent out and received back as a match, the software reads the telephone number that the server uses to establish this telephone connection and further decodes the amount of money associated with the code signal (as it is shown to the customer on a display at the cash register).

[0160] The Cash Server, addressing the recognized phone number, sends a message to the user's account, accessible via that phone number, and checks whether the amount is sufficient. If so, the message is transmitted to the mobile phone (via SMS or an alternative format) so the customer can check the amount to be debited. The message then appears on the mobile phone display. If only a small amount is sufficient, a warning message is displayed in addition to the amount (visual, audible, flashing, etc.). If the amount is not sufficient at all, a zero appears as the amount, along with a corresponding warning message.

[0161] If the displayed amount is to be paid, a specific key (e.g., #, etc.) on the phone must be pressed. If the amount is not to be paid, a different key must be pressed. A confirmation prompt may be displayed for payment, and the key must be pressed again for confirmation. The same procedure can be applied for non-payment.

[0162] A message also appears on the screen of the cash register connected to the cash server when the customer has paid the amount. If the customer has paid less than the specified amount, an alarm is triggered (e.g., the customer can still pay the remaining difference, which is also displayed at the cash register, in cash or other payment methods, etc.).

[0163] Only when the customer has paid, whereby in the event of a missing amount the difference must be confirmed manually at the cash register, the payment process is completed at the cash register as usual.

[0164] Once the customer has confirmed the payment transaction on their mobile phone, the paid amount remains displayed on the mobile phone until the customer performs another function, or the paid amounts can also be saved and displayed like telephone numbers, etc.

[0165] The transaction paid in this way, or the amount debited from the top-up account of the relevant telephone number (the customer or user), can be canceled by the beneficiary within a short period of time, during which the amount has not yet been transferred to the beneficiary. For standard cash payments, this is possible using a special function (usually activated with a special key at the cash register). The same function is also available here via the cash register's server access. For this purpose,

[0166] For this purpose, the procedure is the same as for a payment, except that instead of an amount to be paid, the amount is typed in as a refund by the beneficiary at the cash register and sent to the cash server using the connection or data loop of the mobile phone for the telephone number.

[0167] The mobile phone user will then see the credited amount (which he can immediately access again as it was not debited) displayed on his mobile phone with the note “credited”.

[0168] Furthermore, as is usual with online banking, mobile phone users can call the cash server to view their balance. Cash deposits via a bank are also possible, in principle. Application C:

[0169] Application C differs from applications A and B mainly in that the mobile phone does not have to be pre-charged, i.e. no advance transfer has to be made by the user (who pays), but the transfer only takes place when the user establishes the acoustic connection between the beneficiary's client computer and his mobile phone, e.g. when paying at a beneficiary's cash register, etc. For security reasons, this is done via a specific service server.

[0170] For this purpose, the user uses a mobile phone capable of making a transfer from an online account, e.g., a Java-enabled mobile phone. An interface is provided for the input fields: beneficiary (or recipient of the payment), bank details (bank sort code and other required numbers, account number), amount, and payment purpose, through which this information can be automatically entered.

[0171] The amount and, if applicable (optional), the payment purpose (branch, date, item, etc.) indicated on a receipt are automatically included as the payment purpose in the transfer. Of the available options, the following remains preferred for reasons of simplicity and security. All transfers are supported by a service server, and the transferred money takes the following route: The service server can use a robot to access accounts assigned to it, hereinafter referred to as intermediate accounts. To avoid unnecessary delays in transfers, it is advisable to open such an intermediate account with each of the major banks. This intermediate account, like all other accounts, is managed by the bank's server. The user can transfer money to this intermediate account, but no transfers can be made from this account using standard online access, except via a connection secured by a landline telephone line. Instead of a slow modem connection, a fast broadband connection can be used, which is also secured using the preferred method alongside the usual encrypted data transfer. In this case, the necessary data loop for passing through the identification code is then, for example, permanently switched on.

[0172] And only via this secure data line, which connects the service server to the bank server, can funds be transferred to any other account at any bank.

[0173] If the user wants to pay with their mobile phone, they first make a bank transfer using their mobile phone to the intermediate account specified as a fixed account number, which has the same bank details as their account. The receipt of the payment into the intermediate account is reported by the bank's server to the service server virtually instantaneously. The user only needs to enter the PIN number, the amount, and with the touch of a button, the amount is transferred from their account to the intermediate account (as a fixed bank details).

[0174] The service server immediately detects this payment receipt via a direct notification signal from the bank server (even if the amount has not yet been booked in real time) and must assign it to the correct recipient, since, for reasons of faster processing, the user only uses a fixed account number, namely that of the intermediate account, in order to avoid the time-consuming entry of the bank details and account number of the payee.

[0175] The allocation of an amount received on the intermediate account without a payment purpose, without a payee (i.e. without specifying the name or bank details or account number of the actual beneficiary), and only with the bank details and account number of the intermediate account set up in the user's mobile phone for this payment function, is again carried out using the preferred allocation procedure.

[0176] The cash register, or the client computer used as a cash register, etc., of the actual beneficiary of the payment to be made with the user's mobile phone is networked with the service server, as explained in the example for application B for the cash server, whose function is taken over by the service server here. Differences to application B:

[0177] The key difference from Application B is that the cash server only considers amounts that have actually already been posted. In this example, the service server receives a notification in real time when the user initiates a payment order from their account to the intermediate account. The bank server blocks this amount from further postings (withdrawals and transfers) until it receives notification that the amount has been posted to the intermediate account. Furthermore, in the example of Application A, the amount is transferred to the intermediate account, or to the mobile phone's top-up account, not from a mobile phone, but usually via a computer with internet access. Another key difference to B is the use of accounts:

[0178] The top-up account used in application B, or the portion managed by the Cash Server for the mobile phone user (i.e. the payer) under his telephone number, is to be regarded here as a money store that can be filled by the user as desired through transfers or deposits in order to then be able to dispose of the amount as desired, divided into any number of payments to different recipients (beneficiaries), to whose account the money is transferred from this top-up account under the control of the Cash Server.

[0179] The intermediate account used in application C, however, or the portion managed by the service server for the payee (i.e., the actual beneficiary) under the mobile phone number (as determined during payment via the data loop), is considered here to already belong to the payee and is provided for security reasons. Because only the service server, and only via a specially secured connection, can access the intermediate account via the bank server. For each operation performed by the service server's software as a robot that serves the bank server via its online account interface and which involves a reduction in the amount in the intermediate account, the preferred data loop DS is to be integrated in order to ensure the authenticity of the source of a software operation via the code signal.

[0180] This means that the procedure is particularly suitable for identifying the source server that produces a web page, thus fundamentally ruling out manipulation via the name server (via which a web page is usually accessed or which generates the access address), etc. Similarities between applications B and C:

[0181] As a comparable technical detail of these applications, the cash server in example B, like the service server in example C, performs the function of assigning the beneficiary's account as the actual recipient account, as well as assigning the debit from the payer (user). This assignment is carried out using the procedure using the telephone number of the mobile phone used during payment to establish the special data loop. By finding a match between a code signal sent by the server and the code signal received back, the telephone number of the respective terminal device (here, for example, a mobile phone) that established the special data loop for returning the code signal is identified by the server and the telephone number of the respective terminal device (mobile phone) used as the connection key (or connection address).

[0182] Note: Of course, the account allocation made using the mobile phone number could also be carried out by direct transfer to the beneficiary's account from the payer's (user's) mobile phone. However, this has the disadvantage that the payer (user) would have to enter the beneficiary's bank details, account number, and payment purpose each time, which would be very time-consuming. With the alternative method described, all they have to do is press a button, enter the PIN number, and then open the transfer form. They then enter the amount and, after confirming, submit the transfer, similar to withdrawing money from an ATM. The only difference is that the payer's mobile phone chip card replaces the ATM card.

[0183] The following special measure, which is particularly suitable in practice, has been implemented in the mobile phone's software for unlocking the mobile phone's security function, which provides access to the mobile phone user's online account using a PIN number (or an additional PIN number, for example): In addition to the longer PIN number, a shorter PIN number is also provided, which the user only enters when entering the amount and submitting the transfer order. This means that the user can enter the longer number in peace and access to the online account remains secure until they enter the amount (when it is their turn in a queue at the checkout), press a button, and enter the second, shorter PIN number. If it is entered incorrectly, the status is reset to the first PIN number to prevent anyone from trying it out.

[0184] For further security reasons, a time-out period is provided, which is started for all other transfers (except for the fixed one for the intermediate account) by entering the PIN number. If no subsequent transfer is made, the online account is automatically locked again after the time-out period has expired.

[0185] If, during an online transfer via mobile phone, the transfer (to the intermediate account) is not made immediately after the amount has been entered within a short timeout, or if the data loop for transmitting the code signal back to the server is not established within a short timeout after the transfer, then the complete PIN number must be entered again in order to repeat the process, or if this fails several times, the process is finally aborted and the transfer to the intermediate account is reversed in the bank server due to the lack of the acknowledgment signals expected from the service server for the telephone number in question.

[0186] In order for the payer (user) to be able to automatically allocate his transfer to the bank server's intermediate account via his mobile phone, the following procedure is used: The bank server only accepts access to the intermediate account (for accepting an incoming payment) via the transfer protocol if the payer (user) also provides their number during the telephone connection (so that the bank server can use the telephone number for assignment in the payment purpose). If this is not the case, the process is aborted with an error message. Since the service server's intermediate account is managed by the same bank server as the payer's (user's) personal account, technically implementing this requirement is not a problem. For many bank servers that manage an online account, such an intermediate account is provided (which is assigned to the service server, or under the control of the service server, to the beneficiary and not to the payer!).

[0187] In this variant according to application C (as is also possible in principle with the other applications A and B, but not a requirement), the immediate generation of a notification signal is provided when the payer (user) makes a transfer from their account (here to the intermediate account of the service server). The amount remains blocked in the payer's (user's) account for all further transactions until it is actually received in the intermediate account. This can usually happen immediately because the intermediate account is an account that belongs to the same bank as the payer's (user's) account. This notification signal is then sent to the service server and contains the information about the transferred amount, the sender's data (including bank details) and the mobile phone number, as well as the exact time the online transfer took place.

[0188] After the service server has received the pre-notification of a payment receipt (as a notification signal) from the bank server, which occurs practically in real time immediately after the user's transfer is completed, it evaluates the following data received with the notification signal as a data set received from the bank server as follows: - Telephone number of the mobile phone to be called back; - Time and date of the initialized online transfer of the payer (user); - transferred (=received) amount; - Bank details of the sender, i.e. the depositor (user or remitter); - if applicable, the sender's address.

[0189] Parallel to the process of transferring the amount of money corresponding to an invoice or receipt, or even immediately before, when the cash register displays the amount to be paid, the cash register, or a relevant client computer, etc., has established an Internet connection to the service server or, where appropriate, maintains one continuously.

[0190] The customer or the user paying with their mobile phone should ideally have already entered the PIN to unlock access to their account before the actual payment, or only need to enter a short additional number to transfer money from their account to the intermediate account. After seeing the amount displayed at the cash register, they enter the amount into their mobile phone and press the "send" button. From this point on, the mobile phone is blocked for all incoming calls that do not originate via the service server (detected by the server when calling with a given phone number) (option).

[0191] After sending, for example, an SMS or encrypted data to the bank server. This data may also contain a PIN that is invisible to the mobile phone user or a transfer code generated by entering the PIN into the phone, etc., the mobile phone hangs up, and the bank server sends the above-specified message (with the data listed above) in real time to the service server, which in turn immediately calls back the phone at the received phone number. Upon receiving this callback, the service server continuously repeats the preferred acoustic signal with the preferred recognition code to the mobile phone. Alternatively, an infrared signal can be controlled accordingly.Depending on the mobile phone, both options can be implemented simultaneously, with automatic switching for the respective transmission type, determined by a signal detector for each interface on the terminal device, via which the data loop is closed, and which carries out the switching via a retriggerable mono time triggered by the signal, for example.

[0192] The user places the mobile phone on the support surface with the microphone embedded in it in order to pair the earpiece of his mobile phone with the microphone and / or the infrared interface, etc.

[0193] The code signal reproduced acoustically by the mobile phone is transmitted via the microphone to the client computer (or cash register, or vending machine, etc.), and then transmitted back to the service server via the client computer (or cash register, etc.) via the internet connection. The data packet returning this code to the service server also contains the address and bank details of the payee (beneficiary) (encoded in the client computer or cash register, or vending machine, etc.).

[0194] Thus, the data packet sent to the service server as a data record received from the client computer (the cash register or an ATM, etc.) contains the following minimum data: - the code received via the service server's transmission to the mobile phone and from there back to the service server for verification - together with the sender's details (name, address and bank details with account number).

[0195] The service server continuously checks the returned code (simultaneously) for all established data connections involving such payment transactions (paying with a mobile phone), taking into account all currently transmitted codes, to determine whether such a code is recognized. If so, the received data set is assigned, using this verification code, to the phone number that was previously called (among other phone numbers) or to which the relevant code was sent.

[0196] The data set (BSD) received from the bank server is linked to the data set (CRD) received from the client computer (the cash register) in the service server using the connection key of this telephone number.

[0197] Thus, this data record managed by the service server contains the following data: BSD: - Telephone number of the mobile phone to be called back; - Time and date of the initialized online transfer of the payer (user); - transferred (=received) amount; - Bank details of the sender, i.e. the depositor (user or remitter); - if applicable, the sender's address; (CRD): - the code received from the service server to the mobile phone and from there back to the service server for verification, through which the telephone number of the mobile phone used for payment was found, whereby the corresponding data (BSD and CRD) can be linked to each other based on the correspondence with the telephone number obtained via the BSD data; - together with the sender's details (name, address and bank details with account number).

[0198] With this data, the service server can immediately send the receipt signal to the relevant device of the beneficiary who received the payment. In technical implementation, this could be, for example, a cash register (also the screen of a client computer, etc.) or, if necessary, a machine for unlocking a compartment, or issuing a printed card or ticket, etc.

[0199] Furthermore, the service server's software sets a mark (for deadline monitoring) to the data record corresponding to the data compiled using the phone number of a mobile phone (left) and waits for the actual receipt of payment, which is transferred from the mobile phone user's account to the service server's intermediate account, stating the amount and the phone number of the mobile phone (which was recorded by the bank server during the transfer), whereby the bank's server automatically inserts this phone number as the payment purpose for the transfer to the service server's intermediate account (in the booking document).

[0200] Thus, upon actual receipt of the transferred amount, the service server receives the data (by automatically reading the bank statements of the intermediate account) as a copy of the data set (BSD) received from the bank server: - Telephone number of the mobile phone to be called back; - Time and date of the initialized online transfer of the payer (user); - transferred (=received) amount; - Bank details of the sender, i.e. the depositor (user or remitter); - if applicable, the sender's address, and, using this information (via the telephone number and a comparison of other data), can initiate forwarding as a transfer to the beneficiary according to the data indicated by (CRD). The due date flag is then deleted. If the money expected in the interim account does not arrive, a corresponding alarm message is sent to the log file so that an investigation can be initiated using the data in the relevant record.

[0201] General: A general improvement for the transfer of money with a mobile phone is the evaluation of a voice profile with an FFT, e.g. by saying a word to the user via voice announcement and / or indicating that he has to repeat it in order to recognize his identity.

[0202] Error messages: are provided as usual, for example if online access to a bank account is not available, etc.

[0203] Special features: However, the following error possibility should be fundamentally eliminated or at least reduced in frequency. This concerns an error that could occur if the transfer of funds from the mobile phone user to the service server's intermediate account was completed, but for some reason, the subsequent assignment of the mobile phone number via the code signal issued by the service server could no longer be completed within a specified time period (e.g., the mobile phone battery was empty, etc., or the internet connection of the cash register or a vending machine failed, etc.).

[0204] In addition to error prevention measures, a timeout is also provided, which is measured, for example, from the moment the callback to the respective mobile phone is initiated, or an additional period of time is taken into account that the user needs to place their mobile phone on the surface with the microphone after answering the call. If the number (of the mobile phone) is continuously engaged during a callback attempt, a predefined timeout is also initiated on the server. After the timeout expires, an error procedure is initiated, as always in such cases.

[0205] Exact timing of the transfer via mobile phone from the user's or payer's account (managed by the bank server) to the intermediate account of the service server (managed by the bank server with robot access by the service server).

[0206] After the bank server reads a transfer order from the user (payer) via his mobile phone, where the beneficiary is the intermediate account of the service server (as a trigger condition), the following steps are initialized: a) the caller's mobile phone number is read by the bank server; if this is not possible, the call is aborted with the error message "the caller's number must be activated" and a request to call again is made; b) if the amount specified in the transfer is not covered, the transfer will be aborted with an error message: “Amount not covered”; c) If, however, the amount is covered, the read mobile phone number is transmitted from the bank server with the data specified above under BSD (telephone number, time and date, amount; sender's bank details, sender's address) to the service server of the bank server, whereby the bank server receives this (BSD) data via hard-coded values ​​in the caller's mobile phone, or possibly even encrypted transaction numbers after the date are used to address this fixed data (of the intermediate account). d) the service server dials the received mobile phone number for a callback (or call), whereby d1) if the participant cannot be reached is aborted after a corresponding retry attempt(s) and an SMS with the error information is sent to the mobile phone subscriber; a negative receipt is sent to the bank server that it should not carry out the transfer or should cancel it, the data stored for the telephone number will continue to be removed from the current processing (if necessary, stored for later research in another area). d2) When the participant is reached, the procedure continues with the following step e): (e) when the service server calls back, the code signal currently generated by a random generator, either immediately or in advance, is output to the mobile phone as an acoustic signal, distinguishing it from the code signals of all other mobile phone connections checked at the same time; f) The service server searches for the code signal sent from the mobile phone via their internet connection and returned to the server for the currently connected client connections (each of which performs a cash register function, also a vending machine function, etc.), or searches for the connection address of the respective web participant to which the code signal belongs. This connection address corresponds to the device address transmitted by the respective client computer (or cash register, vending machine, etc.), which is assigned to the beneficiary (which is used to identify the payment recipient).

[0207] If a connection address corresponding to the code signal is found, the procedure continues with step g) below, However, if no connection address corresponding to the code signal is found, the process is aborted and an error message is sent to the mobile phone via SMS and a negative receipt is sent to the bank server, whereupon the bank server does not initiate a transfer and the amounts in the accounts concerned are not changed, and the data stored for the telephone number continues to be removed from the current processing (possibly saved for later research in another area). g) Upon finding a connection address (in the service server) corresponding to the code signal, the service server sends a positive receipt to the bank server, whereupon the bank server reserves the amount exclusively for this transfer (or deducts it from the account balance in advance for further requests and transfers) and transfers the amount to the service server's intermediate account. The mobile phone number read by the mobile phone upon receipt of the call is transmitted as the payment purpose and the associated fixed data (the intermediate account account number) are transmitted in addition to the amount. After the transfer is initialized, a corresponding positive message is sent to the service server at the address of the relevant telephone number, which is received by the payee's respective terminal device (cash register, vending machine, card printer from a roll with a dispenser, turnstile for access control, etc.).) which triggers an actuation signal indicating payment. h) The service server stores the corresponding data record, which contains the relevant telephone number of the mobile phone as a key to connect the data of the beneficiary payee (bank details, time, date, obtained via the network with the terminal device through which the data loop was formed with the mobile phone of the relevant telephone number found via the returned code signal) and the data communicated by the bank server to this telephone number (amount, sender, date, time, etc.) are added (linked) and via a robot function, the forwarding (transfer) of the relevant amount (recognized via the telephone number as the key address) from the intermediate account to the actual account of the beneficiary payee is transferred, whereby this payment receipt to this account, or the actual debit from the intermediate account, is monitored by the server, i) If the debit from the intermediate account is not made within the monitoring time (timeout monitoring) started for each mobile phone number (from the generation of the activation signal) in the service server, the transfer data will be written to a journal file, which will be monitored by an operator in order to be able to carry out investigations if necessary.

[0208] It is evident that, depending on requirements, any number of error controls can be provided for error monitoring and time-out monitoring. Furthermore, the method can be used for controlling a vending machine (e.g. cigarette vending machine) or access through a turnstile, etc., in addition to a cash register application in which the actuation signal is shown as a receipt for the deposit received, e.g. on a cash register display, and furthermore controls the release of the printing of a receipt or an admission ticket, etc.

[0209] Likewise, the mobile phone can be linked, for example, to a variety of services to be paid for by bank transfer, whereby the payment is then recognized by the preferential creation of the data loop via the code signal (with the associated programmed process in the database).

[0210] Furthermore, instead of a cash register networked with a service server, a second mobile phone can also be connected to the service server via an Internet connection, thus allowing payment transactions to be processed with two mobile phones.

[0211] Fig. 12a shows an example of a support surface (plate) padded with a soft foam (1), wherein the foam has a recess into which the mobile phone (2) is inserted and pressed against the foam for the purpose of creating a temporary data loop (here via microphone MIC of the support surface and earpiece HK of the mobile phone and / or via an infrared interface (IF, a, b). The acoustically or infrared-coupled interface is then networked with the server via a corresponding Internet connection of a corresponding terminal device.

[0212] Furthermore, it is illustrated how the automatic switching between infrared interface and acoustic coupling is carried out. If the mobile phone has an infrared interface, whereby several options for attaching a corresponding sensor to the contact surface can be provided, then all other input channels (acoustic coupling, etc.) are switched off and only the infrared coupling (data) is evaluated. For this purpose, the respective infrared signal is used as the trigger signal of a retriggerable mono time MONO (e.g. implemented by software), whereby the output Q of this mono time then only uses this signal channel and switches off all other available channels. It is obvious that any number of infrared interfaces can be provided on a mobile phone, and so on.

[0213] In the example explained below, it is also about recognizing a terminal device (e.g. an IT computer or client computer, or even just a mobile phone, etc.) connected to a server (e.g. an Internet provider), which is usually only assigned a temporary address, as belonging to a terminal device in another network (e.g. a telephone, mobile phone, etc.).

[0214] For this purpose, the terminal device of the further network, which can be regarded as a secure or unmistakable connection (e.g. a telephone connection of a landline or a mobile phone switched via a central office, or also via radio channels, etc.), is called by the server in question, whereby the server sends an acoustic code signal (CODE, also melody as code, etc.) generated by a random generator in the server via the loudspeaker output of the device used to display the website (client computer). This acoustic code signal is generated by a random generator in the server and is received back via the called telephone connection (acoustically coupled via the microphone). The server uses this data loop to check whether this is actually the code signal sent by it to the website in question. Only if the result is positive does it evaluate the assignment of the website in question to the telephone number used for the call as a passed security check.The method can also be applied in reverse, with the server sending the acoustic code signal to the earpiece of the mobile phone via a telephone connection, with the code signal being sent back to the server via the data loop via the microphone of the client computer, acoustically coupled.

[0215] Furthermore, the coupling required for the data loop between the data output of the computer and the data input of the telephone connection, or if necessary also conversely the coupling between the data input of the computer and the data output of the telephone connection, can be realized by any interface, such as infrared coupling, or another optical coupling, or even pluggable connections with conventional start-stop or synchronous data transmission (Modulo 2, etc.), in addition to the acoustic coupling preferred for compatibility reasons.

[0216] Likewise, the procedure can also be carried out exclusively between mobile phones (ie from mobile phone to mobile phone) or in conjunction with mobile phones and a computer, etc., as already indicated in examples, e.g. to use the procedure for general payment transactions.

[0217] Whereby the server, using the connection number T-# of the mobile phone used for the data loop DS (i.e. a connection with a fixed assignment), can assign or synchronise the data of a database or of different databases, even when called up at different times, if when a database is called up under the relevant mobile number T-# the preferred code (KODE) is passed via a data loop created by the user; and the server determines the corresponding telephone connections or telephone numbers by comparing the code signals received in each case (KODE_1...... (KODE_n), which must each correspond to those sent out by it. And via the telephone numbers T-# which correspond to one another in this recognition, the server processes or sessions of the client CL which belong to one another through the data loop are recognised as belonging to one another.Through this synchronization, not only the server processes used for cashless payment transactions can be assigned, but also any other server processes (or their web pages, ditto databases) can be assigned after payment and booking under the telephone number used for synchronization (T-#), following the payment (booking) or even beforehand, e.g. to pay for the service of a web page (or even a service that is only managed via a web page, such as theater tickets, pizzas, fines, etc.).

[0218] As already indicated in the examples mentioned, the code signal can optionally be transmitted in the opposite direction, meaning the code signal is sent to the telephone via the telephone connection and returned to the server via the website (or IT connection). Likewise, the connection of the data loop between the telephone and the computer displaying the website (or another mobile phone, etc.) can also be established via any interface, e.g., an infrared interface.

[0219] Through the preferred data loop, different server processes are synchronized via the telephone connections T-# used on the client side CL (or mobile phone side, etc.) for the data loop, whereby the telephone connections T-# used on the client side are checked by this data loop and even with only temporary IT addresses (of the server processes as an interface to the client), the processes can be clearly assigned to a specific session or a specific client CL. Example(s) 3.0:

[0220] In addition to the application already explained for using a mobile phone for cashless payment transactions, which can also be used, for example, to directly recharge a mobile phone's chip card, two further important applications for such synchronization via the telephone numbers T-# of the telephone connections used by the client CL are proposed here: a1) a lawful link to any website, for which liability for this link is generally excluded, regardless of the type and content of the website. The link is established in such a way that it is not included as such in the "calling" website; a2) a lawful link to any unowned website that belongs to no one because it is held in trust, and the source server cannot be traced. Furthermore, in compliance with IT protocols, the website is presented to the client under a different name (or under a different IT address) than the one used by the server that created it. The name of the website can change continuously; b) a novel use of a mobile phone to provide a digital signature on a document that is transmitted, displayed (or printed, etc.) via any device or client computer (including an internet cafe, etc.). This application can also be easily combined with the previously discussed application for using a mobile phone for cashless payment transactions.

[0221] In further development, any web page can be integrated into a certificate server (e.g. set up at a notary's office, court, etc.) to certify digital signatures on documents that are presented to the client CL on any non-certified server, whereby the user (client) receives a counter-document electronically that cannot be forged even though the client CL has no certification to recognize the authenticity of the document received back (e.g. from a notary server) (so that the signatory also receives a legally valid document from the contractual partner of the web page). Based on this application, it is also possible for the first time to send fully automated (through the transmission of a digital signature) certified emails and faxes from the office computer without the need to verify the digital signature on the sender's or recipient's computer or client CL. This is done via an intermediary certification server, which uses the preferred data loop DS as security for the user and receives the user's digital signature, further verifies it, saves and archives the process, and returns a certified copy of the document signed by the signatory. This makes it possible for the first time to send emails and faxes automatically in digital form, corresponding to the status of a registered letter (even with a return receipt).

[0222] Furthermore, if the client computer is already connected to a provider's server via a telephone line (i.e., via a modem), the data loop can, in principle, also be established by calling back the (relevant) telephone number at which the client computer can be reached. However, since modem connections for Internet use are becoming increasingly rare, this option is not necessarily worthwhile, because a modem connection is already fully utilized for data transmission.

[0223] However, the modem could also directly establish the preferred data loop on the client computer CL to its software for a second telephone connection (option).

[0224] In addition to the main applications listed above (concerning these examples), numerous other applications of the method are proposed.

[0225] In addition, advantageous improvements to the mobile phone's design are also proposed to make the process even more user-friendly. This includes, for example, the option of better utilizing the usually built-in digital camera for the process in various applications. For this purpose, as a technical development, the mobile phone's usually built-in digital camera is used to create the data loop of the code (KODE) sent from the server to the client computer CL and received back via the (further) telephone connection. For this purpose, an image field is optically displayed on the (or possibly also on another additionally provided) screen of the remote station (screen of the client computer CL or mobile phone), via which the data is transmitted using brightness modulation, e.g., according to a synchronous method such as Modulo 2, etc., comparable to data transmission via a fiber optic cable (only slower). This optical image field can be shown on the display or a separate LED, etc.

[0226] Therefore, it is sufficient to hold the lens of the mobile phone's digital camera against the screen, or rather on this optical field of the remote station, if data is to be transferred (coupled) from the client computer or from another specific mobile phone to the mobile phone.

[0227] It is also optionally provided that two arrows (⇑ ⇓) on the phone indicate whether the phone with the built-in camera should be held closer or further away from the screen (“⇑” or “⇓” or “” = OK). Furthermore, the lens is extendable so that the image section can be made narrower as a detail, like with normal extension rings on a standard lens. Two locking positions are provided: one that shortens the distance between the lens and the phone body (corresponds to the end position towards the camera body) (usual position), and one that lengthens this distance for the purpose of displaying a detailed (image) section (as a special position for data coupling).

[0228] Likewise, a barcode can be read by the camera of the mobile phone, for example, in order to Fig. 18 described application to a certification server, which is indicated on the chip label (10, 11 Fig. 16) with the barcode printed on the document (40). A special application where using the camera on a mobile phone also simplifies handling is to link a printed work, such as a newspaper, a book, etc., to a web page not only via the information, e.g. via an exemplary code provided in the printed work, but also to link this web page to a specific person, whereby the preferred data loop using a specific telephone connection (number T-#) of a specific person binds access to the web page to this person.

[0229] This binding can in turn be very well realized by the process by providing an exemplary code number KODE_extern that can be taken from the printed work (ie a different code KODE_extern for each copy) and this code number KODE_extern in connection with the implementation of the e.g. in a relevant WEB page, into which the user has to log in via the preferred data loop with the code (KODE) sent by the server to identify the telephone connection used for this purpose (T-#).

[0230] After entering the exemplary code of the journal KODE_extern once, the user can continue to log in as often as they like for a certain period of time (or number of sessions, etc.) using the data loop with the same telephone connection (e.g. mobile phone or landline number T-#) as was used for the initial login, without having to enter the KODE_extern of the journal each time. This exemplary KODE_extern of the journal is of no use to another user if they use a different telephone connection (e.g. mobile phone or landline number T-#) than the one used when logging in by entering the exemplary code KODE_extern (of the journal) for the data loop to transmit the security code (KODE) generated by the server using a random generator.

[0231] This encourages the user, for example, to regularly purchase the newspaper encoded with exemplary code numbers (KODE_extern). How the code is read from the newspaper is irrelevant. In the simplest case, it is simply stamped, printed as a sample number, or engraved with a laser marker and entered into the relevant website via a keyboard or a pad for handwriting recognition, etc. In further development, this code KODE_extern is fed directly via the data loop (DS) formed for the purpose of transmitting the security code (KODE) generated by the server, here via the mobile phone, whereby the KODE_extern is read into the mobile phone, for example, via the camera. This means that the server receives not only the code (KODE) it sent back in the data loop, but also the KODE_extern, which is only used upon initial login and refers to the encrypted printout, which (as a variant) is entered acoustically via the mobile phone. Further spoken security examples, described later, will further emphasize the advantage of this input method (where the server's KODE and the externally entered KODE_extern can be encrypted together in the mobile phone, etc.).

[0232] If the cell phone does not have a camera, then another preferred method is to enter an additional code, which in this case is, for example, a number KODE_extern of a correspondingly coded newspaper, and in conjunction with the preferred data loop of a code generated by the server (KODE) into the relevant web page or into the server, using the acoustic input of numbers that is already available on many cell phones (e.g. for dialing). As always, the conversion of the acoustically spoken numbers into the corresponding character code can be carried out either offline, i.e. directly on the cell phone, or online via a corresponding service number of the cell phone network, which can be reached, for example, by pressing a key. The same method can also be used to enter a PIN number or a personal identification number (PIC), as used for an encrypted transmission, e.g. in a payment transaction, or in connection with the submission of a digital signature, as described later in an example. ①; ⑤; ⑤; ..... Another application in which the preferential assignment of a web page is carried out is that the server is called from the user's telephone connection T-# in order to bill charges for the use of the web page assigned in the data loop via this telephone call.

[0233] The technically simplest case is when the service on the web page is offered as long as the data loop with the transmitted code signal is maintained, so that telephone charges during the service on the web page can be billed via the user's telephone connection T-# directly according to the duration of the data loop.

[0234] Or, in another variant, if each one-time call to the server via the user's telephone line T-# activates a specific feature (for downloading a file, etc.). The called server can terminate the data loop at any time by hanging up (according to a duration synchronized with the website). Another basic variant is when a user fee is entered via the web page using the preferred data loop in such a way that the user enters or confirms an amount of money via the web page while the data loop is linked to the web page server via his telephone or mobile phone connection T-#, or transmits the security code (KODE), whereby the entered or selected amount of money is then billed via the telephone charges. In a further development, this process can also be combined with the submission of a digital signature to a certification server (as explained in more detail later in this description). The amount to be debited from the telephone bill (for the T-# connection) can also be entered via the mobile phone in the data loop, with this input data being forwarded back to the server along with the security code (code), possibly encrypted. The certification server (its function will be described in more detail later) then guarantees, as an officially recognized intermediary between any website provider and any client user, that, firstly, the amount of money entered by the user on this website is correct and, secondly, that the amount of money can be attributed to the offered service, if necessary, even with notary supervision. This means that the usual rip-offs via dialers and excessively high-fee numbers are no longer necessary for reputable providers and could even be prohibited by law due to this innovation.

[0235] This process could also be easily combined with a parcel service, where the parcel delivery company (e.g., the post office) with its numerous branches acts as a trustee for purchases and sales made online. Similarly, a central file is created via the certification computer, where only reputable sellers and buyers are registered, etc. ❖ Another supplementary application concerns the calling of another WEB page by any other WEB page, without the usual link being required (corresponding to the main application possibilities a1 and a2): In contrast to the prior art, where such a call is made via a conventional link, where the address or name is contained in the code of the web page to be called, or at least the address or name of the web page must be encoded on the server through which the web page is called, this is not the case with this innovative application. The server, which directly displays a web page to the client (CL) (as a provider) via the intermediary of other servers, receives a web page that it has not accessed from a server in order to present it to the client (CL) under a completely different (anonymous) name. The client then only accesses the web page via the IT protocol that the server in question uses to display the (anonymous) displayed web page. In terms of international law, this is comparable to an intermediary service of any data network, or a telephone network, etc., according to which the intermediary service is not liable for the transmitted content and, from a technical point of view, cannot be liable.

[0236] It is intended that the WEB page via which the call is made by the Client CL only executes a general browser function which supports the browser of the Client CL in such a way that the name or address of the WEB page to be called is entered directly (direct addressing) or indirectly (indirect addressing) via the Client CL.

[0237] In both cases (direct addressing and indirect addressing) this is not done, as is otherwise usual, by entering information into the relevant browser window using the standard interfaces provided (via keyboard or by decoding a link on the currently accessed web page), but by calling a telephone number (via the telephone network or mobile phone network), which calls the server via which the web page to be accessed is to be accessed, or which, if necessary, should at least make this call on another server (so that the other server generating the web page being accessed, or even a whole battery of locally branched servers, can hide behind the server initiated by the telephone call).

[0238] The user then only has to call a telephone number (of a corresponding server or robot station, etc.) in order to access a relevant, anonymously presented web page.

[0239] This call can then be made by the user simply dialing a phone number (or, more generally, by entering the appropriate data to control the connection setup) via a landline or mobile phone (including a cellular network, etc.). In advanced configurations, the web page to be accessed not only provides a list of phone numbers but can also generate a dialing code for direct dialing. In this context, for the use of mobile phones, which have standard voice recognition for dialing, this voice recognition is further simplified by tone recognition, the implementation of which, for example, is applied in the same way as the previously mentioned measures for recognizing the code (KODE) transmitted back to the server via the data loop. In addition to using tone frequencies for entering the dialing code, a direct voice announcement could also be used, but the use of tone frequencies is more reliable. This method is not only limited to mobile phones, since the conversion of the audio frequencies reproduced by a web page on the client CL into dial numbers does not necessarily have to take place on the user's terminal (or telephone device), but can also be carried out on a server, for example, via an intermediate dial-up or even directly.

[0240] With an intermediate dialing, the user always dials a permanently stored number (on their telephone, cell phone, etc.) that relates to call forwarding. This call forwarding converts the telephone number generated by the user on the relevant web page, e.g., "WEB-Vermittlung.com" (hereinafter also referred to as WEB Page A) and reproduced as tone frequencies by the user's client computer CL (e.g., "001 / xxx ... xxx") into dial numbers for dialing the connection encoded by the tone frequencies. Optionally, instead of dialing a telephone number, an SMS can be sent to the call forwarding telephone number. The SMS then contains the telephone number of the server to be dialed. The call forwarding can also (optionally) call the sender of the SMS back to test the telephone number, etc.Or you can send an SMS received as a code from the server to be called back to this phone number, which in turn can be sent back (also via direct connection by converting the SMS into corresponding serial data) to the server of a respective web page via the client CL (or a correspondingly formed data loop) in order to perform the data loop check, etc. Of course, the whole thing also works via IT telephony, etc.

[0241] In the case of direct dialing, the preferred data connection on the client side CL is carried out, for example, by dialing the relevant telephone number via the Internet, using a service provider (server) that can dial into the telephone network (dial-up network) of the server whose web page is to be called at low cost.

[0242] Further explanation of the other options with which the WEB page in question can be accessed without a direct link via another WEB page: : I) With direct addressing, the WEB page to be called up, here called WEB page_B, is called up via software installed on the client computer CL ("plug-in"), into which the data for the name or address of the WEB page to be called up can be entered via a data interface (e.g. via an acoustic coupling or via an infrared interface, or another interface, etc.), in order to call up the WEB page directly from the client computer CL via its browser, or can also use a special service via another server for the call, which can call up the WEB page anonymously with regard to the user, but cannot display it anonymously according to the current state of the art.

[0243] The data interface is fed via the preferred connection established by the user or on the client side CL, in which the data is transferred from the telephone server to the user's telephone connection (T-#) after the user calls a telephone number provided for calling up the WEB page, or a relevant telephone server (or robot, etc.), and is fed into the data interface on the client computer CL (or also on a mobile phone, etc.) to call up the relevant WEB page. II) With indirect addressing, no special software ("plug-in") is required on the client computer CL to access a web page via an external data interface of the client computer CL. Instead, software with a function similar to that provided for direct addressing on the client computer is installed on the server Server_A, which, so to speak, merely represents an extension of the interface to the client CL via the IT connection.

[0244] To call up the WEB page to be called, here called WEB Page_B, the same data interface of the respective end devices (client CL, telephone or mobile phone) is preferably used as is also used to create the preferred data loop when the user logs into WEB Page_A (e.g. from “WEB-Vermittlung.com”), whereby the user on the client side then dials in to the respective server, Server_A, and Server_B (via their telephone network!) via the same telephone connection (his number T-#).

[0245] Server_B reads the telephone number T-# of the telephone connection (of the user, or client CL) transmitted over the telephone network during the call. If this is not possible, the user receives a prompt over the telephone connection to repeat the process but disable the caller ID suppression. Server_B saves this telephone number as an allocation address (to be used later, or for later synchronization of the data with web page A of Server_A).

[0246] Here again, the server(s) identify the subscriber via this data loop (of the telephone connection T-#) by generating the verification code (KODE), sending it out and checking the code received back.

[0247] If the called WEB page, here called WEB page_B, were stored on the same server (here called Server_A) as the WEB page (here called WEB page_A) which visually displays the telephone number of the server to be called (or also generates it as a data stream for directly automatically dialing the data loop to the telephone / mobile phone), then only a one-time formation of the data loop would be necessary (to Server_A) in order to check the telephone caller through the data loop.

[0248] Since this is (usually) not the case, i.e. the called WEB page WEB-Page_B is not stored on the server Server_A, but on any other server, here called Server_B, the server Server_B, which is called directly by the client user (CL) via its telephone connection (T-#), sends its name (i.e. its IT address) to Server_A via the telephone connection, as it initially still exists through the establishment of the data loop DS to Server_A (under WEB-Page_A) to the client CL. This means that the data loop established by the user on the client side CL is already connected to Server_B via the telephone connection (T-#), but is still connected to Server_A or its WEB page WEB-Page_A via the Internet connection. Whereby, no connection must initially be established between Server_A and Server_B via the IT network, i.e.the telephone connection established via the data loop DS at the client CL is initially the only connection.

[0249] However, if Server_A receives the IT address of Server_B via the data connection of the data loop DS over the telephone network (T-#), Server_A establishes an internet connection to Server_B and immediately sends the telephone number of the telephone connection (T-#) that the user initially used to establish the data loop. Alternatively, Server_A sends the telephone number (T-#) to Server_B via an SMS, etc. (see later).

[0250] It is evident that the user only needs to create an initial data loop to Server_A via their client computer CL once upon logging in. They can keep WEB page_A constantly open and call any number of other servers in the corresponding category Server_B so that these servers can each send their identifier (IT address) to Server_A via the telephone's data loop. This means that when WEB page_A is called up, the user can call any number of servers in the corresponding category Server_B by telephone and each time create the data loop DS to Server_A, with the purpose of displaying the WEB pages of the relevant servers corresponding to the dialed telephone numbers as anonymous WEB pages via WEB page_A of Server_A.

[0251] The telephone numbers can also refer to only one switching page of the server Server_B dialled via the telephone network with the telephone number, with the corresponding links to the relevant web pages, or the web pages can also be accessed directly via extension numbers on Server_B.

[0252] If Server_B has received the user's telephone number (T-#) from Server_A via the established IT connection, then Server_B calls the corresponding web page, which can be done via two alternatives: - By direct call via the telephone connection to the user (T-#), via which Server_B sends the serial signal for calling the web page designated (or decoded) by the telephone number (their telephone call) via the client CL's WEB_Page_A, or via the data loop (data link) to Server_A. However, Server_B calls the web page, copies it, and makes it available under a different name (or different IT address), or sends it to another server for the same purpose (which then makes the page available under a different name). In each case, this is done under the name that Server_B sends to WEB_Page_A for calling via the user's telephone T-#. This means that Server_B called by telephone is the extended arm of the user, who calls the web page in question (e.g., via a plug-in on their computer) and using an anonymous access service. - or by indirect call, in which Server_B calls up the web page identified (or decoded) by the telephone number (its telephone call) and copies it into its own web page with a different name in order to transmit it directly or via other servers to Server_A for display within Web_Page_A. In this case, Web_Page_A provides an empty window that can be called up with a mouse click, within which the page called up by Server_B directly or via other servers is presented to the user (under a different name). This differs from direct call via the telephone connection, where the web page in question is presented to the user (under a different name) in an empty window provided by Server_B, who calls it up via the data in the data loop of the telephone connection in question.

[0253] In each case, there is the option of making the call via a plug-in on the client CL's computer or directly via server A or the provider's server.

[0254] Thus, in both cases, it is not a link in the legal sense, which would be provided in a specific web page, but rather a pure service, such as occurs in a telephone exchange of a telephone network.

[0255] The same applies to WEB Page_A of Server_A, which is nothing other than a telephone directory (of WEB pages accessed anonymously by telephone call). e.g. a list of the WEB page “WEB-Vermittlung.com” FULL TEXT SEARCH...... Button THEME TEL. Number I know something about corrupt politicians and I tell everyone 001 / XXX...... electoral fraud * bribery * Abuse of office in ministerial office * All about cats 001 / XXX...... Indoor cats 001 / XXX...... Garden cats 001 / XXX...... wild cats 001 / XXX...... . . etc. ............

[0256] Note: Since the pages that can only be accessed by dialing a telephone number are intentionally not meaningfully indexed by a search engine, as their only temporarily assigned name NonameX.com (see also later) is constantly changing for their access via the Internet, it is important to also include keywords related to the topic of the page "WEB-Vermittlung.com", which can be accessed regularly via the Internet protocol, so that the search engines can find the page "WEB-Vermittlung.com" under the entered search term (e.g. "election fraud", "bribery", "politician"). Since the page "WEB-Vermittlung.com" is the only or one of the few directories from which the telephone numbers of the anonymous WEB pages can be obtained, the page "WEB-Vermittlung.com" is therefore accessed by many users and is therefore generally displayed at the top of the search engine rankings, while the anonymous WEB page itself is not, which is also what it should be.This method also makes sense if, in addition to the anonymous web pages, completely harmless topics, such as the example with the cats, are included. In this case, the web page with the cats can then be accessed not only via the telephone number or simply via a direct link, but also via a regular web page (with a regular IT address) hosted on a "less harmful" server. The purpose of including this page in the search engine is to ensure that the search engine displays the overview with the cats at the top. The web page "WEB-Vermittlung.com" also has a self-contained full-text search, so that users can quickly find the desired terms within the list of topics.

[0257] In this example, the topic is listed on the left, similar to a dictionary, and on the right, a US telephone number is provided that the user must dial to access a website, regardless of the server's location in the world. The left column can also open various information windows on the left, and an expert system can be integrated to find the desired topic using intelligent search functions. Of course, any names and designations can be used instead of topics, for example, to refer to a website name that is no longer available, such as proper nouns, etc.

[0258] Further options for the indirect addressing example: • The user (client CL) calls up the WEB page “WEB-Vermittlung.com” (corresponds to WEB page_A generated by server A) via the input window of his browser and closes the data loop via this WEB page and his telephone connection (the telephone number T-#), via which he calls server_A by telephone, whereby if necessary the telephone number used by the user (T-#) is checked by a callback (option); and furthermore the telephone number used by the user is saved in server_A for data synchronization.

[0259] Note: With a reputable provider that guarantees the security of telephone connections, the user (client) can also make the call using an IT telephone that can be reached at the telephone number (T-#). Another cost-saving option, applicable to all proposed examples, is for the user to send an SMS from the mobile phone used to create the data loop and receive a return SMS on the mobile phone used for the data loop. The user doesn't even have to send the SMS from their mobile phone; they simply send their phone number T-# as the text for the SMS, to which the server should call back. Special features: For the callback, the mobile phone contains an SMS data converter as an interface, with which the text of received SMS messages can be fed directly into the user's client computer as corresponding character data via the interface provided for forming the data loop DS, whereby the text of the SMS then corresponds to the random code KODE sent by the server.

[0260] For example, the received SMS characters are converted into an acoustic signal (modem signal, or modulo 2 synchronous signal with block repetition and synchronous bit frequency encoded, etc.) or into an infrared signal to read the received SMS into the client computer CL. Alternatively, the callback can be made via the telephone connection, which is also very cost-effective if the calling server uses the IT network for this callback. Here, again, there is the option of the mobile phone adding an additional code within the data loop, which identifies the mobile phone and / or user (see later part of the description). • Instead of the user calling Server_B by telephone via his telephone connection (the telephone number T-#), whose telephone number he takes from the directory (see example above), whereby the option could also be provided here that when the telephone number in question is clicked on on the web page "WEB-Vermittlung.com" (WEB page A), the number is played back as serial data (e.g. acoustically, infrared, etc.) in order to save manual dialing, in this example the option is provided that the dialing of Server_B takes place via an SMS, which is to be sent to the specified telephone number via the web page "WEB-Vermittlung.com" to Server_B, whereby the user's telephone number T-# is to be sent as the text of the SMS.In addition to the possibility of the user doing this from their mobile phone, they can also send the SMS directly from Server_A to Server_B by clicking on the number. The user's phone number T-# is then automatically inserted as the SMS text by the software on Server_A's website (which Server_A received via the first data loop via Server_A). This is not a link in the classic sense, since Server_A does not call Server_B's website, but rather simply sends an SMS from the user to an undefined website (but only to Server_B).

[0261] This means that in this case, Server_A transfers the user's phone number T-# to Server_B directly via the text of the SMS sent by the user.

[0262] Server_B calls back the telephone number T-# received via SMS and sends the complete Internet address, under which the page selected by clicking on the telephone number (from the table) can be accessed, via the telephone connection to Client CL, which sends this number via the existing data loop to Web page A. Web page_A can also use a service that enables anonymous access to the Web page to access the address (name) of the Web page to be accessed, received as data code via the telephone connection T-#, or, with a corresponding plug-in on the client computer, the input of the address (name) of the Web page to be accessed via the data loop can be redirected directly to the input window of the relevant service for anonymous access to the Web page (piping). • Since the server_A on the WEB page “WEB-Vermittlung.com” (WEB page_A) does not have a direct link to the WEB page_B (which was selected by clicking on a telephone number), but the link is only created when the user enters data (via the data interface), the link to the WEB page_B is very convenient, but is not a link from both a technical and a legal point of view, since the WEB page “WEB-Vermittlung.com” only corresponds to a standard telephone directory (comparable to a yellow pages directory, etc.).

[0263] The more detailed selection of a WEB page to be called up is done, for example, by direct dial numbers or, after calling up WEB page_B, an overview of the topics with real links to click on can be presented to the user. Verifying the authenticity of a website:

[0264] When a web page is accessed via multiple servers, the client user needs to verify the authenticity of the page. This can be done, for example, by the server in question, which transmits and verifies the code (CODE) over the data loop of a telephone network (i.e., over a telephone connection dialed by an exchange, in this case, over the telephone connection to Server_B), generating an acoustic announcement over the telephone network to confirm the authenticity of the page if the transmitted CODE matches the one received, or to provide a message if this is not the case, i.e., the web page that the client user sees on their computer CL is not the one they intended to access. In this example, Server_A can also transmit part of the security code, which is split into two parts [CODE = CODE1, CODE2], to Server_B (via SMS, or IT network, also encrypted, etc.).) to enable this preliminary check and then ask an interim question "Display web page, yes / no" so that the user does not allow the page in question (if it is fake) to be accessed on their computer. The second part of the code then directly checks the web page generated by Server_B again. Another example for the anonymous creation of a WEB page (see also Fig. 19):

[0265] The Fig. 19 (and also in the other figures Fig. 13, Fig. 14) do not concern the actual data paths to the servers, which can be very complex, but only those considered for the procedure.

[0266] The anonymously generated web page is not always made available on the server that created the page (the server_anonymous, SANY), but is stored or generated on the server without internet access. Only when the server_anonymous receives a telephone call, e.g., with an extension number, does it copy the page corresponding to the extension number to another server (the server display, SDIS), which provides a multitude of registered web pages without their own content and inserts the data corresponding to the received page into the empty page. Conversely, form data entered into this page is sent back to the server_anonymous.

[0267] The server_display constantly (rotates) the names NonameX.com of the registered web pages, which it fills with the content sent to it by the server(s) _anonymously. If the data is transferred to the client computer via the telephone line (optionally also the address of the page to be accessed) via the data link, this occurs under the temporary name NonameX.com, which the server _display is currently using to display the page in question. The server_display then informs NonameX.com of the temporary name NonameX.com of the web page, so that NonameX.com can send this name to the user via the telephone connection as data via the preferred data loop to the web page "WEB-Vermittlung.com" of the server _display to call up the NonameX.com page.

[0268] Fig.Figure 19 illustrates this process, with the three most important phases for accessing the anonymous WEB page (generated by the SANY server) marked with steps 1, 2, 3: (1).......The user logs into the SDIS server with their client computer CL by accessing the website "WEB-Vermittlung.com" and closes the data loop DS via their telephone line T-# (or mobile phone). The user has dialed the SDIS server via the TELCOM telephone network. (2).......The user takes the telephone number of the web page to be called from the list on the web page "WEB-Vermittlung.com", which initially only designates the SANY server, and dials the SANY server to send it an SMS with the text of the number of the telephone connection T-# (or mobile phone) used for the data loop.

[0269] In principle, this process can also be automated directly over the Internet (also by mouse click) (since the SDIS server has already verified the telephone number via the DS data loop) if the user does not need proof of authenticity of the anonymously accessed web page, or checks this again later via a telephone loop, etc.

[0270] The SANY server calls back the user T-# and sends the user's IT address (under which an IT connection with the SANY server can be established) to the SDIS server via the data connection (acoustic, infrared, SMS, etc.) via the user's client computer CL to the existing data connection DS of the client to the "WEB-Vermittlung.com" of the SDIS server.

[0271] If the SDIS server recognizes an expected IT address (of an initially arbitrary server) (e.g. after clicking on a corresponding button on the WEB page “WEB-Vermittlung.com”), then this is confirmed to the user, “Server is being called”. (3)........The SDIS server establishes a connection to the SANY server using the received IT address and sends the following data to the SANY server: - the telephone number T-# (of the user) corresponding to the session to the WEB-Vermittlung.com website (via the data loop) under which he received the access address of the SANY server (via the data loop DS), - the (unregistered) reference name or a field address of the database, to designate the desired web page that the user has selected from the topic list by clicking on it, - and the name of one (of many) registered WEB pages NonameX.com (which can also be called "Pseudonym_583.de", see later), which is not currently in use and has no content, and under which the content of the accessed WEB page, anonymously generated by the SANY server, is to be displayed.

[0272] The SANY server responds by transmitting the content of the relevant (requested) web page to the SDIS server, again at the address of the subscriber's telephone number T-#, which it used in the data loop. As already mentioned, all synchronization of the SDIS server and SANY server processes can be performed at this telephone number T-#. The SDIS server then copies the content of the web page received from the SANY server at telephone number T-# (or for the relevant session via its connection to the "WEB-Vermittlung.com" web page) to the empty web page under the web page name "Pseudonym _583.de." The user can also access this web page by entering this name in their browser window or by entering it into a special service (for anonymous access).

[0273] Or to make things more convenient, the SANY server sends the call address that it has received from the SDIS over the telephone network (2) TELCOM, so that it can be automatically entered into the user’s browser window via the DS data loop with the help of plug-in software. There is of course also the alternative of forwarding the call received via the DS data loop directly to the SDIS server. In all cases, the call is guaranteed not to be made directly via the “WEB-Vermittlung.com” page, which does not even know the name “Pseudonym_583.de” (the called up WEB page), because the allocation of the currently free page (without content) to display the WEB page received from the SANY server is not made via “WEB-Vermittlung.com”, but via server software that is still running on the SDIS server and is provided by “WEB-Vermittlung.com”.com" only transfers the telephone number T-# for synchronizing the process, which only corresponds to the telephone connection of the T-# user and otherwise has no connection to the subsequent processes. This option, however, involves transferring a field number from the advertisement (the telephone number list of the "WEB-Vermittlung.com" website) to the SANY server (to assign the selected website). This option is optional, as the user can also communicate this (visually displayed) field number directly to the SANY server via their telephone keypad, which then assigns the desired website based on this field number.

[0274] The telephone numbers displayed in the list on the website “WEB-Vermittlung.com” do not correspond to links, but only to an advertisement.

[0275] If the browser is extended (e.g. directly) in such a way that it can link (connect) the information distributed across several registered web pages and display it in a common window, then the matter becomes even more complicated from a legal point of view (due to the constant change of the name of the web pages displaying the information NonameX1.com..... NonameXn.com).

[0276] Reference to Fig. 13a: The user has logged on using his telephone, e.g. a mobile phone or landline connection, which has a telephone number T-# given to the called party (which is recognized by Server I as the called party or by a received SMS) using the preferred data loop DS (Server I → CL → TELCOM(1) → Server I, Fig. 13a), whereby the server I sends the code signal KODE(1), cf. Fig.13a, to the client computer (CL), on which the browser displays the web page, transmits it as a loudspeaker signal L and receives it back via the data connection DS (data loop) established by the user via the microphone MIC of the telephone T for comparison (for identification). Or, if necessary, the data connection DS also via the reverse path from the server to the handset L of the telephone T ( Fig. 13b) can be routed back to the server via the microphone MIC of the client computer CL (Server I → TELCOM (1) → CL → Server I, Fig. 13b).

[0277] The data loop DS (Server I → CL → TELCOM(2) → Server II → Server I, or vice versa) is not yet closed when the user calls (via TELCOM2) via the Internet connection Server II → Server I (and vice versa). This only happens after the IT address of Server II has been communicated to Server I (via the telephone connection of the data loop DS, as discussed above). Or Server I can also establish a connection to Server II in advance (via a direct link) if the procedure is used, for example, for other applications, such as the connection establishment to a certification server for receiving / verifying a digital signature described below. In this case, Server II then sends Server I the corresponding data with the address of the telephone number T-# used for logging in via the preferred data loop, and the same applies vice versa when Server I sends data to Server II.

[0278] Call forwarding: It is also evident that the telephone number to be called can be routed via a call forwarding connection, which can also be used to make callbacks from the server station(s) involved in the process. The same applies to the use of SMS, IT telephone connections, etc. as additional data channels for the telephone connection of the connection (T-#) to establish the data loop on the client side.

[0279] If required, the interposition of a trusted server is also provided, which receives an SMS (or possibly a call), for example, at the local or free rate. The SMS text then contains two phone numbers, preceded by letters [s000111h22222222]. The first phone number (s) refers to the name of the server, although the designation "000111" is converted by the trusted server into a phone number or email address, or even a direct call to a server via the Internet, etc., and the second phone number (h) refers to the specification of a specific phone number T-#, e.g. a mobile phone number.

[0280] The trusted server either handles the anonymous web page call itself and guarantees the user the authenticity of the accessed web page, or after the trusted server has forwarded the received SMS [s000111h22222222] to the actual web server concerned with the call (the server_anonymous, SANY), the server calls the user back to the T-# connection using a low-cost IT telephone call. Via an acoustic connection, or an SMS, infrared, etc., the user forms the data loop DS to the other server (the server display, SDIS), which displays the telephone number list on its web page "WEB-Vermittlung.com", in order to access the relevant web page in the manner described. The trusted server does not save the calls to the web pages of the server_anonymous, SANY (or several, depending on the received SMS number), but forwards them to another server, which, like a name server, e.g.The first phone number(s) in the SMS are converted into an IT address and responded to the trusted server. As always, this data exchange between the servers is encrypted. Encrypted display of the web pages:

[0281] Since the provider of the website can be perfectly concealed by the preferred procedure, it is logical that emails from a specific server (e.g. Server II) can also be looped through such a provider in order to conceal the sender. The sender would then be called "Pseudonym_081.de" and could even be disguised as an encrypted website. In general, an encrypted browser is long overdue in order to make websites accessible only to a certain circle of people who have the appropriate key. Since the sender or creator of the website can no longer be determined, and since emails can be disguised as encrypted websites, and of course can also be sent encrypted as text or images, etc., without the sender being able to be identified, the Internet will certainly become even more interesting in many areas once it reaches a certain level of total encryption.Encryption without borders is the motto. Since it's no longer possible to distinguish whether an encrypted page is a website or a private email, where the text of the email is encrypted like a geometric shape of pretty girls (because the server simply processes the page accordingly), and since the sender (or owner) of the website can no longer be determined, eavesdropping attacks are becoming increasingly complicated.

[0282] Of course, all of this only makes sense if the provider of a website can securely conceal themselves so that their server is not bugged by intrusive attackers. In other words, the task of securely concealing the sender of a website, primarily by making the website accessible completely anonymously, bypassing the Internet and using a different network (e.g., by calling a telephone number T-#), represents a milestone in encryption technology in the IT sector. The network used to access a website, which is a telephone network in this case, could also be any other network, e.g., a radio network, including one using a Morse channel, etc. It is also possible to use different networks to create the preferred data loops for Server I and Server II.

[0283] In this example, Server II also identifies the user's telephone call via a data loop (2), whereby there is the option of placing the data loop (2) via multiple servers, in this case via Server I and Server II, i.e. continuing to form the data loop via the (first) accessed (and currently selected by the user in the client's browser) WEB page 1 of Server I, and looping the CODE (2) generated by Server II, forwarded to the client and encrypted, via Server I. The decryption of the CODE (2) sent by Server II is then carried out again by Server II upon receipt. Safeguards for the data loop: • It is evident that the encryption of the code sent via the data loop (KOSE) can also be achieved by falsification. This means that if an attacker intercepts the code sent from the server to the data loop and sends it back to the server via the other channel, i.e., if the server receives the same code via both data paths, it will still recognize it as false. To this end, the server sends an encrypted algorithm to one of the terminals involved in the data loop (or uses one) to falsify the code in a defined manner. Upon receiving the code back, after decrypting the falsification, it checks whether the code is correct (i.e., whether it matches the code sent). • Another variant is to send an algorithm to one of the end devices participating in the data loop for defined interruptions after defined pauses / transmission times of the code. Upon receipt, these times are verified. Similarly, if necessary, a code added to the end devices participating in the data loop according to a specific algorithm is verified, etc. The interrupted code is then reassembled before verification. If the time periods, or the duration of a code fragment and the associated pause, do not match those calculated in the server or specified by the server, the code is considered forged. • If the code signal is routed via several servers, then this server can also carry out the alienation of the code (CODE...) routed via the data loop according to an encryption algorithm, with the responsible server then decrypting this alienation again. Further process of the example:

[0284] A corresponding data channel (channel CL-T-#) is provided between Server I and Server II to transmit the code signal KODE (2) between the two servers.

[0285] In Fig. 13a this data loop (2) switched over both servers is formed via: (Server II → Server I → CL → TELCOM(2) → Server II) or in the variant according to Fig. 13b: (Server II → TELCOM(2) → CL → Server I → Server II )

[0286] Example of Fig.13a: Via this data channel (channel CL-T-#) switched on in Server I, the additional code signal KODE(2) transmitted by Server II via Server I (via the Internet) is made available to the user for a data connection DS in the same way as was previously done for the code signal KODE(1) generated by Server I. However, for the code signal KODE(2), Server I only acts as a switch, or rather, provides the data channel. The generation and transmission of the code and the comparison take place in Server II. However, in principle, Server I could also generate the code signal KODE(2) and Server II could only provide the telephone connection, "extended" via an Internet connection IT, for the transmission of the code signal KODE(2) to Server I. The same principle naturally works in the opposite direction, as in Fig. 13b is shown as a variant (alternative) and has already been explained at the beginning for the data connection on the client computer CL.

[0287] In this example (including Server II and Server I), the data loop (2) closed across both servers can be used to directly check using the code signal KODE(2) whether the user is using the same telephone connection T-# (of a relevant telephone number) for their telephone call to Server II (directly or via call forwarding) as they used for the first identification when logging into WEB page 1 for the data loop (1) of the first code signal KODE(1) of Server I. Furthermore, data can be exchanged via this data loop, i.e. via the connection regarded as secure or unmistakable (e.g. switched via an exchange or consisting of radio channels) (here the telephone connection between Client CL and Server II), both from Server II to Server I and from Server I to Server II (in each case via the encrypted connection at Client CL), with each Server (I orII) can set its verification code (CODE 1, CODE 2) as desired within this encryption.

[0288] If necessary, the connection to the client CL can also be bidirectional, ie the client computer CL connects or transmits both input and output data of the relevant web page via the telephone or mobile phone, ditto the mobile phone. • Likewise, in this example, Server II can, for example, send an algorithm to the mobile phone via the telephone connection (i.e. bypassing Server I), or, for example, store data for a string to create a pause in the returned code, or even just store an algorithm for simply changing the code (CODE 2) to alienate the code, so that Server I cannot falsify the check code (CODE 2) of Server II in such a way that Server I falsely evaluates the check code as positive.

[0289] Conversely, Server I can use the IT connection to the client computer CL and the data link to the mobile phone (i.e. bypassing Server II) to store the algorithm for alienating the code (CODE 1) on the mobile phone, via which the code is alienated, so that Server II cannot falsify the check code (CODE 1) of Server I in such a way that Server II falsely evaluates the check code as positive.

[0290] This means that both Server I and Server II can, on the one hand, securely encrypt their verification codes (CODE 1, CODE 2) independently of each other via the common data loop (via WEB page 1), and on the other hand, simultaneously use a common verification loop (through their connection via the Internet), via which they can receive data from the user's terminal device (e.g. mobile phone) that is intended for both servers, and can also verify the telephone loop via their verification codes.

[0291] This means that Server I and Server II have the option of synchronizing the processes independently of one another in successive data loops (each with a telephone connection T-#), or of synchronizing the processes via a shared data loop (telephone connection T-#). For the latter variant, which is preferably carried out using a mobile phone, the mobile phone has two independently functioning and also configurable alienation functions for alienating the code received and forwarded to form the data loop. One is for the code that is fed in from the coupling interface (from the Client CL or another mobile phone) (acoustic, infrared, etc.) to be forwarded via the telephone connection, and one is for the code that is fed in from the telephone connection to be forwarded via the coupling interface (to the Client CL or another mobile phone).

[0292] Thus, for this example, there are two possibilities (in full or half duplex mode) to send the code signal KODE(2) generated by Server II either via Server I and to receive it back to Server II via the data loop DS of the user and the telephone connection (2) ( Fig. 13a), or in the opposite direction, to send the code signal KODE(2) generated by Server II via the telephone connection (2) and to receive it back from Server I to Server II via the user's data loop DS and the Internet connection (IT) ( Fig. 13b).

[0293] Training options and general options for user access to servers (T-#): For a further training variant, the telephone numbers to be dialed by the user are not only displayed as text on the WEB page, but are also coded as a signal (e.g. acoustically corresponding to a modem signal) and output accordingly by the client computer CL and fed into the terminal device used (landline, mobile phone, etc.) of the telephone connection T-# used by the user, e.g. for easier compatibility through acoustic coupling for cheaper versions, or via infrared for slightly more expensive versions. - a) There is a general option, e.g., for a cell phone, that, as a general addition (and direct applicability), a telephone number issued from a web page via such an interface (or another variant, etc.) can be read directly into the telephone or cell phone by acoustically feeding a modem signal (acoustic coupling), or alternatively via an infrared interface (as a further option), so that the number can then be automatically dialed. This option is also generally very suitable for telephone directories or telephone numbers listed on the web, regardless of the preferred application. - b) Or, if a standard telephone without such an option is used, the user can simply dial a specific service number, which will forward calls to the number the user establishes via a simple acoustic connection (from their computer's speaker to their telephone's microphone). This call forwarding is then fed into Server II, including the given extension number. This application, in its most general form, is also applicable independently of the inventive method and can be used for all web pages displayed on the telephone.

[0294] In both cases (a, b), the user copies the telephone number from the relevant web page 1 (displayed by any general server A) using drag and drop (via the clipboard of their operating system) into a window of a second service website (displayed by the service server TCOM). The service server TCOM is operated, for example, as a free service by a mobile phone manufacturer or a network operator, etc. After the user has sent the telephone number to the service server TCOM via the window of the relevant web page, this web page generates the signal output on the user's client computer CL, reading this signal (audibly or via infrared, etc.) into the mobile phone, which decodes the telephone number corresponding to the signal and writes it into the dial memory. The user can, for example,add a comment to the TCOM service server's web page, which is saved for the number on the mobile phone and displayed as a selection aid (text) for selecting telephone numbers. It is evident that if any general server A is networked with the TCOM service server, the user can save themselves the trouble of entering telephone numbers into the TCOM service server's web page (via drag and drop). By clicking on a particular telephone number, or a selection field for telephone number selection, etc., on the general web page of the general server A, a small window of the TCOM service server is called up via a standard link to indicate that the TCOM service server is now generating the output of the signal corresponding to the telephone number (e.g., as a modulo 2 synchronous signal with block repetition) via its web page, which the user can feed into their mobile phone.

[0295] In further development for the design of a telephone or mobile phone when using the preferred coupling for the preferred data loop (to / from the server), this use also includes the following additional data: a) entering the address or name of a web page to be accessed into the client computer (via the signal from the telephone connection T-#), whereby this can be done via a plug-in software that directly supports the browser of the client computer CL, or via a relevant direct support of the internet server, b) the input and output of data that are to be sent via the data loop of the client computer CL from a telephone connection to a server or from a server to a telephone connection, in particular the check code (KODE) for checking the data loop, c) the conversion of an SMS received at the terminal of the telephone connection via the telephone connection T-# (telephone or mobile phone), which corresponds to a data code or data, into a data stream that is sent to the server via the data loop and the direct data connection of the client computer CL, d) the conversion of an SMS received on the client computer, which corresponds to a data code or data, into a data stream that is sent to the server via the data loop (on the client side CL) through the telephone connection (telephone or mobile phone), e) the alienation of the code (CODE) received via the data loop and re-sent in such a way that the received code is modified (encrypted) according to an algorithm, which is then reversed in order to restore the code (decryption) in the server, whereby the terminal device relating to the data loop (e.g. mobile phone) at the coupling point of the data loop obtains the encryption data or the algorithm from the transmission side from which the code to be alienated (CODE) is obtained, which is passed on to the other transmission side (according to this algorithm) in an alienated form and if necessary (if necessary) for both transmission directions independently of one another the alienation (encryption) of the codes looped through the coupling point takes place with encryption data that are completely decoupled from one another.

[0296] As already stated, three variants are particularly preferred for the connection of the telephone or mobile phone to form the preferred data loop to a client computer CL or, if necessary, to another mobile phone, whereby this connection can also be bidirectional if necessary: 1) an acoustic connection via the existing handset and microphone of the telephone or mobile phone, possibly also another mobile phone and / or speaker / microphone of a client computer; 2) the coupling between the mobile phone, possibly also another mobile phone and a client computer via the existing infrared interface; 3) the coupling between a mobile phone, possibly also another mobile phone, and a client computer via an existing camera lens and, for the other side, a corresponding brightness modulation (or color, etc.) of a graphic area shown on a display or screen (e.g. circle, square, etc.); 4) the connection via the SMS channel of the mobile phone, whereby the SMS is read in or read out via the data connection as a data stream (depending on the data direction); 5) the establishment of the coupling via connections switched by hardware and / or software, whereby instead of a user, a server can also form the data loop DS instead of a client CL.

[0297] For these applications, in addition to the design variants for the preferred process, independent, most general protection is also sought.

[0298] Another good application for the specified procedure is, for example, the proof that certain terms and conditions distributed via the web have been read when the data loop is formed via this page, or even the linking of certificates.

[0299] The following chapter concerns the linking of servers authorized to accept certified digital signatures (e.g., hosted and monitored by a notary) with any server that is not subject to any official control and yet presents documents to which the client user can provide a digital signature. However, with the advantageous difference that the signatory providing the digital signature for such a document still has the counter-document secured, which has an equivalent and possibly even notarized signature from the provider on whose document the user is signing. This counter-security is provided (e.g., with the involvement of a notary who hosts the server in question) precisely for the document that the user of a particular website signs with their digital signature.

[0300] Mobile phone (or possibly a landline phone) used to digitally sign a web page: for application: - to provide documents, including received emails, with digital signatures that are displayed on any server and are digitally signed by visiting a certification server established at a notary or court; - to add digital signatures to sent emails addressed to any server and digitally signed by visiting a certification server established at a notary or court; - to process purchases via any web page, to log deposits into bank accounts, transfers, etc., to process any processes and events which are controlled by a server and a mobile phone (e.g. access control to a bank safe deposit box, etc.) with a digital signature by visiting a certification server set up at a notary (or in a bank, etc.).

[0301] In addition to the possibility of using only a code entered into a web page as a digital signature, further development variants are described here which, in addition to this code, use variants as alternatives or in simultaneous use for additional security and concern a sensor system for identifying the person, hereinafter referred to as a person sensor, with the following variants and options: - a PIN code entry, and / or - a fingerprint sensor, and / or - voice recognition, and / or - an iris query

[0302] Valid recognition of a fingerprint and / or a voice, as well as any iris analysis performed via the web camera, is best performed for cost reasons on the server contacted by the mobile phone, although pre-recognition can also be performed on the mobile phone. The preferred method also provides twofold security: firstly, to test whether the ATM is actually being served by the correct server, and secondly, whether the mobile phone is communicating with the correct server via the telephone network. Both options for forming the data loop DS (serial to Fig. 14a and / or parallel Fig. 14b) can be used for this purpose. In the serial data loop ( Fig.14a) the mobile phone receives confirmation from the server via the more secure connection, e.g., the telephone connection, that the loop has been positively verified by the CODE sent by the server. In the parallel data loop ( Fig. 14b), however, the mobile phone can also independently determine the more secure connection via the CODE sent by the server.

[0303] It is evident that the method described below for issuing a digital signature can be used not only for a website, but also for withdrawing money from an ATM connected to the relevant server (via which the data loop is closed), or even for opening an apartment door. In this case, the electric lock is connected to the server, but the opening signal is sent directly from the mobile phone as an encrypted signal to the lock (via an infrared interface, etc.). Advantage: The server alone cannot operate the lock without using a mobile phone (as a key).

[0304] Procedure for this example (to open an electronically locked lock): If the user is positively identified (as an authorized user), the server generates a random code (CODE), which it sends to the lock. The server then also sends the code (CODE) to the mobile phone so that the mobile phone can transmit this code to the lock as the opening code. If the code matches, which is checked here by the lock (i.e. by the CL client), then the lock opens. If this is not the case, the server aborts and registers the opening attempt with the date and time, or if necessary saves a photo (video) sent via a web camera which documents the opening attempt, so that the authorized user can view it if necessary (e.g. automatic call to their mobile phone and automatic notification via e-mail, etc.).The data loop with a code check at the client CL is referred to here as a parallel circuit, in contrast to the serial data loop with code check at the server, and the differences are explained below with reference to . Fig. 14a and Fig. 14b is explained in more detail.

[0305] Locksmith: An authorized locksmith can, for example, gain one-time access via a mobile phone by providing his digital signature on any mobile phone, in which the fingerprint of the authorized person (usually the property owner) must then be entered, by assigning the identity number of the mobile phone to this fingerprint (in the server) for this one-time process, which takes place when the locksmith is authorized to open the door (against the digital signature of the locksmith).

[0306] Instead of entering a PIN code, or as a supplement, it is advisable to use voice recognition, where the user simply repeats a text transmitted via SMS on their mobile phone display. If necessary, these texts can also be spoken by the user as a sample to a corresponding server when certifying the signature, etc.

[0307] For example, the recognition for a digital signature can proceed as follows: Entering a PIN number, even a short one, generates an initialization signal that causes the mobile phone to send an SMS to the certification server, which then immediately replies with an SMS containing the text to be spoken by the user into the mobile phone and displayed on the mobile phone's display. As a further option, the entry of a short PIN number can also be required before speaking. Furthermore, as a supplement or alternative to voice recognition, the data for fingerprint analysis can be sent to the certification server. The certification server first sends an encryption code generated by a random generator to the mobile phone as an input parameter for an algorithm that encrypts (spoofs) the sent data in the mobile phone.

[0308] It is advisable to configure the mobile phone in such a way that encrypted, sensitive data relating to a fingerprint and / or voice recognition and / or iris scan is sent to the relevant server while the preferred data loop (DS) is being passed (verified by the code sent by the server) or while the data loop is being verified by a code. The mobile phone does not send the data to the relevant server if the data loop (or the code) fails the verification. This ensures that sensitive data is never sent from the mobile phone if the verification of the connection endpoints (telephone server / mobile phone / web server) does not match the desired connection.

[0309] If the user does not follow the required actions within a time-out period t started with the initialization of the process, the server will abort the process and, if necessary, only allow a limited number of initialization attempts, as is the rule with the usual simple PIN entry at ATMs.

[0310] In connection with the preferred data loop (2), a digital signature should be submitted to any WEB page "WEBX.com" of any server (e.g. from Server I, which can also be located on the Fiji Islands) via a corresponding mobile phone, whereby Server II is then used as a verification server to verify the digital signature and should be well-accessible and well-monitored at a notary or a court, or a certification authority.

[0311] This application proceeds as follows: The user has accessed a web page “WEBX.com”, which is generated by server I.

[0312] For this digital signature verification, the first step is to determine which mobile phone number (T-#) the user uses to log into the server (here, Server I) using the preferred data loop. By clicking a button on the relevant web page of Server I, Server I establishes a data connection to Certification Server II if one does not already exist (concerning other participants or users).

[0313] The server II (certification server) sends the CODE (2) generated by a random generator and receives it for verification via the data loop 2 (either after Fig. 13a or after Fig.13b), ie via the WEB page "WEBX.com" (which has a corresponding interface to support a digital signature) back again, whereby via CODE (2) the Server II checks for this application which telephone connection, in particular which mobile phone (ie which number T-#) is used during this data loop 2. In this application the CODE (2) does not only consist of the identification code generated by the Server II to determine which mobile phone is in the data loop, whereby the telephone number of the mobile phone T-# e.g.is checked again by a callback from Server II and during this callback the data loop 2 is then formed, but the mobile phone generates in this data loop 2 a further identification code, referred to here as the personal identification code (PIC), comparable to the additional data that is added in the identification data loop (data loop DS) for cashless payment transactions using a mobile phone, as has already been explained in detail. In addition to adding the personal identification code (PIC), the mobile phone alienates the CODE (2) received from Server II for the purpose of encryption according to a secret algorithm, whereby Server II loads corresponding parameters (as input variables) to the mobile phone in advance via the secure, direct connection, i.e. via the telephone network (T-#). The CODE (2) sent back to Server II is then decrypted again in Server II.

[0314] The personal identification code (PIC), which is also transmitted to Server II via data loop 2 in addition to, or rather as a component of KODE (2), corresponds to a standard code as used for transmitting a digital signature and can also contain the necessary additional data (as an option), such as the data for identifying a fingerprint and / or an audio text for voice identification or an optical image of an iris, or even a standard PIN code, etc., so that in addition to the KODE (2) sent out by Server II and distorted in the mobile phone, a long block of data is transmitted as KODE (2) sent back to the server via data loop 2.For this purpose, a corresponding formatting then takes place in the mobile phone, which incorporates the code KODE (2) received from Server II into the encryption in such a way that a falsification of the block also falsifies the code KODE (2) sent from the server to the mobile phone via the data loop.

[0315] This means that in an advantageous further development, the personal identification code (PIC), which is actually only generated and added on the user's end device (in this case the mobile phone), and the original CODE(2), which is already generated by Server II and is only transmitted back, are to be inextricably linked by encryption in such a way that, although tampering is not possible anyway, the very beginning of tampering is made more difficult. In this way, the original CODE(2) sent out by Server II is not only distorted and looped through in the user's end device (here the mobile phone), but after the personal identification code (PIC) has been added to the mobile phone, it is encrypted again and decrypted again when it is received back by Server II and separated again from the specific mobile phone data (PIC), so that the originally sent CODE(2) can be checked orif necessary, can be associated with the one sent to the associated WEB page “WEBX.com” of the server I, or the associated session whose data loop 2 is routed via the telephone number T-# of the user determined in the server II (via which this CODE 2 of the server II) in the preferred data loop (via the IT connection between server I and server II, cf. Fig. 13a, Fig. 13b, Fig. 19).

[0316] In brief, the following steps have been carried out in this process so far: 1. The user logs in to the "WEBX.com" page of Server I via data loop T-#. Note: If Server I is dialed via T-#, it can directly determine the telephone number of T-# via the separate data loop (DS=1) T-#. If the user is to be spared this dialing, the data loop (DS=2) is closed via both servers (via the IT connection between Server I and Server II), whereby both servers can determine the telephone number of T-# via this shared data loop 2 (which includes both servers). 2. After receiving a command via the "WEBX.com" page of Server I: Check the existing IT connection between Server I and the certification server (Server II). If it does not exist, establish one. Server I then dials the certification server Server II and verifies the identity of Server II. The existing procedure can be used in addition for this check, for example, by Server I automatically dialing Server II via its landline telephone connection T-### and verifying the authenticity of Server II via a parallel or serial data loop DS=T-### (if necessary with an encrypted acknowledgment from Server II).

[0317] Note: For this test, the data loop DS is not created by a user or operator but by automatic coupling (semiconductor switches, relays, port addressing, etc.) between telephone connection T-### and Server I. The formation of a parallel loop has the advantage that Server II can be Fig. 14b the CODE generated by a random generator for both channels (1 and 2, here T-### and IT) is generated internally in the same way, but through encryption (alienation of one channel or both channels, here 1 and / or 2) sends unequal codes via the data lines (1 and 2) to the client; this is the server I, via which the data loop DS is formed (by appropriate hardware connection), whereby the server I restores the alienated code sent according to the algorithm agreed with server II, so that it (with correct loop formation 2) for both channels 1 and 2 ( Fig.14b) becomes identical again (1=2), thus verifying the authenticity of Server II (the certification server) called by Server I. It is obvious that this can also be done in the opposite direction, allowing Server II to verify the authenticity of Server I. 3. Calling Server II via the user's telephone connection (or mobile phone) T-#. Data loop 2 is formed via the user's telephone connection (or mobile phone) T-# and the existing IT connection between Server I and Server II, as a serially connected data loop DS, corresponding to Fig. 14a (see also Fig. 19). 4. Server II (this is the certification server) sends the current input parameters to the terminal device on the data loop DS (here mobile phone used for DS=2) in direct access via the more secure connection (this is the telephone connection) for use in the encryption of CODE 2, which is sent by Server II for the purpose of verifying DS and is routed via Server I, and which is further encrypted in the mobile phone together with the security data entered by the user in the mobile phone (PIN number, fingerprint data, voice, iris, etc.).

[0318] Thus, Server II (the certification server) receives the sensitive data of the mobile phone as well as its verification code KODE 2 for checking the data loop DS in encrypted form, without Server I. Thus, Server II, via whose IT connection, would have the possibility of identifying the encrypted data; even if it knew the algorithm, it would still not have the current input parameters for decryption.

[0319] Likewise, in this variant (since DS=2 is used), Server I also has the option of configuring the data loop DS to encrypt data exclusively assigned to it. This means that the terminal device on the data loop DS (here, a mobile phone is used for DS=2) can use the IT connection (to the client CL) to transmit the current input parameters for use in encrypting its code CODE 1 for autonomous testing of the loop (2). If necessary, data can also be transmitted from the mobile phone to Server I that Server II cannot decrypt. Conversely, with a correspondingly special configuration of the mobile phone, Server I can, for example, also directly query the telephone number T-# of the mobile phone independently of Server II via the coupling (acoustic, infrared, etc.).If this training does not exist, then Server I, for example, can also do this by requiring the user to dial it directly via the telephone network beforehand; however, this is spared the user in the advanced training version of the mobile phone (see also later on . Fig. 20). 5. The certification server of Server II continuously runs through a scanner cycle and compares all codes received (here via the IT connection of Server I) after their decryption (CODE 2 of all participants, possibly from a large number of servers of the type "Server I") with the transmitted ones in order to form the pairs of matching codes, as already suggested in a comparable example, and assigns to each code pair the corresponding telephone number T-# (to which a respective code was sent or from which a respective code was received, depending on which variant Fig. 13b or Fig.13a is used). This means that Server II can continuously check as often as required, or can clearly assign mobile phone data linked to the code to the user's respective telephone number T-#, if these are not transmitted directly to the user, but via the IT connection of Server I together with the code 2, or also with the telephone number T-#.

[0320] For many applications, e.g. opening a turnstile, etc., the procedure could even be used in such a way that Server I, which offers the service (and monitors the turnstile), does not identify the telephone number T-# at all, but only receives the response (OK or not OK) to a code 2 sent to Server II, ie if recognized, then open the turnstile, or a door to a bank, etc.

[0321] Furthermore, Server I can of course also send its own data, such as documents, to the certification server Server II under the assignment of CODE 2 (ditto T-#), so that this document can be clearly assigned in the database of Server II to a specific mobile phone that has formed a data loop (DS=2) with it. ➢As an additional special feature, this process also makes it possible to use special plug-in software on the client computer to send the document in question or parts of the document (even just checksums of the data in the text lines, etc.) from the client computer via the telephone connection directly to Server II (certification server) via the mobile phone connection, so that when the latter later receives the document from Server I via the IT connection to a specific mobile phone number T-#, it can check whether it is exactly this document.

[0322] To submit the digital signature from the input code KODE(2), the code (PIC) is added to the mobile phone and this entire code is encrypted, whereby the code (PIC) can also have been previously (additionally) encrypted, etc. The Server II then decrypts this code again and separates the code (PIC) from KODE(2) and checks, on the one hand, the KODE(2) for the telephone number T-# to be received and, on the other hand, checks the code (PIC) composed of the transmitted digital signature and the user identification (PIN number, fingerprint, voice, iris, etc.), whether: 1. the digital signature in the database associated with the telephone number (T#) (of the mobile phone) determined via CODE(2) correctly corresponds to the one received? and 2. whether the user belongs to the mobile phone with the telephone number T-#?

[0323] This means that, in addition to the usual security required for using a certified code for signature purposes, within the code evaluated by the server, i.e., at the time the code arrives (and not just through prior verification, etc.), we also receive the additional security that the user and the exemplary coded input device (here with the telephone number T-#) must be inextricably linked; otherwise, the personal identification code (PIC) will also be evaluated negatively. Containing this information in a single (common) code has the advantage that even if the telephone exchange has already been compromised by an attacker or hacker, it will still not be possible to tamper with this information (assuming careful encryption).

[0324] In addition, when sending the code CODE(2) originally generated by the server to identify the preferred data loop, this code can be supplemented with excess bits to a specific length. The excess bits are intended only as placeholders. The positions belonging to the valid code are distributed among the placeholders (according to a predefined encryption), making speculation more difficult here as well.

[0325] It is evident that the same procedure can also be used to encrypt the payment transaction data together with the loop identification code and then decrypt it again on the server. As a concrete example of the further addition and verification of codes within the preferred data loop(s) (1, or 2, etc.), the application described below uses a mobile phone or even a telephone (on a landline) as an ideal encryption device for creating a digital signature, with the option of using the digital signature via any network and any terminal device (here, for example, on the screen of any client computer CL connected to the Internet) to create a digital signature for a document transmitted via this terminal device (e.g., via a web page). It is obvious that here, too, another mobile phone can be used as the terminal device in addition to a client computer CL. Furthermore, other person-related activities (opening barriers, access control, etc.) can also be controlled using this method.

[0326] The client computer, on which, for example, the web page with the document to be signed is displayed, can also be located in an Internet cafe and can be provided with a special acoustic coupler or an infrared interface, etc., for connecting the mobile phone.

[0327] It is evident that the data for the recognition of the person, or the user identification (PIN number, fingerprint, voice, iris, etc.) can also be pre-evaluated in the mobile phone by a corresponding processor.

[0328] The mobile phone with its secure electronic signature is linked to the website used for the data loop by the preferred method, as already explained for the cashless payment examples. This connection increases security and, above all, identifies the website to which the electronic signature was made. In further development, it is planned to also transmit the document or check values ​​(checksums, totals of data calculated across lines, etc.) via the DS data loop (encrypted if necessary). This means that the certification server, which receives the data for the digital signature from the mobile phone via the DS loop, also simultaneously receives the document on which the signature was made. • Generally speaking, several servers (I, II) can be integrated into the data loop DS, which can exchange data inputs PIC assigned to different devices via the mobile phone and also data (e.g. a document, etc.) between each other via this data loop DS secured by their check code (KODE1, KODE2), whereby the servers can also keep their information regarding the data input by the mobile phone secret using different encryptions (see also Fig. 20 later).

[0329] With the current state-of-the-art procedures, these options and security are not available. While a certain amount of effort is put into proving the authenticity of an electronic signature, the signatory is not immune to web attacks in which, despite the signer's better knowledge, the signature may be applied to a completely different document (or another external server could display the web page under the name of the certification server if it intercepts the request on the internet), especially if a different server is used to display the document than the one used for entering (and verifying) the digital signature.

[0330] Since the data is encrypted to identify the authorization of the signature created with the corresponding data, it can also be passed through the server that actually creates the document to which the user of a client computer (CL) signs the signature. In this case, that is server I.

[0331] In this case, and this is a further advantage of the method, the server I can additionally feed its own identification code KODE (1) into the data loop in order to verify the telephone number T-# of the telephone or mobile phone used to submit the digital signature via the return by the client CL (or via the mobile phone).

[0332] Server I can do this twice: firstly when the user logs into the “WEBX.com” website generated by Server I, where the user establishes a telephone connection to Server I by dialing it directly (to form data loop 1, which can be omitted in the more complex variant of a more complex protocol if necessary); and then, to sign the document, even though the document is located on the “WEBX.com” website generated by Server I, the user establishes a telephone connection to Server II by dialing it directly (to form data loop 2). This means that the (in principle arbitrary) Server I provides the “WEBX.com" on the browser of the user's client computer CL, but the input and verification of the digital signature is carried out via the certification server Server II, which is called directly by the user by telephone for this purpose in order to form the data loop 2, and which is located, for example, in an office or at a notary's office.

[0333] For both variants according to Fig. 13a or after Fig.13b, the client CL has first called up the web page "WEBX.com" generated by server I and is now supposed to sign a document displayed on this web page or on a subpage (such as web page 1, etc.) by submitting the digital signature, whereby this can also be done, for example, on an e-mail to be sent, or the document to be signed can be any electronic document that is sent via such an internet access, regardless of whether the signatory receives the document for signature or whether he sends it as an e-mail.

[0334] If the user of the client computer CL wishes to submit their electronic signature to, in principle, any electronic document X, they first create a data loop (1) by making a telephone call to server I, via which server I can identify the server's telephone call (or, optionally, a data loop 2 via the certification server II). Server I then recognizes the telephone number T-# used by the user (directly via data loop 1 or, optionally, also via data loop 2 or via server II), or, if necessary, directly verifies it by means of a callback following the user's call, via which the user's data loop (1) is then created. Server I then displays the relevant document X on its website ("WEBX.com").

[0335] Immediately before the user wishes to sign (electronically sign) a document X in question, i.e., once any additions to the document that the user may have to make via form input have been made and have been recognized as complete by the server I software, the user uploads the document ready for signature to their PC for archiving and is explicitly prompted to do so on the relevant web page, "WEBX.com." It is advisable for the user to print out the text they are signing before signing so that they can read it carefully again.

[0336] Once the document has been saved on their computer, the user can exit the data loop (1) and click the link on the document (the WB page "WEBX.com") that relates to their digital signature. This link will open WEB page 2 of the certification server (Server II).

[0337] The certification server is located in an office or at a notary and - accepts electronic signatures from the signatory (signatory) together with the document to be signed, with the option of receiving the document via the DS data loop in addition to the direct transmission via the Internet, - checks the received signature with the stored sample, - archives document and signature, - and sends the document to the undersigned as a record, with prior confirmation that they have signed it. The undersigned can later receive the document back from the official body or from a notary by post, with confirmation that they have signed it with their electronic signature. This service can, for example, be handled almost fully automatically by the certification server in the case of a notary, so that the documents are printed in a stack together with a letter sticker for the addressee. Payment for this service is made via the process linked to the certification server's website using a telephone, i.e. via telephone charges, or via the cashless process described above. A further development is described below, in which a chip under the seal (of the notary or an office, etc.) serves as proof of the signature of the document.) which is automatically created by the certification server.

[0338] In an advanced (optional) additional function, the user, i.e. the signatory who uses the digital signature for a specific document, should have absolute certainty that the digital signature has been sent to the correct server (i.e. in this case Server II). This is achieved in an advanced version in such a way that the CODE (2) generated by Server II within the data loop (2) which concerns the certification server (Server II), in addition to the part of the code generated as a random code (for checking the authenticity of the user within data loop 2), also contains an encrypted name code for Server II, via which the mobile phone in question (or possibly another end device such as a telephone or a plug-in in the client computer CL, etc.) recognizes Server II, so that attempts at misuse (with forged web pages) do not have to wait until after the certified and encrypted code from the mobile phone has been sent, orNot only can the server's acknowledgment be recognized by the terminal device (due to the server's incorrect acknowledgment, or one not recognized by the mobile phone or the terminal device, which can also be constantly changed from access to access according to the principle of a transfer code), but it is already clear from the moment contact is made with Server (II) according to the protocol that it is not Server II. The encryption / decryption of the name code of Server II can be carried out using any algorithm, in the simplest case using constants defined partly by the program (stored in the mobile phone's chip card) as transfer codes and partly by variables determined by a secret formula, which change from access to access. The number of access attempts is counted in the mobile phone and the server and can also be compared using control data between the server and the mobile phone, etc.

[0339] The data loop (2) therefore ensures: a) the authenticity of access by Server II within the data loop (2) of the mobile phone as an additional optional security to prevent the user from logging into the wrong website or the wrong server when submitting the digital signature; b) Furthermore, by dialing the telephone number of Server II, a high degree of certainty is already given that only Server II is in the data loop; c) that the mobile phone in question with the relevant telephone number T-# is in the data loop and the digital signature is provided by the user (in compliance with the additional security measures mentioned, such as PIN number, fingerprint, voice profile, etc.), whereby the mobile phone sends this digital signature in encrypted form to the server II within the data loop (2); d) and furthermore, that the security measures mentioned under a)...c) can, if necessary, be combined into a self-contained, encrypted code, whereby the server can detect any manipulation of this code during decryption.

[0340] Thus, the browser of the client computer CL accesses WEB page 2 of the certification server (Server II) via a link secured via the data loop of a telephone connection corresponding to the number of a mobile phone (or other terminal device) T-#.

[0341] When this link is clicked (i.e. calling up WEB page 2 of the certification server), Server I, which displays document X on its WEB page "WEBX.com", sends to Server II, which is supposed to accept / verify a digital signature for document X, the message that a mobile phone (or alternative device) with the telephone number T-# has logged in, so that Server II expects a digital signature for this document X, which is stored on Server I, forming a data loop with the telephone number T-# (by the user).

[0342] This document X, which does not necessarily have to be a text file and can therefore also be an image file, or even a process description generated by Server I, such as the opening of an apartment door using the process by a locksmith, etc., is sent from Server I to Server II as it is to be signed (i.e. including any form entries made by the user), along with the telephone number T-# as the allocation address. Since these may also be confidential documents, Server II is best placed under the access management of a notary, who also has exclusive access and manages system administration, etc. In the event of a contested signature, the notary can then either confirm or deny the accuracy of the process as a witness.The Server II can be connected to a protocol printer, which prints out the signed document and supplements the digital signature with the owner's text. This ensures that the signed document is available to the notary as a hard copy, or can be archived later in the legally prescribed manner (microfilm, etc.) if the paper is destroyed due to space constraints, or the signatory can be given a notary-certified copy. Likewise, additional data media, e.g., on DVD, can be archived as part of regular data backups, etc. A preferred variant is described below, in which the storage of the process (signature + document) is archived on a chip, which can be affixed to a seal (e.g., a notary's).

[0343] All these processes between Server I and the certification server Server II, which the user has triggered by clicking on the link on the WEB page “WEBX.com” of Server I for the purpose of calling up WEB page 2 of the certification server (Server II), naturally run fully automatically on the WEB page using user guidance.

[0344] Whereby the server I prepares the call of the WEB page 2 (by clicking on the link on the WEB page “WEBX.com”) by transmitting the document X together with the telephone number T-# of the user’s mobile phone (as access address) to the server II.

[0345] This means that while WEB page 2 of the certification server Server II is accessed from “WEBX.com” (of Server I), Server II receives the user’s telephone number (mobile phone number T-#) as well as the associated document X from Server I.

[0346] Thus, this process is an application as already stated, namely that different processes running on several servers are coordinated or assigned via corresponding data loops, which are switched via telephone networks (ditto mobile phone networks) by the telephone numbers T-# of the connections (or the users on the client side CL).

[0347] When Web Page 2 is accessed by the certification server (Server II) (via the link on the "WEBX.com" website), the user is prompted to dial the telephone number (of a dial-up network) indicated on the website. This step provides the user with absolute certainty (corresponding to the dial-up network) that when the relevant Web page appears, it is indeed "Web Page 2" of the certification server (Server II). Once the server has verified this using the code it generates and sends (CODE 2), it notifies the user via an acoustic and / or visual display on the user's mobile phone, or possibly also via an SMS. If this confirmation is not received, a procedure is provided on the mobile phone (in further development) whereby, after a certain time period (from which the data loop DS was formed), the mobile phone generates a warning tone (or displays a warning message, etc.) via an acoustic signal.This would mean, assuming the user hasn't dialed the wrong number, that the requested web page isn't being sent from the certification server (Server II). Depending on whether a standard mobile phone or one specially designed for this certification is being used, if the test fails, the mobile phone may be internally locked for the current telephone connection, preventing it from sending a code corresponding to a digital signature. For further security, there is also the option on the server side to generate the code (CODE 2) of the certification server (Server II) externally (e.g. via a DSP circuit) and feed it externally into the server, ditto the checking of the code (here sent via the IT connection to the client CL and received back via the telephone connection T-#) also externally (e.g. via the DSP circuit) and to send the OK / error message to the client (via the telephone connection T-#) also via the external circuit (e.g. via the DSP circuit).If the certification server (Server II) were to be successfully attacked, the user would notice if he were connected to a false server that imitates the WEB page of the certification server (Server II), in order to prevent a false server from receiving secret digital signatures (even if these are encrypted) and possibly also secret documents, regardless of the security measures taken by the server (Server II).

[0348] Clicking the corresponding button on web page 2 initiates a corresponding timeout on the certification server (Server II), during which the certification server (Server II) must assign the mobile phone number via the data loop (2). If this is not the case, an error message is displayed on the web page: “Calling mobile phone number not recognized, please deactivate number suppression or try again.”

[0349] However, if the number of the calling mobile phone is recognized, the following message appears: “The telephone connection was successfully established. The document to be signed will now be displayed and the server will call you back so you can sign digitally.”

[0350] When the server is called back, the server generates the CODE (2) to identify the mobile phone within the data loop (2) of Server II. Optionally (as an additional variant) it also generates the encrypted name code of Server II, so that the mobile phone can check a table to determine whether the server is indeed an authorized server (II) to accept a digital signature. If this is the case, the user receives the following message on the mobile phone display: "You have successfully logged into the server "SERVERNAME" intended for receiving a digital signature, location (e.g. notary office, etc.)."

[0351] If this is not the case (just as with a negative verification result via the data loop by the server's CODE 2), the sending of a valid electronic signature on the mobile phone is prevented again, or the mobile phone can emit a warning beep, so that fake server calls (fake certification server) are immediately recognized by the user. The mobile phone detects the server's lack of positive response by expiring a timeout during which no positive response from the server is detected.

[0352] However, if the user has successfully logged into WEB page 2 of the certification server (Server II), he or she will see the document previously sent from Server I to the certification server (Server II) under the address assigned to the mobile phone number.

[0353] Further training option: After Server I has sent the document to be signed to Server II, the user can now not only view the corresponding file X on Web page 2 of Server II, i.e. on the certification server, exactly as they are supposed to sign it, but can also compare it with the original file X, which they previously downloaded from Server I to their computer (CL), using a comparison program provided by the certification server (Server II). If, for any reason, the user has not previously saved file X, the contents of which they are supposed to sign (via the "WEBX.com" web page generated by Server I), they will be prompted to do so now, after which they can compare the files. The user is also asked to carefully read through the document again before signing (e.g., even in printed form).

[0354] In order for the certification server (Server II) to compare the file (or document) stored under the address of the mobile phone user's telephone number T-# with the file stored on the user's client computer CL, the user must send the file X previously saved from the website "WEBX.com" of Server I on his client computer CL to the certification server (Server II), whereby the certification server (Server II) then carries out the comparison of the files X.

[0355] This comparison is relatively unproblematic with a text file; with image files, in addition to the pixel-by-pixel comparison, a vectorial line evaluation can also be provided, so that if the pixels change slightly due to different resolutions, the comparison only affects the line, e.g. of a handwritten text, etc.

[0356] If the comparison is correct, the user is notified and prompted to submit the electronic signature. If the comparison is incorrect, the relevant text passages or passages in the file are displayed on the screen of the client computer (CL) by the certification server (Server II).

[0357] The user can also terminate the data loop (2) during the comparison of the documents or, for security reasons, choose the option (e.g. entered via the mobile phone) to constantly maintain the data loop (2) for monitoring purposes, whereby the certification server (Server II) then aborts the comparison of the documents if this data loop (2) is interrupted, etc.

[0358] To submit the electronic signature, the data loop (2) is required in any case to identify the correct mobile phone (e.g., also through repeated callbacks, which can be requested by clicking a corresponding button on Web page 2 of Server II). The certification code is transmitted encrypted from the mobile phone to Server II in the usual way, here including the control code KODE (2) generated by Server II to control the data loop (2). To prevent the encryption from being cracked, it is recommended to use a different algorithm for encrypting KODE (2) than for encrypting the digital signature, or to encrypt KODE (2) with the server's name identifier, etc.

[0359] After the user has provided the digital signature, he can download the document signed via the certification server (Server II) to the client computer CL, e.g. with the notary's confirmation that he has placed the signature on the document on that day, on that date (e.g. as a counterpart to a contract, etc.).

[0360] The notary's confirmation can be submitted later on the relevant document with the notary's seal as a certification of the signature. Furthermore, important data can be recorded on an electronically written ROM chip mini-card, which can be glued between the notary's seal and read via a capacitive coupling. Alternatively, the seal can have a window so that contacts can access the chip.

[0361] The data on the chip contains the data of the document or, in the case of extensive image data, only reference data, etc., as well as the evidence of all digital signatures belonging to a document, including the encrypted digital signature of the notary or an authority, etc. contained in the data. The following part of the description will go into more detail about this process and the corresponding device features.

[0362] Since the authenticity of the server is also verified via the data loop (2) by transmitting the encrypted name identifier to the server (optional), and furthermore, the dialed telephone number T-# can only refer to the certification server (Server II), the authenticity of the document issued by the certification server (Server II) is assured. The optional additional encrypted name identifier of the server prevents a user from falling for falsified information and dialing a false telephone number of a falsified certification server.

[0363] In order to prevent careless users from checking the telephone number T-# which may have been automatically read into the mobile phone by the client computer and then dialled by the mobile phone, this automatic function should be handled with caution, or it may be better if the mobile phone dials this number via the telephone number memory (if it is used frequently), or if the user can use the mobile phone's chip card which has been activated for electronic signature to call up this number via the telephone number memory under the designation server number for digital signature for automatic dialling, so that no incorrect number is dialled (which has an important security function). In the following, a further development example is described for which, in addition to the use as a device in connection with the implementation of the inventive

[0364] A procedure for applying for independent protection is used. This involves capturing documents automatically provided with a digital signature, or even records of a process, etc., for a serial process, e.g., in conjunction with a certification computer, and storing them on a chip, which can, if necessary, be affixed under a seal (e.g., a notary or authority) to further certify the signature by the notary or authority.

[0365] The electrically programmable ROM stores the respective document for which the signature was made, or if this would be too extensive, the number of the document deposited with a notary, along with the notarial certificate corresponding to the digital signatures submitted for this document. The digital signature of the notary or an authority is also stored in this ROM chip. This process can also be automated. The chip technology can be an electronically overwrite-protected FLASH memory, an EPROM technology, or any of the technologies commonly used for chip cards, including the interface, which can involve both ohmic and capacitive contact, etc.

[0366] Such a chip can be used not only to verify a signature, but also to verify any event initiated by the user through the submission of a digital signature. The certification computer then creates or prints a corresponding accompanying document. For example, in addition to the aforementioned locking application (for operating an electric lock or similar device), it can also be used to conduct elections. If voting is to be carried out via the certification computer, a plurality of votes are stored on each chip. Furthermore, for security reasons, multiple chips can be written with the same data, etc.

[0367] In a special version and generally applicable for the issuance of certified documents, the Fig. 16 to Fig. 18 and Fig.15, in which the respective chips 30 are printed on a label strip (10 with tear-off perforations 11) which is on a roll (70, Fig. 15), whereby the label strips here replace the carrier material of an otherwise conventional plastic card.

[0368] In addition to the possibility of sticking the chips (30) onto the labels using a small plastic base or a thin ceramic plate as a base, the technical requirements already exist for sticking the chip directly between two paper carriers.

[0369] The roll with the chips (30), which are applied, for example, to a thermal paper strip (10) which has a self-adhesive layer protected by a cover film (80) projecting laterally (as a peel-off edge), is held by a corresponding roll holder (70, 71, Fig.15) and fed to a printing unit (housing 61). This printing device corresponds, for example, to a conventional thermal printer (with printing unit 114 in Fig. 15 and support 58), which additionally uses a contacting head (53, 53b) to contact the chip. If the chip card is designed with capacitively coupled contacting, then it is sufficient to simply pull the chip card (30) applied to the paper strip (10) past the contacts (53) (supported against the support 57). With ohmic contacting, the contacting head (53, 53b) is raised by a lifting magnet (EM) during paper transport and lowered only for contacting. An optical reflection meter 113 scans a code (13, Fig. 16), which corresponds exactly to the contact position of the chip.

[0370] With the thermal printer (which is provided here as an option), a text and a barcode are printed for each chip 30 or for each label that can be separated by perforation (11), which is also printed on the relevant document (40) (cf. Fig. 18). Thus, before sticking the label onto the document, by simply scanning the label and the document with a barcode scanner, or even a digital scanner, etc., it can be precisely compared whether the chip (30) previously written to a printed document via the certification server actually belongs to the document.

[0371] After the paper strip 10 equipped with the chip (30) is affixed to the relevant document 40, the seal (20) of the notary or an authority (which monitors the certification server) is affixed over it, possibly with the cord that permanently connects the document pages (40). However, if the entire document text is stored on the chip (30), this otherwise usual connecting cord for the document is actually unnecessary.

[0372] If the chip can be capacitively contacted, then the seal 20 does not need a window, since the scanning electrodes can contact the chip through the seal 20. If this is not the case, the seal 20 has a corresponding window 22. The marking m printed on the seal 20 and on the carrier strip 10 of the chip 30 (e.g., as a crosshair, etc.) facilitates the precise placement of the seal 20 if a window 22 is provided.

[0373] In Fig.Figure 17 shows a housing suggestion for a chip reader, for example, when the chip has an ohmic contact. The housing is designed like a standard cassette stamp (naturally without a stamp and without a stamp pad). Instead of the stamp, the carrier base (53b) of the contact pins 53 is pressed down when the handle 50 is operated, whereby the document designation (TEXT) can be directly read on a display 54 (optional). The electronics (53b) with the spring-loaded scanning tips and the batteries (not shown) are housed in the handle 50, which can be lifted off by pressing the push buttons k on the side, which push the locking springs f back far enough that they disengage from the stops a, in order to change the battery. Data is transferred to the computer via an RF or an infrared (59) interface, comparable to a wireless mouse or keyboard.The seal then also has a printed mounting frame 21, onto which the contact surface 51 of the "stamp" can be precisely positioned, in order to subsequently contact the contacts upon pressing down. This continues until a built-in piezo beep sounds in the stamp, indicating that the chip data has been successfully read and transferred to the computer. If this beep fails, the data transfer has failed, which will be indicated on a display 54 if present, or otherwise detected on the computer if confirmation is not received (if this has been initialized on the computer). Otherwise, it is advisable to temporarily store the data in the stamp's electronics after reading the chip 30, call up the associated software via the computer's wireless connection, or to check and write the data to the computer (PC, server).

[0374] A further option is to use a generator G for power generation instead of batteries (which are housed in the handle housing 50). This uses the usual design of a cassette stamp housing, in which a generator rotor G rotates when the handle 50 is pushed down via a deflection of the linear movement into a rotational movement on the guide rails of the stamp (instead of the stamp otherwise attached here, with axis a, but without the rotating stamp, being led to the other side between the contact spring pins (56)). The stator of the generator is then attached to the laterally guided linear guide of the handle and is thus moved linearly by the lifting movement of the handle (just as the bearing of the stamp, or in this case the rotor G). Small permanent magnets (cobalt, etc.) are provided as the rotor.Since all the electronics are located in the die anyway, connecting the generator voltage generated in the stator winding, which charges a capacitor, poses no particular problems. The generator voltage is then fed to a capacitor via a standard rectifier circuit with appropriate control and overvoltage protection. This capacitor feeds a switch-mode mini power supply to generate the voltage (for the transmitter and, if necessary, also the receiver of the tapped chip signals).

[0375] A further option concerns an additional mini stamp 100, which is either statically fixed to the handle housing 50 (with ink supply via an external stamp pad) or directly attached to the rotor axis of the generator as a rotary stamp (with built-in stamp pad 101), and can of course also be installed without a generator (when battery operated), and is arranged to the side of the contacts 56 with the purpose of stamping a dot or a small character on the document as confirmation that the function of the chip has been tested again after the seal has been applied.

[0376] Furthermore, in Fig. 15, Fig. 60....guide rollers, 90 support.

[0377] It is evident that instead of a paper on which (or embedded between paper layers) the chips 30 are arranged, a foil, etc. could also be used. Fig.16, the chips are arranged alternately offset (relative to the longitudinal center line of the paper strip 10) so that they are applied symmetrically. However, they could also be placed in the middle of the strip, or plastic or cardboard plates without chips could be used for symmetry, etc. Furthermore, for the Fig. 15, a winding device for winding up the automatically transported labels with the chips automatically written by the certification server should also be provided, whereby the documents are then stacked when printed by the certification server in such a way that the last document is always at the very top of the stack, ie can be removed from the stack in the order in which the label strips with the chips from the (in Fig. 15 take-up reels (no longer shown and connected at the end e) can be torn off one after the other.

[0378] In conjunction with the described device, notaries or even courts can certify documents on an assembly line basis, which can be signed worldwide via the internet. Likewise, authorities can be networked worldwide in this way to provide legally valid information, including the corresponding signature, to another state or authority, notary, etc., on time.

[0379] Certification of electronic signatures for emails sent by the signatory: The same procedure can also be performed with a sent email. The email is first sent to the certification server, where it is stored in a database on the server under the sender's (email) address. The sender accesses the relevant service, e.g., the certification server's website, logs in via the preferred data loop DS on their mobile phone to their client computer CL, enters their (email) address, and thus gains access to their document, which is displayed on the client computer CL. As already explained in principle, they can sign electronically with their mobile phone.After signing the document, the user still has the option of not sending it but deleting it from the certification server. The electronic signature will then be deleted along with it. They can also delete the document from the certification server before signing, or they can submit the document for signature. If the document is not signed and the user leaves the certification server's website for an extended period (timeout), the document will be automatically deleted from the certification server.

[0380] The document can be sent in such a way that the recipient's address is automatically inserted into the certification server's send window in the email header, which can also be corrected by the user. If the email does not reach the recipient after being sent from the certification server, the recipient will be notified accordingly.

[0381] Archiving of the sender's proof: To archive the proof that the user has signed the email via the certification server and sent it to the designated sender, the content of the email and the associated additional key data, such as addressee, sender, date, and signatory, are stored on the certification server, which can also be done in encrypted form.

[0382] Depending on the size of the content, the email key, for example, is stored on the chip in addition to the unencrypted master data, and is then stored in a notary's safe, for example. This key can still be stored encrypted on the certification server for the security of its data, but this is only done in the event of an emergency, such as a chip becoming defective.

[0383] In a special development, a special algorithm is provided on the chip which controls the connection of the chip to the certification server in such a way that it provides the key for decrypting the document stored exclusively in encrypted form on the certification server, but only if at the time when this should be the case: 1) The chip via the interface to the certification server, which is, for example, the contact stamp already explained, which is placed on the chip on a relevant document (in printed form) on the seal, 2) While the stamp is being applied, the sender or the person signing the email must be logged in via their mobile phone to create the digital signature via the DS data loop, sign, and also preselect a mode that is transferred to the certification server via the DS data loop, which initiates the initialization of the file specified for decryption. This file corresponds to the file name recorded on the chip, which is displayed to the user (recipient) on their client computer when the contact stamp is applied to the chip in question (e.g., at a notary's office).

[0384] Only then is the document in question decrypted on the certification server.

[0385] When archiving the chips, the notary, court, etc., can maintain bound files containing the file name, key data, etc., for quick retrieval of a process. For particularly important processes, it may also be useful to store the process on two chips in duplicate, and, if necessary, to store important text of a document directly on each chip, etc.

[0386] The user also has these documents stored on their computer under this name. In the event of a complaint, for example, from a court or an authority that they did not receive a certain email, the notary can then find the chip among these data in their books and, using the method described above, decrypt the file, print it, and send it to the relevant authority (authority), with the certification that this email (time + date) was sent.

[0387] In addition, authorities can also agree on a receipt operation for sending e-mails, whereby the authority's server automatically sends the certification server a receipt for each received e-mail (with details of the exact data, including a serial number if there are multiple e-mails).

[0388] Certification of electronic signatures for faxes sent by the signatory: This is essentially the same as described above for emails, except that when the email is sent to the recipient, the certification server receives a fax number from the sender, from which it sends the email as a fax. Attachments can also be added as image files to the email addressed to the certification server and faxed along when forwarded. These files can also be stored encrypted, etc.

[0389] Or different modes can be used at different costs: - only the control data is stored on the chip, - the sent document is also stored encrypted on the chip.

[0390] This will relieve the postal service of millions of registered letters to authorities, etc.

[0391] It may even be worthwhile for the post office to offer this service. In this case, the client who has sent a fax with a certified signature via email to a certification server set up by the post office or on behalf of the post office at a government agency, receives a document with the chip by registered mail. This document can be read for verification using the preferred stamp contact and an interface to their client computer CL, either independently or via the certification server when logging in via the preferred data loop DS. This document with the affixed chip can also be produced fully automatically at the post office (for example, if the chips are already on a roll with corresponding tear-off cards, onto which the addressee is printed by the certification server using a dot matrix printer). This document serves as proof for the recipient that the letter was sent as an email and forwarded as a fax with a certified signature. A further variant concerns the already mentioned and partially described embodiment for opening a lock, etc., or for other actuation of a triggering process (such as the opening of a barrier of a roadblock, or the release of a person's access via a turnstile, etc.) by the server, but only if at the same time the data loop is closed via the mobile phone and the digital signature is provided.

[0392] In such applications, the operation of the lock or the (general) triggering process of a general device is only released if, on the one hand, the server sends a code (CODE) generated by a random generator via a data connection to the device (e.g. to a lock), e.g. via an Internet data connection, and on the other hand sends this code (CODE) further via the further connection, e.g. via the telephone connection T- to the mobile phone, which, by closing the preferred data loop (acoustic or via infrared, etc.) DS, enters the code (CODE) received from the server into the device (e.g. into an electronic lock), which compares the code (CODE) received from the server via the direct data connection (e.g. an Internet data connection) with the code (CODE) further received from the server via the data loop (which is formed by the coupling via the mobile phone), so to speak as an extended function of the server.

[0393] Even with this variant, it is advisable to encrypt or alienate the code again. This can be achieved, for example, by encrypting the codes (CODE) sent by the server over the different data paths (in this parallel variant, via the mobile phone's telephone network T-# and the lock's IT interface, the "data loop" DS) in such a way that they are unequal. This is because the otherwise identical code (CODE) is alienated when fed into the telephone network T-#, i.e., it is transmitted in encrypted form to the mobile phone, which then decrypts the code. So that, with a correct data loop DS, the same code (CODE) is fed into the lock's unlocking electronics via the data loop as is sent to these electronics from the server directly via the IT connection.The code fed from the server via the direct IT connection is, of course, also encrypted and decrypted in the unlocking electronics. If parameters (e.g., open keys, etc.) used in the unlocking electronics for decrypting the codes need to be updated (also encrypted with a fixed, closed key), it is advisable to do this via the data paths assigned (cross-exchanged). This means that the (open) parameters sent by the server for decrypting the code (KODE) transmitted via the IT connection are sent to the mobile phone via the telephone connection T-#, and the parameters for decrypting the code (KODE) transmitted to the mobile phone via the telephone connection T-# are sent to the mobile phone via the IT connection.Whereby the mobile phone receives the parameters via the data loop DS closed by the user on site (at the lock), the mobile phone receives the parameters via the data loop DS from the unlocking electronics (connected to the IT connection) and the unlocking electronics receives the parameters via the data loop DS from the telephone connection of the mobile phone.

[0394] Only if the decrypted codes received via the separate data paths match, the operation of the lock or the (general) triggering process of a general device takes place directly by the electronics of the lock or the device. The difference between this example and the comparison of the code directly at the server is that, strictly speaking, a parallel connection of the different data paths (server, telephone T-#) takes place between sending (from the server) and comparing the code (at the device or at the lock), whereas in the previous examples, a series connection (via the client, or a telephone or a mobile phone, or possibly two mobile phones) takes place between sending (from the server) and comparing the code (again at the server). However, in both cases, the data loop is closed by the user's end devices (e.g., mobile phone and IT interface, or client computer CL). Likewise, in both cases, the alienation or encryption / decryption of the code(s) transmitted via the data loop can take place. For example, in the case of a series connection, it is advisable to perform the alienation or encryption at the data loop DS (e.g.,in the mobile phone, and / or if necessary also in the client CL) and to carry out the regeneration or decryption of the code transmitted to the server via the data loop DS on the server.

[0395] Fig. 14a illustrates the serial connection via the data loop DS on the client side CL; Fig. 14b, on the other hand, represents the parallel connection. 1 and 2 are the two data paths, one of which is, for example, an internet connection and the other a telephone connection.

[0396] In Fig. 14a the comparison (1=2) of the random code generated by the server and sent via the data loop (1,2) takes place in the server and is, if necessary, distorted at the data loop DS (or at one of the endpoints or terminals via which the data loop DS is closed) for the purpose of encryption and restored at the server for decryption.

[0397] In Fig.14b the comparison (1=2) of the random code generated by the server and sent via the data loop (1,2) takes place at the client (in one of the two terminals forming the data loop DS, whereby in special cases this comparison can also be carried out in both terminals in order to be evaluated in coincidence, etc.), and the code is, if necessary, distorted during transmission by the server for the purpose of encryption and is restored at the data loop DS (i.e. at the relevant terminal(s)) for decryption.

[0398] It is evident that the two procedures according to Fig. 14a and Fig. 14b may be used together if this is beneficial for the application.

[0399] For the variants described above, there are also options for connecting the data loop in parallel instead of in series, e.g. if it can be assumed that the code comparison in a mobile phone can be carried out securely and in a way that cannot be manipulated, and in order to continue to give the user the immediate guarantee (even without a special acknowledgement signal, or regardless of the name coding contained in the code, or the naming of the server) that he is actually communicating with the selected server, etc.

[0400] In both cases (series or parallel connection of the data loop), it is evident that, for example, the telephone connection (T-#), assumed in the examples as a second, secure data path, can also be connected via an internet connection. These procedures are highly advanced and can, if necessary, also be used to request a callback from the server to the user's telephone connection T-# (at the client CL), etc. Regarding the two options of serial or parallel connection of the data loop, it should also be noted that for the purpose of checking the data loop using a code (CODE), this code can in principle also be generated and sent by the mobile phone (or generally by one of the two end devices used to create the data loop) instead of by the server. Depending on the respective option, it is possible to determine whether the code identity is checked at the data loop DS or at the server. The data loop is then, so to speak, created at the server. Likewise, the alienation (encryption) and restoration of the identity (decryption) can be adapted to the requirements, so that the encryption / decryption can take place at the server / client or vice versa (client / server). This means that the possibilities are obtained by applying the duality principle, by Fig. 14a, or Fig. 14b Server and client simply swapped. • A further option which can be used if necessary for the general application of assigning two server processes, where for example a data loop is closed via a first WEB-Page_1 under a certain connection number T-# and when a further WEB-Page_2 (of a further server) is called under this connection number T-# a further data loop is closed in order to synchronise or assign the user data of both WEB-Page_1 and WEB-Page_2 under this connection number T-#, is to introduce time monitoring between the two calls to the WEB-Page_1 and WEB-Page_2 and to no longer enable synchronisation of the user data of WEB-Page_2 after the time monitoring started when the data loop of WEB-Page_1 has been closed, since when the time has elapsed the readiness of WEB-Page_1 (or the server) to transfer the connection number T-# to the server of WEB-Page_2 is no longer possible.their server) no longer exists. Currently, development efforts are underway to establish how a telephone connection, which due to the nature of the Internet is difficult to connect to fixed data paths, which is established using only the data paths of the Internet, can be assigned to a registered telephone number of the caller as well as the called party in terms of connection reliability of the connection numbers between which a connection is established.

[0401] The proposed method is also suitable for this purpose, without requiring any intervention in the fundamental structure of the Internet, which controls the synchronous distribution and reassembly of data blocks transmitted over different data paths. This control mechanism can be considered very reliable. The establishment of the data connection is critical when a server, including a name server, is requested to establish a connection with another server. This means that identifying the subscribers over the existing telephone network by means of a short-term data loop of a accessed web page (in the case of a longer telephone call over the IT network) can also provide security here.

[0402] Of course, it's possible to temporarily insert such a data loop for longer connections. In this case, the data loop is not created manually by the user, but rather, for example, by plug-in software on the client computer, or, in most cases, directly from the provider, in conjunction with appropriate hardware.

[0403] For this purpose, the user, when accessing a web page relating to a telephone service via which he would like to establish a secure Internet telephone connection, calls the service number of the server of this service via a classic dial-up connection (of a standard dial-up network), forming the preferred data loop. As already explained, the telephone number T-# of the caller is thus reliably determined by the server, and the user can receive a message (by announcement or via SMS, etc.) that this is the service being used, which he has accessed, for example, with his client computer CL (or possibly with a mobile phone, etc.). This is because when accessing web pages via a name server, or if a so-called "Trojan horse" is present on the client computer, the access to web pages could possibly be falsified by an attacker.

[0404] The user dials the telephone number via the input window (on the web page) of the service in question, or enters this telephone number with an extension, or by pressing the keys on his telephone, etc., when calling the server by telephone, which he wishes to dial via the Internet.

[0405] The service server then calls the number received from the user via a telephone connection switched by a dialer, which is to be used to make the call via the Internet connection, and informs the user of this, whereupon the called party calls up the relevant web page of the service. It is obvious that this process can also be fully automatic if a special telephone device is available as a terminal. Such a terminal or telephone device then consists of a conventional telephone connection, an Internet telephone of the relevant service and an automatic coupling device (relay, semiconductor switch, etc.) to create the data loop between the conventional telephone connection (without user intervention). After the web page of the relevant service has been called up, the call is made via this coupling device via the server that is connected to this web page orsends a CODE to the called user again via the data loop via one data connection and receives it back via the other for checking, checked whether the correct WEB page was actually called when the WEB page was called.

[0406] It is evident that the procedure can also be carried out if the web page is called manually by the called party, ditto if the data loop is established via a manually established coupling (acoustic coupling, infrared coupling, etc.).

[0407] It is evident that this procedure for the unique coding of a caller, ditto for the unique coding of a called party, using the telephone number of a classic (switched via a dial-up network) telephone connection (T-#) of the caller (ditto possibly also in the reverse direction of the called party), can continue to be used not only to monitor the servers at the end points, which represent the interface of their terminal devices (client server CL, or Internet telephone, etc.) for the caller and the called party, but also for any servers in between, including the house cabling of the connections of the caller and the called party.

[0408] In principle, the preferred data loops (DS) and their check codes can also be used to track the paths of data packets through the Internet without requiring direct access to the network. Instead of dial-up connections, other Internet connections can also be used to create the data loops. Just as in all examples, other connections classified as secure or network connections (including those of the Internet, if special measures are in place) can, in principle, be used instead of dial-up connections (T-#).

[0409] It is also evident that, in addition to or instead of using the telephone number T-# of a mobile phone, an encrypted identity number of the mobile phone can also be included in the data sent by the mobile phone and used to identify the mobile phone in conjunction with the data loop DS used, thus preventing attackers from exploiting it. This means that, in general, the term "telephone connection T-#" refers to the entire combination of security measures implemented by the network provider (for a switched connection) to establish such a connection.

[0410] Fig. Figure 8 illustrates the access for setting current encryption parameters in the mobile phone by the server. For example, if two servers (display server SDIS and anonymous server SANY in Fig. 19 or a general server I and a certification server II, Fig. 13a, Fig.13b) into the data loop DS (telephone network / IT network) closed via the mobile phone, Fig. 8) is included as a serial circuit, then the server feeding the mobile phone directly via the telephone network (of the server chain further networked via the IT network) can store the encryption parameters directly in the mobile phone via the mobile phone's transmit / receive section (S / E), bypassing the other server (VSE). Similarly, the server feeding the data directly via the IT network via the client computer CL (with a coupling interface or interface IF to the mobile phone) can store the encryption parameters in the mobile phone via the coupling interface IF, bypassing the other server (VSS). The encryption units VSS and VSE operate independently of each other, so that the encryption of the server chains (I, II) connected in the data loop can take place completely independently of each other.

[0411] When the data paths are connected in parallel, a single server can also do the opposite by cross-swapping the data paths, as already discussed. Furthermore, different configurations can also be transmitted and controlled by the server using control characters, etc. Example(s) 4.0:

[0412] The examples given below relate to particularly advantageous further developed applications of this method, in which a data loop is formed via the relevant terminal devices (such as an IT client CL and a telephone / mobile phone, etc.) of the networks via an additional network (telephone network, mobile phone network, etc.) in addition to an IT network (or also to an alternative network such as an intranet, etc.), in order to carry out the assignment of the subscriber connections or addresses (of web pages, etc.) of the terminal devices or of different server processes via the connection number (also telephone number T-#) of the relevant additional network using a code (KODE) sent via the data loop DS.

[0413] In this case, two options are provided (which can also be used simultaneously if necessary): the data loop created by linking the client CL, server ←→ end devices (e.g. IT website ←→ telephone via T-# number) ←→ server, is implemented as a series connection, in which a code (CODE) sent by the server via one data path is passed back to the server via the data loop DS created by the client (via its end devices) via the other data path, and the server checks whether the sent code (CODE) defined by the client as a random code matches the code received back. If necessary, using an encrypted alienation / ditto decrypted restoration of the code (CODE).

[0414] Alternatively, if necessary, the data loop DS can also be implemented as a parallel connection, in which a code (KODE) sent by the server via both data paths is verified via the end devices present at the client CL. The verification is performed via a coupling of the data paths (as a data loop DS) in one of the user's end devices (e.g., a mobile phone, etc.). In both cases, series connection and / or parallel connection, tampering (encryption) and recovery (decryption) of the code (KODE) is preferred to prevent manipulation by attackers.

[0415] Fig.21 concerns another preferred application, the purpose of which is to be able to log into a local server, e.g. a company network, using a mobile phone simply and without a password, or with a very simple password (on which the security of the actual access to the protected data depends, but only the initialization of the access procedure).

[0416] In the examples already explained, such an application for an Internet server has already been described, with the purpose that the user enters an exemplary code printed in a magazine, or other printed matter, etc., e.g. as a number, into a web page, into which he logs in using his mobile phone with a corresponding data loop DS, in which a code (KODE) sent out by the server is passed back to the server via the mobile phone, whereby after entering the exemplary number for the first time (taken from the printed matter or magazine), for subsequent calls (or sessions of this web page) the user already receives access to the protected data by exclusively using his mobile phone (identified by its telephone number T-#) by closing the data loop DS (via his mobile phone).

[0417] In Fig.21 describes an example where the same procedure is applied to an internal company server Server I, which is connected to the client or a workstation CL via an intranet ITR or another common network, and furthermore, as already described in the examples mentioned, the conversion of an SMS received from a mobile phone into a serial coupling signal, which is used for the coupling to the client computer CL, takes place, e.g. into an acoustic signal, which is fed into the microphone MIC of the client computer via the handset L of the mobile phone, or into an infrared signal, if an infrared interface is used between the mobile phone and the client computer (or workstation) CL, etc.

[0418] If the user wants to log into the server I via any workstation CL, he can do so without a password or in addition to a password in the following way:

[0419] He enters a name and / or a password assigned to him into the workstation CL, whereupon the server I generates a random code (KODE) and calls the user's mobile phone, or sends an instant SMS to the user's mobile phone via the Internet IT.

[0420] The converter interface of the mobile phone, which converts the SMS into the serial coupling signal, is designed in such a way that the text of the SMS contains, for example, a code word freely selectable by the user (and sent as text by the server), which the user reads as text, e.g. "LOG IN TO COMPANY COMPUTER using the number key 1". Furthermore, the user can see from the sender's telephone number that the company server sent the SMS, whereby the sender's number on the mobile phone can also be assigned to a text such as "COMPANY SERVER", etc. A special operating function, e.g. pressing a specific number key ("1", etc.) on the mobile phone, triggers the transmission of the check code CODE, which is contained in the SMS but not necessarily displayed on the mobile phone and is generated by the server (e.g. as a modulo 2 signal with constant block repetition and synchronization bit).The modulo 2 signal can, as is usual with this method, work with a fixed block length, constant block repetition and a synchronous bit that concludes the block and alternates from block to block, so that by exclusive-or comparison of the serial data signal delayed by the block length with the undelayed one, while simultaneously checking the block length, the components of a correct block information (with error detection or correction by overwriting) can be decoded.

[0421] If the server determines, by comparing the returned code (KODE) after decryption, that it matches the one sent (before encryption), it grants access or considers the user's authorization to be recognized. Since further encryption of the code KODE can be performed on the end devices in the data loop DS, the server's decryption still takes into account all algorithms used to create corresponding alterations to the code.

[0422] As already stated in the examples explained, the possibility of forming a data loop DS can still be secured by entering a PIN number on the mobile phone, and personal data (PIC) of the user can still be sent to the server (I, Fig.21) are sent via the data loop DS (and also encrypted), such as the data for fingerprint recognition (via sensor FI, which is arranged, for example, below a transparent button (see later), or for voice recognition, whereby a voice is then also spoken into the mobile phone when the IT connection is maintained. In this case, an external microphone (as an adapter) can be used as a microphone for the client, for example. This microphone can be attached to the handset T of the mobile phone using a self-adhesive rubber band (which can also be replaced by this adapter so that it can be renewed when its adhesive strength decreases), and can be easily removed again at any time. If the sample text, which is still displayed as an SMS text (from the server), is then spoken into the microphone, this acoustic signal is transmitted in analog or digital form as part of the signal sent from the mobile phone into the data loop DS (acoustic or via infrared, etc.).There are two options: to include the user's personal data (PIC) closed between two blocks of the CODE generated by the server in the data loop, or to nest them (or encrypt them), etc.

[0423] Since the code (KODE) sent by the server via the mobile phone is encrypted and then encrypted again in the mobile phone and in the client computer (thus twice) before it is sent back to the server, the KODE can be displayed with the text of the SMS in a simplified manner. However, if it is to be separated, the mobile phone is modified in such a way that when a server number is recognized (as the sending telephone number of the SMS), it simply separates the code number KODE and does not display it. For example, the KODE can then be introduced by a control character sequence, such as three dots ("...KODE") etc.

[0424] The code is then encrypted at the relevant location by modifying it before transmission (server), or the code received in the terminal device (HANDY, client CL), according to an algorithm that processes constants on the one hand and variables on the other. This algorithm then restores it before comparison. As already explained in the examples given, the parameters (variables) can be modified as required. Depending on the purpose, these parameters can be sent from both sides of the data loop DS (in relation to the different connections ITR and mobile phone connection) to a location for encryption / decryption by the server (I), not only via SMS, but also, if necessary, using the standard mobile phone data format, etc.

[0425] For many applications it is sufficient if the data loop DS closed on the client side via a corresponding terminal device CL (which can, for example, just as easily be a chip card reader networked with a server via Internet IT, etc.) is only closed briefly for the purpose of transferring the encryption parameters, and after the Internet IT connection has checked the telephone number T-# of the telephone connection used by the client (or mobile phone connection, etc.) and has also transferred the current parameters (variables) for encryption / decryption of the data from the server (for the CODE as well as the general data, such as for submitting a digital signature, etc.), the relatively expensive telephone connection (mobile phone connection) can be terminated while the IT connection to the relevant terminal device CL is still maintained.The server can use the IT protocol to check at any time whether it is still the same IT connection that was previously identified by a mobile phone connection T-#, or the telephone connection T-# can also be dialed by the server via the Internet IT telephone in order to save costs.

[0426] It is evident that Server I can also query any database via IT for the verification of fingerprints or voice patterns. In addition to the Fig.21, the testing of the data loop could in principle also be carried out via a local switching system with a corresponding radio network, etc., however, the use of standardised mobile phones is of great advantage, particularly since the proposed extension function, in which an SMS is converted into the serial data signal for coupling to the data loop DS, can also be used for all applications mentioned in the examples already explained, and in principle it makes no difference whether the server I is a local server with a workstation CL, or an Internet server with a client CL.

[0427] An alternative improvement is also proposed for fingerprint recognition: The sensor is located beneath a transparent surface of the mobile phone, which the user has to slowly press with the finger whose print is to be detected. This surface yields springily, with the optics underneath being fixed. When pressed against the transparent surface, the image of the fingerprint changes in sharpness from the outside to the inside. The optics (in relation to the aperture) are dimensioned in such a way that they have a particularly shallow depth of field, so that only the part of the finger directly resting on the surface is in focus, while the part (spatially) behind it is no longer in focus, and even an object brought closer to the optics is not. This dimensioning can be easily achieved by enlarging the image section of the optics by increasing its distance from the recorded image (chip), as is the case, for example, withThis is the case with cameras using extension rings. If the transparent support surface gives way, the part of the object that was previously in focus (because it is now too close to the lens) becomes blurred, and the part that was previously blurred (because it is too far away from the lens) now becomes sharp. The approach of the transparent support surface to the lens is measured. This means that the fingerprint is not only recorded as a surface image by the phone's built-in camera, but also as a three-dimensional image, because the measurements of the surface approaching the lens are constantly being taken. This means that the curvature of the finger is also measured.

[0428] During the evaluation, all snapshots of the fingerprint are assessed and related to each other based on the measured distance of the image (i.e., the scanned path of the recording surface). The advantage of this method is that it is no longer so easy to take a fingerprint from a piece of glass, for example, and then use it for a forgery after computer processing for such input, e.g., using a high-resolution optical adapter on a computer. To Fig.22 to Fig.28:

[0429] The illustrations Fig. 22 to Fig. 28 are not drawn to scale but are shown schematically.

[0430] Fig. 22 concerns another proposal for integrating a cheap lens into the side of a cell phone to scan fingerprints. This involves using the expensive, high-resolution chip of the video or digital camera for scanning, with the development of a simultaneous scanning of the fingerprint's curvature. The image deflection (via mirror), described in more detail below, can also be easily encapsulated in a particularly small module.

[0431] Fig. 23a and Fig. 23b to Fig. 25, concerns proposals for capturing the iris using the mobile phone's high-resolution standard optics and transmitting it to the server for analysis. As already indicated in the previous examples, the user's personal data is encrypted together with the verification code (KODE) of the data loop DS of the wider network (mobile phone network + IT network) in such a way that, even if an attacker illegally feeds it in as valid data, it will be considered invalid by the server if the verification code (KODE) generated by the server (to verify the data loop DS) is incorrect.

[0432] Fig. 24 concerns a variant to indicate the correct distance of the mobile phone from the user's face when taking an iris scan.

[0433] Fig. 25 concerns another variant from Fig. 23a, Fig. 23b.

[0434] Fig. 26 concerns a variant in which the earphones of a mobile phone connection are connected to the mobile phone via radio or via a plug connection and are fixed to a headband (otherwise of a standard design), where 40.....headband with 44 electrical connection of the headphones (41) to an RF receiver with amplifier 45, whereby the antenna can also be inserted in the headband (e.g. between two elastic fabric layers), 43...optional holes.

[0435] Fig. 27 relates to a microphone which is mounted on a tie pin (51) and is connected to t...

Claims

[1] Method for setting up a communication connection and / or logging into a communication connection, which includes the purpose of synchronizing server or data processing processes that receive data from terminal devices assigned to these processes and / or output data to these terminal devices, whereby a) by means of the said method, a first terminal and a second terminal are to be assigned to establish a connection to a message connection belonging to the server or data processing processes, and the two terminals are each networked via their message connections to devices via which the server and / or data processing processes run or are to run, and the data sent by the terminals and / or received by the terminals are or are to be automatically assigned to the processes present in the server or data processing processes via the said synchronization, whereby b) the terminal devices mentioned each have and / or can establish a communication connection, corresponding to the type of connection establishment of a respective terminal device, to a device associated with the respective terminal device and providing the communication connection of the respective terminal device, whereby each terminal device communicates with the device associated with it and the devices providing the communication connection of the terminal devices are networked with one or more servers or an equivalent device or can form or establish such a network, and this networking can concern a server jointly assigned to the terminal devices or can concern servers separately assigned to the terminal devices and networked with one another, or can concern an equivalent device, for all variants hereinafter referred to briefly as "server networking", c) the said network enables the establishment of a communication connection between the terminal devices and the said server network, including the server or data processing processes running on the server(s) or an equivalent device, characterized by , that d) a data loop DS is formed via the terminal devices and their respective associated communication connections, including the aforementioned server network, whereby, for the purpose of establishing a communication connection relating to the aforementioned connection establishment and / or the login process, a data transmission is carried out on the terminal device side directly between the terminal devices and only for the purpose of establishing the communication connection by means of a signal coupling (DS) temporarily carried out directly between the terminal devices, e) within the said network, a CODE is used which contains data of a CONNECTION CODE for selecting or addressing the said server network, whereby the CODE is transmitted from one terminal to another via the signal coupling (DS) which is carried out directly and temporarily on the terminal side between the terminals ( Fig. 1a; Fig. 5; or Fig. 12a), where f) the said CONNECTION CODE is used as a rule for establishing a connection in order to receive the CONNECTION CODE from the other terminal via the direct signal coupling (DS) between the terminals ( Fig. 1a; Fig. 5; or Fig.12a) receives, to establish a connection to a subscriber line designated by the CONNECTION CODE or a subscriber address designated by the CONNECTION CODE via the device providing the communication connection of the terminal and the associated server network, whereby g) at the terminal device which establishes a connection to a subscriber line designated by the CONNECTION CODE or to a subscriber address designated by the CONNECTION CODE via the device providing the communication connection of the terminal device and the associated server network, the established connection is maintained, even if the aforementioned signal coupling (DS) between the terminal devices, which was only temporarily established for setting up the communication connection, no longer exists, h) and / or the data contained in the KODE are used for the synchronization and / or networking of the server processes and / or data processing processes at the aforementioned facilities where these processes take place, whereby h1) data associated with these processes are transmitted via the communication connection existing between the terminal devices and the device(s) providing the communication connection of the terminal devices, including the server network mentioned or an equivalent device, h2) and the data transmitted between the terminal devices and their device(s) providing the communication link between the terminal devices are assigned to the server or data processing processes running via the said server network using the code transmitted during the said establishment of the communication link between the terminal devices, even if the said direct signal coupling (DS) between the terminal devices, which was only temporarily carried out for the purpose of establishing the communication link, no longer exists. [2] Method according to claim 1, characterized by that the respective received CODE is temporarily stored in the terminal devices in order to form the said data loop DS via several, individual connection recordings of the terminal devices and to be able to complete it using the CODE. [3] Method according to claim 1 or 2, characterized bythat the said CODE is integrated into the transmission protocol of the data transmission between the terminal device and the server network. [4] Method according to one of claims 1 to 3, characterized by that the said code, as it is sent from one terminal to the other terminal as a CONNECTION CODE for use in the said server network via the said signal coupling (DS) temporarily carried out between the terminals, contains the device address(es) of the terminals involved in the data loop and is sent to the said server network. [5] Method according to one of claims 1 to 4, characterized by that the CODE or CONNECTION CODE transmitted for the establishment of the communication connection via the signal coupling (DS) temporarily established between the terminals contains further application-specific parameters and / or addresses and / or connection and / or server addresses. [6] Method according to one of claims 1 to 5, carried out on two of said terminals (CL, T-,#), characterized by that the said procedure i. is used to access a web page or to establish or set up an equivalent subscriber or Internet connection or a radio connection, or as referred to below, to access or establish or set up a communication connection on one of the terminals mentioned - hereinafter this terminal is referred to as the first terminal (CL), ii. wherein, for the establishment of said communication connection, said signal coupling (DS) on the terminal side is carried out directly and only temporarily between said first terminal (CL) and the further terminal - hereinafter referred to as second terminal (T-#) - with the CONNECTION CODE and its associated data transmitted on the signal coupling from the first terminal to the second terminal,to establish the communication connection to be established by the CONNECTION CODE using the said server network and to call up a web page on the said first terminal (CL) via this server network or to establish an equivalent subscriber or Internet connection or radio connection or communication connection on the first terminal (CL) with its device providing the communication connection of this terminal, as well as to establish the assignment of the input and / or output data occurring at the terminals in accordance with the communication connection established by the CONNECTION CODE to the server processes running on the server(s) of the said server network. [7] Method according to one of claims 1 to 6, characterized by that at the terminal which receives the said CONNECTION CODE from the other terminal via the direct signal coupling (DS) between the terminals ( Fig. 1a; Fig. 5; or Fig.12a) receives, in order to establish a connection to a subscriber line designated by the CONNECTION CODE or a subscriber address designated by the CONNECTION CODE via the device providing the communication connection of the terminal device and the associated server network, a software, hereinafter referred to as "plug-in", is installed in order to establish a corresponding connection to the said server network using the data contained in the CONNECTION CODE. [8] Method according to one of claims 1 to 7, characterized by that the terminal which receives the said CONNECTION CODE from the other terminal via the direct signal coupling (DS) between the terminals ( Fig. 1a; Fig. 5; or Fig.12a) receives, in order to establish a connection to a subscriber line designated by the CONNECTION CODE or a subscriber address designated by the CONNECTION CODE via the device providing the communication connection of the terminal device and the associated server network, this establishment is carried out by a program installed on a server, whereby this server is networked with the device providing the communication connection of the terminal device. [9] Method according to one of claims 1 to 8, for further use for setting up and / or logging in and / or checking an identification or identity, which includes a) the identification or setting up and / or logging in and / or checking the identity of said terminal devices and their data relating to a secure recognition and / or verification and / or allocation of subscriber connections to communication links and / or subscriber addresses relating to these communication links, in relation to an addressee and / or a sender of data and / or in relation to the authenticity of data and / or the allocation of data and / or the allocation of data to identity data of an identification and / or user identification of a terminal device and / or terminal devices and / or of a log-in process carried out by a terminal device, b) two, or both of the said terminals, each of which has the said possibility of establishing a connection between a respective terminal and a respective communication connection to a device associated with the respective terminal and providing the communication connection of the terminal, in order to be able to establish a communication connection between the terminal and a server from the said server network independently for each terminal, c) whereby the said server network enables the transmission of KODE data generated within the server network and integrated into the data transmission to and / or from the terminal devices, and / or encrypted data - hereinafter referred to as KODE - for the purpose of generating and evaluating the KODE in accordance with the generation, and this KODE generated within the server network or its encrypted KODE data is transmitted to a (1 in Fig.1a) or both (1, 2 in Fig. 1b) terminal device(s) is / are supplied via the server network mentioned, whereby the terminal devices can communicate with the server network mentioned autonomously and independently of each other in terms of time (1 in Fig. 1a, or 1 in Fig. 1b and 2 in Fig. 1b), d) and in this case, in one or both of the respective terminal devices concerned, an intermediate storage of the KODE data or input data obtained from the server network for generating the KODE takes place, and through this intermediate storage the said connection between a respective terminal device and the server network for receiving the KODE data obtained from the server network or its encrypted data can take place independently of the time of the other terminal device in a single connection between a terminal device and the server network in order to be able to use the sum of the individual connections and the data obtained from the server or the server network.to prepare and / or form a data loop for the assignment of the end devices to the server network and the data and KODEs generated by a respective server using the KODE data transmitted from the server network to the relevant end device(s) and temporarily stored in the relevant end device(s), as well as when carrying out an identity check relating to a end device for the stated purpose of identification and / or checking an identity, using the KODE data obtained from the server network and temporarily stored in the end device and / or in the end devices. d1) the CODE data temporarily stored in one of the two terminals - here referred to as the first terminal - or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, second terminal of the two terminals from the first terminal via a direct signal coupling (DS) between the terminals ( Fig. 1a) and is returned via the message connection of the second terminal of the server network mentioned above and by a on the server side (1=2 ? in Fig. 1a) the evaluation device of the KODE is checked for consistency using the comparison data corresponding to the generation of the code in order to identify and / or verify the identity of the said first terminal and / or the identity of the data or data access, and / or d2) the CODE data temporarily stored in one of the two terminals - here referred to as the first terminal - or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, second terminal of the two terminals from the first terminal via a direct signal coupling (DS) between the terminals ( Fig. 1b) and using the comparison data obtained and / or temporarily stored by the second terminal from the server network mentioned above, as well as the generation of the code corresponding to the comparison data by a device on the terminal side (1=2 ? in Fig. 1b) the assessment carried out is checked for consistency in order to identify and / or verify the identity of said first terminal and / or the identity of the data or data access, and / or d3) the CODE data obtained from one of the two terminals - here referred to as the first terminal - through the said server network or server, or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, second terminal of the two terminals via a direct signal coupling (DS) between the terminals ( Fig. 1a) and using the comparison data obtained and / or temporarily stored by the second terminal from the server network mentioned above, as well as the generation of the code corresponding to the comparison data by a device on the terminal side (1=2 ? in Fig. 1b) the assessment carried out is checked for compliance, d 3.1) to identify and / or verify the identity of the data or data access, as obtained by the first terminal device via its data connection to a server or server network, on the terminal device side (1=2 ? in Fig. 1b) to be able to carry out and determine and / or to send further data contained in the CODE transmitted from the first terminal device via the signal coupling to the second terminal device by the second terminal device to a specific address of the server network, d 3.2) and / or by extracting a CONNECTION ADDRESS contained in the CODE transmitted from the first terminal to the second terminal via the direct signal coupling (DS), the second terminal selects or addresses a data connection to the server network corresponding to this CONNECTION ADDRESS in order to send data further contained in the CODE to the location corresponding to the CONNECTION ADDRESS, and / or d4) the CODE data obtained from one of the two terminals - here referred to as the second terminal - through the said server network or server, or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, first terminal of the two terminals via a direct signal coupling (DS) between the terminals ( Fig. 1a) and using the comparison data obtained and / or temporarily stored by the second terminal from the server network mentioned above, as well as the generation of the code corresponding to the comparison data by a device on the terminal side (1=2 ? in Fig. 1b) and / or via the communication connection of the second terminal device of the server network on the server side (1=2 ? in Fig.1a) the assessment carried out is checked for consistency in order to identify and / or verify the identity of said first terminal and / or the identity of the data or data access of data obtained by the first terminal from said server network or server, e) wherein the above-mentioned direct signal coupling (DS) mentioned in features d1, d2, d3 from the said first terminal (A in Fig. 5, or 2 in Fig. 12a) to the said second terminal (B in Fig. 5, or 1 in Fig. 12a) transmitted KODE data e1) identity data to identify the first terminal device and / or to ensure the authenticity of data contained in the first terminal device and / or e2) Data for user identification of the user of the first terminal device and / or e3) data of a digital identification document associated with the first terminal device and / or e4) Payment data of a payment or order process and / or other application data and / or e5) Code data as access security for the operation of an electromechanical process, such as the operation of an electronically secured CODE lock, or the possibility of dispensing fuel at a petrol station, where the CODE data of the CODE lock are supplied by the said second terminal and the said first terminal contains the key data corresponding to these ODE data, e6) Code - data for signing a document displayed on the second terminal and signed with the first terminal, contain or concern, as they have been transferred via the said server network or via the said server to the first terminal for said intermediate storage and / or are generated autonomously in the first terminal in association with the KODE data transferred from the said server or the server network to the first terminal and are used in the said check or assignment, and / or f) wherein the above-mentioned signals, via the direct signal coupling (DS) mentioned in feature d4), are transmitted from the said second terminal (B in Fig. 5, or 1 in Fig. 12a) to the said first terminal (A in Fig. 5, or 2 in Fig. 12a) transmitted KODE data f1) Log-in data for a log-in of a data connection established via the first terminal to a server or a server network or a program running on the server relating to this network or for securing access to a general data access established via the second terminal, contain or concern, as they were transferred via the said server network or via the said server to the second terminal for said intermediate storage and / or are generated independently in the second terminal in association with the KODE data transferred from the said server or the server network to the second terminal and are used in the said check or assignment. g) and the respective transmission of the KODE data used for the said test (1=2 ?) (1 in Fig. 1a, Fig. 1b) and / or comparison data used for testing (2 in SERVER in Fig.1a, or 2 in terminal Fig. 1b) of the CODE to the terminal equipment and / or from the terminal equipment ( Fig. 1a, Fig. 1b) for each terminal device, a dial-up or connection to the server network mentioned can be made independently of the other terminal device via the device belonging to the respective terminal device, h) and / or by simultaneously connecting the end devices to the server network. [10] A method for establishing and / or logging in and / or verifying an identification or identity, which comprises a) the identification or setting up and / or logging in and / or checking the identity of terminal devices and / or their data relating to a secure recognition and / or verification and / or allocation of subscriber connections to communication links and / or subscriber addresses relating to these communication links, in relation to an addressee and / or a sender of data and / or in relation to the authenticity of data and / or the allocation of data and / or the allocation of data to identity data of an identification and / or user identification of a terminal device and / or terminal devices and / or of a log-in process carried out by a terminal device, b) two terminals, each of which has the possibility of a communication connection corresponding to the type of connection established by a respective terminal to a device belonging to the respective terminal which provides the communication connection of the terminal, in order to be able to establish a communication connection between the terminal and a server independently for each terminal, c) and the server communicating with a respective terminal device independently of the other terminal device (SERVER in Fig. 1a or SERVER in Fig. 1b, each with terminal connections 1, 2) can be a server jointly assigned to the terminals or can be servers networked together and separately assigned to the terminals, or can be an equivalent device, for all variants hereinafter referred to as "server networking", d) whereby the said server network enables the transmission of KODE data generated within the server network and integrated into the data transmission to and / or from the terminal devices, and / or encrypted data - hereinafter referred to as KODE - for the purpose of generating and evaluating the KODE in accordance with the generation, and this KODE generated within the server network or its encrypted KODE data is transferred to a (1 in Fig. 1a) or both (1, 2 in Fig. 1b) terminal device(s) is / are supplied via the said server network, whereby the terminal devices can communicate with the said server network autonomously and independently of each other in terms of time, e) and in this case, in one or both of the respective terminal devices concerned, an intermediate storage of the KODE data or input data obtained from the server network for generating the KODE takes place, and through this intermediate storage the said connection between a respective terminal device and the server network for receiving the KODE data obtained from the server network or its encrypted data can be carried out independently of the other terminal device in a single connection between a terminal device and the server network in order to receive the KODE data or its encrypted data obtained from the server network, in order to be able to use the sum of the individual connections and the data received from the server orto prepare and / or form a data loop for the assignment of the end devices to the server network and the data and KODEs generated by a respective server using the KODE data transmitted from the server network to the relevant end device(s) and temporarily stored in the relevant end device(s), as well as when carrying out an identity check relating to a end device for the stated purpose of identification and / or checking an identity, using the KODE data obtained from the server network and temporarily stored in the end device and / or in the end devices. e1) the CODE data temporarily stored in one of the two terminals - here referred to as the first terminal - or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, second terminal of the two terminals from the first terminal via a direct signal coupling (DS) between the terminals ( Fig. 1a) and is returned via the message connection of the second terminal of the server network mentioned above and by a on the server side (1=2 ? in Fig. 1a) the evaluation device of the KODE is checked for consistency using the comparison data corresponding to the generation of the code in order to identify and / or verify the identity of the said first terminal and / or the identity of the data or data access, and / or e2) the CODE data temporarily stored in one of the two terminals - here referred to as the first terminal - or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, second terminal of the two terminals from the first terminal via a direct signal coupling (DS) between the terminals ( Fig. 1b) and using the comparison data obtained and / or temporarily stored by the second terminal from the server network mentioned above, as well as the generation of the code corresponding to the comparison data by a device on the terminal side (1=2 ? in Fig. 1b) the assessment carried out is checked for consistency in order to identify and / or verify the identity of said first terminal and / or the identity of the data or data access, and / or e3) the CODE data obtained from one of the two terminals - here referred to as the first terminal - through the said server network or server, or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, second terminal of the two terminals via a direct signal coupling (DS) between the terminals ( Fig. 1a) and using the comparison data obtained and / or temporarily stored by the second terminal from the server network mentioned above, as well as the generation of the code corresponding to the comparison data by a device on the terminal side (1=2 ? in Fig. 1b) the assessment carried out is checked for compliance, e 3.1) to identify and / or verify the identity of the data or data access, as obtained by the first terminal device via its data connection to a server or server network, on the terminal device side (1=2 ? in Fig. 1b) to be able to carry out and determine and / or to send further data contained in the CODE transmitted from the first terminal device via the signal coupling to the second terminal device by the second terminal device to a specific address of the server network, e 3.2) and / or by extracting a CONNECTION ADDRESS contained in the CODE transmitted from the first terminal to the second terminal via the direct signal coupling (DS), the second terminal selects or addresses a data connection to the server network corresponding to this CONNECTION ADDRESS in order to send data further contained in the CODE to the location corresponding to the CONNECTION ADDRESS, and / or e4) the CODE data obtained from one of the two terminals - here referred to as the second terminal - through the said server network or server, or a CODE modified or formed from these CODE data according to a rule, such as a formula or an algorithm in the terminal, is transmitted to the other, first terminal of the two terminals via a direct signal coupling (DS) between the terminals ( Fig. 1a) and using the comparison data obtained and / or temporarily stored by the second terminal from the server network mentioned above, as well as the generation of the code corresponding to the comparison data by a device on the terminal side (1=2 ? in Fig. 1b) and / or via the communication connection of the second terminal device of the server network on the server side (1=2 ? in Fig.1a) the assessment carried out is checked for consistency in order to identify and / or verify the identity of said first terminal and / or the identity of the data or data access of data obtained by the first terminal from said server network or server, and / or f) wherein the above-mentioned direct signal coupling (DS) mentioned in features e1, e2, e3 from the said first terminal (A in Fig. 5, or 2 in Fig. 12a) to the said second terminal (B in Fig. 5, or 1 in Fig. 12a) transmitted KODE data f1) Identity data to identify the first terminal device and / or to ensure the authenticity of data contained in the first terminal device and / or f2) Data for user identification of the user of the first terminal device and / or f3) data of a digital identification document associated with the first terminal device and / or f4) Payment data of a payment or order process and / or other application data and / or f5) Code data as access security for the operation of an electromechanical process, such as the operation of an electronically secured CODE lock, or the possibility of dispensing fuel at a petrol station, whereby the CODE data of the CODE lock are supplied by the said second terminal and the said first terminal contains the key data corresponding to these ODE data, f6) Code - data for signing a document displayed on the second device and signed with the first device, contain or concern, as they have been transferred via the said server network or via the said server to the first terminal for said intermediate storage and / or are generated autonomously in the first terminal in association with the KODE data transferred from the said server or the server network to the first terminal and are used in the said check or assignment, and / or g) wherein the above-mentioned signals, via the direct signal coupling (DS) mentioned in feature e4), are transmitted from the said second terminal (B in Fig. 5, or 1 in Fig. 12a) to the said first terminal (A in Fig. 5, or 2 in Fig. 12a) transmitted KODE data g1) Contain or relate to log-in data for a log-in of a data connection established via the first terminal to a server or a server network or of a program running on the server relating to this network or for securing access to a general data access established via the second terminal, as they were transferred via the said server network or via the said server to the second terminal for the said intermediate storage and / or are generated independently in the second terminal in association with the KODE data transferred from the said server or the server network to the second terminal and are used in the said check or assignment. h) and the respective transmission of the KODE data used for the said test (1=2 ?) (1 in Fig. 1a, Fig. 1b) and / or comparison data used for testing (2 in SERVER in Fig. 1a, or 2 in terminal Fig. 1b) of the CODE to the terminal equipment and / or from the terminal equipment ( Fig. 1a, Fig. 1b) for each terminal device, a dial-up or connection to the server network mentioned can be made independently of the other terminal device via the device belonging to the respective terminal device, i) and / or by simultaneously connecting the end devices to the server network. [11] Method according to claim 9 or claim 10, characterized by that the evaluation of the KODE data specified in feature d2) and / or d3) and / or d4) of claim 9 or in feature e2) and / or e3) and / or e4) of claim 10, carried out on the terminal side, in that and / or via that terminal (B in Fig. 5, or 1 in Fig. 12a), which receives the KODE data from the other terminal (A in Fig. 5, or 2 in Fig.12a) and / or via a server with which this terminal device is currently connected. [12] according to one of claims 1 to 11, characterized by that the said direct signal coupling for the data transmission of the KODE data and / or further supplementary data between the terminal devices or from one terminal device to another is carried out wirelessly. [13] Method according to one of claims 1 to 12, wherein for said direct signal coupling for data transmission of the KODE data and / or further supplementary data between the two terminals or from one terminal to the other terminal (a) the terminal device transmitting the KODE data has an optical image field for displaying an image, such as a screen or a display or an equivalent arrangement, b) the terminal receiving the KODE data has a digital image recording device, hereinafter referred to as a digital camera, c) and in this case the digital camera of the terminal device receiving the KODE data is used for the said signal coupling between the terminal devices on the receiving side in order to record the KODE data of the transmitting terminal device displayed as image elements in the optical image field and thus to receive the KODE data, whereby the said transmission of the KODE data from one terminal device to the other terminal device is carried out and the signal coupling between the terminal devices is formed. [14] Method according to one of claims 1 to 12, characterized by that a wireless RF data transmission is used for the said direct signal coupling for the data transmission of the KODE data and / or further supplementary data between the two terminal devices or from one terminal device to the other terminal device. [15] Method according to one of claims 1 to 12, characterized bythat infrared data transmission is used for the said direct signal coupling for the data transmission of the KODE data and / or further supplementary data between the two terminal devices or from one terminal device to the other terminal device. [16] Method according to one of claims 1 to 12, characterized by that for the said direct signal coupling for the data transmission of the KODE data and / or further supplementary data between the two terminals or from one terminal to the other terminal, a data transmission by means of acoustic coupling is used, wherein the formation of the direct signal coupling between the terminals is carried out by the KODE data and / or further supplementary data prepared for an acoustic data transmission from the loudspeaker or the earpiece (HK in Fig. 12a) of the terminal sending the KODE data via the signal coupling (2 in Fig. 12a) to the microphone (MIC) of the terminal receiving the CODE data (1 in Fig. 12a) transmitted acoustically and the two terminals are held relative to each other for this purpose ( Fig. 12a, see also Fig. 5 with MIC and HK of mobile phones A and B). [17] Method according to claim 13, characterized by that the representation of the KODE data displayed on the said optical image field, or screen, or display is carried out by the graphic representation of the image corresponding to the KODE data, and thereby the KODE data are transmitted from the terminal device, which displays this data on its optical image field, to the terminal device, which records the image with the camera, by means of the camera recording, whereby the signal coupling between the terminal devices is formed. [18] Method according to claim 13, characterized bythat the KODE data represented by imaging correspond to a corresponding representation by brightness variation or modulation and / or by coloring and are encoded by this representation and transmitted between the terminal devices. [19] Method according to one of claims 1 to 12 or according to claim 14, characterized by that the said direct signal coupling between the terminals relates to a wireless short-distance data transmission whose range is limited to a short distance between the terminals, wherein the formation of the direct signal coupling between the terminals is carried out by keeping the terminals in appropriate proximity to each other according to this short-distance interface. [20] Method according to claim 14 or claim 19, characterized bythat for a wireless short-distance data transmission of the direct signal coupling between the terminal devices, an RF transmitter is used, in which a power measurement of the RF power transmitted via the signal path of the signal coupling is carried out using the data coupling established by the signal coupling for the purpose of a distance measurement and / or distance limitation. [21] Method according to claim 20, characterized by that the RF power obtained by the power measurement mentioned is assigned to a distance measurement in calibration steps. [22] Method according to one of claims 1 to 21, characterized by that the transmitted data, which is secured by the aforementioned KODE or KODE data included in the data transmission, is secured according to a code package using a hash code according to the principle of a digital signature, hereinafter also referred to as a digital signature. [23] Method according to claim 22, characterized by that the digital signature is incorporated both in the security code KODE transmitted via the data loop (DS) and / or via the said signal coupling (DS), as well as in the data transmitted via the data loop (DS), whereby the said code package is formed by the KODE with the associated data. [24] Method according to one of claims 1 to 23, wherein the two terminals via which the direct signal coupling (DS) is carried out are two mobile terminals (A, B Fig. 5) or a mobile terminal (2) and a stationary or stationary used terminal (1 in Fig. 12a). [25] Method according to claim 24 with claim 9 concerning its features d1) or d2) or d4), or with claim 10 concerning its features e1) or e2) or e4), wherein the two terminals mentioned are a mobile terminal (2 in Fig.12a) and a stationary or stationary used terminal (1 in Fig. 12a) is characterized by that the terminal device (2 with earpiece HK or infrared interface IF in Fig. 12a), which sends the mentioned KODE data via the direct signal coupling between the terminals to the other terminal (1 with microphone MIC or infrared interface IF), is a mobile device (mobile phone in Fig. 12a, etc.) and the other terminal is a stationary or stationary used terminal (support surface 1 in Fig. 12a). [26] Method according to one of claims 1 to 25, characterized bythat the two terminal devices mentioned relate to devices which are each used by the same user - for example for a LOG IN process or for identifying a WEB page or for a similar application - wherein the identity check mentioned is carried out in relation to a server process of the server network mentioned which is assigned to the same user, as has been set up or determined by the method mentioned in the server network and this identity check can, depending on the application, relate to checking the identity of the user - such as a LOG IN - or checking or extracting data supplied via a server access - such as the data of a WEB page or checking a similar application which primarily concerns only one user. [27] Method according to one of claims 1 to 25, characterized bythat the two terminal devices mentioned relate to devices which are each used by different users, whereby the identity check mentioned is carried out with regard to the server processes of the server network mentioned which are assigned to the different users, as it has been set up or determined by the method mentioned in the server network and this identity check can, depending on the application, relate to the verification of the identity of the user(s) - such as in a payment or ordering process. [28] Method according to one of claims 1 to 27, characterized by that the said server networking of a device providing the communication connection of a respective terminal device is carried out by integrating one or more networked servers, or that the device providing the communication connection of a respective terminal device is implemented by one or more servers. [29] Method according to one of claims 1 to 28, characterized by that the said CODE used within the network of the data loop (DS) is manipulated on one or more devices located within the network of the data loop (DS) - such as in a terminal device - while the CODE passes through a device in each case according to an algorithm known from the CODE test, wherein this manipulation is taken into account during the said test of the CODE on the server side according to feature d1) or d4) of claim 9 or feature e1) or e4) of claim 10; or on the terminal device side, as stated in feature d2) or d3) or e4) of claim 9 or in feature e2) or e3) or e4) of claim 10 or in claim 11. [30] Method according to one of claims 1 to 29, characterized bythat the KODE data and / or further supplementary data transmitted via the said direct signal coupling of the terminal devices are transmitted via a third device (300, Fig. 3, Fig. 33) and manipulated or further encrypted and / or decrypted in this third-party device according to an algorithm, whereby this manipulation or further encryption is taken into account in the aforementioned verification of the CODE. [31] Method according to one of claims 1 to 30, characterized bythat the CODE transmitted via the network of the data loop (DS) is composed of individual CODE elements or blocks which are distributed to the participating terminals via the network connections of the said server network corresponding to the type of connection established between the terminals and are transmitted to the terminals and / or via the terminals, whereby for decryption and / or encryption and / or manipulation of the CODE, all of these CODE elements or blocks are included in the said test of the CODE. [32] Method according to one of claims 1 to 31, characterized bythat data is transmitted bidirectionally for the purpose of transmitting encryption algorithms via the said server network and / or via the direct signal coupling established between the terminal devices, whereby a respective terminal device involved in the encryption of the data relating to the KODE and / or a third device which may still be in a signal coupling of the terminal devices obtains its algorithms for the encryption and / or a change in the encryption from the network of a respective other terminal device via the signal coupling. [33] Method according to one of claims 1 to 32, characterized by that, via the server network mentioned, all devices and / or terminals integrated into the testing process and / or generation process for transmitting the code via the signal coupling mentioned in the process are supplied with the KODE data for synchronising the process flow and the server processes ( Fig. 1b). [34] Method according to one of claims 1 to 33, characterized by that the said CODE generated within the said server network, to which the CODE data transmitted via the direct signal coupling of the terminal devices belong or contain this CODE as a CODE integrated into the data transmission, is generated according to a random principle. [35] Method according to one of claims 1 to 34, characterized by that several interconnected servers (I, II, III... in Fig.3) which are integrated into the said server network and the said testing procedure, each use their own CODE (Code 1, Code 2, Code n...) or data to create this CODE, whereby this CODE is manipulated and / or checked and / or generated and / or detected by testing with different priorities depending on the application in the servers, and / or on the end device side via the signal coupling of the relevant end devices or directly in the end devices by encryption / decryption in accordance with the application on the servers. [36] Method according to claim 24 with claim 9 concerning its feature d3) or with claim 10 concerning its feature e3), wherein the two terminals mentioned are a mobile terminal and a stationary or stationary used terminal, characterized bythat the terminal which sends the said CODE data to the other terminal via the direct signal coupling between the terminals is a stationary or stationary used terminal and the other terminal is a mobile terminal. [37] Method according to claim 19 with one of claims 30 or 32, characterized by that said third device (300) is integrated into the wireless short-distance interface between the terminals ( Fig. 5). [38] Method according to one of claims 13 or 17 to 18, wherein the CODE data corresponding to a graphic image representation and / or further supplementary data, as shown by the transmitting terminal on its screen or display, are received as corresponding image data by the terminal recording with its camera and thereby receiving the image data, whereby the said signal coupling between the terminals is established, characterized by , that a) that the image data coded according to the representation of a graphic area is forwarded by the image-recording terminal to a server network associated with the decoding of the image data into the CODE data corresponding to the graphic image representation and / or further supplementary data, and / or b) the image data coded according to the representation of a graphic area is decoded by a software (plug-in) installed in the terminal device recording the image and is further used as CODE data and / or further supplementary data obtained by this decoding in accordance with the process, and / or c) the image data coded according to the representation of a graphic area is decoded by software (plug-in) installed in the terminal device recording the image and the CODE data obtained by this decoding are used as the said CONNECTION DATA for establishing a communication connection via the device providing the communication connection of the terminal device. [39] Method according to one of claims 1 to 38, characterized by that the said CODE is linked to and / or contains data of the individual connection participants, such as terminals and / or servers, which correspond to data for processing a business transaction for a cashless payment in which these participants are involved. [40] Method according to one of claims 9 or 10, or according to one of claims 1 to 39, characterized by , ... i. that the method is used to verify the authenticity of a WEB page displayed on a terminal device or an Internet address equivalent to such a WEB page or to verify the authenticity of a data communication established under such an Internet address with the terminal device to a server or the said server network, - hereinafter also referred to as WEB page -, wherein this terminal device corresponds to the first terminal device mentioned in claim 9 feature d3) with d3.1) or in claim 10 in feature e3) with e3.1), i.1) whereby when checking the authenticity of the WEB page on the terminal side ( Fig.1b) in the said second terminal, it is checked whether the CODE contained in the said first terminal in the WEB page displayed on the terminal or in the data of an equivalent Internet address, as transmitted in the said direct signal coupling from the first terminal to the second terminal, also corresponds to the reference data contained in the second terminal, i.2) wherein the second terminal device has obtained this reference data via the individual connection between the terminal device and the server network mentioned in feature d) of claim 9 or feature e) of claim 10 independently of the other terminal device from the server network and has recorded it by means of the said intermediate storage in order to be able to directly carry out the subsequent comparison for checking the said check of the authenticity of the WEB page or equivalent data and / or to be able to generate the CODE data on which the comparison is based from the reference data obtained from the server network; ii. and / or that the method is used for forwarding or linking to a connection address contained as a CONNECTION CODE in a WEB page displayed on a terminal device or in data equivalent to such a WEB page, said terminal device corresponding to the first terminal device mentioned in claim 9 feature d3) with d3.2) or in claim 10 in feature e3) with e3.2), ii.1) whereby, by extracting a CONNECTION ADDRESS contained in the CODE transmitted from the first terminal to the second terminal via the direct signal coupling (DS), the second terminal selects or addresses a data connection to the server network corresponding to this CONNECTION ADDRESS in order to transmit data further contained in the CODE to the location corresponding to the CONNECTION ADDRESS, ii.2) and / or the second terminal device contains and / or generates further application-specific data associated with the CODE and / or has received it from the first terminal device via the immediate direct data connection and transmits this application-specific data to the connection corresponding to the said CONNECTION ADDRESS as the destination. [41] Method according to one of claims 9 or 10, or according to one of claims 1 to 40, characterized by , that i. the method is used for a login process as access security for a WEB page on a terminal device whose access is secured or an Internet address or server communication equivalent to such a WEB page, hereinafter also referred to as WEB page - wherein this terminal device corresponds to the first terminal device mentioned in claim 9 in feature d4) or in claim 10 in feature e4), ii. Wherein, when checking the login process for accessing the WEB page in the first terminal device on the terminal device side ( Fig. 1b) and / or via the server network of the first terminal on the server side ( Fig. 1a) it is checked whether the LOG IN reference data transmitted by the first terminal during the direct signal coupling from the second terminal correspond to the access check to be carried out via the first terminal, iii. wherein the second terminal device has obtained this LOG IN reference data via the individual connection between the terminal device and the server network mentioned in feature d) of claim 9 or feature e) of claim 10, independently of the other terminal device, from the server network and has recorded it by means of the said intermediate storage in order to be able to transfer this LOG IN reference data to the said first terminal device via the said signal coupling during the LOG IN, so that the first terminal device establishes the desired connection and / or the desired access to a function of the first device and / or a connection of the first device. [42] A method according to any one of claims 1 to 41, wherein the method is used to log in a connection establishment, characterized by following procedural steps: i. When a password is used for the first time when logging into a password-protected access control system on a device (server) that has a data connection to a terminal device, ... ii. using the CODE transmitted on the terminal side between two terminals to form the said data loop (DS) and also the said password, an assignment of the CODE transmitted via the data loop (DS) or the data corresponding to the CODE to the password is made by depositing the CODE or the data assigned to the CODE in relation to the said original CODE at the identification point of the server network or the responsible server, iii. whereby for subsequent, further LOG IN login processes, instead of checking the password, a check of the CODE transmitted via the said direct signal coupling (DS) and via the terminal devices and / or data assigned or corresponding to this CODE is carried out, and the CODE or the CODE data and / or data assigned to this CODE is / are transmitted from the said second terminal device to the said first terminal device via the direct signal coupling (DS) of the terminal devices during the LOG IN process. [43] Method according to claim 41 and / or claim 42, characterized by that the CODE used for access security, or data assigned to the CODE, as it is / are stored in relation to an original CODE at the identification point or server, is or can be changed by other devices included in the network. [44] Method according to one of claims 1 to 43, characterized bythat one of the terminal devices mentioned or the terminal devices mentioned use an SMS converter which converts a received SMS into the interface signal as required for establishing the signal coupling between the terminal devices. [45] Method according to one of claims 1 to 44, characterized by that the CODE or data from which this CODE is formed, generated within a network of the said communication links and transmitted via one or more data loops (DS) from the relevant terminals, is used for the allocation and / or addressing and / or establishment of a synchronisation of the functionality of several processes running on a server or on several networked servers, whereby through this synchronisation the server processes allocated to the said terminals are allocated with the data transmitted via the communication links of the terminals. [46] Method according to one of claims 1 to 45, characterized by that the server processes and / or associated data transmissions to be assigned to the terminals are functionally linked to one another via the device providing the communication connection of the terminals involved in the said data loop (DS) directly or via one or more further devices in the way they have been determined by the said transmission of the CODE and / or by the linking of CODEs transmitted in respective individual connections between a terminal and the server network by the process steps carried out to establish the said data loop. [47] Apparatus for carrying out a method according to one of claims 1 to 46, characterized bythat the said immediate direct signal coupling established between the said terminal devices is established as a switchable signal coupling by a device or arrangement provided on the terminal device side - such as a semiconductor switch, or a port addressing, or a relay. [48] Apparatus according to claim 47, wherein said device or arrangement for establishing said switchable signal coupling between the terminals is located in an external device or within a terminal and / or the two terminals involved in said signal coupling are located in a common device. [49] Device according to one of claims 47 or 48, wherein said terminals with their respective interfaces to the devices providing the communication connections of the terminals and for establishing a connection to said server network or a server are accommodated in a terminal which can be used as a telephony device, together with said switchable signal coupling, said interfaces with their communication connections relating to a communication connection for telephony and a communication connection for the Internet, wherein the automatic coupling device establishes said signal coupling between the interface devices. [50] Apparatus for carrying out a method according to claim 30 or 37, characterized by that said third device is incorporated in a wristwatch (300). [51] Apparatus for carrying out a method according to any one of claims 1 to 46 or apparatus according to claim 47 or 48, characterized by that the said terminal devices correspond to a single terminal device, this terminal device then having the connection properties corresponding to the said terminal devices, as specified in the preceding claims, to a device providing the communication connection of the terminal device and the said server network, or to the said server. [52] Device for carrying out a method according to one of claims 1 to 46, wherein a mobile phone or a portable device which has functions comparable to a mobile phone is one of said terminals, characterized bythat this mobile phone or portable device is designed with an RFID - Radio Frequency Identifier Sensor - detector, with the purpose that the user of the mobile phone or portable device can already monitor a purchase made, wherein the payment can then be carried out at the end of the purchase using the mobile phone or portable device by the said method according to one of claims 1 to 46. [53] Method according to one of claims 1 to 46, characterized by that at least one of the terminal devices mentioned uses the data connection of an Internet telephony via the server network mentioned or to a device equivalent to this network. [54] Method according to one of claims 1 to 46 or 53, characterized bythat on the terminal device which sends the KODE data and / or data associated with the KODE as further data to the other terminal device via the aforementioned immediate, direct signal coupling, an encryption is carried out which extracts the KODE data to be sent via the signal coupling from the KODE data received via the aforementioned server network in accordance with the encryption method on the terminal device side of a respective terminal device ( Fig. 1b) and / or on the server side ( Fig. 1a) evaluation of the KODE.

Images