EP1382180A2 - Verfahren zur verarbeitung von daten über das internet - Google Patents

Verfahren zur verarbeitung von daten über das internet

Info

Publication number
EP1382180A2
EP1382180A2 EP02732386A EP02732386A EP1382180A2 EP 1382180 A2 EP1382180 A2 EP 1382180A2 EP 02732386 A EP02732386 A EP 02732386A EP 02732386 A EP02732386 A EP 02732386A EP 1382180 A2 EP1382180 A2 EP 1382180A2
Authority
EP
European Patent Office
Prior art keywords
data
client
server
internet
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02732386A
Other languages
English (en)
French (fr)
Inventor
Holger Schmitt
Michael Klett
Frauke Heistermann
Rolf Henrich
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Digital Logistics GmbH
Original Assignee
Axit GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Axit GmbH filed Critical Axit GmbH
Publication of EP1382180A2 publication Critical patent/EP1382180A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5683—Storage of data provided by user terminals, i.e. reverse caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for processing data via the Internet with at least two clients, a web server and at least one database server for storing and retrieving data, at least one first client storing data on the database server via the Internet using the web server, and at least a second one Client, preferably via the Internet using the web server, which retrieves data.
  • EDI Electronic Data Interchange data
  • a prerequisite for the use of electronic data transmission is agreement on the format of the data to be transmitted, since the recipient of the data must be able to interpret it correctly.
  • Standardized formats, such as EDI are therefore used to design messages.
  • EDI can therefore be defined as a media-free exchange of structured data, which is transferred using the use of electronic data transmission between the applications of the communication partners involved, for example a customer and a service provider.
  • the logistics service providers often provide shippers with many different systems for order transmission and order processing.
  • these systems are manual in nature, i.e. they include loading lists to be filled in manually, waybills, forwarding delivery notes etc.
  • Automated systems are less widespread, in which the data is recorded in separate programs, the data being loaded onto diskettes and / or being transmitted by electronic data transmission, but only very rarely using EDI, and then being further processed. Accordingly, shippers have to handle different processing methods, IT programs, etc., depending on the individual logistics service providers used. This is extremely confusing and often leads to increased effort in order processing and thus to increased costs.
  • the present invention is therefore based on the object of specifying a method for processing data over the Internet of the type mentioned at the outset, in which fast, simple and inexpensive information transmission to and from a service provider, in particular a logistics service provider, is possible.
  • the above object is achieved by the method for processing data via the Internet with the features of patent claim 1.
  • the method in question for processing data via the Internet is designed and developed in such a way that there is an association between the first client and the data stored on the database server and the second client retrieving the stored data, and that the data are assigned to the first Clients by selecting the second client by means of the first client.
  • the selection of the second client by means of the first client could be limited to a set of second clients, in particular to a group of second clients enabled by means of the respective second client.
  • the service provider could thus enable the respective customer to collect data, in particular orders that are intended for him. This would enable the respective service provider to only do business with certain customers or shippers and thus limit its customer base independently.
  • the data could be acquired on at least one website using at least one data mask using the first client.
  • Such a, preferably standardized, data mask also enables smaller customers to enter orders independently without incurring any costs for setting up such a recording measure.
  • the data mask could be individually tailored to the first and / or the second client.
  • the customer and / or the service provider could thus collect or have data tailored to their needs.
  • the data could be transmitted automatically to the second client. This would be particularly conceivable with a regular and high number of orders, whereby the customer receives an interface to the web server and / or the second client and his orders are automatically transmitted to the service provider.
  • the automatic transmission of the order data could then take place directly or via an in-house server of the service provider to the second client and in the order processing of the service provider.
  • An in-house server is to be understood as the server of the LAN.
  • the login and / or the data transmission could be encrypted, preferably by means of SSL encryption - a secure socket layer encryption.
  • the encryption it would also be conceivable for the encryption to be carried out using any other protocol or program.
  • the data of the database on the database server could be mirrored in at least one further database on at least one further database server.
  • this ensures that the data is backed up, and on the other hand, if the system was designed accordingly, improved accessibility of the system would have been achieved.
  • the data from the database could be queried using SQL - Structured Query Language.
  • the data from the database could also be queried using any other query language.
  • the data could be converted in a particularly advantageous manner by means of an EDI server, so that the information can be processed almost without media breaks.
  • a data transmission standard could be, for example, ODETTE - Organization for Data Exchange by Teletransmission in Europe - how it is used, for example, in the European automotive industry.
  • any other data transmission standard could also be used.
  • the data could be transferred using EDIFACT.
  • a prerequisite for data exchange using EDIFACT would be the selection of suitable software for conversion, sequence control and data transfer.
  • a converter in the narrower sense i.e. a format or structure converter
  • tools are usually offered that serve to manage and control the transmission data. The converter and tools then form the converter system.
  • the data could then also be adapted to the software used by the second client.
  • the data, preferably from the EDI server, to the second client could be carried out using a transmission protocol, in particular XML, FTP, OFTP, X.25, X.400 or the like.
  • the data could also first be transmitted from the EDI server to another server, from which it is then transmitted to the second client.
  • This additional server could be the in-house server of the service provider.
  • Such a standard transmission protocol would ensure the universal replaceability for the service provider in a very special way.
  • the data could be output in the form of a form, in particular in the form of an individually customizable form.
  • the data could be processed further using software from the second client, in particular transferred in the order entry. This would eliminate another source of error by not manually processing the data. In addition, it would be particularly easy to change orders that have already been created.
  • the data could also correspond to orders for moving objects. In particular, one should think of forwarding-specific processes, i.e. a customer - a shipper - the data - the order - for the transport of objects - goods - to a logistics service provider - a forwarding agent - and the forwarding agent transports the goods from one place to another ,
  • the objects could be identified by means of identification, preferably a barcode, an identification number or the like. This would have the particular advantage that the objects can be found at any time and that the course of the objects would be traceable.
  • the identification and / or parts of the data and / or the entire data could be output in the form of a label. These labels would then be easily attached to the objects so that no additional errors occur due to the manual transfer of the data.
  • the data originally recorded and stored on the database server could then be supplemented by data which correspond to the movement of the objects.
  • the movement data could be acquired by means of a detection device, preferably a scanner, a mobile radio unit or the like. In the case of a scanner, the data could be collected, which is then transferred to a computer in a special station, transmitted via the Internet and processed further. In the case of a mobile radio unit - GSM, UMTS - a transmission via a "SMS - Short Message Service Center" or via another service unit of a provider of the respective mobile radio provider, for example via SMS or FTP, would be possible.
  • the movement data could then be transferred to the The communication server could prepare the movement data and / or assign the movement data to the relevant data which correspond to an order.
  • the movement data could be called up by means of the first client and / or the second client, in particular by means of the respective in-house server.
  • the web server could be protected by means of a firewall and / or a DMZ - demilitarized zone.
  • the firewall is a combined hardware and software system for protecting a local network - LAN - with a connection to the Internet against attacks from the Internet.
  • the firewall could be supplemented by a DMZ, which could be a host or a small network, which acts as a "neutral zone" between the LAN and the external public network, the Internet.
  • the DMZ therefore protects the web server from direct access by users from outside and is therefore an optional and secure application as a supplement to a firewall.
  • the data could be checked and / or completed automatically by means of at least one further database.
  • This could be done, for example, in the form of an address book functionality, a storage of standard data, such as a match code for recipient addresses, frankings or the like, but also in an automatic assignment of locations to postcodes.
  • the data could also be supplemented by additional data, in particular dangerous goods data. This would make data collection easier again.
  • statistics about the data and / or parts of the data could be called up by means of the first and / or second client. These statistics would make it possible for the customer and / or the service provider to develop, for example, corporate strategies and / or to tailor their services to the needs of the respective customer. It would also be possible for the customer to call up price and / or runtime information, for example.
  • a further service provider preferably an e-shop
  • the data could be transmitted to another client, who in this case could be the shipper of the objects.
  • all and / or parts of the data could be called up by other clients, namely by the customers of the e-shop.
  • the data which are called up by the further clients could be restricted by the second and / or the third client. This ensures that customers can only call up data that is relevant and specific to them.
  • FIG. 1 is a schematic representation of an embodiment of a system structure for use with the inventive method for processing data over the Internet
  • FIG. 2 shows a schematic illustration of a further exemplary embodiment of a system structure for use with the method according to the invention
  • FIG. 3 shows a schematic representation of the data flow of the embodiment of Figs. 2 and Fig. 4 in a schematic representation, the data flow of a further embodiment of the method according to the invention.
  • the method for processing data over the Internet comprises two clients 1, 2, a web server 3 and a database server 4 for storing and retrieving data.
  • a customer namely a shipper
  • the data is then sent via the web server 3 by the logistics service provider, namely a freight forwarder, primarily accessed.
  • the first client 1 there is an assignment between the first client 1, the data stored on the database server 4 and the second client 2 retrieving the stored data.
  • the data of the first client 1 are assigned by the selection of the second client 2 by means of the first client 1 instead.
  • the shipper is part of a group of shippers who primarily store 1 data using a first client and the freight forwarder is part of a group of forwarders who primarily retrieve 2 data using a second client. This means that there are a large number of first and second clients 1, 2, each of which is assigned to a specific shipper or a specific forwarding agent.
  • the selection of the second client 2 by means of the first client 1 is limited to a fixed group of second clients 1 enabled by means of the respective second client 2. This enables the freight forwarder to only do business with certain customers or shippers and thus determine their own customer base.
  • the data is recorded in a data mask by the first client 1 via the Internet on a website.
  • the data mask is individually tailored to the shipping company so that it receives all the information it needs to process the order.
  • the structure of the data mask can also be changed by the forwarding agent using the second client 2, so that the data to be filled in by the shipper can be adapted at any time.
  • tenbankserver 4 and the second client 2 is done using SSL encryption.
  • the data in the database on the database server 4 are mirrored in another database on another database server - not shown here.
  • the data from the database is queried using SQL.
  • the data is converted using an EDI server and the data is transferred using EDIFACT.
  • the data are adapted to the software used by the second client 2, so that the data are taken over directly in the order processing of the forwarding agent.
  • the data is transmitted from the EDI server 5 to the second client 2 by means of FTP - File Transfer Protocol -.
  • the web server 3 is protected by a firewall 7 and a DMZ 8.
  • FIG. 2 shows a further exemplary embodiment of a system structure for use with the method according to the invention.
  • the system structure of the exemplary embodiment shown in FIG. 1 is expanded in such a way that a track-and-trace function can be carried out.
  • the data correspond to orders for moving objects, in this case goods.
  • the goods are identified by means of an identification number which is attached to the goods in the form of an issued label.
  • the movement data are now recorded by the freight forwarder in such a way that the identification number and the respective station at which the goods are located are transmitted to a communication server 9 by means of a cell phone 6 via SMS and by means of the SMS center 10 of the respective cell phone provider.
  • FIG. 3 shows the data flow of the exemplary embodiment in FIG. 2.
  • the order data are transmitted to the second client 2 by means of the system, ie the first client 1, the web server 3, the database server 4 and the EDI server 5.
  • the identification number of the goods is then transmitted to the recipient A of the goods by means of the second client 2. Using this identification number, the recipient A can query movement data and thus the location of the goods from the database server 4 via the Internet.
  • the freight forwarder now transmits the new movement data to the communication server 9, the communication server 9 processing the movement data and assigning it to the order data.
  • FIG. 4 shows the data flow of a further exemplary embodiment of the method according to the invention.
  • An e-shop is interposed between the customer and service provider. Deep-linking thus takes place.
  • the customer who visits the e-shop now transmits data to a third client 11 via the Internet using the first client 1 and via a further web server (not shown here).
  • the and-trace function takes place via the third client 11, namely the e-shop, and the data recorded on the website of the e-shop is now automatically transmitted to a shop operator B, who carries out the inventory management Forwarding-relevant data are transmitted by means of the third client 11 and / or via the shop operator B using the method already described in FIGS. 1 and 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Ein Verfahren zur Verarbeitung von Daten über das Internet mit m indestens zwei Clients (1,2), einem Webserver (3) und mindestens einem Datenbankserver (4) zum Ablegen und Abrufen von Daten, wobei mindestens ein erster Client (1) via Internet mittels des Webservers (3) Daten auf dem Datenbankserver (4) ablegt und wobei mindestens ein zweiter Client (2), vorzugsweise via Internet mittels des Webservers (3), die Daten abruft, ist im Hinblick auf eine schnelle, einfache und kostengünstige Informationsübermittlung an einen und von einem Dienstleister, insbesondere einem Logistikdienstleister, derart ausgebildet, dass eine Zuordnung zwischen dem ersten Client (1) und den auf dem Datenbankserver (4) abgelegten Daten sowie dem zweiten die abgelegten Daten abrufenden Cliens (2) erfolgt und dass die Zuordnung der Daten des ersten Clients (1) durch die Auswahl des zweiten Clients (2) mittels des ersten Clients (1) erfolgt.

