DE10300698A1

DE10300698A1 - Hardware-Bezahlen-Pro-Nutzung

Info

Publication number: DE10300698A1
Application number: DE10300698A
Authority: DE
Inventors: Robert C Lehr; Arif Sardar; Matthew Lane; Winthrop Reis; Cynthia Alderson; Patrick Allaire; Richard Birrell; Christopher K Buss; Paula Zimon Clawson; Michael Graf; Arthur F Green; Monica Lasgoity; Susan C Neidhart; Anthony Keith Towles; Carol Uno
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2002-01-15
Filing date: 2003-01-10
Publication date: 2003-07-31
Also published as: US8271400B2; GB2384137B; GB0230345D0; GB2384137A; JP4318459B2; JP2003248522A; US20030135380A1

Abstract

Ein Hardware-Bezahlen-Pro-Nutzung-System und ein entsprechendes Verfahren ermöglichen es Betreibern von Computersystemen, ihre Hardwarenutzung so zuzuschneiden, daß sie stärker mit sich verändernden Kundenanforderungen übereinstimmt. Das Hardware-Bezahlen-Pro-Nutzung-System umfaßt ein oder mehrere Hardwareprodukte und einen Meßmechanismus, der mit zumindest einem der Hardwareprodukte gekoppelt ist. Der Meßmechanismus umfaßt eine von den Hardwareprodukten getrennte Hardwarevorrichtung. Der Meßmechanismus gewinnt Metrikdaten von den Hardwareprodukten, wobei die Metrikdaten auf einen Betrieb der Hardwareprodukte bezogen sind. Der Mechanismus ermittelt Daten, die bezüglich des Betriebs der Hardwareprodukte zu berichten sind. Ein mit dem Meßmechanismus gekoppeltes Nutzungsdepot empfängt die ermittelten Daten und erstellt Nutzungsberichte, die auf den Betrieb der Hardwareprodukte bezogen sind.

Description

