DE102016013586A1 - Robustes Rechenvorrichtungsidentifizierungssystem - Google Patents

Robustes Rechenvorrichtungsidentifizierungssystem Download PDF

Info

Publication number
DE102016013586A1
DE102016013586A1 DE102016013586.7A DE102016013586A DE102016013586A1 DE 102016013586 A1 DE102016013586 A1 DE 102016013586A1 DE 102016013586 A DE102016013586 A DE 102016013586A DE 102016013586 A1 DE102016013586 A1 DE 102016013586A1
Authority
DE
Germany
Prior art keywords
server
rrg
client device
client
tuple
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.)
Pending
Application number
DE102016013586.7A
Other languages
English (en)
Inventor
Sanjeev Kumar Biswas
Mayank Goyal
Sharad Srivastava
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.)
Adobe Inc
Original Assignee
Adobe Systems Inc
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 Adobe Systems Inc filed Critical Adobe Systems Inc
Publication of DE102016013586A1 publication Critical patent/DE102016013586A1/de
Pending legal-status Critical Current

Links

Images

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
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/305—Authentication, i.e. establishing the identity or authorisation of security principals by remotely controlling device operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Eine Clientvorrichtung wird während einer Zeitspanne unter Verwendung von „Auffrischungstokens” nachverfolgt, die in Verbindung mit routinemäßigen Client-Server-Kommunikationen ausgetauscht werden. Jeder Kommunikationszyklus zwischen Client und Server beinhaltet ein Auffrischungstoken, das an dem Server aufgezeichnet wird. Die aufgezeichneten Auffrischungstokens werden sowohl auf server- wie auch clientseitig erzeugte Vorrichtungsidentifizierer abgebildet. Treten Kommunikationen zwischen Client und Server auf, so wird eine Kette von Tokens, und zwar eines für jeden Kommunikationszyklus, progressiv bzw. fortlaufend an dem Server aufgezeichnet. Empfängt der Server ein Token, das in Bezug auf dasjenige, das andernfalls auf Grundlage der Progression bzw. des Fortlaufens der aufgezeichneten Kette erwartet wird, veraltet ist, so legt dies nahe, dass die empfangene Kommunikation von einer Vorrichtung, die ein Klon einer anderen Clientvorrichtung ist, übertragen worden ist. Verwirklicht ist daher ein robusteres Vorrichtungsidentifizierungssystem, das eine Kombination aus Vorrichtungsidentifizierern und Tokens, die zwischen Client und Server ausgetauscht werden, verwendet.