Description

.Verfahren zur Verarbeitung von Daten über das Internet"
Die Erfindung betrifft ein Verfahren zur Verarbeitung von Daten über das Internet mit mindestens zwei Clients, einem Webserver und mindestens einem Datenbankserver zum Ablegen und Abrufen von Daten, wobei mindestens ein erster Client via Internet mittels des Webservers Daten auf dem Datenbankserver ablegt und wobei mindestens ein zweiter Client, vorzugsweise via Internet mittels des Webservers, die Daten abruft.
Verfahren zur Verarbeitung von Daten über das Internet mit mindestens zwei Clients sind seit längerem bekannt. Bspw. übertragen Großkunden über das Internet mittels elektronischer Datenübertragung, meist mittels EDI - Electronic Data Interchange- Daten, die Aufträge und Auftragsabwicklungen betreffen, direkt an einen Dienstleister. Voraussetzung für den Einsatz elektronischer Datenübertragung ist die Einigung über das Format der zu übertragenden Daten, da der Empfänger der Daten befähigt sein muss, diese korrekt zu interpretieren. Zur Gestaltung von Nachrichten bedient man sich daher standardisierter Formate, wie beispielsweise EDI. Daher lässt sich EDI als medienbruchfreier Austausch strukturierter Daten definieren, welche unter Verwendung elektronischer Datenübertragung zwischen Anwendungen beteiligter Kommunikationspartner, bspw. einem Kunden und einem Dienstleister, transferiert werden.
Für kleinere Kunden lohnt sich eine Investition in EDI allerdings nicht, da sich der finanzielle Aufwand zur Einführung von hard- und softwaremäßigen Lösungen in Relation zu den getätigten Aufträgen nicht rechnet. Demnach erfolgt die Übermittlung vieler kleiner Aufträge, für die aber ebenfalls die gleichen engen Zeitvorgaben wie für Großaufträge bestehen, oftmals in sehr schlechter Qualität. Im Allgemeinen erfolgt die Übermittlung dann nämlich handgeschrieben und per Fax, was dazu führt, dass unter Umständen wichtige Informationen fehlen oder aber auch dass Fehler bei der manuellen Eingabe der Daten dadurch passieren, dass die handgeschriebenen Daten nicht leserlich sind. Dies resultiert in einem Fehler anfälligen, qualitätsgefährden- den Prozess. Neben den durch die manuelle Eingabe entstehenden erhöhten Erfassungskosten entstehen zusätzlich durch die notwendigen Korrekturen, um Fehler zu beheben, hohe Folgekosten. Alles in allem führt dies zu einer hohen Kundenunzufriedenheit.
Diese Problematik tritt vor allem in der Logistikbranche bei Verladern - den Kunden - und Logistikdienstleistern - den Dienstleistern - auf. Den Verladern werden durch die Logistikdienstleister oft viele verschiedene Systeme zur Auftragsübermittlung und zur Auftragsabwicklung zur Verfügung gestellt. Im Allgemeinen sind diese Systeme manueller Natur, d.h., dass manuell auszufüllende Ladelisten, Frachtbriefe, Speditionsübergabescheine etc. umfasst sind. Weniger verbreitet sind automatisierte Systeme, bei denen die Erfassung der Daten in separaten Programmen erfolgt, wobei die Daten auf Disketten geladen werden und/oder mittels elektronischer Datenübertragung, aber nur sehr selten mittels EDI, übertragen und dann weiterverarbeitet werden. Demnach müssen Verlader abhängig von den einzelnen eingesetzten Logistikdienstleistern unterschiedliche Verarbeitungswege, EDV-Programme etc. handhaben. Dies ist äußerst unübersichtlich und führt häufig zu einem erhöhten Aufwand bei der Auftragsbearbeitung und damit zu erhöhten Kosten.
Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Verarbeitung von Daten über das Internet der eingangs genannten Art anzugeben, bei dem eine schnelle, einfache und kostengünstige Informationsübermittlung an einen und von einem Dienstleister, insbesondere einem Logistikdienstleister, möglich ist.
Erfindungsgemäß wird die voranstehende Aufgabe durch das Verfahren zur Verarbeitung von Daten über das Internet mit den Merkmalen des Patentanspruchs 1 gelöst. Danach ist das in Rede stehende Verfahren zur Verarbeitung von Daten über das Internet derart ausgestaltet und weitergebildet, dass eine Zuordnung zwischen dem ersten Client und den auf dem Datenbankserver abgelegten Daten sowie dem zweiten die abgelegten Daten abrufenden Client erfolgt und dass die Zuordnung der Daten des ersten Clients durch die Auswahl des zweiten Clients mittels des ersten Clients erfolgt.
In erfindungsgemäßer Weise ist erkannt worden, dass man in Abkehr zu der bisherigen Praxis Verfahren zur Verarbeitung von Daten über das Internet nicht allein nur für Großkunden realisieren muss, sondern dass es auch kleineren Kunden möglich sein muss Daten, insbesondere Auftragsdaten, standardisiert elektronisch zu übertragen. Die Übertragung von Daten über das Internet, wobei eine Zuordnung zwischen den jeweiligen Clients erfolgt, ermöglicht es auch kleineren Kunden, die nur einen allgemein üblichen Internetbrowser und -Zugang zur Verfügung haben, die Vorteile der elektronischen Datenübermittlung zu nutzen. Durch diese Art der Datenübertragung werden zudem Fehlerquellen weitestgehend minimiert, die Qualität des Prozesses wird damit gesichert und eine schnelle sowie einfache Informationsübermittlung ist ermöglicht. Dies führt zu niedrigen und allein transaktionsbezogenen Kosten.
Im Hinblick auf eine besonders große Unabhängigkeit des Dienstleisters könnte die Auswahl des zweiten Client mittels des ersten Clients auf festgelegte, insbesondere auf eine mittels des jeweiligen zweiten Clients freigeschaltete, Gruppe von zweiten Clients beschränkt sein. Der Dienstleister könnte so dem jeweiligen Kunden ermöglichen, Daten, insbesondere Aufträge, die für ihn bestimmt sind, zu erfassen. Dies würde dem jeweiligen Dienstleister ermöglichen, nur mit bestimmten Kunden bzw. Verladern Geschäfte abzuwickeln und so seinen Kundenkreis selbständig zu beschränken.
Hinsichtlich einer besonders einfachen Erfassung der Daten könnten die Daten auf mindestens einer Webseite mittels mindestens einer Datenmaske mittels des ersten Clients erfasst werden. Eine solche, vorzugsweise standardisierte, Datenmaske ermöglicht es auch kleineren Kunden selbständig Aufträge zu erfassen, ohne dass dabei Kosten für den Aufbau einer solchen Erfassungsmaßnahme entstehen.
Im Rahmen einer individuellen Datenerfassung könnte die Datenmaske individuell auf den ersten und/oder den zweiten Client abgestimmt werden. Der Kunde und/oder der Dienstleister könnte somit besonders auf ihre Bedürfnisse abgestimmte Daten erfassen bzw. erfassen lassen.
Es wäre von weiterem Vorteil, wenn der Aufbau der Datenmaske mittels des jeweiligen Client verändert werden könnte. Dies würde es ermöglichen, dass die Daten- maske und somit bspw. die Auftragsvorlage einfach und schnell auf jeweilige Veränderungen beim Kunden und/oder Dienstleister abgestimmt wird.
Hinsichtlich einer besonders komfortablen Ausgestaltung könnte die Übertragung der Daten an den zweiten Client automatisch erfolgen. Dies wäre besonders bei regelmäßiger und hoher Anzahl von Aufträgen denkbar, wobei der Kunde eine Schnittstelle zum Webserver und/oder dem zweiten Client erhält und seine Aufträge automatisiert an den Dienstleister übermittelt werden. Die automatische Übersendung der Auftragsdaten könnte dann direkt bzw. über einen Inhouseserver des Dienstleisters an den zweiten Client und in die Auftragsabwicklung des Dienstleisters erfolgen. Unter einem Inhouseserver ist hierbei der Server des LANs zu verstehen.
Im Hinblick auf eine besonders sichere Ausführung könnten der Login und/oder die Datenübertragung verschlüsselt, vorzugsweise mittels einer SSL-Verschlüsselung - einer Secure-Socket-Layer-Verschlüsselung- erfolgen. Es wäre allerdings auch denkbar, dass die Verschlüsselung mittels irgendeines anderen Protokolls oder Programms erfolgt.
Im Rahmen einer ganz besonders bevorzugten Ausführung könnten die Daten der Datenbank auf dem Datenbankserver in mindestens eine weitere Datenbank auf mindestens einem weiteren Datenbankserver gespiegelt werden. Dadurch ist zum einen eine Sicherung der Daten erreicht, zum anderen wäre bei einer entsprechenden Ausgestaltung des Systems eine verbesserte Erreichbarkeit des Systems erlangt.
Hinsichtlich einer besonders einfachen Ausgestaltung könnte die Abfrage der Daten aus der Datenbank mittels SQL - Structured Query Language - erfolgen. Die Abfrage der Daten aus der der Datenbank könnte allerdings auch mittels irgendeiner anderen Abfragesprache erfolgen.
Die Daten könnten in besonders vorteilhafter Weise mittels eines EDI-Servers konvertiert werden, so dass eine nahezu medienbruchlose Weiterverarbeitung der Informationen erfolgen kann. Ein solcher Datenübertragungsstandard könnte bspw. ODETTE - Organization for Data Exchange by Teletransmission in Europe - sein, wie er bspw. in der europäischen Automobilindustrie benutzt wird. Es könnte allerdings auch jeder andere Datenübertragungsstandart verwendet werden.
Um eine uneingeschränkte Kommunikation, die noch dazu branchenunabhängig ist, zu gewährleisten, könnte die Übertragung der Daten mittels EDIFACT erfolgen. Voraussetzung für den Datenaustausch mittels EDIFACT wäre die Auswahl einer geeigneten Software für Konvertierung, Ablaufsteuerung und Datenübertragung. Mit einem Konverter im engeren Sinne, d.h. einem Format- bzw. Strukturumsetzer, werden meistens zusätzlich Tools angeboten, die der Verwaltung und Steuerung der Übertragungsdaten dienen. Konverter und Tools bilden dann das Konvertersystem. Mittels des EDI-Servers könnten dann zusätzlich die Daten an die vom zweiten Client verwendete Software angepasst werden.
Die Übermittlung der Daten, vorzugsweise vom EDI-Server, zum zweiten Client könnte mittels eines Übertragungsprotokolls, insbesondere XML, FTP, OFTP, X.25, X.400 oder dgl., erfolgen. Die Daten könnten allerdings auch vom EDI-Server zunächst zu einem weiteren Server übermittelt werden, von dem sie dann zu dem zweiten Client übermittelt werden. Bei diesem weiteren Server könnte es sich dabei um den Inhouseserver des Dienstleisters handeln. Ein solches standardmäßiges Übertragungsprotokoll würde in ganz besonderer Weise die universelle Ersetzbarkeit für den Dienstleister gewährleisten.
Im Rahmen einer besonders praktischen Ausführung könnten die Daten in Form eines Formulars, insbesondere in Form eines individuell gestaltbaren Formulars ausgegeben werden. Insbesondere wäre es dann möglich Auftragsbestätigungen, Rechnungen und dgl. besonders einfach und ohne zusätzlichen Aufwand zu erstellen.
Die Daten könnten mittels einer Software des zweiten Clients weiterbearbeitet werden, insbesondere in dessen Auftragserfassung überführt werden. Dies würde eine weitere Fehlerquelle dadurch ausschalten, dass keine manuelle Weiterverarbeitung der Daten erfolgt. Zusätzlich wäre somit die Änderung bereits erstellter Aufträge besonders einfach möglich. Die Daten könnten zudem mit Aufträgen zur Bewegung von Objekten korrespondieren. Insbesondere ist dabei an speditionsspezifische Vorgänge zu denken, d.h., dass ein Kunde - ein Verlader - die Daten - den Auftrag - zum Transport von Objekten - Waren - an einen Logistikdienstleister - eine Spedition - gibt und die Spedition die Ware von einem Ort zum anderen transportiert.
Hinsichtlich einer besonders praktischen Ausgestaltung könnten die Objekte mittels einer Kennzeichnung, vorzugsweise eines Barcodes, einer Kennnummer oder dgl., gekennzeichnet werden. Dies hätte den besonderen Vorteil, dass die Objekte jederzeit auffindbar sind und dass der Verlauf der Objekte nachvollziehbar wäre.
Im Rahmen einer abermals sehr praktischen Ausgestaltung könnte die Kennzeichnung und/oder Teile der Daten und/oder die gesamten Daten in Form eines Labels ausgegeben werden. Diese Labels wären dann ganz einfach an den Objekten anbringbar, so dass keine zusätzlichen Fehler durch das manuelle Umtragen der Daten erfolgen.
Die ursprünglich erfassten und auf dem Datenbankserver abgelegten Daten könnten dann durch Daten, die mit der Bewegung der Objekte korrespondieren, ergänzt werden. Die Bewegungsdaten könnten dabei mittels einer Erfassungseinrichtung, vorzugsweise einem Scanner, einer Mobilfunkeinheit oder dgl., erfasst werden. Bei einem Scanner wäre eine Sammlung der Daten möglich, die dann in einer speziellen Station auf einen Computer übermittelt, mittels Internet übertragen und weiterverarbeitet werden. Bei einer Mobilfunkeinheit - GSM, UMTS - wäre eine Übertragung über ein „SMS- - Short Message Service - Center" oder über eine andere Serviceeinheit eines Providers der jeweiligen Mobilfunkanbieter, z.B. über SMS oder FTP möglich. Die Bewegungsdaten könnten sodann mittels eines Kommunikationsservers auf den Datenbankserver abgelegt werden. Der Kommunikationsserver könnte dabei die Bewegungsdaten aufbereiten und/oder die Bewegungsdaten den betreffenden Daten, die mit einem Auftrag korrespondieren, zuordnen.
Hinsichtlich einer komfortablen Track-and-Trace Funktion könnten die Bewegungsdaten mittels des ersten Clients und/oder des zweiten Clients, insbesondere mittels des jeweiligen Inhouseservers, abgerufen werden. Im Hinblick auf die Sicherheit des Systems könnte der Webserver mittels einer Firewall und/oder einer DMZ - Demilitarized Zone - geschützt werden. Die Firewall ist ein kombiniertes Hard- und Softwaresystem zum Schutz eines lokalen Netzwerks - LAN - mit Anbindung an das Internet vor Angriffen aus dem Internet. Für eine größtmögliche Sicherheit könnte die Firewall durch eine DMZ ergänzt werden, die ein Host oder ein kleines Netzwerk sein könnte, welches als eine „neutrale Zone" zwischen dem LAN und dem äußeren öffentlichen Netzwerk, dem Internet, steht. Die DMZ schützt also den Webserver vor direktem Zugriff durch Nutzer von außen und ist somit eine optionale und sichere Anwendung als Ergänzung einer Firewall.
Im Hinblick auf einen besonders großen Bedienungskomfort könnte eine automatische Überprüfung und/oder Vervollständigung der Daten mittels mindestens einer weiteren Datenbank erfolgen. Dies könnte bspw. in Form einer Adressbuchfunktionalität, eines Hinterlegens von Standarddaten, wie bspw. eines Matchcodes für Empfängeradressen, Frankaturen oder dgl., aber auch in einer automatischen Zuordnung von Orten zu Postleitzahlen geschehen.
Die Daten könnten zudem durch Zusatzdaten, insbesondere durch Gefahrgutdaten, ergänzt werden. Dies würde die Erfassung von Daten abermals erleichtern.
Im Hinblick auf eine besonders komfortable Ausgestaltung könnten mittels des ersten und/oder zweiten Clients Statistiken über die Daten und/oder Teile der Daten abgerufen werden. Durch diese Statistiken wäre es dem Kunden und/oder dem Dienstleister möglich, bspw. Unternehmensstrategien zu entwickeln und/oder seine Dienstleistungen speziell auf die Bedürfnisse des jeweiligen Kunden auszurichten. Auch wäre es dem Kunden möglich, bspw. Preis- und/oder Laufzeitinformationen abzurufen.
Es könnte allerdings auch ein weiterer Dienstleister, vorzugsweise ein e-Shop, mittels eines dritten Clients zwischen Kunden und Dienstleister stehen, so dass die gesamten oder Teile der in die Datenmaske eingegebenen Daten an einen dritten Client via Internet mittels eines weiteren Webservers übermittelt werden. Damit wäre es für einen e-Shop möglich, direkt an einen Dienstleister in diesem Fall einen Lo- gistikdienstleister angebunden zu werden und die Vorteile der elektronischen Datenübertragung zu nutzen, ohne dass zusätzlicher Erfassungsaufwand oder zusätzliche Fehler durch eine manuelle Erfassung entstehen. Zusätzlich könnten die Daten an einen weiteren Client übermittelt werden, der in diesem Fall der Verlader der Objekte sein könnte.
Im Rahmen einer Track-and-Trace Funktion könnten die gesamten und/oder Teile der Daten durch weitere Clients abgerufen werden, nämlich durch die Kunden des e- Shops. Im Hinblick auf eine besonders gute Datensicherheit könnten die Daten, die durch die weitere Clients abgerufen werden, durch den zweiten und/oder den dritten Client beschränkt werden. Somit ist gewährleistet, dass Kunden nur für sie relevante und bestimmte Daten abrufen können.
Es gibt nun verschiedene Möglichkeiten, die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten und weiterzubilden. Dazu ist einerseits auf die dem Patentanspruch 1 nachgeordneten Patentansprüche und andererseits auf die nachfolgende Erläuterung bevorzugter Ausführungsbeispiele des erfindungsgemäßen Verfahrens zur Verarbeitung von Daten über das Internet anhand der Zeichnung zu verweisen. In Verbindung mit der Erläuterung der bevorzugten Ausführungsbeispiele des erfindungsgemäßen Verfahrens anhand der Zeichnung werden auch im Allgemeinen bevorzugte Ausgestaltungen und Weiterbildungen der Lehre erläutert. In der Zeichnung zeigt die
Fig. 1 in einer schematischen Darstellung, ein Ausführungsbeispiel einer Systemstruktur zur Verwendung mit dem erfindungsgemäßen Verfahren zur Verarbeitung von Daten über das Internet,
Fig. 2 in einer schematischen Darstellung, ein weiteres Ausführungsbeispiel einer Systemstruktur zur Verwendung mit dem erfindungsgemäßen Verfahren,
Fig. 3 in einer schematischen Darstellung, den Datenfluss des Ausführungsbeispiels der Fig. 2 und Fig. 4 in einer schematischen Darstellung, den Datenfluss eines weiteren Ausführungsbeispiels des erfindungsgemäßen Verfahrens.
Das Verfahren zur Verarbeitung von Daten über das Internet umfasst, wie in Fig. 1 in einer Systemstruktur zur Verwendung mit dem Verfahren gezeigt, zwei Clients 1 , 2, einen Webserver 3 und einen Datenbankserver 4 zum Ablegen und Abrufen von Daten. Mittels des ersten Clients 1 legt ein Kunde, nämlich ein Verlader, Daten via Internet unter Verwendung des Webservers 3 auf dem Datenbankserver 4 ab und mittels des zweiten Clients 2 werden dann die Daten via Internet mittels des Webservers 3 durch den Logistikdienstleister, nämlich eine Spedition, vornehmlich abgerufen.
In erfindungsgemäßer Weise erfolgt eine Zuordnung zwischen dem ersten Client 1 , den auf dem Datenbankserver 4 abgelegten Daten und dem zweiten die abgelegten Daten abrufenden Client 2. Zudem findet eine Zuordnung der Daten des ersten Clients 1 durch die Auswahl des zweiten Clients 2 mittels des ersten Clients 1 statt. Dabei ist der Verlader ein Teil einer Gruppe von Verladern, die mittels jeweils eines ersten Clients 1 Daten vornehmlich ablegen und ist die Spedition ein Teil einer Gruppe von Speditionen, die mittels jeweils eines zweiten Clients 2 Daten vornehmlich abrufen. Dies bedeutet, dass es eine Vielzahl von ersten und zweiten Clients 1 , 2 gibt, die jeweils einem bestimmten Verlader bzw. einer bestimmten Spedition zugeordnet sind.
Die Auswahl des zweiten Clients 2 mittels des ersten Clients 1 ist auf eine feste mittels des jeweiligen zweiten Clients 2 freigeschaltete Gruppe von zweiten Clients 1 beschränkt. Dies ermöglicht der Spedition, nur mit bestimmten Kunden bzw. Verladern Geschäfte abzuwickeln und so ihren Kundenkreis selbst zu bestimmen. Die Daten werden mittels des ersten Clients 1 via Internet auf einer Website in einer Datenmaske erfasst. Die Datenmaske ist hierbei individuell auf die Spedition abgestimmt, so dass sie alle von ihr zur Auftragsabwicklung benötigten Informationen erhält. Der Aufbau der Datenmaske ist zudem mittels des zweiten Clients 2 durch die Spedition veränderbar, so dass die vom Verlader auszufüllenden Daten jederzeit an- gepasst werden können. Der Login des ersten Clients 1 , die Datenübertragung vom ersten Client 1 zum Webserver 3, die Datenübertragung vom Webserver 3 zum Da- tenbankserver 4 sowie zum zweiten Client 2 erfolgt mittels einer SSL-Verschlüsselung.
Die Daten in der Datenbank auf dem Datenbankserver 4 sind in eine weitere Datenbank auf einem weiteren Datenbankserver - hier nicht dargestellt - gespiegelt. Die Abfrage der Daten aus der Datenbank erfolgt mittels SQL.
Die Daten werden mittels eines EDI-Servers konvertiert und die Übertragung der Daten erfolgt mittels EDIFACT. Mittels des EDI-Servers 5 werden die Daten an die vom zweiten Client 2 verwendete Software angepasst, so dass die Daten direkt in die Auftragsabwicklung der Spedition übernommen werden. Die Übermittlung der Daten vom EDI-Server 5 zum zweiten Client 2 erfolgt mittels FTP - File Transfer Protocol -.
Zur Gewährleistung der Sicherheit der Daten ist der Webserver 3 mittels einer Firewall 7 und einer DMZ 8 geschützt.
Fig. 2 zeigt ein weiteres Ausführungsbeispiel einer Systemstruktur zur Verwendung mit dem erfindungsgemäßen Verfahren. Die Systemstruktur des in Fig. 1 gezeigten Ausführungsbeispiels ist hierbei derart erweitert, dass eine Track-and-Trace Funktion ausgeführt werden kann. Die Daten korrespondieren hierbei mit Aufträgen zur Bewegung von Objekten, in diesem Fall Waren. Dies bedeutet, dass der Verlader Waren mittels einer Spedition verschickt. Die Waren werden mittels einer Kennnummer gekennzeichnet, die in Form eines ausgegebenen Labels auf der Ware angebracht sind. Die Bewegungsdaten werden nun durch die Spedition derart erfasst, dass die Kennnummer und die jeweilige Station, an der die Ware sich befindet, mittels eines Mobiltelefons 6 via SMS und mittels des SMS Centers 10 des jeweiligen Mobilfunkanbieters an einen Kommunikationsserver 9 übermittelt werden. Die Bewegungsdaten werden sodann mittels des Kommunikationsservers 9 auf dem Datenbankserver 4 abgelegt und dabei derart aufbereitet, dass die Bewegungsdaten den jeweiligen Auftragsdaten zugeordnet werden können. Nun kann der Verlader mittels des ersten Clients 1 und die Spedition mittels des zweiten Clients 2 die Bewegungsdaten abrufen und ist somit jederzeit über den Aufenthaltsort der Waren informiert. In Fig. 3 ist der Datenfluss des Ausführungsbeispiels der Fig. 2 gezeigt. Hierbei werden die Auftragsdaten mittels des Systems, d. h. des ersten Clients 1 , des Webservers 3, des Datenbankservers 4 und des EDI-Servers 5, an den zweiten Client 2 übermittelt. Die Kennnummer der Ware wird dann mittels des zweiten Clients 2 an den Empfänger A der Ware übermittelt. Mittels dieser Kennnummer kann der Empfänger A Bewegungsdaten und somit den Aufenthaltsort der Ware via Internet vom Datenbankserver 4 abfragen. Die Spedition übermittelt nun nach Ablieferung der Ware mittels eines Mobiltelefons 6 via SMS und SMS Center 10 des Mobilfunkanbieters die neuen Bewegungsdaten an den Kommunikationsserver 9, wobei der Kommunikationsserver 9 die Bewegungsdaten aufbereitet und diese den Auftragsdaten zuordnet.
Fig. 4 zeigt den Datenfluss eines weiteren Ausführungsbeispiels des erfindungsgemäßen Verfahrens. Hierbei ist zwischen dem Kunden und Dienstleister ein e-shop zwischengeschaltet. Es erfolgt somit ein sogenanntes „Deep-Linking". Der Kunde, der den e-Shop besucht, übermittelt mittels des ersten Clients 1 nunmehr via Internet sowie mittels eines weiteren - hier nicht dargestellten - Webservers Daten an einen dritten Client 11. Eine Track-and-Trace Funktion erfolgt hierbei über den dritten Client 11 , nämlich den e-Shop. Die auf der Webseite des e-Shops erfassten Daten werden nun automatisch an einen Shopbetreiber B übermittelt, der die Warenwirtschaft ausführt. Teile der Daten, nämlich die für die Spedition relevanten Daten, werden mittels des dritten Clients 11 und/oder über den Shopbetreiber B über das bereits in Fig. 1 und Fig. 2 beschriebene Verfahren übermittelt.
Hinsichtlich weiterer Details wird zur Vermeidung von Wiederholungen auf die allgemeine Beschreibung verwiesen.
Schließlich sei ausdrücklich darauf hingewiesen, dass die voranstehend beschriebenen Ausführungsbeispiele lediglich zur Erörterung der beanspruchten Lehre dienen, diese jedoch nicht auf die Ausführungsbeispiele einschränken.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Verarbeitung von Daten über das Internet mit mindestens zwei Clients (1 , 2), einem Webserver (3) und mindestens einem Datenbankserver (4) zum Ablegen und Abrufen von Daten, wobei mindestens ein erster Client (1) via Internet mittels des Webservers (3) Daten auf dem Datenbankserver (4) ablegt und wobei mindestens ein zweiter Client (2), vorzugsweise via Internet mittels des Webservers (3), die Daten abruft, d a d u r c h g e k e n n z e i c h n e t, dass eine Zuordnung zwischen dem ersten Client (1) und den auf dem Datenbankserver (4) abgelegten Daten sowie dem zweiten die abgelegten Daten abrufenden Client (2) erfolgt und dass die Zuordnung der Daten des ersten Clients (1) durch die Auswahl des zweiten Clients (2) mittels des ersten Clients (1) erfolgt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Auswahl des zweiten Client (2) mittels des ersten Clients (1) auf festgelegte, insbesondere auf eine durch den jeweiligen zweiten Client (2) frei geschaltete, Gruppe von ersten Clients (1) beschränkt ist.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Daten auf mindestens einer Webseite mittels mindestens einer Datenmaske mittels des ersten Clients (1) erfasst werden.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Datenmaske individuell auf den ersten und/oder zweiten Client (1 , 2) abgestimmt wird.
5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass der Aufbau der Datenmaske mittels des jeweiligen Clients (1 , 2) verändert wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Übertragung der Daten an den zweiten Client (2) automatisch erfolgt.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Login und/oder die Datenübertragung verschlüsselt, vorzugsweise mittels einer SSL-Verschlüsselung, erfolgt.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Daten in der Datenbank auf dem Datenbankserver (4) in mindestens eine weitere Datenbank auf mindestens einem weiteren Datenbankserver gespiegelt werden.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Abfrage der Daten aus der Datenbank mittels SQL erfolgt.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Daten mittels eines EDI-Servers (5) konvertiert werden.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Übertragung der Daten mittels EDIFACT erfolgt.
12. Verfahren nach Anspruch 10 oder 11 , dadurch gekennzeichnet, dass mittels des EDI-Servers (5) die Daten an die vom zweiten Client (2) verwendete Software angepasst werden.
13. Verfahren nach einem der Ansprüche 1 bis 12 und ggf. einem der Ansprüche 9 bis 11 , dadurch gekennzeichnet, dass die Übermittlung der Daten, vorzugsweise vom EDI-Server (5), zum zweiten Client (2) mittels eines Übertragungsprotokolls, insbesondere XML, FTP, OFTP, X.25, X.400 oder dergleichen, erfolgt.
14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass die Daten oder Teile der Daten in Form eines Formulars, insbesondere eines individuell gestaltbaren Formulars, ausgeben werden.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Daten mittels der Software des zweiten Clients (2) weiterverarbeitet werden, insbesondere in dessen Auftragserfassung überführt werden.
16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass die Daten mit Aufträgen zur Bewegung von Objekten korrespondieren.
17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die Objekte mittels einer Kennzeichnung, vorzugsweise eines Barcodes, einer Kennnummer oder dergleichen, gekennzeichnet werden.
18. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass die Kennzeichnung und/oder Teile der Daten und/oder die gesamten Daten in Form eines Labels ausgegeben werden.
19. Verfahren nach einem der Ansprüche 16 bis 18, dadurch gekennzeichnet, dass die ursprünglich abgelegten Daten durch Daten, die mit den Bewegungen der Objekte korrespondieren, ergänzt werden.
20. Verfahren nach Anspruch 19, dadurch gekennzeichnet, dass die Bewegungsdaten mittels einer Erfassungseinrichtung, vorzugsweise einem Scanner, einem Mobiltelefon (6) oder dergleichen, erfasst werden.
21. Verfahren nach einem der Ansprüche 16 bis 20, dadurch gekennzeichnet, dass die Bewegungsdaten mittels eines Kommunikationsservers (9) auf dem Datenbankserver (4) abgelegt werden.
22. Verfahren nach Anspruch 21 , dadurch gekennzeichnet, dass der Kommunikationsserver (9) die Bewegungsdaten aufbereitet und/oder die Bewegungsdaten den betreffenden Daten, die mit einem Auftrag korrespondieren, zuordnet.
23. Verfahren nach einem der Ansprüche 16 bis 22, dadurch gekennzeichnet, dass die Bewegungsdaten mittels des ersten Clients (1) und/oder des zweiten Clients (2) abgerufen werden.
24. Verfahren nach einem der Ansprüche 1 bis 23, dadurch gekennzeichnet, dass der Webserver (3) mittels einer Firewall (7) und/oder einer DMZ (8) geschützt wird.
25. Verfahren nach einem der Ansprüche 1 bis 24, dadurch gekennzeichnet, dass eine automatische Überprüfung und/oder Vervollständigung der Daten mittels mindestens einer weiteren Datenbank erfolgt.
26. Verfahren nach einem der Ansprüche 1 bis 25, dadurch gekennzeichnet, dass die Daten durch Zusatzdaten, insbesondere durch Gefahrgutdaten, ergänzt werden.
27. Verfahren nach einem der Ansprüche 1 bis 26, dadurch gekennzeichnet, dass mittels des ersten und/oder des zweiten Clients (2) Statistiken über die Daten und/oder Teile der Daten abgerufen werden.
28. Verfahren nach einem der Ansprüche 1 bis 27, dadurch gekennzeichnet, dass die gesamten oder Teile der in die Datenmaske eingegebenen Daten des ersten Clients (2) an einen dritten Client (11) via Internet mittels eines weiteren Webservers übermittelt werden.
29. Verfahren einem der Ansprüche 1 bis 28, dadurch gekennzeichnet, dass die gesamten und/oder Teile der Daten durch weitere Clients abgerufen werden.
30. Verfahren nach Anspruch 29, dadurch gekennzeichnet, dass die Daten, die durch weitere Clients abgerufen werden, durch den ersten und/oder zweiten Client (1 , 2) beschränkt werden.
EP02732386A 2001-04-25 2002-04-10 Verfahren zur verarbeitung von daten über das internet Withdrawn EP1382180A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10120369A DE10120369A1 (de) 2001-04-25 2001-04-25 Verfahren zur Verarbeitung von Daten über das Internet
DE10120369 2001-04-25
PCT/DE2002/001331 WO2002089438A2 (de) 2001-04-25 2002-04-10 Verfahren zur verarbeitung von daten über das internet