Das technische Gebiet ist eine Preisfestlegung von Hardware auf einer Pro-Nutzung-Basis.
Viele Unternehmen, vor allem Internet-basierte Unternehmen, sehen sich einem steigenden Bedarf an Rechenkapazität gegenüber. Während dieser Bedarf an Rechenkapazität zunimmt, besteht ein typischer Lösungsansatz darin, weiterhin genügend Rechenkapazität (d. h. Hardwarevorrichtungen) zu gewinnen, um ein bestimmtes Dienstniveau-Ziel, das üblicherweise ein normales Dienstniveau übertraf, zu erreichen. Alternativ oder zusätzlich dazu kann eine zusätzliche Rechenleistung im Fall eines Schadensfalles wünschenswert sein, der zum Verlust einer oder mehrerer Hardwarevorrichtungen führt, um das gewünschte Dienstniveau ohne Unterbrechung aufrechtzuerhalten. Dieser traditionelle Ansatz eines Gewinnens einer Rechenkapazität führt in der Praxis zu einem kostspieligen Überdimensionieren oder zum Risiko niedriger Dienstniveaus. Um beispielsweise einen Dienst an einer Internet-Website bereitzustellen, könnte der Betreiber der Website eine ausreichende Serverkapazität gewinnen, um 80 Prozent der Spitzenlast zu bewältigen. Dies bedeutet, daß zu Spitzenzeiten manche Website-Kunden eventuell nicht in der Lage sind, auf die Website zuzugreifen, während außerhalb der Spitzenzeiten manche Server ungenutzt bleiben. Je näher der Website-Betreiber an eine Bewältigung einer Spitzenlast heranzukommen versucht, desto größer wäre die Kapazität an ungenutzten Servern außerhalb der Spitzenzeiten.
Es ist die Aufgabe der vorliegenden Erfindung, Systeme, Verfahren, einen Finanzierungsplan und Vorrichtungen zu schaffen, die eine gleichmäßigere Nutzung von Hardware ermöglichen.
Diese Aufgabe wird durch Systeme gemäß Anspruch 1 oder 45, Verfahren gemäß den Ansprüchen 18, 19, 20 oder 27, einen Finanzierungsplan gemäß Anspruch 37 und durch eine Vorrichtung gemäß Anspruch 53 gelöst.
Ein Hardware-Bezahlen-Pro-Nutzung-System und ein entsprechendes Verfahren ermöglichen es Computersystemen-Clients, ihre Hardwarenutzung so zuzuschneiden, daß sie besser mit sich verändernden Kundenanforderungen übereinstimmt. Das System und das entsprechende Verfahren ermöglichen es einem Client, auf Änderungen der Nachfrage oder auf einen Hardware-Ausfall schnell zu reagieren und gewünschte Dienstniveaus ohne eine teure Gewinnung einer überschüssigen Hardware-Kapazität aufrechtzuerhalten. Das System und Verfahren beinhalten flexible Bezahlen-Pro-Nutzung-Preisfestlegungspläne auf der Basis von Daten, die durch einen Mechanismus, der von den Hardwareprodukten separat und getrennt ist, von Hardwareprodukten zusammengetragen werden.
Bei einem Ausführungsbeispiel umfaßt das Hardware-Bezahlen- Pro-Nutzung-System ein oder mehrere Hardwareprodukte und einen mit den Hardwareprodukten gekoppelten Meßmechanismus. Der Meßmechanismus umfaßt eine von den Hardwareprodukten getrennte Hardwarevorrichtung. Der Meßmechanismus gewinnt Metrikdaten von den Hardwareprodukten, wobei die Metrikdaten beispielsweise auf eine Nutzung der Hardwareprodukte bezogen sind. Der Meßmechanismus ermittelt Daten, die bezüglich der Nutzung der Hardwareprodukte zu berichten sind. Ein mit dem Meßmechanismus gekoppeltes Nutzungsdepot empfängt die ermittelten Daten und erzeugt Nutzungsberichte, die auf die Hardwareprodukte bezogen sind. Ferner können Fakturierungsberichte und Rechnungen auf der Basis der Nutzungsdaten erstellt werden.
Ein Verfahren zum Festlegen von Preisen einer Hardware auf einer Bezahlen-Pro-Nutzung-Basis, bei dem ein oder mehrere Hardwareprodukte mit einem Kommunikationsnetz gekoppelt sind, umfaßt ein Gewinnen, bei einer von einem oder mehreren Hardwareprodukten separaten Hardwarevorrichtung, von Metrikdaten, die auf einen Betrieb, beispielsweise eine Nutzung, der Hardwareprodukte bezogen sind; Ermitteln von zu berichtenden Daten auf der Basis des Gewinnungsschrittes: Senden der ermittelten Daten an ein Nutzungsdepot; Erstellen eines Nutzungsberichts: und Erstellen eines Bezahlen-Pro-Nutzung-Fakturierungsberichts und einer Rechnung auf der Basis des Nutzungsberichts.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
Fig. 1 ein Blockdiagramm einer Hardware-Bezahlen-Pro- Nutzung-Umgebung:
Fig. 2 ein ausführliches Blockdiagramm eines Hardware- Bezahlen-Pro-Nutzung-Systems;
Fig. 3 ein Blockdiagramm eines bei dem System der Fig. 2 verwendeten Meßmechanismus; und
Fig. 4 ein Flußdiagramm, das einen Betrieb des Systems der Fig. 2 veranschaulicht.
Fig. 1 ist ein Blockdiagramm einer Hardware-Bezahlen-Pro- Nutzung-Umgebung 10, die eine flexible Preisfestlegung von Hardwareprodukten ermöglicht. Die flexible Preisfestlegung kann für eine beliebige Anzahl von Finanzierungsmodellen gelten, einschließlich Leasing, Vorauszahlung, Kapitalankauf, Mieten mit dem Ziel des späteren Erwerbs, Kauf und Inzahlungnahme und anderer Finanzierungsmodelle. Die Umgebung 10 umfaßt eine Clientseite 11, die ein oder mehrere Hardwareprodukte 12 aufweist. Ebenfalls enthalten ist ein Mechanismus 13, der in der Lage ist, Daten, die sich auf den Betrieb der Hardwareprodukte 12 beziehen, zu erhalten. Die Hardwareprodukte 12 sind durch eine Verbindung 14 mit dem Mechanismus 13 gekoppelt. Durch eine Verbindung 18 ist eine Serverseite 15 mit der Clientseite 11 gekoppelt. Die Serverseite 15 kann einen oder mehrere Server 16, um Daten zu verarbeiten und die flexible Preisfestlegung zu unterstützen, und eine oder mehrere Datenbanken 17 umfassen, um Daten, die sich auf die flexible Preisfestlegung beziehen, zu speichern.
Die Hardwareprodukte 12 können Server sein, die entworfen sind, um in einem vernetzten Computersystem zu arbeiten. Die Hardwareprodukte 12 können jedoch beliebige Hardwarevorrichtungen sein, die an ein Netz angeschlossen sein können und von denen Metrikdaten erhalten werden können. Bei der in Fig. 1 gezeigten Umgebung 10 werden die Hardwareprodukte 12 an einen Client auf der Clientseite geleast. Bei einem alternativen Ausführungsbeispiel der Umgebung 10 können die Hardwareprodukte 12 auf der Basis anderer Finanzierungsmodelle bereitgestellt werden, beispielsweise Vorauszahlung, Kapitalankauf, Mieten mit dem Ziel des späteren Erwerbs, Kauf und Inzahlungnahme und anderer Finanzierungsmodelle. Die Hardwareprodukte 12 können entworfen sein, um ein durch den Client festgelegtes Dienstniveau zu erfüllen. Beispielsweise kann die Clientseite 11 eine Internet- Website sein, die Hardwareprodukte 12 können Webserver sein, und die Anzahl von Webservern, die geleast werden, kann durch den Client ausgewählt sein, so daß eine erwartete Spitzennachfrage auf der Clientseite 11 immer durch einen Betrieb der Webserver erfüllt werden kann. Wenn man hiervon ausgeht, realisieren die Hardwareprodukte 12 (Webserver) während eines Großteils eines beliebigen gegebenen Zeitraums eventuell keine 100%ige oder nahezu 100%ige Nutzung. Folglich, wie dies auch bei einem traditionellen Hardwareprodukt-Leasingplan der Fall ist, zahlt der Client für eine überschüssige Kapazität, die selten genutzt wird, um während der Stunden des Spitzenbetriebs ein akzeptables Dienstniveau zu garantieren. Die Umgebung 10 löst dieses Problem durch ein flexibles Finanzierungsmodell auf der Basis eines Bezahlen-Pro-Nutzung-Schemas. Das Bezahlen-Pro- Nutzung-Schema sieht vor, daß der Client für Hardwareprodukte 12 zumindest teilweise auf der Basis von Metrikdaten zahlt, die durch den Mechanismus 13 von den Hardwareprodukten 12 gewonnen werden. Die Metrikdaten können sich auf einen gewissen betriebsmäßigen Aspekt der Hardwarevorrichtungen 12 beziehen bzw. einen solchen messen, beispielsweise einen Zeitraum, in dem die Hardwarevorrichtungen 12 tatsächlich in Gebrauch sind. Es können auch andere Metrikdaten, einschließlich. Konfigurationsdaten, als Basis zum Fakturieren bei dem Bezahlen-Pro-Nutzung-Schema verwendet werden.
Die Hardwareprodukte 12, die in der Umgebung 10 an den Client geleast werden, können durch einen Betreiber der Serverseite 15 oder durch eine Identität, die auf den Betreiber der Serverseite 15 bezogen ist, bereitgestellt werden. Alternativ dazu können der Anbieter der Hardwareprodukte 12 und der Betreiber der Serverseite 15 Entitäten sein, die zueinander nicht in Beziehung stehen.
Der Mechanismus 13 kann durch den Anbieter der Hardwareprodukte 12, den Betreiber der Serverseite 15 oder eine andere Entität, die nicht mit dem Anbieter oder dem Betreiber in Beziehung steht, auf der Clientseite 11 bereitgestellt werden. Der Mechanismus 13 kann eine entsprechend programmierte Hardwarevorrichtung sein, die sich physisch von den Hardwareprodukten 12 unterscheidet. Der Mechanismus 13 kann als eine Hardwarevorrichtung in einem gestellmontierbaren System, in dem die Hardwareprodukte 12 ebenfalls angebracht sind, implementiert sein. Bei diesem Ausführungsbeispiel kann der Mechanismus 13 eine alleinstehende Vorrichtung sein. Der Mechanismus 13 kann ferner an einem auf geeignete Weise programmierten Mehrzweckcomputer, einschließlich eines Laptop- oder Notebook-Computers, eines Desktop- Computers, eines Servers und eines Hauptrechners, implementiert sein. Der Mechanismus 13 ist eventuell nicht ressourcenintensiv und kann als eine Vorrichtung mit einer geringeren Rechenleistung als die Hardwareprodukte 12 implementiert sein. Der Mechanismus 13 kann (nicht gezeigte) Merkmale beinhalten, die es dem Client auf der Clientseite 11 ermöglichen, Informationen, die sich auf den Betrieb der Hardwareprodukte 12 beziehen, zu erhalten. Beispielsweise kann der Client in der Lage sein, den Mechanismus 13 abzufragen, um eine laufende Rechnung für den Betrieb der Hardwareprodukte 12 zu erhalten oder Metrikdaten, die durch den Mechanismus 13 gesammelt werden, zu erhalten.
Wenn der Mechanismus 13 auf der Clientseite 11 vorgesehen ist, kann die Verbindung 14 eine beliebige Verbindung sein, die in der Lage ist, digitale Daten zu übertragen, und die Verbindung 18 kann das Internet oder ein ähnliches öffentliches Netz sein, das in der Lage ist, digitale Daten zu übertragen.
Bei einem alternativen Ausführungsbeispiel der Umgebung 10 kann der Mechanismus 13 auf der Serverseite 15 angeordnet sein. Bei diesem Ausführungsbeispiel kann die Verbindung 18 ein beliebiges Medium sein, das in der Lage ist, digitale Daten zu übertragen, und die Verbindung 14 kann ein öffentliches Netz sein, beispielsweise das Internet, das in der Lage ist, digitale Daten zu übertragen.
Fig. 2 ist ein ausführliches Blockdiagramm eines möglichen Hardware-Bezahlen-Pro-Nutzung-Systems. Ein Hardware- Bezahlen-Pro-Nutzung-System 100 umfaßt eine Clientseite 110 und eine Serverseite 115. Die Clientseite 110 ist durch eine Verbindung 118, eine clientseitige Firewall 108 und eine serverseitige Firewall 119 mit der Serverseite 115 gekoppelt. Die Verbindung 118 kann eine beliebige Verbindung sein, die in der Lage ist, digitale Daten zu übertragen. Bei einem Ausführungsbeispiel ist die Verbindung 118 ein Kommunikationsnetz, und die Clientseite 110 ist eine Internet-Website. Bei einem alternativen Ausführungsbeispiel ist die Verbindung 118 eine Kommunikationsverknüpfung in einem lokalen Netzwerk (LAN - local area network), und die Clientseite 110 und die Serverseite 115 sind Knoten in dem LAN. Fachleute werden erkennen, daß das in Fig. 2 gezeigte System 100 an ein beliebiges Netz oder eine beliebige Umgebung, in dem bzw. in der digitale Daten von einem Knoten zu einem anderen Knoten geleitet werden, angepaßt werden kann.
Die Clientseite 110 ist mit drei Hardwareprodukten 112 gezeigt, die mit einem Meßmechanismus 113 gekoppelt sind, der eine Anzeige 107 umfassen kann. Jedoch kann die Clientseite 110 eine beliebige Anzahl von Hardwareprodukten 112 umfassen. Bei einem Ausführungsbeispiel können zusätzliche Meßmechanismen 113 auf der Clientseite 110 angeordnet sein, falls die Anzahl von Hardwareprodukten 112 eine Kapazität eines einzelnen Meßmechanismus 113 übersteigen sollte. Die Funktionen des Meßmechanismus 113 und seine Beziehung zu den Hardwareprodukten 112 werden später ausführlich beschrieben. Ein Meßagent, beispielsweise der Agent 109, kann mit einem oder mehreren der Hardwareprodukte 112 gekoppelt sein. Die Hardwareprodukte 112 können auch eine gebündelte Software, beispielsweise die gebündelte Software 106, umfassen.
Bei einem alternativen Ausführungsbeispiel des Systems 100 sind die Meßmechanismen 113 an der Serverseite 115 auf der Serverseite der Firewall 119 angeordnet. Bei diesem Ausführungsbeispiel kommuniziert der Meßmechanismus 113 auf der Serverseite 115 unter Verwendung eines Digitaldatenübertragungsmediums mit anderen Vorrichtungen und kommuniziert unter Verwendung einer VPN-Technologie (VPN = Virtual Private Network, Virtuelles-Privatnetz) oder einer ähnlichen Technologie mit den Hardwareprodukten 112 auf der Clientseite 110, wobei diese Technologie an einem öffentlichen Netz, beispielsweise dem Internet, oder einem anderen Netz, das in der Lage ist, durch die Firewalls 119 und 108 digitale Daten zu übertragen, implementiert ist.
Die Serverseite 115 umfaßt ein Nutzungsdepot 120, das Daten von dem Meßmechanismus 113 empfängt. Das Nutzungsdepot 120 umfaßt eine Einrichtung zum Empfangen von Metrikdaten, die den Hardwareprodukten 112 zugeordnet sind, zum Validieren der Metrikdaten und zum Speichern der Daten. Bei einem Ausführungsbeispiel ist die Einrichtung zum Empfangen, Validieren, Erstellen und Speichern ein Utility-Validierungsserver 121. Das Nutzungsdepot 120 kann auch eine Einrichtung zum Erstellen von Nutzungsberichten auf der Basis von Metrikdaten umfassen. Der Server 121 kann verarbeitete und rohe (unverarbeitete) Daten und die Nutzungsberichte in einer oder mehreren Nutzungsdatenbanken 123 speichern.
Mit dem Nutzungsdepot 120 sind ein Portal 130 und ein Fakturierungs- und Buchhaltungssystem 140 gekoppelt. Das Portal 130 stellt eine Kommunikationseinrichtung bereit, die es einem Client auf der Clientseite 110 ermöglicht, mit der Serverseite 115 zu interagieren, und es liefert eine Einrichtung für eine Rechnungsvorlage und Zahlungen in dem Hardware-Bezahlen-Pro-Nutzung-System 100. Das Portal 130 ermöglicht es dem Client auf der Clientseite 110 ferner, Daten, die den Hardwareprodukten 112 zugeordnet sind, einzusehen. Bei einem Ausführungsbeispiel kann das Portal 130 eine Anzeige von Daten von der Serverseite 115 auf der Anzeige 107 auf der Clientseite 110 bereitstellen. Ein Beispiel dieser Daten umfaßt Hardwareprodukt-Nutzungsberichte, die an dem Nutzungsdepot 120 erstellt werden können. Das Fakturierungs- und Buchhaltungssystem 140 liefert eine Einrichtung zum Erstellen von Fakturierungsinformationen, Empfangen und Gutschreiben von Zahlungen von der Clientseite 110, Ausführen anderer Verwaltungsaufgaben und Speichern von Daten, die auf diese Funktionen bezogen sind.
Unter erneuter Bezugnahme auf die Clientseite 110 körnen die Hardwareprodukte 112 Server sein, die von einem Betreiber der Serverseite 115 geleast werden. Die Hardwareprodukte 112 können ferner andere geleaste, computerbezogene Hardwarevorrichtungen sein, einschließlich Drucker, Desktop-Computer, sowie anderer Hardwarevorrichtungen. Zusätzlich zu einem Leasingmodell können auch andere Finanzmodelle, beispielsweise Vorauszahlung, Kapitalankauf, Mieten mit dem Ziel des späteren Erwerbs, Kauf und Inzahlungnahme und andere Finanzmodelle verwendet werden, um die Hardwareprodukte 112 bereitzustellen. Obwohl das in Fig. 2 gezeigte System 100 das Hardware-Bezahlen-Pro-Nutzung-Konzept im Kontext eines vernetzten Computersystems, d. h. des Systems 100, veranschaulicht, kann das Hardware-Bezahlen-Pro- Nutzung-Konzept für andere Hardware-Umgebungen verwendet werden, bei denen Metrikdaten, die auf einen Betrieb der Hardwareprodukte bezogen sind, von den Hardwareprodukten gesammelt und zu Nutzungs- und Fakturierungszwecken an einen entfernten Ort geliefert werden können. Bei einem anderen Ausführungsbeispiel des Systems 100 können die Hardwareprodukte 112 von einem Hardwareverkäufer erworben werden, und die Überwachungs- und Fakturierungsfunktionen können durch einen Drittpartei-Verkäufer ausgeführt werden. Bei einem weiteren Ausführungsbeispiel ist das System. 100 ein LAN, wobei die Clientseite 110 einer von einem oder mehreren Knoten in dem LAN ist und die Serverseite 115 ein zentraler Knoten in dem LAN ist. Bei diesem späteren Ausführungsbeispiel verfolgt die Serverseite 115 eine Hardwareproduktnutzung durch die Clientseite 110 nach und kann eine interne Fakturierung für eine Nutzung der Hardwareprodukte 112 einrichten.
Der Meßmechanismus 113 gewinnt Nutzungs- oder Metrikdaten von einem oder mehreren der Hardwareprodukte 112. Der Meßmechanismus 113 kann eine alleinstehende Hardwarevorrichtung sein, die auf geeignete Weise programmiert ist, um die Metrikdaten zu gewinnen. Beispielsweise kann der Meßmechanismus eine mit den Hardwareprodukten 112 gekoppelte gestellmontierte Komponente sein. Alternativ dazu kann sich der Meßmechanismus 113 an einer Nicht-Bezahlen-Pro-Nutzung- Hardwarekomponente, beispielsweise einem administrativen Server beispielsweise auf der Clientseite 110 befinden. Bei einem Ausführungsbeispiel enthält der Meßmechanismus 113 eine Metrikdatengewinnungssoftware, beispielsweise den Open View Internet Usage Manager (IUM) von Hewlett Packard, der als die einzige Anwendung an einem separaten, wartungsfreien Linux-basierten System läuft, das sich auf der Clientseite 110 befindet. Bei einem weiteren Ausführungsbeispiel, bei dem sich der Meßmechanismus 113 auf der Serverseite 115 befindet, kann der Meßmechanismus 113 eine alleinstehende Hardwarevorrichtung sein oder kann in eine oder mehrere Komponenten auf der Serverseite 115, beispielsweise das Nutzungsdepot 120, integriert sein. Wenn der Meßmechanismus 113 auf der Serverseite 115 implementiert ist, kann eine VPN-Technologie oder eine andere ähnliche Technologie, die es den Hardwareprodukten 112 ermöglicht, mit dem Meßmechanismus 113 zu kommunizieren, beim Verbinden der Hardwareprodukte 112 mit der Serverseite 115 verwendet werden.
Der Meßmechanismus 113 kann die Metrikdaten auf einer periodischen oder nicht-periodischen Basis gewinnen. Ein Lösungsansatz bezüglich eines Sammelns der Metrikdaten stützt sich auf einen Abrufbetrieb. Beim Abrufbetrieb werden die Internetprotokoll-Adressen (IP-Adressen) jedes der Hardwareprodukte 112 in den Meßmechanismus 113 eingegeben. Die Eingabe der IP-Adressen kann unter Verwendung beispielsweise einer graphischen Benutzeroberfläche (GUI - Graphical User Interface) bewerkstelligt werden. Anschließend ruft der Meßmechanismus 113 die Hardwareprodukte 112 auf der Clientseite 110 unter Verwendung der IP-Adressen ab, um die Metrikdaten wiederzuerlangen. Die Hardwareprodukte 112 empfangen den Abrufbefehl und leiten eine Aktion ein, um die angeforderten Metrikdaten zu sammeln. Eine solche Sammlung kann sich auf den Meßagenten 109 stützen, der beispielsweise ein Windows®- oder Linux-Agent sein kann, der in jedes der Hardwareprodukte 112 integriert ist. Ferner kann jedes der Hardwareprodukte 112 ein unterschiedliches Abrufintervall aufweisen, auch bei gleichen oder ähnlichen Hardwareprodukten 112.
Als Alternative zu einem Abrufen kann sich der Meßmechanismus 113 auf die Meßagenten stützen, um die Metrikdaten ohne ein Abrufen zu sammeln. Bei diesem Ausführungsbeispiel sammeln Meßagenten, beispielsweise der Meßagent 109, die Metrikdaten kontinuierlich oder zu festgelegten Sammelintervallen und leiten eine Kommunikation mit dem Meßmechanismus 113 ein. Der Meßmechanismus 113 kann eingestellt sein, um Metrikdaten von den Meßagenten 109 zu empfangen.
Der Meßmechanismus 113 kann Metrikdaten mehrmals pro Stunde gewinnen, je nach dem Typ von Metrikdaten, der gerade gesammelt wird. Beispielsweise kann der Meßmechanismus 113 eingestellt sein, um alle 20 Minuten für insgesamt 72 Intervalle pro Tag Daten zu gewinnen. Je nach dem Typ der gesammelten Metrikdaten können jedoch auch andere Gewinnungsintervalle festgelegt werden. Eine häufige Gewinnung kann für augenblickliche bzw. Schnappschußmetriken erwünscht sein; ein häufiges Abrufen wäre jedoch für kumulative Metriken nicht so kritisch. Der Meßmechanismus 113 kann ein einziges Gewinnungsintervall aufweisen, um die Sache zu vereinfachen.
Der Meßmechanismus 113 kann unter Verwendung einer Vielzahl von Techniken Metrikdaten von den Hardwareprodukten 112 gewinnen. Die Metrikdaten können in einer Vielzahl von Formaten gewonnen werden. Der Meßmechanismus 113 kann verschiedene Metrikdaten von verschiedenen Hardwareprodukten 112 gewinnen, und die Hardwareprodukte 112 an einer beliebigen Clientseite müssen nicht identische oder auch nur ähnliche Typen von Hardwarevorrichtungen sein. Der Meßmechanismus 113 kann eine Art Vorverarbeitung der Metrikdaten durch führen und kann die vorverarbeiteten Metrikdaten nach einer geeigneten Komprimierung und Verschlüsselung an das Nutzungsdepot 120 senden.
Der Meßmechanismus 113 kann durch ein Netzverwaltungsprotokoll wie beispielsweise ein einfaches Netzverwaltungsprotokoll (SNMP - Simple Network Management Protocol) oder ein Protokoll einer Web-basierten Unternehmensverwaltung (WBEM-Protokoll, WBEM = Web-Based Enterprise Management), die beide ein Abrufen von Informationen ermöglichen, mit den Hardwareprodukten 112 kommunizieren. Der Meßmechanismus 113 und die Hardwareprodukte 112 können ferner unter Verwendung einer Desktop-Verwaltung-Schnittstelle (DMI - Desktop Management Interface) oder eines ähnlichen Rahmens für eine Netzverwaltung kommunizieren. Der Meßmechanismus 113 und die Hardwareprodukte 112 können unter Verwendung von Protokollen, die nicht spezifisch für eine Netzverwaltung reserviert sind, beispielsweise Hypertext Transport Protocol (HTTP) oder Secure HTTP (HTTP/S) Daten kommunizieren und übertragen.
Wie oben angemerkt wurde, können die Hardwareprodukte 112 den Meßagenten 109 beinhalten, um mit dem Meßmechanismus 113 zu kommunizieren. Die Implementierung des Meßagenten 109 hängt von dem jeweiligen verwendeten Kommunikationsprotokoll ab. Bei einer SNMP-Implementierung ist der Meßagent 109 als ein SNMP-Agent oder Unteragent implementiert. Falls WBEM/DMI das Kommunikationsprotokoll ist, dient ein WBEM/DMI-Datenanbieter als der Meßagent 109. Ein für einen Webserver zugängliches CGI-Programm könnte als Meßagent. 109 verwendet werden, falls HTTP oder HTTP/S als das Kommunikationsprotokoll verwendet wird.
Metrikdaten, die durch die Hardwareprodukte 112 zurückgegeben werden, können eine standardisierte Datenstruktur verwenden, beispielsweise eine, die durch eine Verwaltungsinformationsbasis (MIB - Management Information Base) für SNMP oder durch das verwaltete Objektformat (MOF - Managed Object Format) für WBEM festgelegt ist. Bei einer SNMP- Implementierung kann eine MIB beispielsweise für ein Zurückgeben bestimmter Daten an den Meßmechanismus 113 festgelegt sein. Die MIB könnte zu einer Datenstruktur kompiliert und zu dem Meßagenten 109 (der beispielsweise als ein SNMP-Unteragent implementiert ist) heruntergeladen werden, wenn die Datenstruktur beim Sammeln von Daten verwendet würde. Es können auch andere Datenstrukturen verwendet werden, um den Transfer der Metrikdaten zwischen den Hardwareprodukten 112 und dem Meßmechanismus 113 zu implementieren.
Die bestimmten Metrikdaten, die von den Hardwareprodukten 112 zusammengetragen werden, hängen von dem jeweiligen Hardwareprodukt 112 und einem jeweiligen Geschäftsmodell zum Berechnen einer Nutzung der Hardwareprodukte 112 ab. Eine Art von Metrikdaten, die gewonnen werden können, ist eine Schnappschuß-Metrik, die einen Schnappschuß des aktuellen Zustands der Hardwareprodukte 112 auf der Clientseite 110 darstellt. Ein verbreiteter Typ einer Schnappschußmetrik ist beispielsweise die Anzahl von Hardwareprodukten 112, die zu einem beliebigen Zeitpunkt auf der Clientseite 110 arbeiten. Es können auch kumulative Metrikdaten, die den akkumulierten Gesamtwert eines gegebenen Parameters messen, durch den Meßmechanismus 113 gewonnen werden. Solche kumulativen Metrikdaten umfassen die Anzahl von Transaktionen oder die Anzahl von Dateien, die beispielsweise für ein gegebenes vorbestimmtes Zeitintervall produziert werden. Andere Metrikdaten umfassen eine Metrik einer Zentralverarbeitungseinheit-Nutzung (CPU-Nutzung; CPU - central processing unit) oder Ausführungszeit- und Eingabe-/Ausgabe-Metriken (I-/O-Metriken, I-/O = Input/Output), wie beispielsweise die Anzahl von I-/O-Lese- oder Schreibvorgängen. Noch weitere Metrikdaten umfassen beispielsweise, wieviel Speicher von einem verfügbaren Speicher zu einem beliebigen Zeitpunkt genutzt wird, wieviel Festplatte oder ein anderer Massenspeicher zu einem beliebigen Zeitpunkt genutzt wird; bandbreitenbezogene Metriken wie beispielsweise die Anzahl von Megabytes, die durch eine Netzschnittstellenkarte (NIC - Network Interface Card) über einen gegebenen Zeitraum übertragen werden; die Anzahl von Dateien, auf die über einen gegebenen Zeitraum hinweg zugegriffen wird; und die Anzahl angeschlossener Benutzer.
Der Client kann ferner durch einen Client bereitgestellte Metrikdaten festlegen (denen der serverseitige Betreiber zustimmen kann), auf denen die Bezahlen-Pro-Nutzung-Faktura oder -Rechnung beruht. Beispielsweise kann die Clientseite 110 eine Online-Maklerfirma sein. Bei diesem Beispiel kann die Bezahlen-Pro-Nutzung-Faktura auf einer Anzahl von Handelstransaktionen beruhen, die über einen gegebenen Zeitraum durch den bzw. die Webserver (die Hardwareprodukte 112) der Maklerfirma bearbeitet werden. Die Anzahl von Transaktionen kann durch einen Meßagenten, der durch den serverseitigen Betreiber oder eine andere dritte Entität bereitgestellt wird, ermittelt werden, wobei der Meßagent an den Hardwareprodukten 112 auf der Clientseite 110 installiert ist, wie oben beschrieben wurde. Somit ist das System 100 in der Lage, kundenspezifische Schemata für ein Berichten und Verwenden von Metrikdaten zu Ermöglichen, um eine Hardwareproduktnutzung durch einen bestimmten Client sehr genau zu erfassen.
Der Meßmechanismus 113 kann die Metrikdaten in einer spezifischen vorbestimmten Datenschnittstelle, beispielsweise in einem durch Doppelpunkte getrennten variablen Textformat oder Reihen von Variablen/Wertegruppen, die mit dem Meßmechanismus 113 kompatibel ist, zurückgeben. Die Metrikdaten können beispielsweise in einem binären Format oder in einem Textformat vorliegen.
Der Meßmechanismus 113 kann die akkumulierten Metrikdaten periodisch an die Serverseite 115 berichten oder übermitteln. Die Berichterstattungsperiodizität kann auf einer Kalenderbasis, auf der Basis einer akkumulierten Anzahl von Datenbytes oder auf einer anderen Basis bestimmt werden. Beispielsweise kann der Meßmechanismus 113 Metrikdaten eines ganzen Tages von den Hardwareprodukten 112 akkumulieren. Zu einem festgelegten Zeitpunkt kann der Meßmechanismus 113 Kommunikationen mit der Serverseite 115 einrichten und anschließend die akkumulierten Metrikdaten hochladen.
Wenn er auf der Clientseite 110 implementiert ist, kann der Meßmechanismus 113 die Metrikdaten von den Hardwareprodukten 112 gewinnen und kann zu einem festgelegten Zeitpunkt Kommunikationen mit der Serverseite 115 einrichten, um die Metrikdaten zu übermitteln. Derartige Kommunikationen können durch den Meßmechanismus 113 unter Verwendung einer IP- Adresse der Serverseite 115, um beispielsweise einen Kommunikationsweg zu öffnen, eingerichtet werden. Bei diesem Ausführungsbeispiel wird eine Übertragung von Metrikdaten durch den Meßmechanismus 113 eingeleitet, und die Serverseite 115 kann Anfragen, beispielsweise E-Mail-Nachrichten bei der Clientseite 110, einleiten. Die Metrikdaten werden anschließend zu der Serverseite 115 "geschoben".
Wenn er auf der Clientseite 110 implementiert ist, kann der Meßmechanismus 113 die Metrikdaten unter Verwendung einer Vielzahl von bekannten Protokollen und Netztransportmechanismen, beispielsweise einschließlich HTTP und HTTPLS, an die Serverseite 115 übertragen. Die Übertragung kann automatisch erfolgen, unter Verwendung eines (nicht gezeigten) Proxy-Servers auf der Clientseite 110 und/oder einer Netzadressenübersetzung (NAT - Network Address Translation), um durch die Firewalls 108 und 119 über das Internet zu kommunizieren. Der Meßmechanismus 113 kann ferner unter Verwendung von E-Mail die Metrikdaten über das Internet übertragen.
Wenn er auf der Serverseite 115 implementiert ist, wie oben beschrieben wurde, kann der Meßmechanismus 113 eine Gewinnung der Metrikdaten von den Hardwareprodukten 112 beispielsweise unter Verwendung einer IP-Adresse der Clientseite 110 und der Hardwareprodukte 112 einleiten. Der Meßmechanismus 113 "zieht" dann die Metrikdaten von der Clientseite 110 herüber.
Wenn er auf der Serverseite 115 implementiert ist, kann der Meßmechanismus 115 Netztransportmechanismen und -protokolle verwenden, wie oben beschrieben wurde, um die Metrikdaten von den Hardwareprodukten 112 zu gewinnen.
Wenn er auf der Clientseite 110 implementiert ist, kann der Meßmechanismus 113 Patches oder Softwareaktualisierungen von der Serverseite 115 empfangen. Der Meßmechanismus 113 kann die Serverseite 115 periodisch, beispielsweise täglich, abfragen, um derartige Aktualisierungen zu empfangen.
Alternativ dazu kann der Meßmechanismus 113 die Aktualisierungen auf ein Kommunizieren mit der Serverseite 115 zum Zweck eines Übertragens der Metrikdaten hin empfangen. Somit beinhaltet der Meßmechanismus 113 die Fähigkeit, dynamisch aktualisiert zu werden. Desgleichen kann der Meßmechanismus 113 Patches für ein Aktualisieren eines Betriebs eines oder mehrerer der Hardwareprodukte 112 empfangen.
Ferner liefert der Meßmechanismus 113 der Clientseite 110 die Mittel zum Aktualisieren einer Konfiguration der Hardwareprodukte 112. Falls beispielsweise ein zusätzliches Hardwareprodukt 112 zu der Clientseite 110 hinzugefügt wird, kann der Meßmechanismus 113 der Serverseite 115 aktualisierte Hardwareproduktinformationen, einschließlich einer Identität des zusätzlichen Hardwareproduktes 112, und jegliche Metrikdaten, die von dem neuen Hardwareprodukt 112 zusammengetragen werden, liefern. Die gespeicherte Hardwareproduktkonfiguration kann ferner zu der Clientseite 110 heruntergeladen werden, falls ein vorhandener Meßmechanismus 113 ersetzt werden sollte oder falls ein zusätzlicher Meßmechanismus 113 zu der Clientseite 110 hinzugefügt werden sollte.
Der Meßmechanismus 113 kann viele Komponenten oder Merkmale beinhalten, die einen Betrieb in einer Vielzahl von Netzumgebungen ermöglichen. Fig. 3 ist ein Blockdiagramm, das ein Ausführungsbeispiel des Meßmechanismus 113 zeigt, der auf der Clientseite 110 implementiert sein kann. Der Meßmechanismus 113 umfaßt eine Regelmaschine 151, einen Prozessor 153, einen Anzeigetreiber 155, eine Kommunikationsmaschine 157, eine Datengewinnungsmaschine 159 und eine Datenbank 161. Die Regelmaschine 151 kann mit generischen und spezifischen Regeln programmiert sein, die sich auf die Aufnahme und das Berichten von Metrikdaten von den Hardwareprodukten 112 beziehen. Beispielsweise kann der Meßmechanismus 113 für die spezifische Clientseite 110 entworfen sein, um kontinuierlich eine CPU-Nutzung zu gewinnen und eine CPU- Nutzung alle fünf Minuten aufzuzeichnen. Die Regelmaschine 151 kann programmiert sein, um zu erfordern, daß der CPU- Nutzungswert, der der Serverseite 115 berichtet wird, für jedes Fünf-Minuten-Intervall eine Spitzen-CPU-Nutzung ist. Alternativ dazu könnte eine Regel festlegen, daß eine durchschnittliche CPU-Nutzung für jedes Fünf-Minuten- Intervall der Serverseite 115 berichtet werden soll. Die Regeln in der Regelmaschine 151 können sich auch auf einen Bezahlen-Pro-Nutzung-Preisfestlegungsplan beziehen, mit dem sich der Client und der serverseitige Betreiber einverstanden erklärt. Beispielsweise kann der Bezahlen-Pro-Nutzung- Preisfestlegungsplan eine erste Fakturierungsrate, die eine Pauschal- oder Mindestgebühr sein kann, falls eine durchschnittliche CPU-Nutzung über einen Zeitraum von 24 Stunden weniger als 20 Prozent beträgt, und eine zweite Fakturierungsrate festlegen, die variieren kann, falls die CPU- Nutzung gleich oder größer als 20 Prozent ist.
Der Prozessor 153 kann eine Vielzahl von Rechenfunktionen für den Meßmechanismus 113 liefern und kann einen Betrieb der Meßmechanismuskomponenten steuern. Der Prozessor 153 kann ferner ein gewisses Vorverarbeiten der von den Hardwareprodukten 112 gewonnenen Metrikdaten liefern. Beispielsweise kann der Prozessor 153 einen Durchschnittswert einer CPU-Nutzung für jedes Fünf-Minuten-Intervall am Tag erstellen. Der Prozessor 153 arbeitet mit der Regelmaschine 151, um zu gewährleisten, daß Metrikdaten, wie sie durch den Bezahlen-Pro-Nutzung-Preisfestlegungsplan festgelegt wurden, gewonnen, verarbeitet und zum Zweck einer Übertragung an die Serverseite 115 verpackt werden. Falls der Bezahlen-Pro-Nutzung-Preisfestlegungsplan beispielsweise festlegt, daß die Hardwareprodukt-Finanzierungsrate auf einer durchschnittlichen CPU-Nutzung beruht, wobei der Durchschnitt über jedes Fünf-Minuten-Intervall ermittelt wird, errechnet der Prozessor 153 die durchschnittliche CPU- Nutzung und stellt die durchschnittliche CPU-Nutzung für eine Übertragung an die Serverseite 115 zur Verfügung. Der Prozessor 153 kann ferner bestimmte Datenwegintegritätsprüfungen beinhalten. Beispielsweise kann der Prozessor 153Routinen zum Testen des Hardwareprodukts zum Meßmechanismus-Transportmechanismus beinhalten, beispielsweise SNMP, WBEM oder HTTP, indem er eine bekannte Antwort von dem Meßagenten 109 erhält.
Der Anzeigetreiber 155 kann eine Software umfassen, die erforderlich ist, um dem Client auf der Clientseite 110 Informationen anzuzeigen. Die Informationen können an einem Monitor, einem Drucker oder einer anderen Anzeigevorrichtung, die mit dem Meßmechanismus 113 gekoppelt ist, angezeigt werden. Die Informationen können ferner über das Netz 118 einem Webbrowser, der an einer Hardwarevorrichtung auf der Clientseite 110 installiert ist, angezeigt werden. Beispiele von Informationen, die auf der Clientseite angezeigt werden können, umfassen eine augenblickliche und durchschnittliche CPU-Nutzung, eine gesamte oder durchschnittliche CPU-Nutzung über 24 Stunden und andere Metrikdaten, einschließlich vorverarbeiteter Metrikdaten, die an dem Meßmechanismus 113 gesammelt werden, und diagnostische und Hilfe-Informationen.
Die Kommunikationsmaschine 157 umfaßt die notwendige Programmierung, um die Metrikdaten, einschließlich vorverarbeiteter Metrikdaten, zum Zweck einer Übertragung an die Serverseite 115 in einem Format, das mit der Verbindung 118 und den serverseitigen Komponenten kompatibel ist, zu verschlüsseln, zu komprimieren und zu verpacken.
Die Datengewinnungsmaschine 159 umfaßt die Programmierung, die benötigt wird, um Daten von den Hardwareprodukten 112 zu gewinnen. Die Programmierung umfaßt die notwendigen Schnittstellen, um mit jeglichen Meßagenten, die an den Hardwareprodukten 112 installiert sind, zu kommunizieren. Die Programmierung kann ferner die Art und Weise diktieren, auf die Metrikdaten gewonnen werden sollen. Beispielsweise kann die Programmierung festlegen, daß der Meßmechanismus 113 jedes der Hardwareprodukte 112 zu einem festgelegten Intervall (z. B. alle fünf Minuten) abruft, um die erforderlichen Metrikdaten wiederzuerlangen. Die Datengewinnungsmaschine 159 kann ferner die Metrikdaten digital signieren, so daß eine etwaige Datenmanipulation erfaßt werden kann.
Die Datenbank 161 speichert eine Vielzahl von Daten, die auf den Bezahlen-Pro-Nutzung-Preisfestlegungsplan bezogen sind. Die Datenbank 161 kann Metrikdaten, einschließlich vorverarbeiteter Metrikdaten, vor einer Übertragung der Metrikdaten an die Serverseite 115 speichern. Beispielsweise kann die Datenbank 161 Metrikdaten 24-Stunden-Intervalle lang speichern, wobei der Meßmechanismus 113 die Metrikdaten alle 24 Stunden an die Serverseite 115 überträgt. Die Datenbank 161 kann fortfahren, die Metrikdaten zu speichern, bis der Meßmechanismus 113 eine Anweisung von der Serverseite 115 empfängt, daß die Metrikdaten aus der Datenbank 161 gelöscht werden können. Auf diese Weise kann die Serverseite 115 die Metrikdaten validieren und deren Genauigkeit und Angemessenheit gewährleisten, bevor die Metrikdaten gelöscht werden. Die Datenbank 161 kann andere Daten und Informationen, beispielsweise Hardwareproduktkonfiguration, Fakturas oder Rechnungen, und andere Informationen, die sich auf den Betrieb und die Verwaltung des Bezahlen-Pro-Nutzung-Preisfestlegungsplans beziehen, speichern.
Wie oben erwähnt wurde, überträgt der Meßmechanismus 113 die Metrikdaten periodisch an die Serverseite 115. Die Periodizität zum Berichten von Metrikdaten kann von Clientseite zu Clientseite variieren und kann innerhalb einer spezifischen Clientseite von Hardwareprodukt zu Hardwareprodukt variieren. Bei einem Ausführungsbeispiel des Systems 100 werden die Metrikdaten täglich an die Serverseite 115 übertragen. Falls die Serverseite 115 nach einem festgelegten Zeitraum, beispielsweise nach drei Tagen, noch keine Metrikdaten von der Clientseite 110 empfangen hat, kann eine E-Mail-Benachrichtigung an eine festgelegte E-Mail-Adresse auf der Clientseite 110 gesandt werden. Alternativ oder zusätzlich dazu kann der Clientseite, falls auf der Serverseite 115 keine Metrikdaten für die Clientseite 110 empfangen werden, eine festgelegte Gebühr für den Zeitraum, für den keine Metrikdaten geliefert wurden, berechnet werden. Beispielsweise könnte dem Client eine Rechnung über 50 Prozent der maximalen Nutzung für jeden Zeitraum, der nicht durch die Metrikdaten abgedeckt ist, in Rechnung gestellt werden. Das Nutzungsdepot 120, und insbesondere der Validierungsserver 121, verarbeitet anschließend die gesammelten Metrikdaten als Schritt beim Abschließen einer Faktura oder Rechnung für eine Nutzung der Hardwareprodukte 112. Der Validierungsserver 121 kann die Metrikdaten entschlüsseln und dekomprimieren und anschließend eine Anzahl von Routinen durchführen, um die Daten vor einem Verarbeiten zum Zweck einer Fakturaerstellung zu validieren.
Der Validierungsserver 121 kann auf der Basis der von der Clientseite 110 empfangenen Metrikdaten eine oder mehrere Validierungs- oder Prüffunktionen durchführen. Eine erste bzw. Konfigurationsvalidierungsfunktion kann sich darauf beziehen, zu gewährleisten, daß eine ursprüngliche, abgesegnete Konfiguration der Hardwareprodukte 112 auf der Clientseite 110 nicht durch den Client oder eine andere Entität verändert oder modifiziert wurde. Die Konfigurationsvalidierung kann auf einer Konfigurationsdatei für die Clientseite 110, die in der Nutzungsdatenbank 123 gespeichert ist, beruhen. Wie oben erwähnt wurde, kann, wenn sich die Hardwareproduktkonfiguration auf der Clientseite 110 ändert (durch abgesegnete Prozesse, beispielsweise erneut überprüfte Finanzierungsvereinbarungen oder Hardwareproduktverbesserungen), die Hardwareproduktkonfigurationsdatei für die Clientseite 110 aktualisiert werden. Die Hardwareproduktkonfiguration kann im Fall eines Webservers beispielsweise durch ein Hinzufügen oder Entfernen eines Prozessors, ein Hinzufügen oder Entfernen eines Speichers oder durch ein Hinzufügen oder Entfernen von Festplattenlaufwerken verändert werden.
Als ein alternatives Mittel zum Validieren der Konfiguration könnte der Validierungsserver 121 die Hardwareproduktkonfiguration bemerken, wenn Metrikdaten von der Clientseite 110 empfangen werden, und kann diese Konfiguration in der Nutzungsdatenbank 123 speichern. Das nächste Mal, wenn der Validierungsserver 121 Metrikdaten von derselben Clientseite 110 empfängt, kann der Validierungsserver 121 die aktuelle Hardwareproduktkonfiguration empfangen. Der Validierungsserver 121 kann anschließend die aktuelle Hardwareproduktkonfiguration mit der vorherigen Hardwareproduktkonfiguration, die in der Nutzungsdatenbank 123 gespeichert ist, vergleichen. Etwaige Unterschiede bei der Hardwareproduktkonfiguration können bemerkt werden und können den Validierungsserver 121 veranlassen, eine spezifische Aktion auszuführen, beispielsweise einschließlich einer Erstellung einer Fehlermeldung zum Zweck einer Anzeige für Betreiber der Serverseite 115. Eine aktualisierte Hardwarekonfigurationsdatei kann für den Client durch den Meßmechanismus 113 oder, wie unten erörtert wird, durch das Portal 130 zur Verfügung stehen.
Andere Validierungsfunktionen können sich auf das Format und die Annehmbarkeit der Metrikdaten beziehen. Beispielsweise kann der Validierungsserver 121 gewährleisten, daß die Metrikdaten nicht verfälscht sind, daß die von der Clientseite 110 empfangenen Metrikdaten in einen Bereich erwarteter Werte für die Daten fallen, und andere Validierungsprüfungen. Als spezifisches Beispiel, falls die Clientseite 110 drei Webserver als die Hardwareprodukte 112 aufweist und sich die empfangenen Metrikdaten auf Stunden oder einen Prozentsatz einer CPU-Nutzung beziehen, wäre die maximale Anzahl an Stunden für alle drei Webserver an einem Tag jeweils 24 Stunden, und der maximale Prozentsatz einer CPU-Nutzung wäre 100 Prozent. Jegliche Metrikdaten, die diese maximalen Werte überschreiten, wären fehlerhaft, und der Validierungsserver 121 könnte das Fehlerereignis bemerken, ein Verarbeiten stoppen und eine Fehlermeldung erstellen. Der Validierungsserver 121 könnte andere Kriterien oder Regeln beinhalten, anhand derer die Genauigkeit und Angemessenheit der empfangenen Metrikdaten beurteilt werden kann. Der Validierungsserver 121 kann die empfangenen Metrikdaten ferner prüfen, um zu bestimmen, ob jemand die Metrikdaten, wie sie an den Hardwareprodukten gesammelt wurden, manipuliert hat. Dieser Manipulationsprüfprozeß kann ausgeführt werden, indem die digitale Signatur, oben erwähnt, die durch den Meßmechanismus 113 an die Metrikdaten angehängt werden kann, verwendet wird. Es können auch andere Fehlerprüf- und Testroutinen in das System 100 integriert werden. Beispielsweise kann die Integrität des Transportmechanismus von der Clientseite zu der Serverseite, wenn der Transportmechanismus HTTP- oder HTTPLS- Protokolle verwendet, durch ein Hochladen einer Testdatei von dem Meßmechanismus 113 zu dem Nutzungsdepot 120 verifiziert werden.
Die Nutzungsdatenbank 123 speichert Metrikdaten, einschließlich Metrikdaten, die durch den Meßmechanismus 113 vorverarbeitet und durch den Validierungsserver 121 verarbeitet werden, und unverarbeiteter Metrikdaten, für jede der verbundenen Clientseiten 110. Die Nutzungsdatenbank 123 speichert ferner Hardwareproduktkonfigurationsdaten, Nutzungsberichte und andere Daten, die auf einen Betrieb und eine Verwaltung des Bezahlen-Pro-Nutzung-Preisfestlegungsplans bezogen sind.
Unter erneuter Bezugnahme auf Fig. 2 dient das Portal 130 als Kommunikationsschnittstelle zwischen der Clientseite 110 und der Serverseite 115. Das Portal 130 liefert ein Mittel, anhand dessen der Client Daten auf der Serverseite 115 einsehen kann, und ein Mittel für eine Fakturavorlage und Zahlung. Das Portal 130 umfaßt einen Nutzungsberichte- Mechanismus 131, mittels dessen dem Client Informationen vorgelegt werden können, die sich auf einen Betrieb der Hardwareprodukte 112 beziehen. Insbesondere kann der Nutzungsberichte-Mechanismus 131 dem Client einen Zugriff auf alle verarbeiteten und unverarbeiteten Metrikdaten für die Clientseite 110 gewähren. Der Nutzungsberichte-Mechanismus 131 kann ferner ein Mittel für den Client bereitstellen, um mit der Serverseite 115 zu kommunizieren, um bezüglich der Hardwareprodukte 112, des Bezahlen-Pro-Nutzung-Leasingplans und anderer Angelegenheiten in punkto Administration und Buchhaltung nachzufragen. Ein Zugriff auf das Portal 130 durch den Client kann unter Verwendung verschiedener Sicherheitsmaßnahmen, beispielsweise eines Benutzernamens und eines Paßworts, gesteuert werden. Ein Fakturavorlagemechanismus 133 kann verwendet werden, um der Clientseite 110 eine elektronische Kopie einer aktuellen Faktura oder Rechnung zu liefern. Der Mechanismus 133 kann die Rechnung als E-Mail-Anhang, eine herunterladbare elektronische Datei, die an einer Server-Website plaziert ist, oder in einer beliebigen anderen Form einer elektronischen Fakturavorlage bereitstellen. Ein Fakturazahlungsmechanismus 135 kann es dem Client ermöglichen, für ein Leasen der Hardwareprodukte 112 unter Verwendung einer standardmäßigen Form eines elektronischen Zahlungsverkehrs; einer Zahlung per Kreditkarte oder einer anderen Zahlungsform über ein Kommunikationsnetz zu zahlen. Der Fakturazahlungsmechanismus 135 kann ferner eine gebührenfreie Telefonnummer (800-Nr.) bereitstellen, mit der der Client anrufen kann, um eine Zahlung der Rechnung zu arrangieren.
Das Fakturierungs- und Buchhaltungssystem 140 umfaßt ein Fakturierungssystem 141, ein Administrationssystem 143 und eine Fakturierungs-/Administrationsdatenbank 145. Das Fakturierungssystem 141 empfängt Nutzungsdaten von dem Nutzungsdepot 120 und erstellt eine Faktura oder Rechnung zur Vorlage beim Client unter Verwendung des Portals 130. Das Administrationssystem 143 führt verschiedene administrative Funktionen für die Serverseite 115 durch. Die Datenbank 145 speichert verschiedene Fakturierungs- und administrative Daten, einschließlich Clientdaten.
Wie in Fig. 2 gezeigt ist, ist das Fakturierungs- und Buchhaltungssystem 140 in die Serverseite 115 integriert. Jedoch kann das Fakturierungs- und Buchhaltungssystem 140 auch an einer von der Serverseite 115 entfernten Stelle angeordnet sein und kann durch eine andere Entität als den serverseitigen Betreiber betrieben werden.
Fig. 4 ist ein Flußdiagramm, das einen Betrieb 200 des Systems 100 der Fig. 2 veranschaulicht, bei dem der Meßmechanismus 113 auf der Clientseite 110 angeordnet ist. Der Betrieb 200 bezieht sich auf eine Metrikdatensammlung und -fakturierung und beginnt bei Block 205. Bei Block 210 ruft der Meßmechanismus 113 die Hardwareprodukte 112 auf der Clientseite 110 ab, um Metrikdaten wiederzuerlangen. Bei Block 215 empfangen die Hardwareprodukte 112 den Abrufbefehl und leiten eine Aktion ein, um die angeforderten Metrikdaten zu gewinnen und/oder bereitzustellen. Eine solche Gewinnung kann sich auf einen Meßagenten stützen, der in jedes der Hardwareprodukte 112 integriert ist. Ferner kann jedes der Hardwareprodukte 112 ein unterschiedliches Abrufintervall aufweisen, auch bei gleichen oder ähnlichen Hardwareprodukten 112. Die Hardwareprodukte 112 übertragen anschließend die Metrikdaten an den Meßmechanismus 113.
Bei einer Alternative zu einem Abrufen kann sich der Meßmechanismus 113 darauf stützen, daß die Meßagenten die Metrikdaten ohne ein Abrufen bereitstellen. Bei diesem Ausführungsbeispiel sammeln die Meßagenten die Metrikdaten an festgelegten Sammelintervallen und leiten eine Kommunikation mit dem Meßmechanismus 113 ein. Der Meßmechanismus 113 kann eingestellt sein, um Metrikdaten von den Meßagenten zu empfangen. Der Meßmechanismus 113 kann mehrere Male pro Stunde Metrikdaten empfangen, je nach dem Typ von Metrikdaten, der gerade gesammelt wird. Beispielsweise kann der Meßmechanismus 113 eingestellt sein, um alle 20 Minuten für insgesamt 72 Intervalle pro Tag Daten zu sammeln.
Bei einer weiteren Alternative kann der Meßmechanismus 113 auf bestimmte Betriebsdaten zugreifen, die sich auf die Hardwareprodukte 112 beziehen, um die Metrikdaten zusammenzutragen.
Bei Block 220 speichert der Meßmechanismus 113 die gesammelten Metrikdaten. Bei Block 225 kann der Meßmechanismus 113 ein jegliches erforderliches Vorverarbeiten der gewonnenen Metrikdaten durchführen. Etwaige vorverarbeitete Metrikdaten können anschließend in einer Datenbank in dem Meßmechanismus 113 gespeichert werden.
Bei Block 230 verschlüsselt, komprimiert und verpackt der Meßmechanismus 113 die Metrikdaten zum Zweck einer Übertragung an die Serverseite 115 und überträgt anschließend das Datenpaket. Eine Übertragung des Datenpakets kann normalerweise durch den Meßmechanismus 113 eingeleitet werden, wenn der Meßmechanismus 113 auf der Clientseite 110 implementiert ist. Wenn er auf der Serverseite 115 implementiert ist, kann der Meßmechanismus 113 eine Auf-Anfrage- Übertragung der Metrikdaten einleiten. Bei beiden Ausführungsbeispielen kann die Übertragung in vorbestimmten Intervallen stattfinden, oder wenn andere Kriterien, beispielsweise eine Akkumulierung einer festgelegten Anzahl von Bytes, erfüllt sind.
Bei Block 235 empfängt der Validierungsserver 121 auf der Serverseite 115 das Datenpaket, dekomprimiert und entschlüsselt das Datenpaket, speichert die entschlüsselten Daten und führt jegliche erwünschten Datenvalidierungsroutinen durch, einschließlich Routinen, um die Konfiguration der Hardwareprodukte 112 zu verifizieren. Bei Block 237 bestimmt der Validierungsserver 121 auf der Basis der Ausführung der Validierungsroutinen, ob die Metrikdaten gültig sind und ob die Hardwareproduktkonfiguration unverändert ist. Falls beide Bedingungen erfüllt sind, geht der Betrieb zu Block 240 weiter. Andernfalls bewegt sich der Betrieb 200 zu Block 239, und es wird eine Fehlermeldung erstellt. Anschließend an Block 239 bewegt sich die Operation 200 zu Block 270 und endet.
Bei Block 240 verarbeitet der Validierungsserver 121 die Metrikdaten gemäß dem Bezahlen-Pro-Nutzung-Preisfestlegungsplan für die Clientseite 110. Bei Block 245 werden die verarbeiteten Metrikdaten in der Nutzungsdatenbank 123 gesichert.
Bei Block 250, nachdem ausreichende verarbeitete Metrikdaten in der Nutzungsdatenbank 123 gespeichert wurden, erstellt der Validierungsserver 121 einen Nutzungsbericht, sichert den Nutzungsbericht in der Nutzungsdatenbank 123 und liefert den Nutzungsbericht an das Portal 130 und an das Fakturierungs- und Buchhaltungssystem 140. Bei Block 255 erstellt das Fakturierungssystem 141 eine elektronische Rechnung und plaziert die Rechnung an dem Portal 130. Bei Block 260 präsentiert das Portal 130 die Rechnung der Clientseite 110. Eine solche Präsentation kann mittels einer E-Mail-Benachrichtigung oder durch ein Senden der Rechnung direkt an die Clientseite 110 erfolgen. Bei Block 265 empfängt die Serverseite 115 eine Zahlung auf der Basis der Rechnung. Eine solche Zahlung kann beispielsweise mittels eines elektronischen Zahlungsverkehrs erfolgen. Anschließend bewegt sich der Betrieb 200 zu Block 270 und endet.
Während das Hardware-Bezahlen-Pro-Nutzung-System und das entsprechende Verfahren in Verbindung mit beispielhaften Ausführungsbeispielen beschrieben wurden, werden Fachleute ohne weiteres erkennen, daß die hierin erörterten Konzepte auch auf andere Variationen und Ausführungsbeispiele ausgedehnt werden können und daß diese Anmeldung diese Variationen abdecken würde.