Description

  • Gebiet der Offenbarung
  • Die vorliegende Offenbarung betrifft allgemein die Identifizierung von Rechenvorrichtungen und insbesondere ein robusteres Vorrichtungsidentifizierungssystem, das gegenüber Problemen, die von geklonten Vorrichtungen und duplizierten Vorrichtungsidentifizierern verursacht werden, widerstandsfähig ist.
  • Hintergrund
  • Ein Vorrichtungsidentifizierungssystem ermöglicht, dass ein Server eine Clientrechenvorrichtung, die einen Zugriff auf Informationen und Ressourcen, die von dem Server gehostet werden, anfordert, eindeutig identifiziert. Vorrichtungsidentifizierungssysteme werden in einem weiten Anwendungsbereich eingesetzt, darunter die Authentifizierung, die Softwarelizenzierung, die Lizenzierung von digitalem Content, die Mitteilung von Softwareaktualisierungen und die zielgerichtete Verteilung von Content. Ein Vorrichtungsidentifizierungssystem kann beispielsweise in Verbindung mit einem Probeprogramm implementiert sein, das einem Kunden freien oder ermäßigten Zugang zu ansonsten begrenzten Ressourcen, so beispielsweise ein Softwareprogramm oder ein Multimediacontent, für begrenzte Zeit bietet. Ein derartiges Probeprogramm beruht darauf, dass ein Vorrichtungsidentifizierungssystem einzelne Vorrichtungen eindeutig und zuverlässig identifiziert. Andernfalls könnten Nutzer das Probeprogramm beispielsweise dadurch missbrauchen, dass sie sich jeden Monat für ein 30-Tage-Probeprogramm anmelden. Vorrichtungsidentifizierungssysteme werden zudem zu analytischen Zwecken verwendet, so beispielsweise zur Nachverfolgung dessen, wie oft Empfänger das vorgenannte freie Probepaket nutzen, bevor sie schließlich die Software oder den Content, die bzw. der anfänglich betroffen war, erwerben. Bei wieder einem anderen Beispiel kann ein Vorrichtungsidentifizierungssystem als Teil eines zwei Faktoren umfassenden Authentifzierungsprozesses implementiert werden, der eine wissensbasierte Authentifizierung (so beispielsweise ein Passwort, ein Muster oder dergleichen) mit einer vorrichtungsbasierten Authentifizierung (so beispielsweise einem erkannten Computer, Smartphone oder dergleichen) kombiniert. Unabhängig von der speziellen Implementierung verwenden bestehende Vorrichtungsidentifizierungssysteme allgemein einen Vorrichtungsidentifizierer, der, wie der Name nahelegt, Information umfasst, die eine spezielle Clientrechenvorrichtung identifiziert. Der Vorrichtungsidentifizierer kann beispielsweise auf einer herstellerseitig bereitgestellten Identifizierungsnummer, einem Maschinenidentifizierungscode, einer Telefonnummer, einem Mobilidentifizierer, einer Seriennummer, einer Versionsnummer, einer Hardwarekonfiguration oder einer Leistungsspezifizierung beruhen. Idealerweise kann der Vorrichtungsidentifizierer von einem Kunden nicht manipuliert werden und identifiziert eine spezielle Clientvorrichtung gegenüber allen anderen Vorrichtungen, die mit einem gegebenen Server interagieren können, eindeutig.
  • Theoretisch unterstützt ein eindeutig zugewiesener Vorrichtungsidentifizierer ein robustes Vorrichtungsidentifizierungssystem, das ermöglicht, dass ein Server Clients, die mit dem Server interagieren, zuverlässig identifiziert. In der Praxis sind jedoch einige Gründe vorhanden, warum es ungünstig ist, sich allein auf einen vom Client stammenden Vorrichtungsidentifizierer zur Vorrichtungsidentifizierung zu verlassen. Einerseits kann in vielen Fällen einem Client nicht zuverlässig dahingehend vertraut werden, dass er sich durchweg mit demselben Vorrichtungsidentifizierer zuverlässig identifiziert. Dies kann daher rühren, dass der Client eine instabile Hardwarekonfiguration oder einen Defekt in der Berechnungslogik des Vorrichtungsidentifiziers hat. Es kann andererseits auch daher rühren, dass der Nutzer den Vorrichtungsidentifizierer böswillig geändert, falsch dargestellt oder auf andere Weise manipuliert hat. Ein weiterer Grund dafür, warum die Vorgehensweise, sich allein auf einen von einem Client stammenden Vorrichtungsidentifizierer zu verlassen, nicht ratsam ist, rührt daher, dass es unmöglich ist sicherzustellen, dass ein gegebener Vorrichtungsidentifizierer überhaupt eindeutig ist. Dies rührt insbesondere daher, dass Hersteller bei der Zuweisung von Identifizierern an ihre Vorrichtungen nicht gewissenhaft sind. Zudem können duplizierte Vorrichtungsidentifizierer auftreten, wenn eine Vorrichtung virtualisiert oder geklont wird, so beispielsweise von einem böswilligen Nutzer, der eine vorrichtungsbasierte Lizenz, die von einem Softwareverkäufer oder Contentanbieter bereitgestellt wird, missbrauchen will. Dies hat das leicht widersprüchliche Szenario zur Folge, dass einige Vorrichtungen mit duplizierten Identifizierern akzeptabel sind (so beispielsweise für den Fall eines nichtgewissenhaften Herstellers), wohingegen dies bei anderen Vorrichtungen mit duplizierten Identifizierern nicht der Fall ist (beispielsweise für den Fall eines böswilligen Nutzers, der eine Vorrichtung klont). Ein Versuch, diesen Widerspruch durch Änderungen dahingehend zu lösen, wie der Vorrichtungsidentifizierer anfänglich zugewiesen wird, führt zu beträchtlichen Änderungen an bestehenden Lizenzierungssystemen und installierten Computerrechenvorrichtungen und wird daher vom Standpunkt der Übertragbarkeit her nicht als gangbare Lösung betrachtet. Es besteht daher Bedarf an einem robusteren Vorrichtungsidentifizierungssystem. Idealerweise ist ein derartiges System gegenüber Problemen, die von geklonten Vorrichtungen und duplizierten Vorrichtungsidentifizierern verursacht werden, widerstandsfähig und kann implementiert werden, ohne dass bestehende Clientarchitekturen oder Client-Server-Kommunikationssysteme grundlegend geändert werden müssten.
  • Kurzbeschreibung der Zeichnung
  • 1 ist ein Datenflussdiagramm zur schematischen Darstellung von exemplarischen Kommunikationen, die in einer Client-Server-Rechenumgebung auftreten und die entsprechend einem verbesserten Vorrichtungsidentifizierungssystem vorgenommen werden.
  • 2 ist ein Blockdiagramm zur schematischen Darstellung von ausgewählten Komponenten eines exemplarischen Vorrichtungsidentifizierungssystems, das gegenüber Problemen, die von geklonten Vorrichtungen und duplizierten Vorrichtungsidentifizierern verursacht werden, widerstandsfähig ist.
  • 3A bis 3D umfassen ein Flussdiagramm zur Darstellung eines exemplarischen Verfahrens zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung in einer Client-Server-Rechenumgebung.
  • 4A und 4B zeigen ein Flussdiagramm zur Darstellung eines exemplarischen Verfahrens zur Unterscheidung von geklonten Vorrichtungen in einem Vorrichtungsidentifizierungssystem.
  • 5A und 5B umfassen ein Flussdiagramm zur Darstellung eines exemplarischen Verfahrens zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung in einer Client-Server-Rechenumgebung, wobei die Clientvorrichtung mehrere eindeutige Vorrichtungsidentifiziererwerte erzeugt.
  • 6 ist ein Flussdiagramm zur Darstellung eines computerimplementierten Verfahrens zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung.
  • Detailbeschreibung
  • Entsprechend einigen der hier offenbarten Ausführungsformen ist ein robusteres Vorrichtungsidentifizierungssystem dadurch verwirklicht, dass eine Clientvorrichtung während einer Zeitspanne unter Verwendung von „Auffrischungstokens”, die in Verbindung mit routinemäßigen Client-Server-Kommunikationen ausgetauscht werden, nachverfolgt wird. Bei derartigen Ausführungsformen beinhaltet jeder Kommunikationszyklus zwischen Client und Server ein Auffrischungstoken, das an dem Server aufgezeichnet wird. Die aufgezeichneten Auffrischungstokens werden sowohl auf server- wie auch clientseitig erzeugte Vorrichtungsidentifizierer abgebildet. Treten Kommunikationen zwischen Client und Server auf, so wird eine Kette von aufeinanderfolgenden Auffrischungstokens, und zwar eines für jeden Kommunikationszyklus, progressiv bzw. fortlaufend an dem Server aufgezeichnet. Empfängt der Server ein Auffrischungstoken, das in Bezug auf dasjenige, das auf Grundlage der Abfolge der aufgezeichneten Kette andernfalls erwartet wird, veraltet oder nicht abfolgekonform ist, so legt dies nahe, dass die empfangene Kommunikation von einer Clientvorrichtung, die eine nichtautorisierte Kopie einer anderen Clientvorrichtung ist, übertragen worden ist. Hat der Server beispielsweise eine aufeinanderfolgende Kette von Auffrischungstokens {α, β, γ}, die an einen speziellen Client gesendet worden ist, aufgezeichnet, so erwartet der Server, dass die nächste von dem Client empfangene Kommunikation das letzte gesendete Auffrischungstoken γ enthält. Enthält die nächste empfangene Kommunikation anstatt dessen das veraltete Auffrischungstoken β, so legt dies nahe, dass die Kommunikation von einer Clientvorrichtung, die eine nichtautorisierte Kopie einer anderen Clientvorrichtung ist, empfangen worden ist. Es wird daher ein robusteres Vorrichtungsidentifizierungssystem verwirklicht, bei dem eine Kombination aus Vorrichtungsidentifizierern und Tokens, die zwischen Client und Server ausgetauscht werden, verwendet wird. Hierdurch werden viele der Unzulänglichkeiten im Zusammenhang mit bestehenden Systemen, die allein auf Vorrichtungsidentifizierern beruhen, beseitigt. Da darüber hinaus ein derartiges System Auffrischungstokens verwendet, die an dem Server erzeugt und analysiert werden, erfordert die Implementierung nur eine geringe oder überhaupt keine Modifizierung von bestehenden clientbasierten Systemen. In Lichte der vorliegenden Offenbarung erschließt sich ein weiter Bereich von alternativen Ausführungsformen.
  • 1 ist ein Datenflussdiagramm zur schematischen Darstellung von exemplarischen Kommunikationen, die in einer Client-Server-Rechenumgebung auftreten und die entsprechend einem verbesserten Vorrichtungsidentifizierungssystem vorgenommen werden. Die Client-Server-Rechenumgebung umfasst einen Server 100, der mit einer oder mehreren Clientvorrichtungen 300 in Verbindung steht. Eine erste Clientvorrichtung 300a überträgt an den Server 100 eine erste Kommunikation ➀, die ein Identifizierungstupel <DID, RRG-1> beinhaltet. Im Sinne des Vorliegenden bezeichnet die Abkürzung „DID” einen Vorrichtungsidentifizierer (Device Identifier), der ein Datenstring ist, der eine spezielle Clientvorrichtung gegenüber einem Server eindeutig identifizieren soll. Aus vorstehend zusammengefassten Gründen ist eine derartige Identifizierung jedoch gegebenenfalls nicht immer zuverlässig. Der DID wird oftmals zu Beginn vom Hersteller der Clientvorrichtung zugewiesen. Im Sinne des Vorliegenden bezeichnet die Abkürzung „RRG” einen „ursprünglichen beliebigen global eindeutigen Identifizierer (Root Random Globally Unique Identifier), der ein Datenstring ist, der bei einem Anfangsvorgang von einer Clientvorrichtung beliebig erzeugt wird. Bei einer Ausführungsform umfasst der RRG einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Ausführungsformen können auch andere Längen zum Einsatz kommen. Bei Implementierungen, bei denen einige verschiedene RRG-Werte verwendet werden, bezeichnet die Nomenklatur RRG-x den x-ten RRG. Daher stammen sowohl der DID wie auch der RRG von der Clientseite einer Client-Server-Rechenumgebung.
  • Der Server 100 umfasst unter anderem eine Datenbank 122, die eine Mehrzahl von Ketteneinträgen in dem Format <DID, RRG> → <SIUI> → {RT-1, RT-2, RT-3, ..., RT-n} beinhaltet. Jedes empfangene Identifizierungstupel <DID, RRG> wird auf einen entsprechenden SIUI abgebildet. Im Sinne des Vorliegenden bezeichnet die Abkürzung „SIUI” einen „serverseitig ausgestellten eindeutigen Identifizierer” (Server-Issued Unique Identifier), der ein Datenstring ist, der von einem Server beliebig erzeugt wird und der mit einem von dem Server empfangenen speziellen Identifizierungstupel <DID, RRG> korreliert ist. Bei einer Ausführungsform umfasst der SIUI einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Ausführungsformen können auch andere Wertlängen zum Einsatz kommen. Bei Implementierungen, bei denen einige verschiedene SIUI-Werte verwendet werden, bezeichnet die Nomenklatur SIUI-x den x-ten SIUI. Auf gleiche Weise wird jede Abbildung <DID, RRG> → <SIUI> des Weiteren auf einen Satz von einem oder mehreren RT-Werten {RT-1, RT-2, RT-3, ..., RT-n} abgebildet. Im Sinne des Vorliegenden bezeichnet die Abkürzung „RT” ein Auffrischungstoken (Refresh Token), das ein Datenstring ist, der ebenfalls beliebig von dem Server erzeugt wird und einem Kommunikationszyklus zwischen dem Server und einer speziellen Clientvorrichtung entspricht. Wenn der Server und die spezielle Clientvorrichtung einen Kommunikationszyklus aufweisen (beispielsweise dann, wenn die Clientvorrichtung den Server kontaktiert und der Server geantwortet hat, oder umgekehrt), weist der sich ergebende Satz von RT-Werten ein einziges Element {RT-1} auf. Bei einer Ausführungsform umfasst RT einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Ausführungsformen können andere Wertlängen zum Einsatz kommen. Die Nomenklatur RT-x bezeichnet ein x-tes RT. Ein Satz von RT-Werten {RT-1, RT-2, RT-3, ..., RT-n} wird hierbei als „RT-Satz” bezeichnet. Daher stammen sowohl der SIUI wie auch das RT von der Serverseite einer Client-Server-Rechenumgebung.
  • Beim Empfangen des Identifizierungstupels <DID, RRG-1> von der ersten Clientvorrichtung 300a erzeugt der Server 100 einen neuen SIUI-1, der der ersten Clientvorrichtung 300a entspricht und der auf das eingehende Tupel <DID, RRG-1> abgebildet wird. Diese Abbildung wird in der Datenbank 122 gespeichert. Darüber hinaus erzeugt der Server 100 ein neues RT-1 und einen neuen RT-Satz {RT-1}. Dieser neue RT-Satz wird ebenfalls in der Datenbank 122 gespeichert und auf die bestehende Abbildung <DID, RRG-1> → <SIUI-1>, wie vorstehend beschrieben worden ist, abgebildet. Das Ergebnis ist ein Ketteneintrag in der Datenbank 122, der als <DID, RRG-1> → <SIUI-1> → <{RT-1} erscheint. Der Server 100 antwortet auf die erste Clientvorrichtung 300a mit einer zweiten Kommunikation ➁, die ein Antworttupel <RRG-1, RT-1> beinhaltet.
  • Beim Empfangen dieses Antworttupels speichert die erste Clientvorrichtung 300a RT-1 Lokal.
  • Überträgt die erste Clientvorrichtung 300a später an den Server 100 eine dritte Kommunikation ➂, so beinhaltet diese das Antworttupel <DID, RRG-1, RT-1> mit ihrer ausgehenden Übertragung. Der Server 100 versucht, das eingehende RT-1 mit dem letzten RT in dem RT-Satz, der mit <DID, RRG-1> und <SIUI-1> in der Datenbank 122 verknüpft ist, abzugleichen. Ist ein Abgleichtreffer vorhanden, so wird ein nächstes RT-2 erzeugt und hinzugefügt, wodurch sich ein aktualisierter RT-Satz {RT-1, RT-2} bildet. Der Server 100 antwortet auf die erste Clientvorrichtung 300a mit einer vierten Kommunikation ➃, die ein aktualisiertes Antworttupel <RRG-1, RT-2> beinhaltet. Setzen die erste Clientvorrichtung 300a und der Server 100 ihre wechselseitige Kommunikation fort, so wächst der RT-Satz, der mit <DID, RRG-1> und <SIUI> in der Datenbank 122 verknüpft ist, beständig an, wodurch eine Kette gebildet wird, die die aufeinanderfolgenden Client-Server-Kommunikationszyklen zwischen der ersten Clientvorrichtung 300a und dem Server 100 darstellt. Diese fortlaufenden aufeinanderfolgenden Kommunikationszyklen werden hier als Nutzungsfall (Use Case) 1 beschrieben und können als Szenario der grundlegenden Verwendung gedeutet werden, bei dem keine geklonten oder duplizierten Clientvorrichtungen anzutreffen sind.
  • Wie weiterhin anhand der in 1 dargestellten exemplarischen Ausführungsform erläutert wird, kann an einem bestimmten Punkt, nachdem der erste Kommunikationszyklus zwischen dem Server 100 und der ersten Clientvorrichtung 300a vollständig ist (das heißt, nachdem die zweiten Kommunikation ➁ aufgetreten ist), die erste Clientvorrichtung 300a geklont werden, wodurch eine zweite Clientvorrichtung 300b erzeugt wird. Mögliche Klonbildungsereignisse sind in 1 durch das •-Symbol dargestellt. Dies kann von einem böswilligen Nutzer vorgenommen werden, der eine vorrichtungsbasierte Lizenz, die von einem Softwareverkäufer oder Contentanbieter bereitgestellt wird, missbraucht. Oder es geschieht dies ohne unrechtmäßige Absicht, so beispielsweise durch einen Systemadministrator, der eine bestehende Vorrichtungskonfiguration auf eine neue Vorrichtung kopiert, um die neue Vorrichtung schnell zu konfigurieren. Unabhängig vom Grund für das Klonen sind einige der hier offenbarten Ausführungsformen sehr gut dafür geeignet, das Klonen zu erfassen. Insbesondere wenn die erste Clientvorrichtung 300a geklont wird, übernimmt die sich ergebende zweite Clientvorrichtung 300b das Antworttupel <RRG-1, RT-1>, das von dem Server 100 vorher empfangen worden ist. Der Klonprozess kann daher als Weiterleitung (Propagation) des vorher empfangenen RT-1 von der ersten Clientvorrichtung 300a (geklonte Vorrichtung) an die zweite Clientvorrichtung 300b (Klonvorrichtung) gedeutet werden. Beginnt die zweite Clientvorrichtung 300b die Kommunikation mit dem Server 100, so beinhaltet die nächste Kommunikation ➄ das Antworttupel <DID, RRG-1, RT-1> mit seiner ausgehenden Übertragung. Der Server 100 versucht, das eingehende RT-1 mit dem letzten RT in dem RT-Satz, der mit <DID, RRG-1> und <SIUI> in der Datenbank 122 verknüpft ist, abzugleichen. Hat der Server 100 auf die erste Clientvorrichtung 300a bereits geantwortet, so ist das letzte RT gleich RT-2. Das Versagen beim Abgleichen der RT-Werte, das vorliegend als „Konfliktzustand” (Clash State) bezeichnet wird, weist den Server 100 darauf hin, dass die empfangene Kommunikation ➄ von einer Vorrichtung, die ein veraltetes RT aus einer nichtautorisierten Quelle, so beispielsweise von einer geklonten Clientvorrichtung, empfangen hat, übertragen worden ist. Die Erfassung eines nichtautorisierten duplizierten Vorrichtungsidentifizierers wird hier als Nutzungsfall (Use Case) 2 bezeichnet und kann als Szenario der Verwendung einer geklonten Vorrichtung gedeutet werden. Hat der Server 100 nicht bereits auf die erste Clientvorrichtung 300a geantwortet, so wird die Kommunikation zwischen der zweiten Clientvorrichtung 300b als legitimiert gewertet, und es werden nachfolgende Kommunikationen von der ersten Clientvorrichtung 300a dahingehend gewertet, dass sie einen nichtautorisierten duplizierten Vorrichtungsidentifizierer enthalten.
  • Wie vorstehend ausgeführt worden ist, können in einigen Fällen mehrere nicht in Beziehung zueinander stehende Vorrichtungen identische Vorrichtungsidentifizierer aufweisen. Dies kann beispielsweise dort auftreten, wo ein Vorrichtungshersteller beim Zuweisen der Identifizierer an die Vorrichtungen nicht gewissenhaft ist oder wo zwei Vorrichtungshersteller unwissentlich Vorrichtungen mit identischen Identifizierern herstellen. Zwei nicht in Beziehung zueinander stehende Vorrichtungen mit identischen Vorrichtungsidentifizierern erzeugen jedoch verschiedene RRG-Werte. Daher initiiert, wie in 1 dargestellt ist, eine dritte Clientvorrichtung 300c, die einen zu denjenigen der ersten und zweiten Clientvorrichtungen 300a, 300b identischen DID aufweist, eine Kommunikation mit dem Server 100, indem eine erste Kommunikation ➀, die ein Identifizierungsstupel <DID, RRG-2> beinhaltet, gesendet wird. Da ein derartiges Tupel in der Datenbank 122 nicht vorhanden ist, behandelt der Server 100 die dritte Clientvorrichtung 300c als neue Vorrichtung und löst daher keinen Konfliktzustand aus. Der Server 100 antwortet daher auf die dritte Clientvorrichtung 300c mit einer zweiten Kommunikation ➁, die ein Antworttupel <RRG-2, RT-1>, wie hier beschrieben ist, beinhaltet. Die erste Clientvorrichtung 300a und die dritte Clientvorrichtung 300c beeinflussen einander daher nicht, obwohl sie gemeinsam einen identischen DID nutzen (share). Dieser Parallelbetrieb wird hier als Nutzungsfall (Use Case) 3 bezeichnet und kann als Szenario der Verwendung eines duplizierten Vorrichtungsidentifizierers gedeutet werden
  • Die in 1 dargestellte und vorstehend beschriebene exemplarische Implementierung zeigt, wie einige der hier offenbarten Ausführungsformen Unzulänglichkeiten von bestehenden Vorrichtungsidentifizierungssystemen beseitigen. Ein System, das einen clientseitig bereitgestellten DID durch einen serverseitig erzeugten SIUI ergänzt, ist beispielsweise weniger anfällig für eine clientseitige Manipulation des DID, und zwar weder infolge einer instabilen Hardwarekonfiguration oder eines Softwaredefektes noch infolge eines Nutzers mit böswilliger Absicht. Auf gleiche Weise ermöglicht der Aufbau einer serverseitigen Kette von Auffrischungstokens, die den Client-Server-Kommunikationszyklen entsprechen, dass der Server unabhängig verifiziert, dass eine bestimmte Kommunikation in Übereinstimmung mit anderen von einer speziellen Clientvorrichtung empfangenen Kommunikationen ist, weshalb geklonte Vorrichtungen zuverlässiger erfasst werden können. Daher ermöglicht ein System, das den DID durch einen RRG ergänzt, dass nicht in Beziehung zueinander stehende Vorrichtungen mit identischen Identifizierern unabhängig und ohne wechselseitige Störung betrieben werden können. Dies ermöglicht wiederum, dass der Server zwischen Vorrichtungen mit duplizierten Identifizierern, die (beispielsweise durch einen Klonvorgang) in Beziehung zueinander stehen, und Vorrichtungen mit duplizierten Identifizierern, die nicht in Beziehung zueinander stehen (beispielsweise da die Vorrichtungen anfänglich mit duplizierten Identifizierern hergestellt worden sind) unterscheidet. Da das exemplarische Vorrichtungsidentifizierungssystem, das in 1 dargestellt ist, ohne wesentliche Änderungen an bestehenden Client-Server-Kommunikationssystemen und ohne wesentliches Modifizieren einer bestehenden Clientvorrichtungsarchitektur implementiert werden kann, kann es bei bestehenden Systemen direkt implementiert werden. Dies bietet einen Grad der Übertragbarkeit, der anderen Lösungen fehlt. Diese und weitere Vorteile erschließen sich im Lichte der vorliegenden Offenbarung.
  • Im Sinne des Vorliegenden bezeichnet der Begriff „Rechenvorrichtung” über seine allgemeine Bedeutung hinausgehend eine Einrichtung, die einen Prozessor, einen Speicher sowie Eingabe-/Ausgabekomponenten, die für einen Zugriff auf die Vorrichtung oder eine Interaktion mit dieser verwendet werden können, aufweist. Eine Rechenvorrichtung beinhaltet zudem typischerweise ein oder mehrere Softwaremodule, die dafür konfiguriert sind, eine bestimmte Funktionalität zu implementieren, wie auch Hardware, die zur Umsetzung einer derartigen Implementierung imstande ist. Beispiele für Rechenvorrichtungen beinhalten manuelle Computer, zellbasierte Telefone, Tabletcomputer, Smartphones, Laptopcomputer, Desktopcomputer und Set-Top-Boxen. Eine „Clientrechenvorrichtung” bezeichnet eine Rechenvorrichtung, die in einer Client-Server-Rechenumgebung arbeitet und die einen Zugriff auf Informationen oder Ressourcen, die von einem Server gehostet werden, anfordert.
  • Im Sinne des Vorliegenden bezeichnet der Begriff „Datenstruktur” über seine allgemeine Bedeutung hinausgehend eine Art der Speicherung und Organisierung von Daten in einem computerseitig zugänglichen Speicher derart, dass die Daten von einer Anwendung bzw. App oder einem Softwaremodul verwendet werden können. In ihrer einfachsten Form kann eine Datenstruktur beispielsweise ein Satz aus einer oder mehreren Speicherstellen sein. In einigen Fällen kann eine Datenstruktur als sogenannte Aufzeichnung (record) implementiert sein, die manchmal auch als „struct” oder Tupel bezeichnet wird, und eine geeignete Anzahl von Feldern, Elementen oder Speicherstellen aufweisen. Wie zudem ersichtlich ist, kann eine Datenstruktur von Interesse seiende Daten oder einen Zeiger, der auf eine Speicherstelle verweist, an der die von Interesse seienden Daten vorgefunden werden können, beinhalten. Eine Datenstruktur kann ein geeignetes Format aufweisen, so beispielsweise eine Nachschlagetabelle oder ein Indexformat, ein Feldanordnungs- bzw. Arrayformat, ein Hash-Tabellenformat, einen Graph, einen Baum oder ein hierarchisches Format mit einer geeigneten Anzahl von Knoten, ein Objektformat, das Datenfelder beinhaltet, oder eine Kombination aus Vorgenanntem. Eine Datenstruktur kann ausführbaren Code für einen Zugriff auf die darunter liegende Struktur und das Format der darin gespeicherten Daten und eine Modifizierung hiervon beinhalten. Allgemein bedeutet dies, dass die Datenstruktur als Datensatz implementiert sein kann, der spezifische Werte ohne Beschränkung auf eine spezielle Reihenfolge oder ein spezielles Format speichern kann. Bei einer Ausführungsform umfasst eine Datenstruktur eine Mehrzahl von Ketteneinträgen in dem Format <DID, RRG> → <SIUI> → {RT-1, RT-2, RT-3, ..., RT-n}, wobei der RT-Satz {RT-1, RT-2, RT-3, ..., RT-n} zwischen einem Server und einer Vorrichtung auftretende Kommunikationszyklen darstellt, die durch DID-, RRG- und SIUI-Werte dargestellt werden.
  • Systemarchitektur
  • 2 ist ein Blockdiagramm zur schematischen Darstellung von ausgewählten Komponenten eines exemplarischen Vorrichtungsidentifizierungssystems 10, das gegenüber Vorrichtungsidentifizierungsproblemen, die von geklonten Vorrichtungen und duplizierten Vorrichtungsidentifizierern verursacht werden, widerstandsfähig ist. Das System 10 ermöglicht beispielsweise, dass ein Server zwischen Clientvorrichtungen mit duplizierten Identifizierern, die (beispielsweise durch einen Klonvorgang) in Beziehung zueinander stehen, und Vorrichtungen mit duplizierten Identifizierern, die nicht in Beziehung zueinander stehen (beispielsweise da die Vorrichtungen anfänglich mit duplizierten Identifizierern hergestellt worden sind) unterscheidet. Das System 10 kann derart gedeutet werden, dass es einen Server 100 umfasst, der zu einer Kommunikation mit einer oder mehreren Clientvorrichtungen 300 über ein Netzwerk 200 imstande ist. Das Netzwerk 200 kann darüber hinaus für einen Zugriff auf optionale ergänzende Ressourcen, so beispielsweise Cloudspeicherressourcen und Netzwerkverwaltungsressourcen, verwendet werden. In einigen Fällen sind derartige ergänzende Ressourcen weggelassen, da die entsprechende Funktionalität entweder von dem Server 100 selbst bereitgestellt wird oder gänzlich darauf verzichtet ist. Darüber hinaus können, obwohl der Server 100 und die Clientvorrichtung 300 in 2 als direkt über das Netzwerk 200 verbunden dargestellt sind, diese bei anderen Implementierungen auch von fern mit einem Netzwerk 200 über ein oder mehrere Netzwerke oder Kommunikationskanäle gekoppelt sein.
  • Bei einer Ausführungsform umfasst der Server 100 eine oder mehrere der Unternehmensklasse zuzurechnende Servervorrichtungen, die digitale Ressourcen, die für die Clientvorrichtung 300 zugänglich gemacht werden, hosten, verteilen oder verwalten. Bei Implementierungen, die mehrere Server beinhalten, werden die mehreren Server optional von einem Lastausgleichssystem verwaltet. Beispiele für Ressourcen, die der Server 100 für die Clientvorrichtung 300 verfügbar machen kann, beinhalten Software, Multimediainhalt, digitale Leistungen und cloudbasierte Speicherressourcen. Bei einigen Implementierungen werden die digitalen Ressourcen für die Clientvorrichtung 300 auf Probebasis bereitgestellt, wodurch ein freier oder ermäßigter Zugriff auf eine Ressource für begrenzte Zeit gewährt wird. Bei anderen Implementierungen wird ein unbeschränkter Zugriff auf eine Ressource nur für diejenigen Clients bzw. Kunden, die eine gültige Lizenz innehaben, bereitgestellt. Der Server 100 kann dafür konfiguriert sein, die Verteilung von digitalen Ressourcen zu verwalten, indem Regeln, die vorgeben, wie die Ressourcen für Clients bereitgestellt werden, aufgestellt und durchgesetzt werden. Zu diesem Zweck nutzt der Server 100 oftmals die Fähigkeit, eine spezielle Clientvorrichtung 300, die einen Zugriff auf die gehosteten Ressourcen anfordert, zuverlässig zu identifizieren und zu erkennen. Daher beinhaltet bei bestimmten Implementierungen der Server 100 ein oder mehrere Softwaremodule, die dafür konfiguriert sind, die verschiedenen Funktionalitäten, die mit dem Vorrichtungsidentifizierungssystem 10 verknüpft sind, zu konfigurieren, wie auch Hardware, die eine derartige Implementierung umsetzt. Beispiele für die Umsetzung von Hardware beinhalten einen Prozessor 110, einen Speicher 120, ein Kommunikationsmodul 150 und einen Bus oder Interconnect 190. Beispiele für die Implementierung von Software beinhalten ein Betriebssystem 140, ein Tokenverwaltungsmodul 160, ein Konflikttriggermodul 170 und ein Nutzerschnittstellenmodul 180.
  • Obwohl nur eine repräsentative Clientvorrichtung 300 aus Gründen der Einfachheit in 2 dargestellt ist, sollte einsichtig sein, dass ein System 10 im Allgemeinen Dutzende, Hunderte, Tausende oder sogar eine beliebige geeignete Anzahl von Clientvorrichtungen, die mit dem Server 100 kommunizieren, beinhalten kann. Daher sollen Bezugnahmen auf eine einzige „Clientvorrichtung” derart gedeutet werden, dass Ausführungsformen mit umfasst sind, die mehrere Clientvorrichtungen umfassen. Die Clientvorrichtung 300 kann beispielsweise eine oder mehrere Vorrichtungen umfassen, die unter einem Desktopcomputer, einem Laptopcomputer, einer Workstation, einem Tabletcomputer, einem Smartphone, einem manuellen Computer, einer Set-Top-Box, einer der Unternehmensklasse zuzurechnenden Vorrichtung oder einer beliebigen anderen derartigen Vorrichtung, die zu einer Kommunikation mit dem Server 100 imstande ist, ausgewählt sind. Es kann auch eine Kombination aus verschiedenen Vorrichtungen bei bestimmten Ausführungsformen verwendet werden. Wie in 2 dargestellt ist, beinhaltet die Clientvorrichtung 300 optional einen lokalen Sicherungscache 322, der zur Speicherung von Auffrischungstokens, Antworttupeln oder anderen Objekten, die von dem Server 100 empfangen werden, oder zur Cache-Speicherung für die Übertragung an den Server 100 verwendet werden kann. Bei einer Ausführungsform ist der lokale Sicherungscache 322 dafür konfiguriert, dasjenige zu begrenzen oder zu verhindern, dass ein Nutzer auf die darin gespeicherten Objekte zugreift oder diese manipuliert.
  • Wie wiederum anhand der in 2 dargestellten exemplarischen Implementierung des Servers 100 gezeigt ist, umfasst der Prozessor 110 einen beliebigen geeigneten Prozessor und kann einen oder mehrere Coprozessoren oder Controller beinhalten, so beispielsweise eine grafische Verarbeitungseinheit, um die Steuerungs- bzw. Regelungs- und Verarbeitungsvorgänge im Zusammenhang mit dem Server 100 zu unterstützen. Der Speicher 120 ist unter Verwendung eines beliebigen geeigneten Typs von digitalem Speicher implementiert, so beispielsweise einem oder mehreren von einem Festplattenlaufwerk, einer redundanten Anordnung von unabhängigen Platten (RAID), einem USB-Laufwerk (Universeller Serieller Bus USB), einem Flash-Speicher, einem Speicher mit wahlfreiem Zugriff (RAM) oder einer beliebigen geeigneten Kombination aus Vorgenanntem. Bei bestimmten Ausführungsformen umfasst der Speicher 120 daher ein verteiltes System aus mehreren digitalen Speichervorrichtungen, von denen eines oder mehrere entfernt angeordnet und über ein Netzwerk zugänglich sein können. Der Speicher 120 hostet optional die Datenbank 122, die zum Speichern von Abbildungen zwischen Identifizierungstupeln, SIUI-Werten und RT-Sätzen, wie beschrieben ist, verwendet werden kann. In einigen Fällen wird der Speicher 120 auch optional zur Speicherung einer Konflikt-Erfasst-Datenstruktur (Clash Detected data structure) 172, die von dem Konflikttriggermodul 170 bereitgestellt wird, verwendet.
  • Das Betriebssystem 140 umfasst ein geeignetes Betriebssystem, so beispielsweise GOOGLE® ANDROIDTM (Google Inc., Mountain View, CA), MICROSOFT® WINDOWS® (Microsoft Corp., Redmond WA), oder APPLE® OS X® (Apple Inc., Cupertino CA). Wie sich im Lichte der vorliegenden Offenbarung ergibt, können die hier vorgestellten Techniken ohne Rücksicht auf ein spezielles Betriebssystem, das in Verbindung mit dem Server 100 bereitgestellt wird, implementiert sein und können daher auch unter Verwendung einer beliebigen anderen geeigneten bestehenden oder noch zu entwickelnden Plattform implementiert werden. Das Kommunikationsmodul 150 ist ein geeigneter Netzwerkchip oder Chipsatz, der eine verdrahtete oder drahtlose Verbindung mit dem Netzwerk 200 und anderen Rechenvorrichtungen und Ressourcen ermöglicht. Das Kommunikationsmodul 150 kann auch zur Bereitstellung von vorrichtungsinternen Kommunikationen über einen Bus oder Interconncet 190 konfiguriert sein.
  • Wie weiterhin in 2 dargestellt ist, umfasst das Tokenverwaltungsmodul 160 auf einem computerlesbaren Medium codierte Anweisungen, die bei Ausführung unter Verwendung eines Prozessors veranlassen, dass einer oder mehrere aus einer Vielzahl von verschiedenen Tokenverarbeitungsprozessen aufgerufen werden. Ein derartiger Prozess impliziert das Verwalten des Beziehens von digitalen Tokens, so beispielsweise von SIUI-Werten (aus einem SIUI-Vorrat 162 bezogen), von RT-Werten (aus einem RT-Vorrat 164 bezogen) und von RRG-Werten (auf Grundlage eines beliebigen Algorithmus erzeugt). Ein Tokenverwaltungsprozess kann zudem das Analysieren von eingehenden Tupeln, die von einer Clientvorrichtung 300 empfangen werden, und das Erzeugen von geeigneten Antworttupeln implizieren. Beinhalten kann dies ein Extrahieren von Information aus einer Serverdatenbank 122 oder ein Speichern von Abbildungen in dieser. Bei einer Implementierung zeichnet, wenn Kommunikationen zwischen der Clientvorrichtung 300 und dem Server 100 auftreten, ein Tokenverwaltungsprozess beispielsweise eine Kette von Tokens, und zwar eines für jeden Kommunikationszyklus, in der Datenbank 122 auf. Clients, die Duplizierungen von anderen Clientvorrichtungen sein können, können auf Grundlage des Empfangs eines Tokens identifiziert werden, das in Bezug auf eines, das andernfalls auf Grundlage des Fortlaufens bzw. der Progression der aufgezeichneten Kette zu erwarten war, veraltet ist. Diese und weitere Funktionalitäten können durch das Tokenverwaltungsmodul 160, das nachstehend noch beschrieben wird, bereitgestellt werden.
  • Das Konflikttriggermodul 170 umfasst auf einem computerlesbaren Medium codierte Anweisungen, die bei Ausführung unter Verwendung eines Prozessors veranlassen, dass ein oder mehrere aus einer Vielzahl von verschiedenen Konflikttriggerprozessen aufgerufen werden. Ein derartiger Prozess impliziert ein Kompilieren und Verwahren der Konflikt-Erfasst-Datenstruktur 172. Wie nachstehend noch detaillierter beschrieben wird, bietet die Konflikt-Erfasst-Datenstruktur 172 einen Einblick in die Beziehung zwischen geklonten Clientvorrichtungen, wodurch einem Analysten ermöglicht wird, eine Quellvorrichtung, von der andere Klone abstammen, zu identifizieren. Dies kann beispielsweise durch Errichten einer Verbindung zwischen SIUI-Werten für Vorrichtungen, die als Klone voneinander erfasst worden sind, erreicht werden. Bei bestimmten Ausführungsformen kompiliert ein Konflikttriggerprozess Metadaten, die die Konflikt-Erfasst-Datenstruktur 172 definieren, und verwahrt diese. Bei einigen Ausführungsformen können die Metadaten in der Datenbank 122 gespeichert werden. Die von dem Konflikttriggermodul 170 bereitgestellten Funktionalitäten werden nachstehend beschrieben.
  • Das Nutzerschnittstellenmodul 180 umfasst auf einem computerlesbaren Medium codierte Anweisungen, die bei Ausführung unter Verwendung eines Prozessors veranlassen, dass eine Nutzerschnittstelle erzeugt wird. Bei einer Implementierung ist die Nutzerschnittstelle dafür konfiguriert, Information im Zusammenhang mit den verschiedenen Clientvorrichtungen, die mit dem Server 100 interagiert haben, und insbesondere im Zusammenhang mit den Konfliktzuständen, die der Server 100 erfasst hat, anzuzeigen. Eine derartige Information wird optional in Form einer Konflikt-Erfasst-Datenstruktur 172 bereitgestellt. Die Nutzerschnittstelle kann auch dafür konfiguriert sein, eine Nutzereingabe zu empfangen, die definiert, wie Betriebsdaten mitgeteilt werden, oder allgemeiner, wie das Vorrichtungsidentifizierungssystem 10 arbeitet. Zu diesem Zweck kann die von dem Nutzerschnittstellenmodul 180 erzeugte Nutzerschnittstelle Elemente wie Menüleisten, Werkzeugleisten, Dialogkästchen, Steuer- bzw. Regelfelder, Dropdownmenüs, Kontextmenüs, Prüfkästchen, Stellflächen und dergleichen mehr beinhalten.
  • Die hier offenbarten Ausführungsformen können in verschiedenen Formen von Hardware, Software, Firmware oder Prozessoren für spezielle Zwecke implementiert sein. Bei einer Ausführungsform sind auf einem nichttemporären computerlesbaren Medium beispielsweise Anweisungen codiert, die bei Ausführung durch einen oder mehrere Prozessoren eines oder mehrere der Vorrichtungsidentifizierungssysteme der vorliegenden Offenbarung implementieren. Die Anweisungen können unter Verwendung einer beliebigen geeigneten Programmiersprache codiert sein, so beispielsweise Scala, C, C++, objektorientiertes C, Swift, JavaScript, Java, Visual Basic .NET, Basic, oder alternativ unter Verwendung von allgemein zugänglichen oder proprietären Anweisungssätzen. Derartige Anweisungen können in Form einer oder mehrerer Computersoftwareanwendungen bzw. Apps oder von Applets bereitgestellt werden, die auf einer Speichervorrichtung physisch verkörpert sind und die von einem Computer mit einer beliebigen geeigneten Architektur ausgeführt werden können. Bei einer Ausführungsform kann das System auf einer gegebenen Webseite gehostet und beispielsweise unter Verwendung von JavaScript oder einer anderen geeigneten browserbasierten Technologie implementiert sein.
  • Die hier offenbarten Funktionalitäten können in einem weiten Bereich von Rechenumgebungen eingebaut werden, so beispielsweise in Webverkehrsanalyseanwendungen bzw. Apps, in Systemen zur Verteilung von lizenziertem Content sowie in Softwareverteilungs-, Aktivierungs- und Aktualisierungsmitteilungssystemen. Bei einer Implementierung ist das Vorrichtungsidentifizierungssystem 10 beispielsweise in Verbindung mit einem Probeprogramm implementiert, das Verbrauchern einen freien Zugang zu einer Softwareanwendung bzw. App für eine begrenzte Zeitspanne bietet. Die Client-Server-Kommunikationen, die während der Aktivierung der Probezeitspanne auftreten, werden gemäß vorliegender Beschreibung verarbeitet, wodurch es für einen Administrator einfacher wird, Verbraucher zu identifizieren, die wiederholt versuchen, sich für das Probeprogramm anzumelden. Die hier offenbarten Vorrichtungsidentifizierungssysteme können eine beliebige Anzahl von geeigneten Modulen, Teilmodulen oder anderen Komponenten mit eigener Funktionalität beinhalten und Information für andere Komponenten und Dienste bereitstellen oder von diesen empfangen. Die Module können beispielsweise für einen Zugriff auf Cloudspeicherressourcen oder Netzwerkverwaltungsressourcen verwendet werden. Andere Komponenten und Funktionalitäten, die in der Darstellung nicht auftreten, erschließen sich allgemein im Lichte der vorliegenden Offenbarung, wobei einsichtig sein sollte, dass die vorliegende Offenbarung nicht in dem Sinne verstanden werden sollte, dass sie auf eine spezielle Hardware- oder Softwarekonfiguration beschränkt ist. Daher können die in 2 dargestellten Komponenten bei anderen Ausführungsformen zusätzliche, weniger oder alternative Teilkomponenten beinhalten.
  • Das vorgenannte nichttemporäre computerlesbare Medium kann ein beliebiges geeignetes Medium zur Speicherung von digitaler Information sein, so beispielsweise ein Festplattenlaufwerk, ein Server, ein Flash-Speicher, ein RAM oder eine beliebige Kombination aus Vorgenanntem. Bei alternativen Ausführungsformen können die hier offenbarten Computer und Module mit Hardware implementiert sein, darunter mit einer Gate-Level-Logik, so beispielsweise einem feldprogrammierbaren Gate Array (FPGA), oder alternativ mit einem Spezialzweckhalbleiter, so beispielsweise einer anwendungsspezifischen integrierten Schaltung (ASIC). Wieder andere Anwendungen können mit einem Microcontroller implementiert sein, der eine Anzahl von Eingabe-/Ausgabeports zum Empfangen und Ausgeben von Daten und eine Anzahl von eingebetteten Routinen zum Ausführen der verschiedenen hier offenbarten Funktionalitäten aufweist. Es erschließt sich, dass in diesem Zusammenhang eine beliebige geeignete Kombination aus Hardware, Software und Firmware verwendet werden kann und dass die vorliegende Offenbarung nicht derart gedeutet werden soll, dass sie auf eine spezielle Systemarchitektur beschränkt ist.
  • Methodische Vorgehensweise: Grundsätzlicher Fall (Nutzungsfall 1)
  • 3A bis 3D umfassen ein Flussdiagramm zur Darstellung eines exemplarischen Verfahrens 1000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung in einer Client-Server-Rechenumgebung. Das Verfahren 1000 wird hier auch als Nutzungsfall 1 bezeichnet. Wie ersichtlich ist, beinhaltet das Verfahren 1000 eine Anzahl von Phasen und Teilprozessen, deren Abfolge von einer Ausführungsform zur anderen variieren kann. Diese Phasen und Teilprozesse sind jedoch bei einer Betrachtung als Ganzes Teil eines verbesserten Vorrichtungsidentifizierungssystems, das gegenüber Herausforderungen, die von geklonten Vorrichtungen und duplizierten Vorrichtungsidentifizierern verursacht werden, widerstandsfähig ist. Bei einer Ausführungsform reagiert das System auf erfasste Kommunikationen in einer Client-Server-Rechenumgebung entsprechend einer bestimmten der hier offenbarten Techniken. Das Verfahren 1000 kann beispielsweise unter Verwendung der in 2 dargestellten und hier beschriebenen Systemarchitektur implementiert sein. Bei anderen Ausführungsformen können jedoch auch andere Systemarchitekturen verwendet werden, wie sich im Lichte der vorliegenden Offenbarung erschließt. Zu diesem Zweck soll eine Korrelation der in 3A bis 3D gezeigten verschiedenen Funktionalitäten mit den in 2 dargestellten spezifischen Komponenten keine strukturellen oder Nutzungsbeschränkungen implizieren. Vielmehr können andere Ausführungsformen beispielsweise abweichende Grade der Integration beinhalten, wobei mehrere Funktionalitäten effektiv auch von einem System oder Modul wahrgenommen werden können. Bei einer alternativen Ausführungsform wird beispielsweise ein einziges Modul zum Verwalten von Tokens und Antworten auf erfasste Konfliktzustände verwendet. Daher können andere Ausführungsformen in Abhängigkeit von der Kleinteiligkeit bzw. Granularität der Implementierung auch weniger oder mehr Module aufweisen. Verschiedene Variationen und alternative Konfigurationen erschließen sich im Lichte der vorliegenden Offenbarung.
  • Das Verfahren 1000 ist in einer Client-Server-Rechenumgebung implementiert, wobei (a) mehrere Clientvorrichtungen einen Zugriff auf Informationen, Ressourcen oder Informationen und Ressourcen, die von einem Server gehostet werden, anfordern, und (b) der Server danach strebt, Kommunikationen von einzelnen Clientvorrichtungen zu unterscheiden. In diesem Zusammenhang beginnt das Verfahren 1000 damit, dass sich eine bestimmte Clientvorrichtung 300 anschickt, eine Anfrage bei einem Server 100 vorzulegen. Zu diesem Zweck definiert die Clientvorrichtung 300 ein „Anfangsidentifizierungstupel” <DID, RRG>, siehe Bezugszeichen 1110 in 3A. Hierbei bezeichnet DID einen Vorrichtungsidentifizierer im Zusammenhang mit der Clientvorrichtung 300, so beispielsweise einen, der gegebenenfalls anfänglich von einem Hersteller zugewiesen worden ist. Der DID soll eine bestimmte Clientvorrichtung gegenüber einem Server eindeutig identifizieren, obwohl eine derartige Identifizierung gegebenenfalls nicht immer stabil oder zuverlässig ist. RRG bezeichnet einen ursprünglichen beliebigen global eindeutigen Identifizierer, der von der Clientvorrichtung 300 bei einem Anfangsvorgang beliebig erzeugt wird. Bei einer Ausführungsform umfasst der RRG einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Algorithmen können auch ändere Wertlängen verwendet werden. Die Clientvorrichtung 300 kombiniert den DID und den RRG zur Bildung des Anfangsidentifizierungstupels. Die Clientvorrichtung 300 sendet sodann das Anfangsidentifizierungstupel an den Server 100, und zwar beispielsweise mit einer Anfangsserveranfrage, siehe Bezugszeichen 1120 in 3A.
  • Beim Empfangen des Anfangsidentifizierungstupels durch den Server 100 bezieht der Tokenverwaltungsprozess, der von dem Tokenverwaltungsmodul 160 aufgerufen wird, einen SIUI aus dem SIUI-Vorrat 162, siehe Bezugszeichen 1140 in 3A. Hierbei bezeichnet SIUI einen serverseitig ausgestellten eindeutigen Identifizierer, der von dem Server 100 beliebig erzeugt wird. Daher kann der SIUI-Vorrat 162 derart gedeutet werden, dass er einen Bestand an verfügbaren SIUI-Werten bereitstellt. Bei einer Ausführungsform werden die Tokenwerte in dem SIUI-Vorrat 162 unter Verwendung eines Standardzufallszahlengenerators mit einem alphanumerischen Zeichenraum von 256 erzeugt. Nachdem die Zufallszahlen erzeugt worden sind, wird eine zusätzliche Überprüfung hinsichtlich duplizierter Werte durchgeführt. Bei einer Ausführungsform umfasst der SIUI einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Ausführungsformen können auch andere Wertlängen Verwendung finden. Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess bezieht zudem ein RT aus dem RT-Vorrat 164, siehe Bezugszeichen 1150 in 3A. Hierbei bezeichnet RT ein Auffrischungstoken, das von dem Server 100 beliebig erzeugt wird. Der RT-Vorrat 164 kann daher derart gedeutet werden, dass er einen Bestand an verfügbaren RT-Werten bereitstellt. Bei einer Ausführungsform werden die Tokenwerte in dem RT-Vorrat 164 unter Verwendung eines Standardzufallszahlengenerators mit einem alphanumerischen Zeichenraum von 256 erzeugt. Nachdem die Zufallszahlen erzeugt worden sind, wird eine optionale Prüfung hinsichtlich duplizierter Werte durchgeführt. Bei einer Ausführungsform umfasst das RT daher einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Ausführungsformen können auch andere Wertlängen Verwendung finden.
  • Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess bildet das von der Clientvorrichtung 300 empfangene Anfangsidentifizierungstupel auf den bezogenen SIUI ab, wodurch eine Abbildung <DID, RRG> → <SIUI> gebildet wird, die in der Serverdatenbank 122 gespeichert wird, siehe Bezugszeichen 1160 in 3A. Ein Ketteneintrag <DID, RRG> → <SIUI> → {RT} wird zudem in der Serverdatenbank 122 gespeichert, siehe Bezugszeichen 1170 in 3A. Hierbei bezeichnet {RT} einen Satz von RT-Werten. Zu Beginn umfasst {RT} lediglich den RT-Wert, der anfänglich aus dem RT-Vorrat 164 bezogen worden ist. Werden zusätzliche Kommunikationen zwischen anderen Clients und dem Server 100 verarbeitet, so wächst die Datenbank 122 und enthält bald eine große Anzahl von derartigen Einträgen für die verschiedenen Clients, wie sie durch ihre DID-, RRG- und SIUI-Werte identifiziert werden. Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess definiert ein „Antworttupel” <RRG, RT>, siehe Bezugszeichen 1210 in 3B. Das Kommunikationsmodul 150 ist dafür konfiguriert, dieses Antworttupel an die Antwort, die von dem Server 100 an die Clientvorrichtung 300 gesendet wird, anzuhängen, siehe Bezugszeichen 1220 in 3B.
  • Die Clientvorrichtung 300 speichert das empfangene Antworttupel <RRG, RT> in dem lokalen Sicherungscache 322, siehe Bezugszeichen 1230 in 3B. Bei der Vorbereitung einer erneuten Kommunikation mit dem Server 100 hängt die Clientvorrichtung 300 ihre DID an das gespeicherte Antworttupel an und bildet so ein modifiziertes Antworttupel <DID, RRG, RT>, siehe Bezugszeichen 1240 in 3B. Die Clientvorrichtung 300 kann dem Server auch nach dem anfänglichen Empfang des Antworttupels von dem Server 100 antworten, und zwar insbesondere bei Implementierungen, bei denen eine beträchtliche clientseitige Verarbeitung oder Nutzerinteraktion auftritt. In einigen Fällen kann die Clientvorrichtung 300 verschiedene DID-Werte zu verschiedenen Zeiten erzeugen, und zwar beispielsweise infolge eines Defektes in der DID-Berechnungslogik. Vorgenommen wird daher eine Bestimmung dahingehend, ob die von der Clientvorrichtung 300 erzeugten DID-Werte stabil sind, und insbesondere dahingehend, ob ein vorher erzeugter DID zu einem nachfolgend erzeugten DID passt, siehe Bezugszeichen 1250 in 3B. Dies wird durch Vergleichen der beiden DID-Wertwerte erreicht. Erzeugt die Clientvorrichtung 300 instabile DID-Werte, so werden nachfolgende Kommunikationen mit dem Server 100 auf andere Weise konfiguriert und verarbeitet, wie nachstehend noch in Verbindung mit Nutzungsfall 4 erläutert wird. Passt demgegenüber der nachfolgend erzeugte DID, der zur Bildung des modifizierten Antworttupels verwendet wird, zu dem in dem Anfangsidentifizierungstupel vorhandenen DID, so wird das modifizierte Antworttupel dann <DID, RRG, RT> an den Server 100 mit einer nachfolgenden Serveranfrage gesendet, siehe Bezugszeichen 1260 in 3B.
  • Beim Empfangen des modifizierten Antworttupels extrahiert der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess die DID- und RRG-Werte, siehe Bezugszeichen 1410 in 3C. Unter Verwendung dieser extrahierten Werte wird die Datenbank 122 durchsucht, um den zugehörigen SIUI und RT-Satz zu identifizieren und abzurufen, siehe Bezugszeichen 1420 in 3C. Der RT-Satz wird analysiert, und es wird der letzte hinzugefügte RT-Wert identifiziert. Dieser Wert wird hier als RT-server bezeichnet, da er an dem Server 100 gespeichert ist, siehe Bezugszeichen 1430 in 3C. Auf gleiche Weise wird derjenige RT-Wert, der von der Clientvorrichtung 300 als Teil des modifizierten Antworttupels empfangen wird, hier als RT-client bezeichnet, siehe Bezugszeichen 1440 in 3C. Es wird eine Bestimmung dahingehend vorgenommen, ob RT-server und RT-client identisch sind, siehe Bezugszeichen 1450 in 3C. Ist dem nicht so, so weist dies darauf hin, dass andere Kommunikationen zwischen dem Server 100 und einem anderen Client, der einen identischen DID und RRG innehat, stattgefunden haben, wie wiederum in Verbindung mit Nutzungsfall 2 noch erläutert wird.
  • Sind demgegenüber RT-server und RT-client identisch, so bezieht der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess das nächste verfügbare RT aus dem RT-Vorrat 164, siehe Bezugszeichen 1460 in 3C. Der in der Datenbank 122 gespeicherte RT-Satz wird aktualisiert und enthält damit das letzte bezogene RT als neustes in dem RT-Satz enthaltenes RT, siehe Bezugszeichen 1510 in 3D. Daher kann der RT-Satz derart gedeutet werden, dass er eine Abfolge von RT-Werten offenbart, von denen jeder einen Kommunikationszyklus zwischen dem Server 100 und der Clientvorrichtung 300 darstellt. Der RT-Satz kann daher derart gedeutet werden, dass er eine Aufzeichnung von Kommunikationen bereitstellt, die zwischen dem Server 100 und einem bestimmten Client stattgefunden haben und durch die abgebildeten DID-, RRG- und SIUI-Werte identifiziert werden. Werden nicht aufeinanderfolgende Kommunikationen erfasst, so kann dies ein Hinweis auf eine Vorrichtung sein, die ein Klon einer anderen Vorrichtung ist, die vorher mit dem Server 100 kommuniziert hat.
  • Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess aktualisiert das Antworttupel und ersetzt dabei das bestehende RT-client durch das aus dem RT-Vorrat 164 bezogene neuere RT, siehe Bezugszeichen 1520 in 3D. Das Kommunikationsmodul 150 kann dafür konfiguriert sein zu bestimmen, ob eine weitere Client-Server-Kommunikation auftritt, siehe Bezugszeichen 1530 in 3D. Ist dem so, so wird das Antworttupel, wie hier beschrieben worden ist, an die Clientvorrichtung 300 ausgegeben. Die Clientvorrichtung 300 verarbeitet das Antworttupel auf ähnliche Weise, wie das vorher empfangene Antworttupel verarbeitet worden ist. Dieser Prozess des Austauschens eines aktualisierten RT zwischen dem Client und dem Server und des Verwahrens der Abfolge von ausgetauschten RT-Werten in der Datenbank 122 kann unendlich fortgesetzt werden. Sobald keine weiteren Client-Server-Kommunikationen mehr auftreten, endet das Verfahren 1000. Das Verfahren 1000 kann als Szenario der grundlegenden Verwendung gedeutet werden, da es eine Situation betrifft, in der keine duplizierten Vorrichtungen anzutreffen sind und die Abfolge von RT-Werten, die der Server 100 von der Clientvorrichtung 300 empfängt, keine unerwarteten Unterbrechungen oder Duplizierungen aufweist.
  • Es ist in einigen Fällen möglich, dass einer oder beide von dem SIUI-Vorrat 162 und dem RT-Vorrat 164 leer werden. Geschieht dies, so kann das Tokenverwaltungsmodul 160 dafür konfiguriert sein, einen Aufräumvorgang zu initiieren, bei dem die in der Datenbank 122 gespeicherten RT-Sätze auf den Nullsatz gekürzt werden und bei dem alle eingehenden Clientkommunikationen als anfänglicher Clientkontakt mit Bereitstellung eines anfänglichen Identifizierungstupels behandelt werden. Dies impliziert ein Ignorieren des letzten ausgestellten RT und der vorherigen RRG- und SIUI-Abbildungen. Obwohl durchaus möglich ist, dass ein Konfliktzustand auftritt, ohne dass er während des ersten Kommunikationszyklus nach dem Aufräumvorgang erfasst wird, ist wahrscheinlich, dass beliebige duplizierte Vorrichtungen in einem nachfolgenden Kommunikationszyklus erfasst werden.
  • Methodische Vorgehensweise: geklonte Vorrichtung (Nutzungsfall 2)
  • Wie vorstehend ausgeführt worden ist, umfasst der in der Datenbank 122 verwahrte RT-Satz eine Abfolge von RT-Werten, die den ausgehenden Antworttupeln, die von dem Server 100 an die Clientvorrichtung 300 gesendet werden, entsprechen. Daher passen unter normalen Umständen, also beispielsweise dann, wenn keine duplizierten Vorrichtungen anzutreffen sind, die RT-Werte, die in den von der Clientvorrichtung 300 empfangenen Antworttupeln enthalten sind, zu den in der Datenbank 122 gespeicherten Werten. Tritt ein Abgleichfehler zwischen diesen Werten auf, so weist dies darauf hin, dass bereits andere Kommunikationen zwischen dem Server 100 und dem anderen Client, der einen duplizierten DID und RRG innehat, aufgetreten sind. Insbesondere weist dies darauf hin, dass gegebenenfalls eine bestimmte Clientvorrichtung beispielsweise durch einen Virtualisierungsprozess geklont worden ist. Das Klonen, Virtualisieren oder auf andere Weise erfolgende Duplizieren der Clientvorrichtung 300 kann ein Szenario bereitstellen, bei dem zwei Clientvorrichtungen mit identischen DID- und RRG-Werten versuchen, getrennte Kommunikationszyklen mit dem Server 100 aufzubauen. Dies rührt daher, dass der Klonvorgang bewirkt, dass der Klon dasselbe Tupel <DID, RRG, RT> wie die geklonte Vorrichtung innehat. Angesichts der zunehmenden Verfeinerung und Verbesserung von Vorrichtungsklon- und Virtualisierungstechniken ist es einfacher geworden, die DID- und RRG-Werte, die eine geklonte Vorrichtung innehat, zu duplizieren.
  • 4A und 4B umfassen ein Flussdiagramm zur Darstellung eines exemplarischen Verfahrens 2000 zur Unterscheidung von geklonten Vorrichtungen in einem Vorrichtungsidentifizierungssystem. Das Verfahren 2000 wird hier auch als Nutzungsfall 2 bezeichnet. Wie ersichtlich ist, beinhaltet das Verfahren 2000 eine Anzahl von Phasen und Teilprozessen, deren Abfolge von einer Ausführungsform zur anderen variieren kann. Diese Phasen und Teilprozesse sind jedoch bei einer Betrachtung als Ganzes Teil eines verbesserten Vorrichtungsidentifizierungssystems, das gegenüber Problemen, die von geklonten Vorrichtungen und duplizierten Vorrichtungsidentifizierern verursacht werden, widerstandsfähig ist. Bei einer Ausführungsform reagiert dieses System auf erfasste Kommunikationen in einer Client-Server-Rechenumgebung entsprechend bestimmten der hier offenbarten Techniken. Das Verfahren 2000 kann beispielsweise unter Verwendung der in 2 dargestellten und hier beschriebenen Systemarchitektur implementiert sein. Bei anderen Ausführungsformen können jedoch auch andere Systemarchitekturen Verwendung finden, wie sich im Lichte der vorliegenden Offenbarung erschließt.
  • Zu diesem Zweck soll die Korrelation der in 4A und 4B gezeigten verschiedenen Funktionalitäten mit den in 2 dargestellten spezifischen Komponenten keine strukturellen oder Nutzungsbeschränkungen implizieren. Vielmehr können andere Ausführungsformen beispielsweise einen abweichenden Grad der Integration aufweisen, wobei mehrere Funktionalitäten effektiv von einem System oder Modul wahrgenommen werden. Daher können andere Ausführungsformen in Abhängigkeit von der Kleinteiligkeit bzw. Granularität der Implementierung weniger oder mehr Module aufweisen. Verschiedene Abwandlungen und alternative Konfigurationen erschließen sich im Lichte der vorliegenden Offenbarung.
  • Das Verfahren 2000 wird in Reaktion auf eine Bestimmung dessen aufgerufen, dass ein von der Clientvorrichtung 300 empfangenes RT (RT-client) nicht zu dem letzten RT, das der Server innehat, (RT-server) in dem in der Datenbank 122 gespeicherten RT-Satz passt, siehe Bezugszeichen 1450 in 3C. Dies geschieht, nachdem wenigstens ein Client-Server-Kommunikationszyklus vollständig ist, wie vorstehend bei Nutzungsfall 1 beschrieben worden ist. Sobald ein Abgleichfehler zwischen RT-client und RT-server auftritt, wird das Verfahren 2000 aufgerufen, und es erzeugt der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess einen neuen RRG, der hier als RRG-new bezeichnet wird und der mit der Vorrichtung, die das nicht nachfolgende RT gesendet hat, verknüpft wird, siehe Bezugszeichen 2110 in 4A. Wie bei dem anfänglich erzeugten RRG umfasst RRG-new bei einer Ausführungsform einen 256-Byte-Wert, der durch einen String aus alphanumerischen Zeichen dargestellt werden kann. Bei anderen Ausführungsformen können andere Wertlängen verwendet werden. Der nächste verfügbare SIUI, der hier als SIUI-next bezeichnet wird, wird aus dem SIUI-Vorrat 162 bezogen, siehe Bezugszeichen 2120 in 4A. Auf gleiche Weise wird das nächste verfügbare RT, das hier als RT-next bezeichnet wird, aus dem RT-Vorrat 164 bezogen, siehe Bezugszeichen 2140 in 4A. Das Beziehen der neuen RRG-, SIUI- und RT-Werte ermöglicht, dass der Server 100 die duplizierte Clientvorrichtung eindeutig identifiziert.
  • Unter Verwendung von RRG-new wird ein neues „Klonidentifizierungstupel” <DID, RRG-new> definiert, siehe Bezugszeichen 2150 in 4A. Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess bildet das Klonidentifizierungstupel auf das bezogene SIUI-next ab, sodass eine Abbildung <DID, RRG-new> → <SIUI-next> gebildet wird, die in der Serverdatenbank 122 gespeichert wird, siehe Bezugszeichen 2160 in 4A. Ein entsprechender Ketteneintrag <DID, RRG-new> → <SIUI-next> → {RT-next} wird ebenfalls in der Serverdatenbank 122 gespeichert, siehe Bezugszeichen 2170 in 4A. Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess definiert ein Antworttupel <RRG-new, RT-next>, siehe Bezugszeichen 2210 in 4B.
  • Passt ein von der Clientvorrichtung 300 empfangenes RT nicht zu dem letzten RT, das der Server 100 innehat, in dem in der Datenbank 122 gespeicherten RT-Satz, so weist dies darauf hin, dass andere Kommunikationen zwischen dem Server 100 und einem anderen Client, der einen duplizierten DID und RRG innehat, stattgefunden haben. Dies wird als Konfliktzustand (Clash State) bezeichnet. Es ist von Vorteil, den Konfliktzustand und insbesondere den Umstand, welche Vorrichtungen die den Konflikt hervorrufenden RT-Werte gesendet haben, aufzuzeichnen. Wo eine Vorrichtung die Quelle für zahlreiche geklonte Vorrichtungen ist, wie dies oftmals der Fall ist, ermöglicht ein Verknüpfen der Vorrichtungen, die die einen Konflikt hervorrufenden RT-Werte bereitstellen, ein Identifizieren von ganzen Paketen (Suiten) von virtualisierten Vorrichtungen. Damit ist bei bestimmten Ausführungsformen ein von dem Konflikttriggermodul 170 aufgerufener Konflikttriggerprozess dafür konfiguriert, einen Eintrag {SIUI-old → SIUI-next} in der Konflikt-Erfasst-Datenstruktur 172 zu erstellen, siehe Bezugszeichen 2220 in 4B. Hierbei bezeichnet SIUI-old den duplizierten SIUI, der von der duplizierten Clientvorrichtung empfangen worden ist, während SIUI-next den ersetzten SIUI, der im Verlauf des Verfahrens 2000 erzeugt wird, bezeichnet.
  • Bei bestimmten Ausführungsformen kann die Konflikt-Erfasst-Datenstruktur grafisch wiedergegeben werden, wie in 4B gezeigt ist. Bei dieser exemplarischen Darstellung ist eine den Ursprung bildende Clientvorrichtung, die durch SIUI-0 identifiziert wird, virtualisiert worden und bildet eine erste duplizierte Clientvorrichtung, die durch SIUI-1 identifiziert und wiederum virtualisiert wird, um eine zweite duplizierte Clientvorrichtung zu bilden, die durch SIUI-2 identifiziert wird, und so weiter. In einigen Fällen kann eine bestimmte Clientvorrichtung mehrmals geklont werden, wie dies beispielsweise bei der durch SIUI-5 identifizierten Clientvorrichtung der Fall ist. Eine grafische Darstellung der Konflikt-Erfasst-Datenstruktur 172 ermöglicht, dass die Quelle der duplizierten Vorrichtungen (beim dargestellten Beispiel SIUI-0) schnell identifiziert wird. Auf gleiche Weise können alle Vorrichtungen, die mit der den Ursprung bildenden Clientvorrichtung verknüpft sind, ohne Weiteres ebenfalls identifiziert werden. Diese Funktionalität ist gegebenenfalls von besonderem Nutzen, wenn ein Sicherheitsverstoß an einer duplizierten Vorrichtung erfasst wird, wie es oftmals erwünscht ist, um die Quelle der duplizierten Vorrichtung zu identifizieren. Der von dem Konflikttriggermodul 170 aufgerufene Konflikttriggerprozess ist zudem optional dafür konfiguriert, einen beliebigen anderen geeigneten Vorgang in Reaktion auf das Erfassen eines Konfliktzustandes auszuführen, und zwar beispielsweise mittels Senden von Benachrichtigungen oder mittels Beschränken des Zugriffs auf Serverressourcen. Derartige Handlungen können in Bezug auf die einen Konflikt hervorrufenden Vorrichtungen oder auch in Bezug auf alle Vorrichtungen, die damit in Beziehung stehen, über die Konflikt-Erfasst-Datenstruktur 172 ausgeführt werden.
  • Das in 4A und 4B dargestellte Verfahren 2000 definiert effektiv neue RRG-, SIUI- und RT-Werte für die Vorrichtung, die derart erfasst wird, dass sie ein unerwartetes RT bereitstellt. Diese spezielle Behandlung bietet einen neuen Weg für die duplizierte Vorrichtung, wodurch Konflikte mit bestehenden Clientvorrichtungen vermieden werden, was die Serverkommunikation mit beiden Vorrichtungen vereinfacht. Sogar dann, wenn eine große Anzahl von duplizierten Vorrichtungen vorhanden ist, kann das Verfahren 2000 bei jeder einzelnen derartigen Vorrichtung angewandt werden, wobei jede duplizierte Vorrichtung ihre eigenen neuen RRG- und SIUI-Werte und damit ihren eigenen neuen Weg empfängt. Sobald das neue und eindeutige Antworttupel <RRG-new, RT-next> für eine bestimmte Vorrichtung definiert ist, kann es an die Clientvorrichtung 300 ausgegeben werden, wo es gemäß vorstehender Beschreibung in Verbindung mit Nutzungsfall 1 verarbeitet wird. Dies setzt den iterativen Prozess des Austauschens eines aktualisierten RT zwischen dem Client und dem Server und des Verwahrens der Abfolge von ausgetauschten RT-Werten in der Datenbank 122 mit Verknüpfung zu der eindeutigen Abbildung <DID, RRG-new> → <SIUI-next> fort.
  • Methodische Vorgehensweise: duplizierter Vorrichtungsidentifizierer (Nutzungsfall 3)
  • Wie vorstehend ausgeführt worden ist, treten zahlreiche Fälle auf, in denen mehrere nicht in Beziehung zueinander stehende Clientvorrichtungen gegebenenfalls identische Vorrichtungsidentifizierer aufweisen. Dies kann beispielsweise dort auftreten, wo ein Vorrichtungshersteller beim Zuweisen von Identifizierern an seine Vorrichtungen nicht gewissenhaft ist oder wo zwei Vorrichtungshersteller unwissentlich Vorrichtungen mit identischen Identifizierern herstellen. Zwei nicht in Beziehung zueinander stehende Clientvorrichtungen mit identischen Vorrichtungsidentifizierern erzeugen indes dennoch unterschiedliche RRG-Werte. Wenn also zwei derartige Vorrichtungen anfänglich einen Kontakt mit einem Server gemäß dem hier offenbarten Vorrichtungsidentifizierungssystem einrichten, erzeugt eine erste der Vorrichtungen ein Antworttupel <DID, RRG-1, RT>, während eine zweite der Vorrichtungen ein Antworttupel <DID, RRG-2, RT> erzeugt. Die Vorrichtungen arbeiten unabhängig voneinander und erzeugen keinen Konfliktzustand, da der Server die identischen RRG-Werte von beiden Vorrichtungen nicht empfängt.
  • Methodische Vorgehensweise: instabiler Vorrichtungsidentifizierer (Nutzungsfall 4)
  • Wie vorstehend ausgeführt worden ist, kann in vielen Fällen einer Clientvorrichtung dahingehend nicht vertraut werden, dass sie sich immer dann, wenn der Client mit dem Server in Kontakt tritt, mit demselben Vorrichtungsidentifizierer zuverlässig identifiziert. Dies kann daher rühren, dass der Client eine instabile Hardwarekonfiguration oder einen Defekt in der Berechnungslogik des Vorrichtungsidentifizierers aufweist. Es kann der Fall auftreten, dass Clientkommunikationsprotokolle mit der Absicht, eine Software- oder Contentlizenz, die auf eine einzige Vorrichtung beschränkt ist, zu umgehen, manipuliert worden sind. Unabhängig vom Grund kann, wenn eine einzige Clientvorrichtung 300 mehrere DID-Werte erzeugt, das Verfahren 1000 dahingehend modifiziert werden, dass es mit einem derartigen Verhalten umgehen kann. Ein derartiger Umgang wird hier als Nutzungsfall 4 bezeichnet und kann als Szenario mit einem instabilen Vorrichtungsidentifizierer gedeutet werden.
  • 5A und 5B umfassen ein Flussdiagramm zur Darstellung eines exemplarischen Verfahrens 4000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung in einer Client-Server-Rechenumgebung, wobei die Clientvorrichtung mehrere eindeutige Vorrichtungsidentifiziererwerte erzeugt. Das Verfahren 4000 wird hier auch als Nutzungsfall 4 bezeichnet. Wie ersichtlich ist, beinhaltet das Verfahren 4000 eine Anzahl von Phasen und Teilprozessen, deren Abfolge von einer Ausführungsform zur anderen variieren kann. Diese Phasen und Teilprozesse sind jedoch bei einer Betrachtung als Ganzes Teil eines verbesserten Vorrichtungsidentifizierungssystems, das gegenüber Problemen widerstandsfähig ist, die von Vorrichtungen verursacht werden, denen dahingehend nicht vertraut werden kann, dass sie sich selbst mit demselben Vorrichtungsidentifizierer zuverlässig identifizieren. Bei einer Ausführungsform reagiert das System auf erfasste Kommunikationen in einer Client-Server-Rechenumgebung entsprechend bestimmten der hier offenbarten Techniken. Dasselbe Verfahren 4000 kann beispielsweise unter Verwendung der in 2 dargestellten und hier beschriebenen Systemarchitektur implementiert sein. Bei anderen Ausführungsformen können jedoch auch andere Systemarchitekturen zum Einsatz kommen, wie sich im Lichte der vorliegenden Offenbarung erschließt. Zu diesem Zweck soll die Korrelation der in 5A und 5B gezeigten verschiedenen Funktionalitäten mit den in 2 dargestellten spezifischen Komponenten keine strukturellen oder Nutzungsbeschränkungen implizieren. Vielmehr können andere Ausführungsformen beispielsweise abweichende Grade der Integration aufweisen, wobei mehrere Funktionalitäten effektiv von einem System oder Modul wahrgenommen werden. Daher können andere Ausführungsformen in Abhängigkeit von der Kleinteiligkeit oder Granularität der Implementierung auch weniger oder mehr Module aufweisen. Zahlreiche Abwandlungen und alternative Konfigurationen erschließen sich im Lichte der vorliegenden Offenbarung.
  • Aufgerufen wird das Verfahren 4000 in Reaktion auf eine Bestimmung dessen, dass die Clientvorrichtung 300 DID-Werte erzeugt, die instabil sind, und insbesondere in Reaktion auf eine Bestimmung dessen, dass ein vorher erzeugter DID nicht zu einem nachher erzeugten DID passt, siehe Bezugszeichen 1250 in 3B. Dies geschieht, nachdem wenigstens ein Client-Server-Kommunikationszyklus vollständig ist, wie vorstehend bei Nutzungsfall 1 beschrieben worden ist. Sobald eine instabile DID-Erzeugung beobachtet wird, wird das Verfahren 4000 aufgerufen, und die Clientvorrichtung 300 erzeugt ein modifiziertes Antworttupel, das sowohl einen vorher erzeugten DID (hier als DID-old bezeichnet) und einen nachher erzeugten DID (hier als DID-new bezeichnet) beinhaltet, siehe Bezugszeichen 4110 in 5A. Ein Beispiel für ein derartiges modifiziertes Antworttupel ist <DID-new, RRG, RT, DID-old>. Bei bestimmten Ausführungsformen werden diese Daten aus dem lokalen Speicherungscache 322 extrahiert. Die Clientvorrichtung 300 sendet das modifizierte Antworttupel an den Server mit einer nachfolgenden Serveranfrage, siehe Bezugszeichen 4120 in 5A. Hierdurch wird für den Server 100 effektiv eine Liste von DID-Werten bereitgestellt, die die Clientvorrichtung 300 über eine Zeitspanne erstellt hat. Bei einigen Ausführungsformen leitet beim Empfangen des modifizierten Antworttokens bzw. Antworttupels der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess einen neuen pseudoserverseitigen Vorrichtungsidentifizierer (PDID) mittels Durchführen einer bitweise angewendeten ODER-Operation an DID-old und DID-new her, siehe Bezugszeichen 4140 in 5A. Bei einer alternativen Ausführungsform wird eine andere Operation verwendet, um DID-old und DID-new zu kombinieren, so beispielsweise eine Verkettungsoperation oder eine bitweise angewendete UND-Operation.
  • Der RRG wird aus dem von der Clientvorrichtung 100 empfangenen modifizierten Antworttupel extrahiert, siehe Bezugszeichen 4150 in 5A. Unter Verwendung des hergeleiteten PDID-Wertes und des extrahierten RRG-Wertes wird die Datenbank 122 durchsucht, um den zugeordneten SIUI und RT-Satz zu identifizieren und abzurufen, siehe Bezugszeichen 4160 in 5A. Der RT-Satz wird analysiert, und es wird der letzte hinzugefügte RT-Wert identifiziert. Dieser Wert wird hier als RT-server bezeichnet, da er an dem Server 100 gespeichert ist, siehe Bezugszeichen 4170 in 5A. Auf gleiche Weise wird der von der Clientvorrichtung 300 als Teil des modifizierten Antworttupels empfangene RT-Wert hier als RT-client bezeichnet, siehe Bezugszeichen 4210 in 5B. Es wird eine Bestimmung dahingehend vorgenommen, ob RT-server und RT-client identisch sind, siehe Bezugszeichen 4220 in 5B. Ist dies nicht der Fall, so weist dies darauf hin, dass andere Kommunikationen zwischen dem Server 100 und anderen Clients unter Erzeugung derselben DID-Werte DID-old und DID-new stattgefunden haben. Dies kann dann auftreten, wenn dieselbe defekte Logik bei einem Vorrichtungsvirtualisierungsvorgang dupliziert worden ist. In diesem Fall wird Nutzungsfall 2 unter Verwendung des PDID anstelle eines Standard-DID aufgerufen.
  • Sind demgegenüber RT-server und RT-client identisch, so bezieht der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess den nächsten verfügbaren SIUI, der hier als SIUI-next bezeichnet wird, aus dem SIUI-Vorrat 162, siehe Bezugszeichen 4230 in 5B. Auf gleiche Weise wird das nächste verfügbare RT, das hier als RT-next bezeichnet wird, aus dem RT-Vorrat 164 bezogen, siehe Bezugszeichen 4240 in 5B. Ein modifiziertes Clientidentifizierungstupel <PDID, RRG> wird auf den erworbenen SIUI-next abgebildet, wodurch eine Abbildung <PDID, RRG> → <SIUI-next> gebildet wird, die in der Serverdatenbank 122 gespeichert wird. Ein entsprechender Ketteneintrag <PDID, RRG> → <SIUI-next> → {RT-next} wird zudem in der Serverdatenbank 122 gespeichert, siehe Bezugszeichen 4250 in 5B. Der von dem Tokenverwaltungsmodul 160 aufgerufene Tokenverwaltungsprozess definiert zudem ein aktualisiertes Antworttupel <RRG, RT-next>, siehe Bezugszeichen 4260 in 5B. Dieses aktualisierte Antworttupel kann an die Clientvorrichtung 300 ausgegeben werden, wo es gemäß vorstehender Beschreibung in Verbindung mit Nutzungsfall 1 verarbeitet wird. Dies setzt den iterativen Prozess des Austauschens eines aktualisierten RT zwischen dem Client und dem Server und des Verwahrens der Abfolge der ausgetauschten RT-Werte in der Datenbank 122 mit Verknüpfung zu einer eindeutigen Abbildung <PDID, RRG> → <SIUI-next> fort.
  • Obwohl das Verfahren 4000 im Zusammenhang mit einer Clientvorrichtung beschrieben worden ist, die zwei verschiedene DID-Werte DID-old und DID-new erzeugt, kann es auch bei Anwendungen zum Einsatz kommen, wo die Clientvorrichtung (a) wiederholt zwischen der Bereitstellung von DID-old und DID-new wechselt oder (b) mit der Bereitstellung von neuen DID-Werten in jedem Kommunikationszyklus fortfährt. Das von der Clientvorrichtung bereitgestellte modifizierte Antworttupel stellt eine abfolgetechnische Historie der vorher erzeugten DID-Werte bereit. Zudem erzeugt die bitweise angewendete ODER-Operation, die an allen empfangenen DID-Werten durchgeführt wird, weiterhin einen eindeutigen PDID-Wert, der zum Identifizieren der speziellen Clientvorrichtung und zum Abrufen des damit verknüpften SIUI und RT-Satzes verwendet werden kann. Das Verfahren wird durch den Verlust von SIUI-Werten nicht beeinträchtigt, da die PDID-Werte zum eindeutigen Identifizieren der Clientvorrichtung verwendet werden können.
  • Wird eine Clientvorrichtung, die mehrere DID-Werte erzeugt, geklont und erzeugen die resultierenden duplizierten Vorrichtungen dieselbe Abfolge von mehreren DID-Werten, so legt dies nahe, dass sich der Defekt in der DID-Berechnungslogik von der den Ursprung bildenden Vorrichtung ausgehend zu deren Klonen ausgebreitet hat. In diesem Fall kann die methodische Vorgehensweise im Zusammenhang mit Nutzungsfall 2 aufgerufen werden, um mit Situationen umzugehen, in denen ein RT-Abgleichfehler erfasst wird, siehe Bezugszeichen 4220 in 5B. Wenn demgegenüber eine Clientvorrichtung, die mehrere DID-Werte erzeugt, geklont wird und die resultierenden duplizierten Vorrichtungen verschiedene Vorrichtungsidentifizierer erstellen, kann die methodische Vorgehensweise in Verbindung mit Nutzungsfall 3 aufgerufen werden.
  • Weitere exemplarische Ausführungsformen
  • Es erschließen sich zahlreiche Abwandlungen und Konfigurationen im Lichte der vorliegenden Offenbarung. Wie in 6 gezeigt ist, stellt eine exemplarische Ausführungsform beispielsweise ein computerimplementiertes Verfahren 6000 zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung bereit. Das Verfahren 6000 beinhaltet ein durch einen Server von einer Clientvorrichtung erfolgendes Empfangen eines DID, der der Clientvorrichtung zugewiesen worden ist, siehe Bezugszeichen 6100 in 6 und siehe zudem Bezugszeichen 1110 und 1120 in 3A, die darauf hinweisen, dass das Verfahren 1000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung ein Senden eines Anfangsidentifizierungstupels <DID, RRG> an einen Server mit einer Anfangsserveranfrage beinhaltet.
  • Das Verfahren 6000 beinhaltet des Weiteren ein durch den Server erfolgendes Beziehen eines ersten RT, siehe Bezugszeichen 6200 in 6 und siehe zudem Bezugszeichen 1150 in 3A, das darauf hinweist, dass das Verfahren 1000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung ein Beziehen eines RT aus einem RT-Vorrat beinhaltet.
  • Das Verfahren 6000 beinhaltet des Weiteren ein von dem Server an die Clientvorrichtung erfolgendes Senden des ersten RT, siehe Bezugszeichen 6300 in 6 und siehe zudem Bezugszeichen 1210 und 1220 in 3B, die darauf hinweisen, dass das Verfahren 1000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung ein Anhängen eines Antworttupels <RRG, RT> an eine Antwort, die von einem Server an eine Clientvorrichtung gesendet wird, beinhaltet.
  • Das Verfahren 6000 beinhaltet des Weiteren ein durch den Server von einer nichtidentifizierten Vorrichtung erfolgendes Empfangen des DID und eines zweiten RT, siehe Bezugszeichen 6400 in 6 und siehe zudem Bezugszeichen 1240 und 1260 in 3B, die darauf hinweisen, dass das Verfahren 1000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung ein Senden eines modifizierten Antworttupels an den Server mit einer nachfolgenden Serveranfrage beinhaltet, wobei das modifizierte Antworttupel durch Anhängen einer Client-DID an ein Antworttupel, das vorher von dem Server an die Clientvorrichtung gesendet worden ist, gebildet wird.
  • Das Verfahren 6000 beinhaltet des Weiteren ein Vornehmen einer Bestimmung dessen, dass die ersten und zweiten RT-Werte identisch sind, siehe Bezugszeichen 6500 in 6 und siehe zudem Bezugszeichen 1450 in 3C, das darauf hinweist, dass das Verfahren 1000 zum Identifizieren einer Clientvorrichtung gegenüber einer Servervorrichtung ein Bestimmen dessen, ob RT-server und RT-client gleich sind, beinhaltet. Hierbei ist RT-server als neustes RT in einem aus einer Serverdatenbank abgerufenen RT-Satz definiert, während RT-client als von dem Client in einem modifizierten Antworttupel empfangenes RT definiert ist, siehe Bezugszeichen 1430 und 1440 in 3C.
  • Das Verfahren 6000 beinhaltet des Weiteren ein Identifizieren der unbekannten Vorrichtung als Clientvorrichtung auf Grundlage der Bestimmung, siehe Bezugszeichen 6600 in 6 und siehe zudem Bezugszeichen 1460 in 3C und Bezugszeichen 1510 und 1520 in 3D, die darauf hinweisen, dass ein aktualisiertes Antworttupel ohne neue Vorrichtungsidentifizierungstokenwerte, so beispielsweise neue RRG- oder SIUI-Werte, erzeugt wird.
  • In einigen Fällen beinhaltet das Verfahren des Weiteren ein durch den Server von der Clientvorrichtung in einem den DID beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines RRG, der von der Clientvorrichtung erzeugt worden ist. In einigen Fällen (a) beinhaltet das Verfahren des Weiteren ein durch den Server von der Clientvorrichtung in einem den DID beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines RRG, der von der Clientvorrichtung erzeugt worden ist, und (b) wird der RRG von dem Server an die Clientvorrichtung in einem Antworttupel, das das erste RT beinhaltet, gesendet. In einigen Fällen werden der DID und der zweite RT in einem modifizierten Antworttupel empfangen, das von der unbekannten Vorrichtung erzeugt worden ist. In einigen Fällen (a) beinhaltet das Verfahren des Weiteren ein durch den Server von der Clientvorrichtung in einem den DID beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines RRG, der von der Clientvorrichtung erzeugt worden ist, und (b) werden zudem der DID und der RRG von der nichtidentifizierten Vorrichtung empfangen. In einigen Fällen beinhaltet der Server einen RT-Vorrat, aus dem das erste RT bezogen wird. In einigen Fällen beinhaltet das Verfahren des Weiteren (a) ein durch den Server erfolgendes Erzeugen eines SIUI entsprechend der Clientvorrichtung und (b) ein Bilden einer Verknüpfung zwischen dem SIUI, dem empfangenen DID und dem ersten RT, wobei die Verknüpfung in einer von dem Server verwalteten Datenbank gebildet wird. In einigen Fällen beinhaltet das Verfahren des Weiteren (a) ein durch den Server von der Clientvorrichtung in einem den DID beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines RRG, der von der Clientvorrichtung erzeugt worden ist, und (b) ein Abbilden des Anfangsidentifizierungstupels auf das erste RT in einer von dem Server verwalteten Datenbank, wobei (c) das Vornehmen der Bestimmung des Weiteren ein Verwenden des DID zum Extrahieren des ersten RT aus der Datenbank umfasst.
  • Eine weitere exemplarische Ausführungsform stellt ein Vorrichtungsidentifizierungssystem bereit. Das System beinhaltet eine Speichervorrichtung. Das System beinhaltet des Weiteren einen Prozessor, der operativ mit der Speichervorrichtung gekoppelt ist. Die Vorrichtung ist dafür konfiguriert, in der Speichervorrichtung gespeicherte Anweisungen auszuführen, die bei Ausführung veranlassen, dass der Prozessor einen Prozess zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung ausführt. Der Prozess beinhaltet ein durch einen Server von einer Clientvorrichtung erfolgendes Empfangen eines RRG, der von der Clientvorrichtung erzeugt worden ist, und eines ersten RT. Der Prozess beinhaltet des Weiteren ein Verwenden des empfangenen RRG zum Nachschlagen eines zweiten RT in einer von dem Server verwalteten Datenbank. Der Prozess beinhaltet des Weiteren ein Vornehmen einer Bestimmung dessen, dass das erste RT in Bezug auf das zweite RT veraltet ist. Der Prozess beinhaltet des Weiteren ein Zuweisen eines neuen RRG (RRG-new) an die Clientvorrichtung. Der Prozess beinhaltet des Weiteren ein Beziehen eines neuen RT. Der Prozess beinhaltet des Weiteren ein Verknüpfen von RRG-new mit dem neuen RT in der Datenbank. Der Prozess beinhaltet des Weiteren ein Senden eines Tupels, das RRG-new und das neue RT umfasst, an die Clientvorrichtung. In einigen Fällen (a) werden der RRG und das erste RT in einem Antworttupel empfangen, das eine Mehrzahl von verschiedenen DID-Werten beinhaltet, (b) beinhaltet der Prozess des Weiteren ein Erzeugen eines pseudoserverseitigen Vorrichtungsidentifizierers (PDIP) mittels Durchführen einer bitweise angewendeten ODER-Operation an der Mehrzahl von verschiedenen DID-Werten, wobei (c) das Verknüpfen von RRG-new mit dem neuen RT in der Datenbank des Weiteren ein Abbilden eines Tupels <PDID, RRG-new> auf einen RT-Satz, der das neue RT beinhaltet, umfasst. In einigen Fällen umfasst das Beziehen des neuen RT ein Beziehen des neuen RT aus einem von dem Server gehosteten RT-Vorrat. In einigen Fällen (a) werden der RRG und das erste RT in einem Antworttupel, das einen DID beinhaltet, empfangen, (b) beinhaltet die Datenbank eine Abbildung des Antworttupels auf SIUI-1, der mit der Clientvorrichtung verknüpft ist, (c) beinhaltet der Prozess des Weiteren ein Beziehen eines neuen SIUI-2 und ein Verknüpfen des neuen SIUI-2 mit der Clientvorrichtung, und (d) beinhaltet der Prozess des Weiteren ein Erstellen eines neuen Eintrages {SIUI-1 → SIUI-2} in einer Konflikt-Erfasst-Datenstruktur. In einigen Fällen (a) werden der RRG und das erste RT in einem Antworttupel empfangen, das einen DID beinhaltet, (b) beinhaltet die Datenbank eine Abbildung des Antworttupels auf einen SIUI, der mit der Clientvorrichtung verknüpft ist, (c) beinhaltet der Prozess des Weiteren ein Definieren eines Klonidentifizierungstupels <DID, RRG-new>, (d) beinhaltet der Prozess des Weiteren ein Beziehen eines neuen SIUI, und (e) beinhaltet der Prozess des Weiteren ein Erstellen eines Ketteneintrages in der Datenbank, der bzw. die eine aktualisierte Abbildung des Klonidentifizierungstupels auf den neuen SIUI umfasst, der wiederum auf einen RT-Satz, der das neue RT beinhaltet, abgebildet wird. In einigen Fällen (a) werden der RRG und das erste RT in einem Antworttupel empfangen, das einen DID beinhaltet, und (b) beinhaltet der Prozess des Weiteren ein Definieren eines Klonidentifizierungstupels, das den DID und den neuen RRG beinhaltet. In einigen Fällen (a) werden der RRG und der erste RT in einem Antworttupel, das einen DID beinhaltet, empfangen, und (b) werden sowohl der RRG wie auch der DID zum Nachschlagen des zweiten RT verwendet. In einigen Fällen (a) werden der RRG und das erste RT in einem Antworttupel, das einen DID beinhaltet, empfangen, (b) wird der RRG von der Clientvorrichtung erzeugt, und (c) wird der DID von einem Hersteller der Clientvorrichtung zugewiesen.
  • Eine weitere exemplarische Ausführungsform stellt ein nichttemporäres computerlesbares Medium bereit, auf dem Anweisungen codiert sind, die bei Ausführung durch einen oder mehrere Prozessoren veranlassen, dass ein Prozess zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung ausgeführt wird. Der Prozess beinhaltet ein durch einen Server von einer Clientvorrichtung erfolgendes Empfangen eines DID, der der Clientvorrichtung zugewiesen worden ist, und eines RRG, der von der Clientvorrichtung erzeugt worden ist. Der Prozessor beinhaltet des Weiteren ein durch den Server erfolgendes Beziehen eines SIUI entsprechend der Clientvorrichtung. Der Prozess umfasst des Weiteren ein durch den Server erfolgendes Beziehen eines ersten Auffrischungstokens (RT-1). Der Prozess umfasst des Weiteren ein Erstellen eines Ketteneintrages in einer von dem Server verwalteten Datenbank, wobei der Ketteneintrag <DID, RRG> → <SIUI> → {RT-1} umfasst, wobei {RT-1} ein RT-1 umfassender Satz ist. Der Prozess beinhaltet des Weiteren ein Senden eines Antworttupels <RRG, RT-1> von der Clientvorrichtung. Der Prozess beinhaltet des Weiteren ein Empfangen eines modifizierten Antworttupels <DID, RRG, RG-1> an die Clientvorrichtung. Der Prozess beinhaltet des Weiteren ein in Reaktion auf das Empfangen des modifizierten Antworttupels erfolgendes Beziehen eines zweiten Auffrischungstokens RT-2. Der Prozess beinhaltet des Weiteren ein Anhängen des zweiten Auffrischungstokens RT-2 zu dem das erste RT umfassenden Satz. Der Prozess beinhaltet des Weiteren ein Senden eines aktualisierten Antworttupels <RRG, RT-2> an die Clientvorrichtung. In einigen Fällen wird der SIUI aus einem von dem Server gehosteten SIUI-Vorrat bezogen. In einigen Fällen entspricht eine Menge von RT in dem Satz einer Menge der Kommunikationszyklen, die zwischen dem Server und der Clientvorrichtung aufgetreten sind. In einigen Fällen (a) werden die ersten und zweiten RT-Werte aus einem RT-Vorrat bezogen, und (b) beinhaltet der Prozess des Weiteren ein in Reaktion auf ein Bestimmen dessen, dass der RT-Vorrat ausgeschöpft ist, erfolgendes Leeren des Satzes und Zurücksetzen des RT-Vorrates.
  • Die vorstehende Beschreibung ist zu Zwecken der Darstellung und Erläuterung aufgeführt. Sie soll nicht dahingehend gedeutet werden, dass sie erschöpfend ist oder die Offenbarung auf die speziellen beschriebenen Ausführungsformen beschränkt. Daher sind im Lichte der vorliegenden Offenbarung vielerlei Modifikationen und Abwandlungen möglich. Es ist beabsichtigt, dass der Umfang der Erfindung nicht durch die Detailbeschreibung, sondern durch die beigefügten Ansprüche beschränkt wird.