Publications (1)

Publication Number Publication Date
EP1382180A2 true EP1382180A2 (de) 2004-01-21

Family

ID=7682741

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02732386A Withdrawn EP1382180A2 (de) 2001-04-25 2002-04-10 Verfahren zur verarbeitung von daten über das internet

Country Status (4)

Country Link
EP (1) EP1382180A2 (de)
AU (1) AU2002304890A1 (de)
DE (1) DE10120369A1 (de)
WO (1) WO2002089438A2 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1826715A1 (de) * 2005-12-30 2007-08-29 BRITISH TELECOMMUNICATIONS public limited company Generierung von Datennachrichten

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5168444A (en) * 1989-11-15 1992-12-01 Teknekron Transportation Systems Shipment system including processing of document images
DE4339357A1 (de) * 1993-11-18 1995-05-24 M A I Deutschland Gmbh Offener Datenaustausch
US5787400A (en) * 1994-12-12 1998-07-28 Pitney Bowes Inc. Method for implementing electronic data interchange (EDI) in the processing of manifests and parcel inquiry/responses for multiple carriers in a parcel processing system
US5940807A (en) * 1996-05-24 1999-08-17 Purcell; Daniel S. Automated and independently accessible inventory information exchange system
CA2294038A1 (en) * 1997-06-17 1998-12-23 Dsx International, Inc. Partially user-defined computer transportation system
WO1999006934A1 (en) * 1997-07-31 1999-02-11 Csx Technology, Inc. System and method for graphically organizing and accessing freight transportation network information on a map over the internet
ATE200373T1 (de) * 1997-10-13 2001-04-15 X Way Rights B V Verfahren und vorrichtung zur strukturierten kommunikation
GB2332540B (en) * 1997-12-18 2002-12-04 Ibm An improved parcel trace system
AU2507800A (en) * 1999-01-14 2000-08-01 Autobytel.Com, Inc. Computer implemented purchasing system with available inventory management functions
WO2000046718A2 (en) * 1999-02-03 2000-08-10 Freightmart.Com Corporation A method and apparatus for handling shipping requests via the internet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02089438A3 *