Claims

1. Hardware-Bezahlen-Pro-Nutzung-System (100), das folgende Merkmale aufweist:
ein oder mehrere Hardwareprodukte (112);
einen Meßmechanismus (113), der mit zumindest einem des einen oder der mehreren Hardwareprodukte (112) gekoppelt ist, wobei der Meßmechanismus (113) eine von dem einen oder den mehreren Hardwareprodukten getrennte Hardwarevorrichtung umfaßt, wobei der Meßmechanismus Metrikdaten von dem einen oder den mehreren Hardwareprodukten gewinnt, wobei die Metrikdaten auf einen Betrieb an dem einen oder den mehreren Hardwareprodukten bezogen sind und wobei der Meßmechanismus zu berichtende Daten ermittelt, die bezüglich des Betriebs des einen oder der mehreren Hardwareprodukte zu berichten sind; und
ein mit dem Meßmechanismus (113) gekoppeltes Nutzungsdepot (120), das die ermittelten Daten empfängt und Nutzungsberichte erstellt, die auf den Betrieb des einen oder der mehreren Hardwareprodukte (112) bezogen sind.

2. System gemäß Anspruch 1, das ferner ein Fakturierungs- und Buchhaltungssystem (140) aufweist, das mit dem Nutzungsdepot (120) gekoppelt ist und die Nutzungsberichte empfängt, wobei eine Bezahlen-Pro-Nutzung- Rechnung auf der Basis der Nutzungsberichte ermittelt wird.