Claims (20)

  1. Computerimplementiertes Verfahren zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung, wobei das Verfahren umfasst: durch einen Server von einer Clientvorrichtung erfolgendes Empfangen eines Vorrichtungsidentifizierers, der der Clientvorrichtung zugewiesen worden ist; durch den Server erfolgendes Beziehen eines ersten Auffrischungstokens; von dem Server an die Clientvorrichtung erfolgendes Senden des ersten Auffrischungstokens; durch den Server von einer nichtidentifizierten Vorrichtung erfolgendes Empfangen des Vorrichtungsidentifizierers und eines zweiten Auffrischungstokens; Vornehmen einer Bestimmung dessen, dass die ersten und zweiten Auffrischungstokens identisch sind; und Identifizieren der unbekannten Vorrichtung als Clientvorrichtung auf Grundlage der Bestimmung.
  2. Verfahren nach Anspruch 1, des Weiteren umfassend ein durch den Server von der Clientvorrichtung in einem den Vorrichtungsidentifizierer beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines ursprünglichen beliebigen global eindeutigen Identifizierers (RRG), der von der Clientvorrichtung erzeugt worden ist.
  3. Verfahren nach Anspruch 1 oder 2, des Weiteren umfassend ein durch den Server von der Clientvorrichtung in einem den Vorrichtungsidentifizierer beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines ursprünglichen beliebigen global eindeutigen Identifizierers (RRG), der von der Clientvorrichtung erzeugt worden ist; wobei der RRG von dem Server an die Clientvorrichtung in einem Antworttupel, das das erste Auffrischungstoken beinhaltet, gesendet wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Vorrichtungsidentifizierer und das zweite Auffrischungstoken in einem modifizierten Antworttupel, das von der unbekannten Vorrichtung erzeugt worden ist, empfangen werden.
  5. Verfahren nach einem der vorhergehenden Ansprüche, des Weiteren umfassend ein durch den Server von der Clientvorrichtung in einem den Vorrichtungsidentifizierer beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines ursprünglichen beliebigen global eindeutigen Identifizierers (RRG), der von der Clientvorrichtung erzeugt worden ist; wobei der Vorrichtungsidentifizierer und der RRG zudem von der nichtidentifizierten Vorrichtung empfangen werden.
  6. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Server einen Auffrischungstokenvorrat- bzw. pool, aus dem das erste Auffrischungstoken bezogen wird, beinhaltet.
  7. Verfahren nach einem der vorhergehenden Ansprüche, des Weiteren umfassend: durch den Server erfolgendes Erzeugen eines serverseitig ausgestellten eindeutigen Identifizierers (SIUI) entsprechend der Clientvorrichtung; und Bilden einer Verknüpfung zwischen dem SIUI, dem empfangenen Vorrichtungsidentifizierer und dem ersten Auffrischungstoken, wobei die Verknüpfung in einer von dem Server verwalteten Datenbank gebildet wird.
  8. Verfahren nach einem der vorhergehenden Ansprüche, des Weiteren umfassend: durch den Server von der Clientvorrichtung in einem den Vorrichtungsidentifizierer beinhaltenden Anfangsidentifizierungstupel erfolgendes Empfangen eines ursprünglichen beliebigen global eindeutigen Identifizierers (RRG), der von der Clientvorrichtung erzeugt worden ist; und Abbilden des Anfangsidentifizierungstupels auf das erste Auffrischungstoken in einer von dem Server verwalteten Datenbank; wobei das Vornehmen der Bestimmung des Weiteren ein Verwenden des Vorrichtungsidentifizierers zum Extrahieren des ersten Auffrischungstokens aus der Datenbank umfasst.
  9. Vorrichtungsidentifizierungssystem, das eine Speichervorrichtung und einen operativ mit der Speichervorrichtung gekoppelten Prozessor umfasst, wobei der Prozessor dafür konfiguriert ist, in der Speichervorrichtung gespeicherte Anweisungen auszuführen, die bei Ausführung veranlassen, dass der Prozessor einen Prozess zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung ausführt, wobei der Prozess umfasst: durch einen Server von einer Clientvorrichtung erfolgendes Empfangen eines ursprünglichen beliebigen global eindeutigen Identifizierers (RRG), der von der Clientvorrichtung erzeugt worden ist, und eines ersten Auffrischungstokens; Verwenden des empfangenen RRG zum Nachschlagen eines zweiten Auffrischungstokens in einer von dem Server verwalteten Datenbank; Vornehmen einer Bestimmung dessen, dass das erste Auffrischungstoken in Bezug auf das zweite Auffrischungstoken veraltet ist; Zuweisen eines neuen RRG (RRG-new) an die Clientvorrichtung; Beziehen eines neuen Auffrischungstokens; Verknüpfen des neuen RRG mit dem neuen Auffrischungstoken in der Datenbank; und Senden eines Tupels, das den neuen RRG und das neue Auffrischungstoken umfasst, an die Clientvorrichtung.
  10. System nach Anspruch 9, wobei: der RRG und das erste Auffrischungstoken in einem Antworttupel, das eine Mehrzahl von verschiedenen Vorrichtungsidentifizierern beinhaltet, empfangen werden; der Prozess des Weiteren ein Erzeugen eines pseudoserverseitigen Vorrichtungsidentifizierers (PDID) mittels Durchführen einer bitweise angewendeten ODER-Operation an der Mehrzahl von verschiedenen Vorrichtungsidentifizierern umfasst; und das Verknüpfen des neuen RRG mit dem neuen Auffrischungstoken in der Datenbank des Weiteren umfasst: Abbilden eines Tupels <PDID, RRG-new> auf einen Auffrischungstokensatz, der das neue Auffrischungstoken beinhaltet.
  11. System nach Anspruch 9 oder 10, wobei das Beziehen des neuen Auffrischungstokens ein Beziehen des neuen Auffrischungstokens aus einem von dem Server gehosteten Auffrischungstokenvorrat umfasst.
  12. System nach einem der Ansprüche 9 bis 11, wobei: der RRG und das erste Auffrischungstoken in einem Antworttupel, das einen Vorrichtungsidentifizierer (DID) beinhaltet, empfangen werden; die Datenbank eine Abbildung des Antworttupels auf einen ersten serverseitig ausgestellten eindeutigen Identifizierer (SIUI-1), der mit der Clientvorrichtung verknüpft ist, beinhaltet; der Prozess des Weiteren ein Beziehen eines neuen SIUI-2 und ein Verknüpfen des neuen SIUI-2 mit der Clientvorrichtung umfasst; und der Prozess des Weiteren ein Erstellen eines neuen Eintrages {SIUI-1 → SIUI-2} in einer Konflikt-Erfasst-Datenstruktur bzw. Clash Detected-Datenstruktur umfasst.
  13. System nach einem der Ansprüche 9 bis 12, wobei: der RRG und das erste Auffrischungstoken in einem Antworttupel, das einen Vorrichtungsidentifizierer (DID) beinhaltet, empfangen werden; die Datenbank eine Abbildung des Antworttupels auf einen serverseitig ausgestellten eindeutigen Identifizierer (SIUI), der mit der Clientvorrichtung verknüpft ist, beinhaltet; der Prozess des Weiteren ein Definieren eines Klonidentifizierungstupels <DID, RRG-new> umfasst; der Prozess des Weiteren ein Beziehen eines neuen SIUI umfasst; und der Prozess des Weiteren ein Erstellen eines Ketteneintrages in der Datenbank umfasst, der bzw. die eine aktualisierte Abbildung des Klonidentifizierungstupels auf den neuen SIUI umfasst, der wiederum auf einen Auffrischungstokensatz, der das neue Auffrischungstoken beinhaltet, abgebildet wird.
  14. System nach einem der Ansprüche 9 bis 13, wobei: der RRG und das erste Auffrischungstoken in einem Antworttupel, das einen Vorrichtungsidentifizierer beinhaltet, empfangen werden; und der Prozess des Weiteren ein Definieren eines Klonidentifizierungstupels, das den Vorrichtungsidentifizierer und den neuen RRG beinhaltet, umfasst.
  15. System nach einem der Ansprüche 9 bis 14, wobei: der RRG und das erste Auffrischungstoken in einem Antworttupel, das einen Vorrichtungsidentifizierer beinhaltet, empfangen werden; und sowohl der RRG wie auch der Vorrichtungsidentifizierer zum Nachschlagen des zweiten Auffrischungstokens verwendet werden.
  16. System nach einem der Ansprüche 9 bis 15, wobei: der RRG und das erste Auffrischungstoken in einem Antworttupel, das einen Vorrichtungsidentifizierer beinhaltet, empfangen werden; der RRG von der Clientvorrichtung erzeugt wird; und der Vorrichtungsidentifizierer durch einen Hersteller der Clientvorrichtung zugewiesen wird.
  17. Nichttemporäres computerlesbares Medium, auf dem Anweisungen codiert sind, die bei Ausführung durch einen oder mehrere Prozessoren veranlassen, dass ein Prozess zum Identifizieren von Clientvorrichtungen in einer Client-Server-Rechenumgebung ausgeführt wird, wobei der Prozess umfasst: durch einen Server von einer Clientvorrichtung erfolgendes Empfangen eines Vorrichtungsidentifizierers (DID), der der Clientvorrichtung zugewiesen worden ist, und eines ursprünglichen beliebigen global eindeutigen Identifizierers (RRG), der von der Clientvorrichtung erzeugt worden ist; durch den Server erfolgendes Beziehen eines serverseitig ausgestellten eindeutigen Identifizierers (SIUI) entsprechend der Clientvorrichtung; durch den Server erfolgendes Beziehen eines ersten Auffrischungstokens (RT-1); Erstellen eines Ketteneintrages in einer von dem Server verwalteten Datenbank, wobei der Ketteneintrag <DID, RRG> → <SIUI> → {RT-1} umfasst, wobei {RT-1} ein Satz ist, der das erste Auffrischungstoken beinhaltet; Senden eines Antworttupels <RRG, RT-1> an die Clientvorrichtung; Empfangen eines modifizierten Antworttupels <DID, RRG, RT-1> von der Clientvorrichtung; in Reaktion auf das Empfangen des modifizierten Antworttupels erfolgendes Beziehen eines zweiten Auffrischungstokens RT-2; Hinzufügen des zweiten Auffrischungstokens RT-2 zu dem das erste Auffrischungstoken umfassenden Satz; und Senden eines aktualisierten Antworttupels <RRG, RT-2> an die Clientvorrichtung.
  18. Nichttemporäres computerlesbares Medium nach Anspruch 17, wobei der SIUI aus einem von dem Server gehosteten SIUI-Vorrat bezogen wird.
  19. Nichttemporäres computerlesbares Medium nach Anspruch 17 oder 18, wobei eine Menge von Auffrischungstokens in dem Satz einer Menge von Kommunikationszyklen, die zwischen dem Server und der Clientvorrichtung aufgetreten sind, entspricht.
  20. Nichttemporäres computerlesbares Medium nach einem der Ansprüche 17 bis 19, wobei: die ersten und zweiten Auffrischungstokens aus einem Auffrischungstokenvorrat bzw. –pool bezogen werden; und der Prozess des Weiteren in Reaktion auf ein Bestimmen dessen, dass der Auffrischungstokenvorrat ausgeschöpft ist, ein Leeren des Satzes und ein Zurücksetzen des Auffrischungstokenvorrates umfasst.