Also Published As

Publication number Publication date
AU2002304890A1 (en) 2002-11-11
DE10120369A1 (de) 2002-11-07
WO2002089438A2 (de) 2002-11-07
WO2002089438A3 (de) 2003-01-23

Similar Documents

Publication Publication Date Title
EP0951774B1 (de) Verfahren und system zur übermittlung von aufträgen in einem telekommunikationsnetz
DE10057638C2 (de) Verfahren zur Dokumentation von Daten eines Verkehrsmittels
WO2004092986A2 (de) Verfahren und system zur versorgung von mehreren service-dienstleistern mit technischen servicegeräten
EP2953067A1 (de) Verfahren und system zur reparatur- und/oder wartung von fahrrädern
EP1179793A1 (de) Portal für Finanzdienstleister
WO2002071250A2 (de) Verfahren und vorrichtung zum bestellen von produkten, insbesondere kraftfahrzeugen
WO2007073713A1 (de) Anordnung zur nutzung von erp-systemen auf vorzugsweise mobilen endgeräten
DE10115046A1 (de) Verfahren und Einrichtung zur Erzeugung eines Abbildes eines netzwerkartigen Herstellungsprozesses
WO2002089438A2 (de) Verfahren zur verarbeitung von daten über das internet
DE20101221U1 (de) Kurznachrichtendienst Bestellwesen
WO2006008223A1 (de) Verfahren, mit welchem ein endgerät informationen, die mit einem epc-code assoziiert werden, aus einem epc-netzwerk holen kann
DE19856519B4 (de) Datenspeichersystem und Verfahren zu seinem Betrieb
DE10123796A1 (de) Computersystem und Verfahren zur Lieferung einer Dokumentation
AT500055A2 (de) Verfahren und bestellplattform zur lenkung von warenströmen
DE102004008493B4 (de) Internetgestütztes Informationssystem
DE10142343B4 (de) Kommunikationsverfahren für Werkzeug- bzw. Produktionsmaschinen
DE10118827A1 (de) Verfahren zum automatischen Abgleich einer Datenmenge sowie Versandlogistiksystem
DE202018100360U1 (de) Computersystem zur Abwicklung von Bestellvorgängen
DE10143495A1 (de) Verfahren und Einrichtung zur Datenumwandlung elektronischer Dokumente
DE10130282A1 (de) Rechnergestütztes Bestellsystem und -verfahren
DE102017125798A1 (de) Verfahren zur elektronischen Bestellabwicklung über einen elektronischen Marktplatz
EP1471451A1 (de) Verfahren zur Ausgabe von Produktinformationen und System zur Durchführung des Verfahrens
DE102020126572A1 (de) Tracking Verfahren
DE202019104714U1 (de) System zur Übermittlung von Informationen hinsichtlich einer geografisch entfernt nutzbaren Dienstleistung
DE19804319A1 (de) Aufnahmeverfahren von Informationen im virtuellen Benutzersystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20031030

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HENRICH, ROLF

Inventor name: HEISTERMANN, FRAUKE

Inventor name: KLETT, MICHAEL

Inventor name: SCHMITT, HOLGER

17Q First examination report despatched

Effective date: 20061222

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20081031