3. System gemäß Anspruch 2, das ferner ein mit dem Nutzungsdepot (120) und dem Fakturierungs- und Buchhaltungssystem (140) gekoppeltes Portal aufweist, das folgende Merkmale aufweist:
einen Nutzungsberichte-Mechanismus (131), bei dem die Nutzungsberichte anzeigbar sind;
einen Rechnungsvorlagemechanismus (133), bei dem die Rechnung vorlegbar ist; und
einen Rechnungszahlungsmechanismus (135), bei dem eine Zahlung bezüglich der Rechnung empfangen werden kann.

4. System gemäß einem der Ansprüche 1 bis 3, bei dem das Nutzungsdepot (120) folgende Merkmale aufweist:
einen Validierungsserver (121); und
eine mit dem Validierungsserver gekoppelte Nutzungsdatenbank (123), wobei der Validierungsserver die an dem Nutzungsdepot empfangenen ermittelten Daten validiert und eine korrekte Konfiguration des einen oder der mehreren Hardwareprodukte (112) verifiziert und wobei die Nutzungsdatenbank (123) die ermittelten Daten und die Nutzungsberichte speichert.

5. System gemäß einem der Ansprüche 1 bis 4, bei dem der Meßmechanismus (113) eine gestellmontierbare Hardwarevorrichtung in einem vernetzten Computersystem ist.