DE102016013586.7A 2016-01-06 2016-11-14 Robustes Rechenvorrichtungsidentifizierungssystem Pending DE102016013586A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/988,954 2016-01-06
US14/988,954 US10652365B2 (en) 2016-01-06 2016-01-06 Robust computing device identification framework

Publications (1)

Publication Number Publication Date
DE102016013586A1 true DE102016013586A1 (de) 2017-07-06

Family

ID=59055344

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016013586.7A Pending DE102016013586A1 (de) 2016-01-06 2016-11-14 Robustes Rechenvorrichtungsidentifizierungssystem

Country Status (5)

Country Link
US (2) US10652365B2 (de)
CN (1) CN107085681B (de)
AU (1) AU2016253706B2 (de)
DE (1) DE102016013586A1 (de)
GB (1) GB2546135B (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108880912A (zh) * 2018-07-18 2018-11-23 北京力尊信通科技股份有限公司 一种it运维控制系统及方法
US11277267B2 (en) * 2019-05-07 2022-03-15 International Business Machines Corporation Fine-grained token based access control

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030163693A1 (en) * 2002-02-28 2003-08-28 General Instrument Corporation Detection of duplicate client identities in a communication system
US7428587B2 (en) 2002-12-19 2008-09-23 Microsoft Corporation Generating globally unique device identification
US7716474B2 (en) * 2003-05-12 2010-05-11 Byteblaze, Inc. Anti-piracy software protection system and method
US8875236B2 (en) * 2007-06-11 2014-10-28 Nokia Corporation Security in communication networks
US8949827B2 (en) * 2007-06-22 2015-02-03 Red Hat, Inc. Tracking a virtual machine
US20100011391A1 (en) * 2008-07-14 2010-01-14 Carpenter Jason P Decoder-specific content provision system and method
US8595361B2 (en) * 2009-02-10 2013-11-26 Novell, Inc. Virtual machine software license management
US8898748B2 (en) * 2009-05-21 2014-11-25 Mobile Iron, Inc. Remote verification for configuration updates
US8527774B2 (en) * 2009-05-28 2013-09-03 Kaazing Corporation System and methods for providing stateless security management for web applications using non-HTTP communications protocols
CN101990183B (zh) * 2009-07-31 2013-10-02 国际商业机器公司 保护用户信息的方法、装置及系统
CN105243313B (zh) * 2010-01-12 2018-12-25 维萨国际服务协会 用于对验证令牌的任何时候确认的方法
US8850219B2 (en) * 2010-05-13 2014-09-30 Salesforce.Com, Inc. Secure communications
GB2481133A (en) 2010-06-09 2011-12-14 Omnifone Ltd Uniquely identifying a computing device in trial period abuse prevention
US20110307387A1 (en) * 2010-06-15 2011-12-15 Opensky Project, Inc. Method and System for Distributed Point of Sale Transactions
CN103190130A (zh) * 2010-11-05 2013-07-03 瑞典爱立信有限公司 用于向设备提供秘密值的注册服务器、网关装置和方法
GB2485241A (en) 2010-11-05 2012-05-09 Bluecava Inc Incremental browser-based fingerprinting of a computing device
US8868915B2 (en) * 2010-12-06 2014-10-21 Verizon Patent And Licensing Inc. Secure authentication for client application access to protected resources
US9280765B2 (en) * 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US8789209B2 (en) * 2012-03-07 2014-07-22 Avaya Inc. Enterprise license registrar anchor point
US8898764B2 (en) * 2012-04-19 2014-11-25 Microsoft Corporation Authenticating user through web extension using token based authentication scheme
US9413758B2 (en) * 2012-05-24 2016-08-09 Fmr Llc Communication session transfer between devices
US9038148B1 (en) * 2012-08-23 2015-05-19 Amazon Technologies, Inc. Secret variation for network sessions
US20140067687A1 (en) * 2012-09-02 2014-03-06 Mpayme Ltd. Clone defence system for secure mobile payment
EP2787696B1 (de) * 2012-11-15 2016-10-26 Huawei Device Co., Ltd. Verfahren und vorrichtung zur übertragung einer echtzeit-webkommunikationssitzung
US9130926B2 (en) * 2012-12-27 2015-09-08 Microsoft Technology Licensing, Llc Authorization messaging with integral delegation data
US9210155B2 (en) * 2013-03-08 2015-12-08 Stocktree Inc. System and method of extending a host website
US8966599B1 (en) * 2013-03-14 2015-02-24 Amazon Technologies, Inc. Automatic token renewal for device authentication
US9510193B2 (en) * 2013-03-15 2016-11-29 Qualcomm Incorporated Wireless networking-enabled personal identification system
US9015817B2 (en) 2013-04-03 2015-04-21 Symantec Corporation Resilient and restorable dynamic device identification
KR102058175B1 (ko) * 2013-05-15 2019-12-20 비자 인터네셔널 서비스 어소시에이션 모바일 토큰화 허브
JP6124687B2 (ja) * 2013-05-29 2017-05-10 キヤノン株式会社 画像形成装置、サーバー装置、情報処理方法及びプログラム
US9537659B2 (en) * 2013-08-30 2017-01-03 Verizon Patent And Licensing Inc. Authenticating a user device to access services based on a device ID
US9229987B2 (en) * 2013-09-30 2016-01-05 Protegrity Corporation Mapping between tokenization domains
US20150113588A1 (en) * 2013-10-22 2015-04-23 Cisco Technology, Inc. Firewall Limiting with Third-Party Traffic Classification
US9106620B2 (en) * 2013-11-14 2015-08-11 Comcast Cable Communications, Llc Trusted communication session and content delivery
CN104767719B (zh) * 2014-01-07 2018-09-18 阿里巴巴集团控股有限公司 确定登录网站的终端是否是移动终端的方法及服务器
US9241269B1 (en) * 2014-07-10 2016-01-19 Sprint Communications Company L.P. Method to identify a customer on a Wi-Fi network
US20160012422A1 (en) * 2014-07-11 2016-01-14 Google Inc. Hands-free transactions with a transaction confirmation request
KR20160012575A (ko) * 2014-07-24 2016-02-03 삼성전자주식회사 재난 알림 서버 및 재난 알림 서버의 재난 알림 방법
GB2530726B (en) * 2014-09-25 2016-11-02 Ibm Distributed single sign-on
CN106796630B (zh) * 2014-09-30 2020-04-24 惠普发展公司，有限责任合伙企业 用户认证
SG10201501246TA (en) * 2015-02-17 2016-09-29 Mastercard Asia Pacific Pte Ltd Methods and systems for processing an electronic payment
US9779233B2 (en) * 2015-03-05 2017-10-03 Ricoh Co., Ltd. Broker-based authentication system architecture and design
US9648007B1 (en) * 2015-06-17 2017-05-09 Amazon Technologies, Inc. Token-based storage service
CN105245541B (zh) * 2015-10-28 2020-02-18 腾讯科技（深圳）有限公司 鉴权方法、设备及系统
EP3384471B1 (de) * 2015-12-03 2022-04-13 Nokia Technologies Oy Zugangsverwaltung

Also Published As

Publication number Publication date
CN107085681B (zh) 2022-10-21
US10652365B2 (en) 2020-05-12
AU2016253706A1 (en) 2017-07-20
AU2016253706B2 (en) 2021-04-01
GB2546135B (en) 2019-01-09
US11418570B2 (en) 2022-08-16
US20170195460A1 (en) 2017-07-06
CN107085681A (zh) 2017-08-22
GB2546135A (en) 2017-07-12
US20200267240A1 (en) 2020-08-20

Similar Documents

Publication Publication Date Title
US11082226B2 (en) Zero-knowledge identity verification in a distributed computing system
DE112019001481T5 (de) Selektives bereitstellen gegenseitiger transportschichtsicherheit mittels alternativer servernamen
US20200287719A1 (en) Zero-knowledge identity verification in a distributed computing system
DE112011101831B4 (de) Schutz vor websiteübergreifenden Scripting-Attacken
DE112020005786T5 (de) Systeme und verfahren zum ermöglichen eines hochverfügbaren verwalteten ausfallsicherungsdienstes
DE202018006529U1 (de) Gemeinsames Nutzen bzw. Teilen von Daten in einem mandantenfähigen Datenbanksystem
DE112013003289T5 (de) Gerät, System und Verfahren für client-geregelte Sitzungspersistenz zwischen ein oder mehreren Clients und Servern eines Rechenzentrums
DE202020005715U1 (de) Dynamische Maskierung geteilter Datenobjekte
DE112013002544T5 (de) Cloudbasiertes Teilen von Datenpunkten und Zusammenarbeit unter Benutzergruppen
DE112012003193T5 (de) Verbeesertes Captcha-Programm unter Verwendung von Bildfolgen
DE202013012495U1 (de) Metadatenbasierte virtual Maschine-Konfiguration
DE102016102424A1 (de) Auf Inhalt beruhende Hardware-Sicherheitsmodulzuweisung zu virtuellen Maschinen
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
DE112018000525T5 (de) Systeme und Verfahren für die Authentifizierung von Platform Trust bzw. Plattform-Vertrauen in einerNetzwerkfunktions-Virtualisierungsumgebung
DE202012013482U1 (de) Verteilung von Zugriffsinformationen auf Overlay-Netzwerken
DE202015104128U1 (de) Datenzugriffssystem
DE112011104787T5 (de) Nutzung von Inhalten über persönliche Clouds
DE112018002954T5 (de) Bereitstellen eines konfigurationsabhängigen arbeitsablaufs
DE102021130396A1 (de) Datenzugriffsüberwachung und -steuerung
DE112016002392T5 (de) Autorisierung in einem verteilten System unter Verwendung von Zugriffssteuerungslisten und Gruppen
DE112016000790T5 (de) Instanziierung von Broadcast-Verschlüsselungsschemata zur Laufzeit
DE102016013586A1 (de) Robustes Rechenvorrichtungsidentifizierungssystem
DE112011104020T5 (de) Validierung des Zugriffs auf einen gemeinsam genutzen Datensatz bei Lese- und Schreibzugriff mehrerer Anforderer
WO2017095391A1 (en) Label management
DE112012000780T5 (de) Verarbeiten von Berechtigungsprüfungsdaten

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: ADOBE INC., SAN JOSE, US

Free format text: FORMER OWNER: ADOBE SYSTEMS INCORPORATED, SAN JOSE, CALIF., US

R082 Change of representative

Representative=s name: MUELLER-BORE & PARTNER PATENTANWAELTE PARTG MB, DE

R012 Request for examination validly filed