6. System gemäß einem der Ansprüche 1 bis 5, bei dem der Meßmechanismus (113) ein alleinstehender Computer ist.

7. System gemäß einem der Ansprüche 1 bis 6, bei dem der Meßmechanismus (113) ein Teil eines Servers ist, der mit dem einen oder den mehreren Hardwareprodukten (112) gekoppelt ist.

8. System gemäß einem der Ansprüche 1 bis 7, bei dem eines oder mehrere des einen oder der mehreren Hardwareprodukte (112) Meßagenten (109) aufweist beziehungsweise aufweisen, die die durch den Meßmechanismus (113) gewonnenen Metrikdaten sammeln.

9. System gemäß einem der Ansprüche 1 bis 8, bei dem der Meßmechanismus (113) eine Regelmaschine (151) aufweist und bei dem Regeln in der Regelmaschine verwendet werden, um die zu berichtenden Daten zu ermitteln.

10. System gemäß einem der Ansprüche 1 bis 9, bei dem der Meßmechanismus (113) eine Abrufmaschine aufweist, wobei der Meßmechanismus das eine oder die mehreren Hardwareprodukte (112) abruft, um die Metrikdaten zu gewinnen.

11. System gemäß einem der Ansprüche 1 bis 10, bei dem das eine oder die mehreren geleasten Hardwareprodukte (112) die Metrikdaten auf einer periodischen Basis liefern.

12. System gemäß einem der Ansprüche 1 bis 11, bei dem der Betrieb eine Zentralverarbeitungseinheit-Nutzung (CPU- Nutzung) ist.

13. System gemäß einem der Ansprüche 1 bis 12, bei dem das eine oder die mehreren Hardwareprodukte (112) geleast sind.

14. System gemäß einem der Ansprüche 1 bis 13, bei dem der Meßmechanismus (113) an einer ersten Stelle angeordnet ist, die eine selbe Stelle wie die des einen oder der mehreren Hardwareprodukte (112) ist, und bei dem das Nutzungsdepot (120) an einer von der ersten Stelle entfernten zweiten Stelle angeordnet ist.

15. System gemäß einem der Ansprüche 1 bis 14, bei dem die erste Stelle und die zweite Stelle Internet-Websites sind.

16. System gemäß einem der Ansprüche 1 bis 15, bei dem der Meßmechanismus (113) und das Nutzungsdepot (120) an einer von dem einen oder den mehreren Hardwareprodukten (112) entfernten Stelle angeordnet sind.

17. System gemäß einem der Ansprüche 1 bis 16, bei dem die Stelle eine Internet-Website ist.

18. Verfahren zum Festlegen des Preises einer Hardware auf einer Bezahlen-Pro-Nutzung-Basis, wobei eines oder mehrere Hardwareprodukte (112) mit einem Kommunikationsnetz (118) gekoppelt sind, wobei das Verfahren folgende Schritte aufweist:
Gewinnen, in einer Hardwarevorrichtung (113), die von dem einen oder den mehreren Hardwareprodukten (112) getrennt ist, von Metrikdaten, die auf einen Betrieb des einen oder der mehreren Hardwareprodukte (112) bezogen sind;
Ermitteln von zu berichtenden Daten auf der Basis des Gewinnungsschrittes;
Senden der ermittelten Daten an ein Nutzungsdepot (120);
Erstellen eines Nutzungsberichts; und
Erstellen einer Bezahlen-Pro-Nutzung-Rechnung auf der Basis des Nutzungsberichts.

19. Verfahren zum Festlegen des Preises einer Hardware auf einer Bezahlen-Pro-Nutzung-Basis, wobei eines oder mehrere Hardwareprodukte (112) mit einem Kommunikationsnetz (118) gekoppelt sind, wobei das Verfahren folgende Schritte aufweist:
Gewinnen, in einer Hardwarevorrichtung (113), die von dem einen oder den mehreren Hardwareprodukten (112) getrennt ist, von Metrikdaten, die auf einen Betrieb des einen oder der mehreren Hardwareprodukte (112) bezogen sind;
Ermitteln von zu berichtenden Daten auf der Basis des Gewinnungsschrittes;
Senden der ermittelten Daten an ein Nutzungsdepot (120);
Empfangen einer Bezahlen-Pro-Nutzung-Rechnung, wobei die Bezahlen-Pro-Nutzung-Rechnung auf den an das Nutzungsdepot (120) gesandten Daten beruht.

20. Verfahren zum Festlegen des Preises einer Hardware auf einer Bezahlen-Pro-Nutzung-Basis, bei dem sich ein oder mehrere Hardwareprodukte (112) an einem mit einem Kommunikationsnetz (118) gekoppelten Knoten (110) befinden, wobei das Verfahren folgende Schritte aufweist:
Empfangen, an einem Nutzungsdepot (120), von Metrikdaten auf der Basis eines Betriebs des einen oder der mehreren Hardwareprodukte, wobei die Metrikdaten durch einen Meßmechanismus (113) geliefert werden, der von dem einen oder den mehreren Hardwareprodukten getrennt ist;
Erstellen eines Nutzungsberichts;
Erstellen einer Bezahlen-Pro-Nutzung-Rechnung auf der Basis des Nutzungsberichts; und
Präsentieren der Rechnung bei dem Knoten (110).

21. Verfahren gemäß Anspruch 20, das ferner den Schritt des Empfangens einer Zahlung bezüglich der Rechnung umfaßt.

22. Verfahren gemäß Anspruch 20 oder 21, bei dem der Schritt des Erstellens des Nutzungsberichts folgenden Schritt aufweist:
Anwenden einer oder mehrerer Regeln auf die Metrikdaten, wobei eine Anwendung der Regeln die Metrikdaten zu einer Datenstruktur verarbeitet, die einen Betrieb des einen oder der mehreren Hardwareprodukte (112) darstellt.

23. Verfahren gemäß Anspruch 22, bei dem der Schritt des Erstellens der Bezahlen-Pro-Nutzung-Rechnung ein Vergleichen der Nutzungsberichte mit einem Bezahlen-Pro- Nutzung-Preisfestlegungsplan umfaßt, wobei der Preisfestlegungsplan eine auf den Metrikdaten beruhende Finanzierungsratenkomponente festlegt.

24. Verfahren gemäß Anspruch 23, bei dem die Finanzierungsratenkomponente mit Variationen der Metrikdaten variiert.

25. Verfahren gemäß einem der Ansprüche 22 bis 24, bei dem die empfangenen Metrikdaten auf der Basis einer oder mehrerer gelieferter Geschäftsregeln ermittelt werden.

26. Verfahren gemäß Anspruch 25, bei dem sich der Betrieb auf eine Zentralprozessornutzung über ein gegebenes Zeitintervall bezieht und bei dem angewandte Geschäftsregeln ein Berichten über eine Spitzennutzung über das Zeitintervall hinweg erfordern.

27. Verfahren zum Festlegen des Preises eines Hardwareprodukts (112) auf der Basis von Betriebsdaten, die von dem Hardwareprodukt gesammelt werden, wobei das Verfahren folgende Schritte aufweist:
Liefern eines Meßmechanismus (113), der von dem Hardwareprodukt (112) getrennt ist und der die Betriebsdaten von dem Hardwareprodukt (112) erhält; und
Liefern der erhaltenen Betriebsdaten an eine Verarbeitungsvorrichtung, bei der Nutzungsdaten berechnet werden; und
Erstellen einer Bezahlen-Pro-Nutzung-Rechnung auf der Basis der Nutzungsdaten und eines Bezahlen-Pro- Nutzung-Preisfestlegungsplans.

28. Verfahren gemäß Anspruch 27, das ferner den Schritt des Bereitstellens des Meßmechanismus (113) mit einer Abruffunktion umfaßt, bei der das Hardwareprodukt (112) abgerufen wird, um die Betriebsdaten zu erhalten.

29. Verfahren gemäß Anspruch 27 oder 28, bei dem das Hardwareprodukt (112) geleast wird, wobei die Bezahlen- Pro-Nutzung-Rechnung einem Leasingnehmer des Hardwareprodukts (112) präsentiert wird.

30. Verfahren gemäß Anspruch 29, das ferner den Schritt des Empfangens einer Anfrage von dem Leasingnehmer umfaßt.

31. Verfahren gemäß Anspruch 29 oder 30, das ferner den Schritt des Bereitstellens einer Einrichtung zum Anzeigen der Nutzungsdaten und einer Einrichtung zum Empfangen einer Zahlung bezüglich der Rechnung umfaßt.

32. Verfahren gemäß einem der Ansprüche 27 bis 31, das ferner folgende Schritte aufweist:
Validieren der erhaltenen Betriebsdaten;
Verifizieren einer bewilligten Konfiguration des Hardwareprodukts (112); und
Sichern der Betriebsdaten.

33. Verfahren gemäß einem der Ansprüche 27 bis 32, bei dem der Meßmechanismus (113) an einer ersten Stelle vorgesehen ist, die eine selbe Stelle wie die des Hardwareprodukts (112) ist, und bei dem die Verarbeitungsvorrichtung an einer von der ersten Stelle entfernten zweiten Stelle vorgesehen ist.

34. Verfahren gemäß Anspruch 33, bei dem die erste Stelle und die zweite Stelle Internet-Websites sind.

35. Verfahren gemäß einem der Ansprüche 27 bis 34, bei dem der Meßmechanismus (113) und die Verarbeitungsvorrichtung an einer von dem Hardwareprodukt (112) entfernten Stelle vorgesehen sind.

36. Verfahren gemäß Anspruch 35, bei dem die Stelle eine Internet-Website ist.

37. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan, der folgende Schritte aufweist:
Liefern eines Hardwareprodukts (112) an einen Client an einer Clientstelle;
Liefern eines Bezahlen-Pro-Nutzung-Plans, wobei der Plan auf zumindest einer von dem Hardwareprodukt (112) gewonnenen Metrik beruht; und
Beliefern der Clientstelle mit einem Mechanismus, der von dem Hardwareprodukt (112) getrennt ist und die zumindest eine Metrik gewinnt und die zumindest eine Metrik an einen von der Clientstelle entfernten Ort überträgt.

38. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß Anspruch 37, bei dem der Mechanismus das Hardwareprodukt (112) abruft, um die zumindest eine Metrik zu erhalten.

39. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß Anspruch 37 oder 38, der ferner folgende Schritte aufweist:
Erstellen eines Nutzungsberichts auf der Basis der zumindest einen Metrik;
Berechnen einer Bezahlen-Pro-Nutzung-Rechnung auf der Basis der zumindest einen Metrik; und
Präsentieren der Bezahlen-Pro-Nutzung-Rechnung gegenüber dem Client.

40. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß Anspruch 39, der ferner den Schritt des Zurverfügungstellens des Nutzungsberichts gegenüber dem Client aufweist.

41. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß einem der Ansprüche 27 bis 40, bei dem die zumindest eine Metrik auf einer periodischen Basis an die entfernte Stelle übertragen wird.

42. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß einem der Ansprüche 32 bis 41, bei dem die periodische Basis täglich bedeutet.

43. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß einem der Ansprüche 27 bis 42, bei dem eine anfängliche Konfiguration des Hardwareprodukts (112) an dem entfernten Ort gespeichert ist und bei dem die entfernte Stelle:
die zumindest eine Metrik validiert; und
verifiziert, ob eine aktuelle Konfiguration des Hardwareprodukts (112) mit der anfänglichen Konfiguration übereinstimmt.

44. Bezahlen-Pro-Nutzung-Hardware-Finanzierungsplan gemäß einem der Ansprüche 37 bis 43, der ferner den Schritt des Bereitstellens eines Softwaremeßagenten mit dem Hardwareprodukt (112) umfaßt.

45. Hardware-Bezahlen-Pro-Nutzung-System, das folgende Merkmale aufweist:
eine Einrichtung zum Empfangen von Metrikdaten von dem einen oder den mehreren Hardwareprodukten (112);
eine mit der Empfangseinrichtung gekoppelte Einrichtung zum Berechnen von Nutzungs- und Fakturierungsdaten aus den empfangenen Metrikdaten;
eine mit der Recheneinrichtung gekoppelte Einrichtung zum Erstellen einer Rechnung auf der Basis der berechneten Nutzungs- und Fakturierungsdaten.

46. System gemäß Anspruch 45, bei dem ein oder mehrere Hardwareprodukte zum Zweck einer Installation an einer Clientstelle an einen Client geleast werden.

47. System gemäß Anspruch 46, bei dem die Clientstelle eine Stelle in einem digitalen Kommunikationsnetz (118) ist.

48. System gemäß einem der Ansprüche 45 bis 47, bei dem die Empfangseinrichtung folgende Merkmale umfaßt:
eine Einrichtung zum Validieren der empfangenen Metrikdaten;
eine Einrichtung zum Verifizieren einer Konfiguration des einen oder der mehreren Hardwareprodukte (112); und
eine Einrichtung zum Speichern der Metrikdaten und der Konfiguration.

49. System gemäß einem der Ansprüche 45 bis 48, das ferner folgende Merkmale aufweist:
eine mit dem einen oder den mehreren Hardwareprodukten (112) gekoppelte Einrichtung zum Erhalten der Metrikdaten von dem einen oder den mehreren Hardwareprodukten, wobei die Einrichtung folgende Merkmale umfaßt:
eine in dem einen oder den mehreren Hardwareprodukten installierte Einrichtung zum Sammeln der Metrikdaten; und
eine mit der Sammeleinrichtung gekoppelte Einrichtung zum Gewinnen der gesammelten Metrikdaten, wobei die Gewinnungseinrichtung eine von den Hardwareprodukten getrennte alleinstehende Hardwarevorrichtung ist.

50. System gemäß einem der Ansprüche 45 bis 49, das ferner folgende Merkmale aufweist:
eine mit der Erstellungseinrichtung gekoppelte Einrichtung zum Erstellen eines Nutzungsberichts auf der Basis der empfangenen Nutzungsdaten; und
eine Einrichtung zum Präsentieren des Nutzungsberichts gegenüber einem Client.

51. System gemäß einem der Ansprüche 45 bis 50, das ferner folgende Merkmale aufweist:
eine Einrichtung zum Präsentieren der Rechnung gegenüber einem Client; und
eine Einrichtung zum Empfangen einer Zahlung von dem Client auf der Basis der Rechnung.

52. Hardware-Bezahlen-Pro-Nutzung-System ist gemäß einem der Ansprüche 45 bis 51, bei dem zumindest eines des einen oder der mehreren Hardwareprodukte (112) eine gebündelte Software umfaßt und bei dem die Einrichtung zum Erstellen der Rechnung eine Einrichtung zum Festlegen eines Preises einer Nutzung der gebündelten Software auf der Basis von Hardware-Metrikdaten umfaßt.

53. Vorrichtung zum Gewinnen von Metrikdaten von Hardwareprodukten (112) in einem Hardware-Bezahlen-Pro- Nutzung-System (100), die mit den Hardwareprodukten (112) gekoppelt ist und folgende Merkmale aufweist:
eine Regelmaschine (151), die eine oder mehrere Geschäftsregeln zum Gewinnen der Metrikdaten umfaßt;
einen mit der Regelmaschine gekoppelten Prozessor, der einen Betrieb der Vorrichtung steuert; und
eine mit dem Prozessor gekoppelte Datengewinnungsmaschine, die ein Programmieren umfaßt, wodurch die Metrikdaten von den Hardwareprodukten (112) gewonnen werden, wobei das Programmieren ein Transportprotokoll und eine Schnittstelle zum Transportieren der Metrikdaten von den Hardwareprodukten (112) zu der Vorrichtung umfaßt und wobei die Vorrichtung von den Hardwareprodukten (112) getrennt ist.

54. Vorrichtung gemäß Anspruch 53, die ferner folgende Merkmale aufweist:
eine Kommunikationsmaschine, durch die die Metrikdaten zum Zweck einer Lieferung an einen entfernten Ort verschlüsselt, komprimiert und verpackt werden;
einen Anzeigetreiber, durch den spezifizierte Metrikdaten zur Anzeige bereitgestellt werden; und
eine Datenbank, die die durch die Vorrichtung gewonnenen Metrikdaten speichert.

55. Vorrichtung gemäß Anspruch 53 oder 54, bei der der Prozessor folgende Merkmale aufweist:
eine Einrichtung zum Testen eines ersten Transportmechanismus von den Hardwareprodukten (112) zu der Vorrichtung; und
eine Einrichtung zum Testen eines zweiten Transportmechanismus von der Vorrichtung zu einem entfernten Ort.

56. Vorrichtung gemäß Anspruch 55, bei der der erste und der zweite Transportmechanismus eines oder mehrere der folgenden umfassen: SNMP, WBEM, HTTP, HTTP/S, und E-Mail.

57. Vorrichtung gemäß Anspruch 55 oder 56, bei der die Einrichtung zum Testen des zweiten Transportmechanismus ein Hochladen einer Testdatei von der Vorrichtung zu dem entfernten Ort umfaßt.

58. Vorrichtung gemäß einem der Ansprüche 55 bis 57, bei der die Einrichtung zum Testen des ersten Transportmechanismus ein Erhalten einer bekannten. Antwort von den Hardwareprodukten (112) umfaßt.

59. Vorrichtung gemäß Anspruch 58, bei der die Hardwareprodukte (112) Meßagenten (109) aufweisen und bei der die bekannte Antwort durch die Meßagenten bereitgestellt wird.

60. Vorrichtung gemäß einem der Ansprüche 53 bis 59, bei der die Metrikdaten durch die Vorrichtung über das Internet gewonnen werden.

61. Vorrichtung gemäß einem der Ansprüche 53 bis 60, bei der die Metrikdaten durch die Vorrichtung über ein digitales Datenkommunikationsnetz (118) gewonnen werden.