DE112016006707T5

DE112016006707T5 - All-in-one-mobilrechnervorrichtung

Info

Publication number: DE112016006707T5
Application number: DE112016006707.0T
Authority: DE
Inventors: Matthew J. Adiletta; Myles Wilde; Michael F. Fallon; Amit Kumar; Chengda Yang; Aaron Gorius; William R. Wheeler
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-04-26
Filing date: 2016-04-26
Publication date: 2019-01-10
Also published as: US20200326955A1; US11237840B2; WO2016176219A1

Abstract

All-In-One-Mobilrechnervorrichtungen und Verfahren, die durch die Vorrichtungen durchgeführt werden. Die All-In-One-Mobilrechnervorrichtung beinhaltet einen Prozessor, einen Speicher und Softwareanweisungen, die dazu konfiguriert sind, auf dem Prozessor ausgeführt zu werden, um zu ermöglichen, dass die Mobilrechnervorrichtung verschiedene Operationen durchführt. Die All-In-One-Vorrichtung kann verschiedene drahtgebundene und drahtlose Schnittstellen beinhalten, die ermöglichen, dass sie mit einem breiten Bereich von Vorrichtungen, einschließlich Smartphones, Tablets, Laptops, PCs, Smart-Fernseher und anderer, kommuniziert. Die All-In-One-Vorrichtung ist dazu in der Lage, dass auf sie aus der Ferne zugegriffen wird, wenn sie in Kommunikation mit einer zweiten Vorrichtung verlinkt ist, und es wird ermöglicht, dass Daten von verschiedenen Benutzervorrichtungen und Cloud-basierten Diensten aggregiert werden, um einheitliche Datenressourcen zu erschaffen. Daten, auf die durch die Vorrichtung zugegriffen wird, können mit einem Cloud-basierten Speicherungsdienst synchronisiert werden, um zu ermöglichen, dass ein Benutzer auf die Daten von einem Bereich von Vorrichtungen über die All-In-One-Vorrichtung zugreift. Die All-In-One-Vorrichtung weist einen Formfaktor auf, der näherungsweise die Größe einer Kreditkarte ist, aber trotzdem dazu in der Lage ist, ein vollwertiges Desktop-Betriebssystem auszuführen.

Description

Verwandte Anmeldungen
Die vorliegende Anmeldung ist eine Fortsetzung der vorläufigen US-Anmeldung Nr. 62/152,929 , eingereicht am 26. April 2015, mit dem Titel „ALL IN ONE MOBILE COMPUTING DEVICE,‟, die hiermit durch Bezugnahme in ihrer Gesamtheit und für alle Zwecke aufgenommen ist.
HINTERGRUNDINFORMATIONEN
In der heutigen immerzu verbundenen Gesellschaft ist es üblich für Benutzer, dass sie einige Vorrichtungen haben, die für spezialisierte Zwecke verwendet werden. Zum Beispiel haben Benutzer typischerweise ein Smartphone zur Sprach- und elektronischen Kommunikation und zur Unterhaltung (sowie zu anderen Zwecken), wenigstens einen Desktop-, Laptop-, Notebook- oder ähnlichen Typ von Computer für die Arbeit und/oder persönliche Aufgaben und können ferner ein Tablet, Netbook oder Chromebook haben, das (allgemein) zum Zugriff auf das Internet, Ansehen von Videos usw. verwendet wird. Jede dieser Vorrichtungen stellt ein Mittel zum Verbinden mit dem Internet und Zugreifen auf Daten von verschiedenen Quellen und Repositorien bereit.
Software- und Vorrichtungshersteller haben Universalplattformen und nahtlose Umgebungen anvisiert, sind aber bisher beim Erreichen ihrer Ziele kläglich zu kurz gekommen. Zum Beispiel drängte Microsoft auf eine einheitliche Plattform um Windows 8 (und bald Windows 10) herum, unter der verschiedene Klassen von Vorrichtungen (Desktop/Laptop, Smartphone und Tablet) eine ähnliche Benutzeroberfläche (UI: User Interface) teilen und ein ähnliches Benutzererlebnis (UX: User Experience) bereitstellen. Das Windows-8-Paradigma des Verwendens einer kachelbasierten UI, die inhärent für eine Verwendung mit berührungsbasierter Benutzereingabe entworfenwurde, wurde von der Geschäftswelt nicht gut angenommen, bei der das Verwenden von Produktivitätssoftwareanwendungen und Netzwerkdiensten von Microsoft etabliert ist. Insbesondere wurde eine UI-Funktionalität, wie etwa das in Windows 7 verwendete Startmenü, aus Windows 8 gestrichen, aber nach einer riesigen Menge an Benutzerbeschwerden in Windows 8.1 (mit einigen Beschränkungen) wieder hinzugefügt. Noch schlimmer ist für Microsoft, dass der Marktanteil für Windows Phones bei etwa 2-3 % in den Vereinigten Staaten liegt, mit geringfügig höherem Anteil in anderen Märkten. Microsoft's Surface-Tablets haben einen ähnlichen nicht relevanten Marktanteil. In Anbetracht der Dominanz von Android- und Apples iOS-Vorrichtungen in dem Smartphone- und Tablet-Markt ist es sehr unwahrscheinlich, dass Microsoft jemals in diesen Märkten viel an Boden gewinnt. Im Gegensatz dazu ist es wahrscheinlich, dass Microsoft weiterhin den Geschäfts- und Verbrauchssoftware- und Betriebssystemmarkt dominiert.
Ein anderer Aspekt, der von verschiedenen Firmen behandelt wird, ist universeller Zugriff auf Daten. Dies wird typischerweise über „Cloud“-basierte Datenanlagen ermöglicht, wie etwa durch Google (z. B. Google Docs und Google Drive), Microsoft (Office 365 und SkyDrive), Apple (iCloud), Dropbox und andere. Auf der einen Seite bieten Cloud-basierte Datenanlagen einen gewissen Grad an universellem Zugriff auf wenigstens manche Benutzerdaten. Jedoch geschieht dies nicht ohne Probleme. Insbesondere benötigt man Zugang zu den Internet-gehosteten Anlagen, nur um auf die Daten zuzugreifen; kein Internetzugang bedeutet keinen Datenzugriff. Außerdem gibt es Probleme mit Netzwerklatenzen und Sicherheitsbedenken. Während Microsoft die Fähigkeit von Office 365 betont, auf Dokumente von mehreren Vorrichtungen aus zuzugreifen, wird es von einem tatsächlichen Nutzungsstandpunkt primär als ein Abonnementdienst zum Zugriff auf Produktivitätsanwendungen von Microsoft Office auf einer einzigen Vorrichtung unter Verwendung einer lokalen Speicherung von Anwendungsdokumentdaten verwendet, anstatt eine Cloud-Speicherung der Dokumente zu verwenden, die durch die Anwendungen produziert werden und auf die durch diese zugegriffen wird.
Zusätzlich zu dem Vorausgehenden bevorzugen Benutzer allgemein, auf Daten direkt von ihren Vorrichtungen zuzugreifen, ein Nutzungsmodell, bei dem der Benutzer eine bessere Kontrolle über seine eigenen Daten hat. Erstens haben sich Benutzer über die Jahre daran gewöhnt, und der Gedanke, sich auf jemand anders zu verlassen, um ihre Daten zu schützen, ist etwas beunruhigend. Zweitens ist die Echtzeitinteraktion, die durch Cloud-basierte Anwendungen, wie etwa Google Docs, bereitgestellt wird, nicht optimal, selbst mit einer schnellen Netzwerkverbindung. Obwohl Google gute Arbeit beim Implementieren einer Produktivitätsanwendungsfunktionalität über Webseiten (eine einschüchternde technische Aufgabe) geleistet hat, geht nichts über das Verwenden einer Anwendung, die direkt auf der eigenen Vorrichtung läuft.
Dass die Daten auf Vorrichtungen des Benutzers gespeichert sind, bringt seine eigenen Nachteile mit sich. Erstens können Daten auf einer unterschiedlichen Vorrichtung gespeichert werden, die momentan für den Benutzer nicht verfügbar ist (die z. B. zu Hause oder in der Arbeit gelassen wurde). Zweitens ist es sehr üblich, die gleichen Daten über mehrere Vorrichtungen zu replizieren, was Speicherressourcen verschwendet. Zum Beispiel ist es sehr üblich für iPhone- und iPad-Benutzer Fotos und Videos über mehrere Vorrichtungen zu replizieren, wie etwa, dass die gleichen Fotos auf einem iPhone/iPad und in iPhoto auf einem Apple-Mac-Computer vorhanden sind. Obwohl Apple versucht hat, dies durch die Verwendung von seinem iCloud-Dienst zu behandeln, überschreitet die Menge an Speicherplatz, die durch die Fotos in Videos belegt wird, typischerweise die Menge an iCloud-Speicher, der je Benutzer kostenlos bereitgestellt wird, und Benutzer sind abgeneigt, für den extra Speicher zu zahlen. Dementsprechend führt jede Synchronisations- oder Backup-Operation nur zu einer weiteren Replikation von Daten.
Zu einem großen Grad werden die Nutzungsmodelle in der vorhersehbaren Zukunft jene in der jüngsten Vergangenheit wiederspiegeln. Ein typischer Benutzer wird immer noch sein oder ihr Android- oder iPhone-Mobiltelefon für die Zwecke nutzen, für die diese Vorrichtungen hervorragend geeignet sind, während ein Desktop- oder Laptop-Computer (oft mit einer zweiten Anzeige verbunden) für Produktivitätsaufgaben verwendet wird und möglicherweise andere Vorrichtungen (Tablets, Netbooks usw.) zur Freizeit verwendet werden.
Figurenliste
Die vorstehenden Aspekte und viele der dazugehörigen Vorteile dieser Erfindung werden besser verstanden, wenn dieselben unter Bezugnahme auf die folgende ausführliche Beschreibung, wenn in Verbindung mit den zugehörigen Zeichnungen gebracht, besser verstanden werden, wobei sich gleiche Bezugszeichen über alle verschiedenen Ansichten hinweg auf gleiche Teile beziehen, sofern nicht anders angegeben:

1 ist ein schematisches Blockdiagramm, das funktionale Blöcke für eine Rechnerkarte gemäß einer Ausführungsform veranschaulicht;
2 ist ein schematisches Blockdiagramm, das eine Rechnerkarte veranschaulicht, die mit einer Docking-PCB gekoppelt ist, die wiederum mit einem Monitor verbunden ist;
3 ist ein schematisches Blockdiagramm, das eine Rechnerkarte veranschaulicht, die mit einem Backpack gekoppelt ist, die wiederum mit einem Monitor verbunden ist;
4 ist ein schematisches Blockdiagramm, das selektive Komponenten zum Integrieren einer Rechnerkarte in ein Smartphone gemäß einer Ausführungsform veranschaulicht;
5 ist ein schematisches Blockdiagramm eines ersten Prozessors, der zur Implementierung in einer oder mehreren hier beschriebenen Ausführungsformen geeignet ist;
6 ist ein schematisches Blockdiagramm eines zweiten Prozessors, der zur Implementierung in einer oder mehreren hier beschriebenen Ausführungsformen geeignet ist;
7 ist ein schematisches Blockdiagramm, das Komponenten veranschaulicht, die durch eine Grafikvorrichtung zum Rendern nativer Grafikbefehle und von Inhalt eingesetzt wird;
8 ist ein schematisches Blockdiagramm, das eine native Grafik-Thrower-Catcher-Architektur gemäß einer Ausführungsform veranschaulicht;
8a ist ein schematisches Blockdiagramm, das eine Android-Grafik-Thrower-Catcher-Architektur gemäß einer Ausführungsform veranschaulicht;
9 ist ein schematisches Blockdiagramm, das die Softwarekomponenten wie durch die Android-Architektur definiert veranschaulicht;
10 ist ein schematisches Block- und Datenflussdiagramm, das ausgewählte Android-Grafikkomponenten und Datenflüsse zwischen ihnen veranschaulicht;
11 ist ein schematisches Block- und Datenflussdiagramm, das ausgewählte Komponenten des Android-Grafiksystems und das Zusammensetzen von Grafikinhalt durch Android's SurfaceFlinger and Hardware Composer veranschaulicht;
12a ist ein Kombinationsschema- und Nachrichtenflussdiagramm, das eine Ausführungsform veranschaulicht, die native(n) Android-Grafikbefehle und -Inhalt zu einer fernen Android-Vorrichtung wirft;
12a ist ein Kombinationsschema- und Nachrichtenflussdiagramm, das eine Ausführungsform veranschaulicht, die native(n) Android-Grafikbefehle und -Inhalt zu einer fernen Android-Vorrichtung unter Verwendung mehrerer Sockets wirft;
12b ist ein Kombinationsschema- und Nachrichtenflussdiagramm, das eine zu der in 12a alternative Konfiguration zeigt, unter der OpenGL-Grafikbefehle unter Verwendung eines einzigen Sockets gesendet werden;
13 ist ein Blockdiagramm, das Windows-Grafik-APIs und Anzeigetreiberschnittstellen veranschaulicht;
14 ist ein Blockdiagramm, das Windowssoftwarekomponenten zum Ermöglichen von Windows-Rendering-Operationen veranschaulicht;
15 ist ein schematisches Blockdiagramm, das eine Ausführungsform einer Windows-Grafik-Thrower-Catcher-Architektur veranschaulicht, unter der ein Windows-Grafik-Thrower native Windows-Grafikbefehle an einen fernen Windows-Grafik-Catcher wirft;
16 ist ein schematisches Blockdiagramm, das eine Ausführungsform einer Windows-Grafik-Thrower-Android-Grafik-Catcher-Architektur veranschaulicht, unter der native(n) Windows-Grafikbefehle und -Inhalt in native(n) Android-Grafikbefehle und -Inhalt auf der Windows-Thrower-Vorrichtung umgewandelt werden;
17a ist ein Kombinationsschema- und Nachrichtenflussdiagramm, das eine Ausführungsform veranschaulicht, die native(n) Android-Grafikbefehle und -Inhalt von einer Windows-Hostvorrichtung an eine ferne Android-Vorrichtung unter Verwendung mehrerer Sockets wirft, wobei native(r) Windows-Grafikbefehle und -Inhalt in Android-Grafikbefehle und -Inhalt auf der Windows-Hostvorrichtung umgewandelt werden;
17b ist ein Kombinationsschema- und Nachrichtenflussdiagramm, das eine zu der in 12a alternative Konfiguration zeigt, unter der OpenGL-Grafikbefehle unter Verwendung eines einzigen Sockets gesendet werden;
18 ist ein schematisches Blockdiagramm, das eine Ausführungsform einer Windows-Grafik-Thrower-Android-Grafik-Catcher-Architektur veranschaulicht, unter der native(n) Windows-Grafikbefehle und -Inhalt in native(n) Android-Grafikbefehle und -Inhalt auf der Android-Catcher-Vorrichtung umgewandelt werden;
19 ist ein schematisches Blockdiagramm, das eine Übersicht auf hoher Ebene über ausgewählte Komponenten in einer LDE-Architektur (LDE: Little Data Engine - Kleine-Daten-Engine) gemäß einer Ausführungsform veranschaulicht;
20 ist ein schematisches Blockdiagramm, das eine Architektur für den Analysestapel der LDE in Bezug auf das Verarbeiten von Sensordaten veranschaulicht;
21 ist ein schematisches Blockdiagramm, das eine Software-API für die LDE gemäß einer Ausführungsform veranschaulicht;
22 ist eine Tabelle, die ein persönliches Analysenutzungsmodell 2200 gemäß einer Ausführungsform veranschaulicht;
23 ist ein schematisches Blockdiagramm, das eine Implementierungsarchitektur veranschaulicht, die eine weitere Integration von hier besprochenen Komponenten veranschaulicht;
24a, 24b und 24c zeigen beispielhafte Ansichten einer Rechnerkarte gemäß einer Ausführungsform; und
25 zeigt eine Ausführungsform einer Prozessorplatine, die für die Verwendung in der Rechnerkarte aus 24a-24c geeignet ist;
26 veranschaulicht die mechanische Verpackung einer Ausführungsform einer Rechnerkarten-Docking-Station;
27 ist ein Diagramm, das eine Rechnerkarte veranschaulicht, die dazu konfiguriert ist, auf mehrere Vorrichtungen zuzugreifen;
28a und 28b zeigen zwei Beispiele für eine Rechnerkarte, die über eine drahtgebundene Verbindung mit einer Anzeigevorrichtung verbunden ist;
29a und 29b zeigen zwei Beispiele für eine Rechnerkarte, die über eine drahtlose Verbindung mit einer Anzeigevorrichtung verbunden ist;
30 ist ein schematisches Diagramm, das eine Datenzugriffsarchitektur, die einen Datenzugriff für mehrere Profile ermöglicht, gemäß einer Ausführungsform veranschaulicht;
31 ist ein schematisches Diagramm, das eine Datenverwaltungsarchitektur einschließlich einer sicheren vorrichtungsunabhängigen Datenverwaltungsplattform veranschaulicht, die einen Zugriff auf mehrere Datenquellen ermöglicht und mehrere Verwendungsmodelle unterstützt;
32 ist ein schematisches Diagramm, das eine Ausführungsform einer Architektur für eine integrierte Android- und Windows-Vorrichtung veranschaulicht, die dazu in der Lage ist, sowohl Android- als auch Windows-Anwendungen auszuführen;
33 ist ein schematisches Diagramm einer Softwarearchitektur, die implementiert wird, um es zu ermöglichen, Szenarien zu verwenden, die eine Rechnerkarte einsetzen, die auf einer Windows-OS- und einer Android-Hostvorrichtung läuft;
34 stellen eine Porträtanziege einer einheitlichen Oberfläche mit mehreren Feldern einschließlich eines ersten Felds mit Android-Anwendungen, eines zweiten Felds mit Windows-Anwendungen und eines dritten Felds, das kombinierte Datei-, Kontakt- und E-Mail-Ordner zeigt, dar;
35 stellt eine beispielhafte einheitliche Oberfläche dar, die einheitliche Ordner darstellt, die gemäß einem ausgewählten Benutzerprofil angezeigt werden;
36a und 36b sind isometrische perspektivische Zeichnungen einer Klappgehäusehosteinrichtung mit Doppelsteckplatz gemäß einer Ausführungsform;
36c zeigt eine isometrische perspektivische Ansicht einer Klappgehäusehosteinrichtung mit Einzelsteckplatz;
37 ist ein schematisches Blockdiagramm einer ersten Ausführungsform einer Prozessorplatine, die in einer Doppelsteckplatzhosteinrichtung implementiert werden kann;
38 ist ein schematisches Blockdiagramm einer zweiten Ausführungsform einer Prozessorplatine, die in einer Doppelsteckplatzhosteinrichtung implementiert werden kann;
39 ist ein schematisches Blockdiagramm einer Ausführungsform einer Rechnerkarte, die einen USB-Typ-C-Verbinder einsetzt;
40 ist ein schematisches Diagramm, das eine Schnittstellenschaltungsanordnung zwischen einem USB-Typ-C-Verbinder und einer CPU und einem PMIC gemäß einer Ausführungsform veranschaulicht;
41a und 41b sind perspektivische Ansichten einer Rechnerkarte, die einen USB-Typ-C-Verbinder und ein Fingerabdrucklesegerät beinhaltet, gemäß einer Ausführungsform;
42 ist ein schematisches Diagramm von Komponenten und einer Schaltungsanordnung einer Mobilen Docking-Station;
43 ist ein Diagramm, das eine Rechnerkarte veranschaulicht, die in einer mobilen Docking-Station installiert ist, die mit einem Videomonitor gekoppelt ist;
44 zeigt eine isometrische Ansicht der Unterseite einer Ausführungsform eines Tablets mit Doppelsteckplatz;
45 ist ein Flussdiagramm, das Operationen und eine Logik veranschaulicht, die als Reaktion darauf durchgeführt werden, dass eine Rechnerkarte, die sich aktuell in einem Ruhezustand befindet, in einen Rechnerkartensteckplatz in einer Hosteinrichtung oder - vorrichtung eingefügt wird;
46 ist ein Flussdiagramm, das Operationen und eine Logik veranschaulicht, die durch eine Ausführungsform eines Klonprozesses durchgeführt werden;
47 ist ein Flussdiagramm, das Operationen und eine Logik veranschaulicht, die durch eine Ausführungsform eines Migrationsprozesses durchgeführt werden;
48 ist ein schematisches Diagramm einer Ausführungsform eines Smart-Armbandes;
49a und 49b sind eine Draufsicht und Seitenansicht einer dünnen Docking-Station, in die eine Rechnerkarte eingefügt ist; und
50 ist ein Diagramm, das eine Rechnerkarte von einem Markenhändler veranschaulicht, die in einer mobilen Docking-Station installiert ist, die mit einem Videomonitor gekoppelt ist, und ferner die Webseite für den Markenhändler veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen von All-In-One-Mobilrechnervorrichtungen und assoziierte Verfahren, die durch die Rechnerkarten ermöglicht werden, sind hier beschrieben. In der folgenden Beschreibung werden zahlreiche Einzelheiten dargelegt, um ein umfassendes Verständnis von Ausführungsformen der Erfindung bereitzustellen. Ein Fachmann auf dem relevanten Gebiet wird jedoch erkennen, dass die Erfindung ohne eine oder mehrere der spezifischen Einzelheiten oder mit anderen Verfahren, Komponenten, Materialien, usw. praktiziert werden kann. In anderen Fällen werden gut bekannte Strukturen, Materialien oder Operationen nicht im Einzelnen gezeigt oder beschrieben, um das Verschleiern von Aspekten der Erfindung zu vermeiden.
Zur Klarheit können einzelne Komponenten in den Figuren hier anstatt durch eine bestimmte Referenznummer auch durch ihre Beschriftungen in den Figuren bezeichnet werden. Außerdem können Referenznummern, die sich auf einen bestimmten Komponententyp (im Gegensatz zu einer bestimmten Komponente) beziehen, mit einer Referenznummer gezeigt werden, gefolgt von „(typ)“, was „typisch“ bedeutet. Es versteht sich, dass die Konfiguration dieser Komponenten für ähnliche Komponenten, die existieren können, in den Zeichnungsfiguren der Einfachheit und Klarheit halber aber nicht gezeigt sind, oder anderweitig ähnliche Komponenten, die nicht mit getrennten Referenznummern beschriftet sind, typisch ist. Umgekehrt ist „(typ)“ nicht dahingehend auszulegen, dass die Komponente, das Element, usw. typischerweise für ihre offenbarte Funktion, Implementierung, ihren Zweck usw. verwendet wird.
Die Ausdrücke „Kommunikationsnetz“ und „Kommunikationsnetze“ werden hier austauschbar verwendet, um auf ein oder mehrere Systeme und/oder Verfahren zum Senden und/oder Empfangen eines Datensignals zu verweisen. Diese Begriffe schließen kurzreichweitige Kommunikation und langreichweitige Kommunikation ein. Als eine Option kann eine Kommunikation zwischen einer Rechnerkarte 100 und einer Android-Hostvorrichtung 102 eine drahtlose Wi-Fi-Verbindung oder ein drahtloser BLUETOOTH®-Link sein. Bei jeweiligen Ausführungsformen ist die drahtlose Wi-Fi-Verbindung ein Wi-Fi-Direct-Link, eine INTEL®-Wireless-Display(WiDi)-Verbindung, eine INTEL®-WiGig-Verbindung.
Der Ausdruck „kurzreichweitige Kommunikation“ wird hier verwendet, um auf Systeme und Verfahren zum drahtlosen Senden/Empfangen von Datensignalen zwischen Vorrichtungen verwendet, die relativ nahe beieinander sind. Kurzreichweitige Kommunikation beinhaltet zum Beispiel eine Kommunikation zwischen Vorrichtungen unter Verwendung eines BLUETOOTH®-Netzes, eines Personal Area Network (PAN), von Nahfeldkommunikation (NFC), Hochfrequenzidentifikation (RFID), ZigBee-Netzen, einer INTEL®-Wireless-Display(WiDi)-Verbindung, einer INTEL®-WiGig(Wireless with Gigabit capability - drahtlos mit Gigabit-Fähigkeit)-Verbindung, Millimeterwellenkommunikation, Ultrahochfrequenz(UHF)-Kommunikation, Kombinationen davon und dergleichen. Kurzreichweitige Kommunikation kann daher als eine direkte Kommunikation zwischen Vorrichtungen ermöglichend, ohne die Notwendigkeit für dazwischenliegende Hardware/Systeme, wie etwa Router, Mobilfunkmasten, Internetanbieter und dergleichen, verstanden werden.
Im Gegensatz dazu wird der Ausdruck „langreichweitige Kommunikation“ hier verwendet, um sich auf Systeme und Verfahren zum drahtlosen Senden/Empfangen von Datensignalen zwischen Vorrichtungen zubeziehen, die einen signifikanten Abstand voneinander entfernt sind. Langreichweitige Kommunikation beinhaltet zum Beispiel eine Kommunikation zwischen Vorrichtungen unter Verwendung von Wi-Fi, einem Wide Area Network (WAN) (einschließlich unter anderem einem Mobiltelefonnetz (3G, 4G usw. und dergleichen)), dem Internet, einem globalen Positionierungssystem (GPS), einem Fernseh-Whitespace-Netz, Kombinationen davon und dergleichen. Langreichweitige Kommunikation kann daher als eine Kommunikation zwischen Vorrichtungen durch die Verwendung von dazwischenliegender/dazwischenliegenden Hardware/Systemen, wie etwa Routern, Mobilfunkmasten, Fernsehen-Whitespace-Masten, Internetanbietern, Kombinationen davon und dergleichen ermöglichend verstanden werden.
Wie bei einer beliebigen Ausführungsform hier verwendet, kann der Begriff „Modul“ auf Software, Firmware und/oder eine Schaltungsanordnung verweisen, die dazu konfiguriert ist, eine oder mehrere Operationen in Einklang mit der vorliegenden Offenbarung durchzuführen oder eine Durchführung davon zu bewirken. Software kann als ein Softwarepaket, Code, Befehle, Befehlssätze und/oder Daten, das/der/die auf nichtflüchtigen computerlesbaren Speichermedien aufgezeichnet ist/sind, ausgeführt sein. Firmware kann als Code, Befehle oder Befehlssätze und/oder Daten, der/die in nichtflüchtigen Speichervorrichtungen gespeichert werden, einschließlich Vorrichtungen, die aktualisiert werden können (z. B. Flash-Speicher), ausgeführt sein. „Schaltungsanordnung“, wie bei einer beliebigen Ausführungsform hier verwendet, kann zum Beispiel eine festverdrahtete Schaltungsanordnung, eine programmierbare Schaltungsanordnung, wie etwa Computerprozessoren, die einen oder mehrere einzelne Anweisungsverarbeitungskerne umfassen, eine Zustandsmaschinenschaltungsanordnung, Software und/oder Firmware, die Anweisungen speichert, die durch eine programmierbare Schaltungsanordnung ausgeführt werden, alleine oder in Kombination umfassen. Die Module können gemeinsam oder einzeln als Schaltungsanordnung umgesetzt werden, die einen Teil einer Client-Vorrichtung oder einer Authentifizierungsvorrichtung bildet.
Der Klarheit und des einfacheren Verständnisses halber beschreibt die vorliegende Offenbarung oft Mobilrechenvorrichtungen und Bildschirme als ein oder mehrere Module in einem Speicher gespeichert beinhaltend, wobei das (die) Modul(e) computerlesbare Anweisungen beinhaltet (beinhalten), die, wenn sie durch einen Prozessor der relevanten Vorrichtung (Mobilrechnervorrichtung oder Bildschirm) ausgeführt werden, bewirken, dass die Vorrichtung verschiedene Operationen durchführt. Es versteht sich, dass solche Beschreibungen beispielhaft sind und dass Mobilrechnervorrichtungen und Bildschirme dazu konfiguriert sein können, in Assoziation mit einem oder mehreren Modulen beschriebene Operationen auf eine andere Weise durchzuführen. Beispielsweise können die Mobilrechnervorrichtungen und Bildschirme hier eine Logik beinhalten, die wenigstens teilweise in Hardware implementiert ist, um die Durchführung einer oder mehrerer Operationen in Übereinstimmung mit der vorliegenden Offenbarung, wie etwa jene in Assoziation mit verschiedenen hier identifizierten Modulen beschriebenen, zu bewirken. In dieser Hinsicht wird angemerkt, dass „Logik“, wie hier verwendet, eine diskrete und/oder analoge Schaltungsanordnung beinalten kann, einschließlich zum Beispiel eines Mehrzweckprozessors, eines digitalen Signalprozessors (DSP), eines System-on-Chips (SoC), einer Zustandsmaschinenschaltungsanordnung, festverdrahteter Elemente, anwendungsspezifischer integrierter Schaltkreise, Kombinationen davon und dergleichen.
Die Verwendung von Mobilvorrichtungen, wie etwa Mobiltelefonen, Smartphones, Tablet-PCs und Laptop-PCs hat drastisch zugenommen. Hinsichtlich der weitverbreiteten Annahme dieser Mobiltechnologien konzentrieren sich Mikroprozessorentwickler zunehmend auf die Entwicklung von Prozessoren, die sowohl eine hohe Leistungsfähigkeit als auch einen geringen Leistungsverbrauch aufzeigen. Ein Ziel einer solchen Entwicklung besteht darin, eine Verarbeitungsfähigkeit zu erhöhen, während eine Batterielebensdauer der zugrundeliegenden Vorrichtung beibehalten oder sogar erhöht wird. In manchen Fällen wurde demonstriert, dass Verkleinern der Größe der Prozessorkomponenten eine Prozessorleistungsfähigkeit verbessern kann, während gleichzeitig der Leistungsverbrauch reduziert wird. In den kommenden Jahren wird erwartet, dass die Herstellungstechniken die Produktion von Prozessoren mit „Desktop-ähnlicher“ Rechenleistungsfähigkeit sowie einem Leistungsverbrauch, der niedrig genug ist, um in einer Mobilvorrichtung verwendet zu werden, ermöglicht haben wird.
In den letzten Jahren neigte die Verbrauchernachfrage zu Mobilvorrichtungen, die große integrale Anzeigen haben, aber dünn genug sind, um in eine Kleidungstasche oder eine kleine Tragetasche zu passen. Verbesserte Herstellungstechniken haben ermöglicht, dass Hersteller die Ansteuerungselektronik solcher Vorrichtungen zunehmend miniaturisieren. Obwohl dies die Produktion von zunehmend dünnen Vorrichtungen ermöglicht hat, werden die Längen- und Breitenabmessungen aktueller Mobilvorrichtungen oft durch die Anforderung einer integralen Anzeige begrenzt. Während eine weitere Miniaturisierung der Ansteuerungselektronik weitere Reduzierungen der Vorrichtungsdicke ermöglichen kann, können die Länge und Breite einer Mobilvorrichtung durch die entsprechenden Abmessungen einer integralen Anzeige vorgeschrieben werden. Dies kann den Grad begrenzen, zu dem eine Mobilvorrichtung als ein Ganzes miniaturisiert werden kann.
Wie oben besprochen, ist es heute üblich, dass Benutzer mehrere Vorrichtungen, jeweils mit ihren eigenen Anwendungen und Daten, haben. Während manche Typen von Daten über Plattformen relativ portabel sind (z. B. Bilder, die in Standardformaten, wie etwa JPEG und PNG, gespeichert sind), sind andere dies nicht (z. B. Dokumente, die durch Produktivitätsanwendungen, wie etwa Microsoft-Office-Produkte, produziert werden). Die Verwendung von persönlichen Vorrichtungen in Unternehmensumgebungen, oft als BYOD (Bring Your Own Device - bring deine eigene Vorrichtung) bezeichnet, trägt weiter zu der Mischung bei. Dies erschafft eine massive Herausforderung für IT(Informationstechnologie)-Manager, da es mehr Typen von Vorrichtungen und Daten zu verwalten gibt, was Personalkosten erhöht. Ein Ansatz bestand darin, Angestellten einfach nicht zu erlauben, ihre eigenen Vorrichtungen zu Betriebszwecken zu verwenden. Jedoch ist BYOD von Dauer, weil Angestellte in vielen Industrien und Technologien erwarten, dazu in der Lage zu sein, ihre eigenen vertrauten Vorrichtungen zu verwenden, und oft nicht in Betracht ziehen, für Firmen zu arbeiten, die die Verwendung von persönlichen Vorrichtungen der Benutzer nicht erlauben.
Eine der Herausforderungen ist das separate Verwalten von Firmendaten und persönlichen Daten auf derselben Vorrichtung. Betriebssysteme stellen keine inhärente Ausstattung bereit, um dies vorzunehmen, und Ansätze auf Anwendungsebene waren allgemein klägliche Fehlschläge. Bei manchen Unternehmensumgebungen ist es möglicherweise nicht erlaubt, gewisse Typen von Daten und Dokumenten auf persönlichen Vorrichtungen zu speichern (und in manchen Fällen ist es nicht einmal erlaubt, dass sie auf Computern gespeichert werden, die durch die Firmen selbst bereitgestellt werden). Während manche Vorrichtungshersteller, wie etwa BlackBerry, versucht haben, „Doppelpersönlichkeit“-Vorrichtungen zu implementieren, die Betriebsdaten von persönlichen Daten trennen, hat es geringen Anklang solcher Vorrichtungen in Betriebsumgebungen gegeben.
Eine andere Überlegung hinsichtlich persönlicher und Betriebsverwendung ist die Verwendung von Cloud-basierten Ressourcen, sowohl zum Archivieren von Daten als auch zum Ermöglichen von aktiven Arbeitsräumen. Oft können persönliche Benutzer Cloud-basierte Archivierungsanlagen als Sicherheitsdecke verwenden, wenn sie daran denken, dies zu tun. Cloud-basierten Archivierungsanlagen wird sowohl von individuellen Benutzern als auch von Unternehmen misstraut. Wie sicher sind ihre Daten? Oft entscheiden sich Benutzer für die kostenlose Speicherungsgrenze, die entweder nicht ausreicht, um ihre Anforderungen zu erfüllen (wie viele Benutzer haben lediglich 5GB an Daten auf ihren Vorrichtungen), oder zu schwierig auf eine komfortable Weise zu implementieren ist (die meisten Benutzer speichern ihre Daten nicht in nur einem einzigen oder einigen wenigen Ordern). Jeder, der eine Vorrichtung hat, die synchronisiert, erkennt, dass die gleichen Daten schlussendlich über mehrere Vorrichtungen verbreitet werden.
Datenorganisation ist auch eine Herausforderung für viele Benutzer. Wie können Benutzer persönliche Daten einfach von Firmendaten trennen, nicht nur auf einer einzigen Vorrichtung, sondern über alle Vorrichtungen, die sie möglicherweise verwenden? Man muss eine bestimmte Datei lokalisieren... die vor einigen Monaten erstellt wurde? Wie wäre es mit einer Gruppe von Dateien, die verwandte Daten auf einer Ebene für einen gewissen Zweck enthalten können, aber anderweitig für andere Zwecke nicht in Zusammenhang stehen, so dass es keinen logischen Sinn machen würde, solche Dateien zusammen zu speichern. Während Suchwerkzeuge, wie etwa Spotlight von Apple OS X, nett sind, geben sie entweder eine übermäßig inklusive oder zu wenig inklusive Liste von Ergebnissen, allgemein in einem abgeflachten Format, zurück.
Gemäß Aspekten der hier offenbarten Ausführungsformen werden die vorausgehenden Mängel durch die Verwendung einer einzigen Vorrichtung (auch als „eine Vorrichtung“ bezeichnet) adressiert, die dazu konfiguriert ist, mehrere Nutzungsszenarien zu unterstützen. Der Ansatz mit einer Vorrichtung repräsentiert einen Paradigmenwechsel in den aktuellen Daten- und Anwendungsverwendungsmodellen, während er zur gleichen Zeit nahtlos in die heutigen Umgebungen mit vielen Vorrichtungen eines Benutzers integriert wird.
Gemäß Aspekten eines ersten Benutzererlebnisses ermöglicht eine Vorrichtung Zugriff auf und Verwaltung aller Daten von mehreren Vorrichtungen unter Verwendung einer einzigen Vorrichtung und Datenverwaltungsschnittstelle. Eine Vorrichtung organisiert automatisch Daten über sowohl physische Vorrichtungs- als auch Cloud-Dienste, mit robuster Sicherheit. Eine Trennung von persönlichen und Firmendaten wird bereitgestellt, während dem Benutzer eine minimale Einrichtungslast auferlegt wird. Vorrichtungen, die unterschiedliche Betriebssysteme einsetzen? Kein Problem, eine Vorrichtung kann sie alle bedienen. Bedenken hinsichtlich der Sicherheit? Eine Vorrichtung führt einen Datenzugriff in einer „Sandbox“ aus, nicht nur zwischen persönlichen und Firmendaten, sondern auch für andere Typen von Daten, wie etwa Benutzergesundheitsdaten.
Gemäß Aspekten eines zweiten Benutzererlebnisses kann eine Vorrichtung mit mehreren existierenden Benutzervorrichtungen, wie etwa Desktop- und Laptop-Computern, Tablets und HDTVs, kombiniert werden. Bei verschiedenen Szenarien wird Benutzern ermöglicht, auf Daten zuzugreifen und Anwendungen auszuführen, die durch ein Desktop-Betriebssystem gehostet werden, das auf einem Computersystem läuft, das die Größe einer Kreditkarte aufweist. Eine Vorrichtung ist auch dazu konfiguriert, einen Grafikinhalt zu einer Hostvorrichtung auf eine solche Weise zu „werfen“, die gegenüber einfachem Bildschirmspiegeln verbessert ist. Statt des Sendens von Bitmaps eines Anzeigeinhalts und Diffs, ist zum Beispiel eine Vorrichtung dazu konfiguriert, einen Grafikinhalt in nativen Grafikformaten, die durch Anwendungen, verwendet werden, wie etwa OpenGL und DirectX, zu werfen. Zudem sind neuartige Grafikbefehlsübersetzer und -Schnittstellen zum Unterstützen der Verwendung von nativen Grafikformaten über verschiedene Betriebssysteme hinweg bereitgestellt.
Gemäß Aspekten eines dritten Benutzererlebnisses stellt eine Vorrichtung eine skalierbare Leistungsfähigkeit bereit. Zum Beispiel kann eine Vorrichtung in Abhängigkeit von Benutzeranwendungsanforderungen unterschiedliche Leistungsfähigkeitsniveaus, im Bereich von niedrigerer Leistungsfähigkeit und längerer Batterielebensdauer bis zu angebundenen Erlebnissen mit hoher Leistungsfähigkeit, unterstützen. Bei manchen Ausführungsformen setzt eine Vorrichtung eine neuartige Prozessorarchitektur ein, die sowohl Niederleistungskerne, die typischerweise in Mobilvorrichtungen zu finden sind, mit einem oder mehreren Kernen ähnlich jenen, die in heutigen Desktop-/Laptop-Prozessoren verwendet werden, beinhaltet.
Gemäß Aspekten eines vierten Benutzererlebnisses unterstützt eine Vorrichtung kontinuierliches Cloud-Caching mit Verschlüsselung. Der Benutzer muss sich nie Sorgen machen „gibt es Platz auf meinem Telefon für ein weiteres Bild oder Video?“. Stattdessen werden die Daten auf einer Vorrichtung unter Verwendung eines Cloud-basierten Dienstes gecacht, der ermöglicht, dass Benutzer den effektiven Datenspeicher auf der einen Vorrichtung nahtlos erweitern. Außerdem kann, falls eine Vorrichtung jemals verloren geht, gestohlen wird oder kaputt geht, eine Ersatzvorrichtung einfach in den Zustand der verlorenen, gestohlenen oder kaputten Vorrichtung zurückgesetzt werden.
Gemäß Aspekten eines fünften und sechsten Benutzererlebnisses stellt eine Vorrichtung eine Zugriffsverwaltung für Data-Sharing bereit und stellt ein oder mehrere Doppelprofile bereit. Beispielsweise werden die folgenden beispielhaften Doppelprofile unterstützt:

Spielen/Arbeit.
Öffentlich/Privat.
Verbrauchen/Erstellen.
Chrome/Privat.
Öffentlich/„Sandbox“.
Außerdem können auch andere Doppelprofile unterstützt werden.

Gemäß Aspekten eines siebten Benutzererlebnisses stellt eine Vorrichtung einheitliche Daten und Anwendungsansichten bereit. Beispielsweise wird Benutzern ermöglicht, unter Verwendung einheitlicher Datenansichten ihre Daten zu organisieren und von ihren Vorrichtungen und ihren Cloud-basierte Diensten zu finden. Zudem ist der Zugriff robust und sicher und dem Benutzer können mehrere einheitliche Ansichten gemäß den Profilen, die durch den Benutzer eingerichtet oder ausgewählt werden, präsentieren.
Gemäß Aspekten eines achten Benutzererlebnisses stellt eine Vorrichtung eine lokale „Dropbox“ bereit, die dem Benutzer ermöglicht, Daten mit anderen Benutzern ohne Verwendung des Internet zu teilen. Unter Verwendung sicherer Peer-to-Peer-Verbindungen ermöglicht eine Vorrichtung das Teilen von Daten mit gepaarten Vorrichtungen einschließlich Vorrichtungen mit unterschiedlichen Ökosystemen (z. B. Android-Vorrichtungen, iOS-Vorrichtungen, Windows-Vorrichtungen usw.).
Gemäß einem neunten Benutzererlebnis fungiert eine Vorrichtung als eine elektronische Geldbörse (E-Wallet). Dies ermöglicht dem Benutzer, für Produkte und Dienste elektronisch auf eine sehr sichere und vertrauenswürdige Weise zu zahlen.
1 zeigt ausgewählte Komponenten einer Rechnerkarte 100 gemäß einer Ausführungsform. Die Rechnerkarte 100 beinhaltet eine Prozessorplatine, auf der verschiedene Komponenten montiert sind und die eine (nicht gezeigte) Zwischenverbindungsverdrahtung zum Koppeln der Komponenten beinhaltet. Die ausgewählten Komponenten beinhalten ein Prozessor-SoC 104, einen Systemspeicher 106 und eine eingebettete Multimediakarte (EMMC: Embedded Multimedia Card) 108, einen integrierten Leistungsverwaltungsschaltkreis (IC, auch als „Chip“ bezeichnet) 110, einen Batterielade-IC 112, einen Kraftstoffanzeige-IC 114, einen Flash-Treiber 116, Flash-Speicher 118, einen Sensor-Hub 120. Ein Docking-Verbinder 122 ist auch mit einem Rand der Prozessorplatine 102 verbunden, welcher eine Verbindung von mehreren Eingabe/Ausgabe(E/A)-Signalen mit externen Komponenten über zutreffende Kabel mit Gegenverbindern (oder unter Verwendung eines Gegenverbinders, der an einer externen Komponente montiert ist) (beides nicht gezeigt) ermöglicht. Der Docking-Verbinder 122 ist als einen Leistungsverbinder 124 und einen HDMI-Verbinder 126, einen USB-3.0-Verbinder 130 und ein Paar von USB-2.0-Verbindern 130 und 132 beinhaltend dargestellt. Der Leistungsverbinder 124 ist mit einem Kraftstoffanzeige-IC 124 gekoppelt, während der HDMI-Verbinder mit HDMI-Pegelumsetzern 134 verbunden ist, die wiederum mit einer HDMI-Schnittstelle 136 auf dem Prozessor-SoC 104 gekoppelt sind. Das Prozessor-SoC 104 ist ferner als eine USB-3.0-Schnittstelle 138 und USB-2.0-Schnittstellen 140 und 142 beinhaltend dargestellt die mit einem USB-3.0-Verbinder 128, einem USB-2.0-Verbinder 130 bzw. einem USB-2.0-Verbinder 132 gekoppelt sind. Zusätzlich zu diesen in 1 dargestellten Schnittstellen beinhaltet der SoC-Prozessor 104 ferner Schnittstellen, die nicht gezeigt sind, um ein Durcheinander zu vermeiden, sie sind aber unten in Verbindung mit den in 6 und 7 gezeigten beispielhaften Prozessor-SoCs besprochen.
Allgemein kann der Prozessor 104 ein beliebiger Prozessor sein, der dazu konfiguriert ist, die Funktionalität einer bestimmten Implementierung oder eines Satzes von Implementierungen, wie hier beschrieben, zu unterstützen. Zum Beispiel kann der Prozessor 104 ein Einzel- oder Mehrfachkernprozessor, ein Mehrzweckprozessor, ein anwendungsspezifischer integrierter Schaltkreis, Kombinationen davon und dergleichen sein. Ohne Beschränkung ist der Prozessor 104 bevorzugt einer oder mehrere Prozessoren, die von INTEL^® Corporation, NVIDIA^®, ARM^®, Advanced Micro Devices (AMD^®), SAMSUNG^®, APPLE^® oder QUALCOMM^® zum Verkauf angeboten werden. Nichtbeschränkende Beispiele für geeignete Prozessoren beinhalten die Atom-, Nehalem-, Ivy-Bridge- und Sandy-Bridge-Reihen von Prozessoren, die von INTEL^® verkauft werden.
Allgemein können die Verbinder auf dem Docking-Verbinder 122 einzelne physische Verbinder umfassen oder mehrere Verbinder können einen physischen Verbinder teilen. Zum Beispiel beinhaltet bei einer Ausführungsform der Docking-Verbinder 122 einen physischen Mikro-USB-Verbinder, der dazu konfiguriert ist, eine Leistung- und eine einzige E/A-Schnittstelle für den Leistungsverbinder 124 und einen oder mehrere USB-3.0-Verbinder 128, USB-2.0-Verbinder 130 und USB-2.0-Verbinder 132 zu unterstützen. Der Mikro-USB-Verbinder kann auch dazu konfiguriert sein, eine HDMI-Signalschnittstelle zu unterstützen, die einen MHL-Link (Mobile High-Definition Link) einsetzt.
Der Sensor-Hub 120 fungiert als eine E/A-Schnittstelle zum Koppeln verschiedener Sensordaten mit dem Prozessor-SoC 102. Bei der veranschaulichten Ausführungsform beinhalten diese einen Näherungssensor 144, einen Beschleunigungsmesser 146, einen Gyroskopsensor 148, einen Umgebungslichtsensor 150 und einen Biometriesensor 152.
Der Systemspeicher 106 umfasst bevorzugt irgendeine Art von dynamischem Direktzugriffsspeicher (DRAM Dynamic Random Access Memory), wie etwa unter anderem DDR2- oder DDR3-DRAM. Der Flash-Speicher 118 ist veranschaulichend für verschiedene Typen von nichtflüchtigem Speicher und kann allgemein zum Beispiel Speicherstrukturen vom NAND- oder NOR-Typ beinhalten. Zusätzlich oder alternativ dazu können der Systemspeicher 106 und/oder der Flash-Speicher 118 andere und/oder später entwickelte Typen von computerlesbarem Speicher beinhalten. Der Systemspeicher 106 kann integral mit dem Prozessor 104, separat von dem Prozessor 104 oder eine Kombination davon sein. Wie unten besprochen, kann der Flash-Speicher 118 ein oder mehrere Module speichern, die computerlesbare Anweisungen beinhalten, die, wenn sie durch den Prozessor 104 ausgeführt werden, bewirken können, dass eine Vorrichtung, in der die Rechnerkarte 100 implementiert ist, Funktionen entsprechend der vorliegenden Offenbarung durchführt.
In Abhängigkeit von der bestimmten Implementierung kann die Rechnerkarte 100 ein oder mehrere Drahtloskommunikationsmittel beinhalten, wie durch WCOMMS 154 dargestellt ist. WCOMMS 154 kann Hardware (z. B. eine Schaltungsanordnung), Software oder eine Kombination aus Hardware und Software beinhalten, die ermöglicht, dass die Rechnerkarte 100 Signale über ein oder mehrere Drahtloskommunikationsnetze und/oder mittels Peer-to-Peer-Kommunikation sendet und empfängt. Zum Beispiel kann WCOMMS 204 eine oder mehrere Antennen, Sender, Empfänger, Sendeempfänger, Transponder, eine Netzschnittstellenkommunikationsschaltungsanordnung und Kombinationen davon beinhalten, die ermöglichen, dass die Rechnerkarte 100 Signale über ein oder mehrere Drahtloskommunikationsprotokolle sendet und empfängt. Beispiele für solche Drahtloskommunikationsprotokolle beinhalten IEEE-802.11-basierte Protokolle (auch bekannt als Wi-Fi) und BLUETOOTH^®-, Nahfeldkommunikation. Außerdem kann die Rechnerkarte 100 dazu konfiguriert sein, Hochfrequenzidentifikation (RFID: Radio Frequency Identification) zu Authentifizierungs- und ähnlichen Zwecken einzusetzen, wie unten beschrieben ist.
2 zeigt eine Rechnerkarte 100, die mit einer Docking-PCB (Printed Circuit Board - Leiterplatte) 200 gekoppelt ist, die wiederum mit einem Monitor 202 verbunden ist. Die Docking-PCB 200 beinhaltet einen HDMI-Verbinder 204, einen USB-Verbinder 206, einen USB-Hub 208, ein Wi-Fi-Funkelement 210, ein BLUETOOTH^®-Funkelement 212, eine LED/Taste 214, einen DC-Verbinder 216, einen Lüfter 218, der mit einer Lüftersteuerung 220 gekoppelt ist, einen Wärmesensor 222, einen Spannungsregler 224 und eine Batterie 226. Der Monitor 202 beinhaltet einen USB-Hub 228 und einen HDMI-Verbinder 230.
Wie weiter gezeigt, ist der HDMI-Verbinder 204 mit dem HDMI-Verbinder 126 auf dem Docking-Verbinder 122 und mit dem HDMI-Verbinder 230 an dem Monitor 202 verbunden. Bei einer Ausführungsform arbeitet der HDMI-Verbinder 204 als eine Durchleitung, die ermöglicht, dass die Rechnerkarte 100 HDMI-Signale an den Monitor 202 sendet, um die Anzeige des Monitors anzusteuern.
Eine Tastatur 232 und eine Maus 234 sind als mit dem Monitor 202 verbunden dargestellt und werden verwendet, um eine Eingabe an den Monitor 202 für eine Implementierung zu liefern, bei der der Monitor eine eingebaute Intelligenz zum Annehmen von Tastatur- und/oder Mauseingaben beinhaltet. Zum Beispiel ist der Monitor 202 bei einer Ausführungsform ein Smart-Fernseher einschließlich eines Betriebssystems, das zum Annehmen von Tastatur- und/oder Mauseingaben konfiguriert ist. Als eine Option können die Tastatur 232 und/oder die Maus 234 über eine BLUETOOTH®-Verbindung (nicht gezeigt) mit dem Monitor 202 verbunden sein. Als eine andere Option kann die Docking-PCB 200 auch mit dem Monitor 202 über den USB-Verbinder 206 verbunden werden.
Die Docking-PCB 200 beinhaltet verschiedene Leistungssystemkomponenten, die verwendet werden, um sowohl die Schaltungsanordnung auf der Docking-PCB mit Leistung zu versorgen als auch die Rechnerkarte 100 mit Leistung zu versorgen. Wie gezeigt, empfängt der DC-Verbinder 216 Leistung von einem 5-Volt-AC-Leistungsadapter 236. Optional kann die Docking-PCB 200 eine 5-Volt-Eingabeleistung über den USB-Verbinder 206 empfangen.
In Abhängigkeit von der bestimmten Implementierung kann die Docking-PCB eine Batterie und eine assoziierte Batterieladeschaltungsanordnung beinhalten oder auch nicht. Falls zum Beispiel geplant ist, dass die Docking-PCB immer mit einem Monitor (oder einer anderen Vorrichtung) über eine USB-Verbindung mit ausreichend Leistung verbunden wird, ist die Aufnahme einer Batterie möglicherweise nicht notwendig.
3 zeigt ein System einschließlich einer Rechnerkarte 100, die mit einer Backpack-PCB 300 gekoppelt ist, die wiederum mit einem Monitor 202 gekoppelt ist. Die Backpack-PCB 300 beinhaltet einen HDMI-Verbinder 204, einen USB-Verbinder 206, ein Wi-Fi-Funkelement 210, ein BLUETOOTH®-Funkelement 212 und einen USB-Verbinder 302. Außerdem kann das Wi-Fi-Funkelement 210 und das BLUETOOTH®-Funkelement 212 mit einem USB-Hub (nicht gezeigt) auf eine jener in 2 gezeigten ähnliche Weise verbunden werden. Wie zuvor kann der HDMI-Verbinder 204 dazu konfiguriert sein, als eine Durchleitung zu arbeiten, die ermöglicht, dass HDMI-Signale, die von dem HDMI-Verbinder 126 ausgegeben werden, über den HDMI-Verbinder 230 als eine Eingabe an den Monitor 202 geliefert werden. Wie zuvor kann der USB-Verbinder 206 mit dem USB-Hub 228 verbunden werden. Bei der veranschaulichten Ausführungsform wird Leistung über eine 5-Volt-USB-Quelle (nicht gezeigt), die mit dem USB-Verbinder 302 verbunden ist, an die Backpack-PCB 300 geliefert.
4 zeigt eine Ausführungsform einer Smartphone-Implementierung, bei der eine Rechnerkarte 100 mit einem Smartphone 402 über eine USB-Adapterplatine 404 gekoppelt ist. Wie dargestellt, beinhaltet die USB-Adapterplatine 404 einen USB-Hub 406, einen USB-Verbinder 408, eine Batterie 410, ein Lademodul 412 und eine Status-LED und Einschalttaste 414. Der USB-Hub 406 ist mit einem USB-Verbinder 416 auf dem Smartphone 402 verbunden. Wenn ein Docking-Verbinder 122 mit einem Gegenverbinder (nicht gezeigt) auf der USB-Adapterplatine 404 verbunden ist, ist, während der USB-Verbinder 408 mit dem USB-Verbinder 130 verbunden ist, eine Batterie 410 mit dem Leistungsverbinder 132 verbunden und sind die Status-LED und Einschalttaste 414 mit der LED/Taste 124 verbunden.
5 zeigt einen Prozessor 500, der in einer oder mehreren der hier beschriebenen Ausführungsformen verwendet werden kann. Der Prozessor 500 umfasst eine SoC-Architektur und beinhaltet mehrere Intel®-Atom®-Kerne 502, die mit einem Paar von Level-2(L2)-Caches 504 und 506 gekoppelt sind, einen Grafikprozessor 508, Speichersteuerungen 510, einen Systemagenten 512, eine Fabric-Zwischenverbindung 514, ein CSE 516, Sensoren 518, eine Anzeigeschnittstelle 520, eine IUnit 522, einen Biometrieblock 524, einen Audioblock 326, einen Drahtlosblock 528 und eine E/A-Schnittstelle 530. Der Prozessor 500 ist dazu konfiguriert, einen oder mehrere Atom®-Kerne 502 einzusetzen, um ein Betriebssystem 532 zu hosten.
6 zeigt einen Prozessor 600, der auch in einer oder mehreren der hier beschriebenen Ausführungsformen verwendet werden kann. Wie gezeigt, ist eine Anzahl an Komponenten in dem Prozessor 500 mit ähnlichen Bezugsziffern auch in dem Prozessor 600 vorhanden. Außerdem beinhaltet der Prozessor 600 zwei Prozessorkerne 602 und 604, jeweils mit einem jeweiligen L2-Cache 606 und 608, einen Systemagenten 610 einschließlich Profilservern 612, einen skalierbaren E/A-Block 614 und einen sicheren Datenblock 616.
Die Kerne 602 und 604 sind als „große“ Kerne bezeichnet und die Atom®-Kerne 502 sind als „kleine“ Kerne bezeichnet. Ein Kern 602 und 64 stellt eine erheblich höhere Leistungsfähigkeit als ein Atom®-Kern 602 bereit, aber unter dem Kompromiss eines erheblich höheren Leistungsverbrauchs. Um auszunutzen, dass sowohl Hochleistungs- als auch Niederleistungsprozessorkerne vorhanden sind, arbeiten Profilserver 612 in Verbindung mit einem Klein/Groß&Profilunterstützung-Modul 618 in einer Referenzplattformabstraktionsschicht 620, um zu ermöglichen, dass der Prozessor 600 die Kerne 502 und 504 verwendet, wenn Leistung zum Arbeiten in einem Hochleistungsprofil verfügbar ist, während er die Atom®-Kerne 602 verwendet, wenn er in einem Profil mit reduzierter Leistung arbeitet. Die Referenzplattformabstraktionsschicht 620 stellt eine Schicht zur Abstraktion zwischen einem Betriebssystem 622 und dem Prozessor 600 bereit, so dass ermöglicht wird, dass das Betriebssystem 622 unter einem Bereich von Profiloptionen arbeitet, ohne irgendeine Notwendigkeit, das Betriebssystem zu modifizieren.
Native Grafik-Thrower-Catcher-Architekturen
7 veranschaulicht eine abstrahierte Grafik-Rendering-Architektur einer generischen Grafikvorrichtung 700, die Vorrichtungsanwendungen 702, Grafik-APIs 704, ein Grafik-Rendering-System 706, einen Anzeigepuffer 708 und eine Anzeige 710 beinhaltet. Die Vorrichtungsanwendungen 702, die auf dem Betriebssystem der Grafikvorrichtung laufen, geben native Grafikbefehle an die Grafik-APIs 704 aus. Die nativen Grafikbefehle umfassen allgemein einen beliebigen Grafikbefehl, der zum Rendern von Inhalt auf einer gegebenen Plattform oder Vorrichtung verwendet werden kann und nicht auf einen bestimmten Satz von APIs in dieser Grafikarchitektur beschränkt ist. Zum Beispiel können die nativen Grafikbefehle allgemein einen beliebigen Grafikbefehl beinhalten, der durch das Betriebssystem/die Vorrichtungsimplementierung unterstützt wird; speziellere Einzelheiten beispielhafter APIs sind unten besprochen.
Die Grafik-APIs 704 sind dazu konfiguriert, zwei Rendering-Pfade zu unterstützen: 1) einen Software-Rendering-Pfad; und 2) einen Hardware-Rendering-Pfad. Der Software-Rendering-Pfad schließt das Verwenden einer Software ein, die auf dem Hostprozessor der Grafikvorrichtung, wie etwa einer zentralen Verarbeitungseinheit (CPU: Central Processing Unit), ausgeführt wird, wie durch das Software-Rendering 712 dargestellt ist. Allgemein wird dies über eine oder mehrere Laufzeit-Bibliotheken 713 implementiert, auf die über die Ausführung entsprechender Grafik-APIs 704 zugegriffen wird. Im Gegensatz dazu ist der Hardware-Rendering-Pfad dazu gestaltet, Grafik unter Verwendung einer oder mehrerer hardwarebasierter Vorrichtungen, wie etwa einer GPU 714, zu rendern. Während intern eine GPU eingebettete Software (nicht gezeigt) zum Durchführen von einigen ihrer Operationen verwenden kann, wird solche eingebettete Software nicht über eine Grafikbibliothek freigelegt, die für Vorrichtungsanwendungen 702 zugänglich ist, und dementsprechend wird das Rendern von Grafikinhalt auf einer GPU nicht als Software-Rendering betrachtet.
Das Grafik-Rendering-Untersystem 706 ist ferner als Bitmap-Puffer 714 und einen Compositor 718 beinhaltend dargestellt. Software-Rendering bringt üblicherweise das Rendering von Grafikinhalt als Bitmaps mit sich, die virtuelle Zeichenoberflächen oder dergleichen umfassen, die als Bitmap-Puffer 716 in einem Speicher (z. B. Systemspeicher) zugeordnet sind. In Abhängigkeit von der Terminologie, die durch die Softwareplattform für die Grafikvorrichtung 700 verwendet wird, werden die Bitmap-Puffer typischerweise als Schichten, Oberflächen, Ansichten und/oder Fenster bezeichnet. Zu Veranschaulichungszwecken stelle man sich ein Bitmap-Puffer als ein virtuelles Blatt Papier mit einer Anordnung aus winzigen Kästchen vor, auf die Inhalt durch Füllen der Kästchen mit verschiedenen Farben „gemalt“ werden kann.
Die GPU 714 rendert Inhalt unter Verwendung einer mathematischen Manipulation von Texturen und anderem Inhalt, wobei sie auch das Rendern von vektorbasiertem Inhalt unterstützt. Die GPU 714 verwendet auch Bitmap-Puffer, sowohl intern (nicht gezeigt) als auch in dem Speicher. Dieser kann Systemspeicher, Speicher, der für die GPU dediziert ist (entweder On-Die-Speicher oder Off-Die-Speicher), oder eine Kombination der beiden beinhalten. Falls zum Beispiel die GPU in einer Grafikkarte in einem PC oder einem separaten Grafikchip in einem Laptop enthalten ist, wird die Grafikkarte oder der Grafikchip allgemein einen Speicher beinhalten, der für die GPU-Verwendung dediziert ist. Für Mobilvorrichtungen, wie etwa Smartphones und Tablets, ist die GPU tatsächlich in dem Prozessor-SoC eingebettet und wird typischerweise irgendeinen On-Die-Speicher als auch einen Speicher, der entweder auf dem SoC oder auf einem separaten Speicherchip eingebettet ist, einsetzen.
Der Compositor 718 wird zum „Zusammensetzen“ des finalen Grafikinhalts verwendet, der auf dem Anzeigebildschirm der Grafikvorrichtung gezeigt wird. Dies wird durch Kombinieren von verschiedenem Bitmap-Inhalt in Bitmap-Puffern 716 und Puffern, die durch die GPU 714 gerendert werden (nicht gezeigt), und Schreiben des zusammengesetzten Bitmap-Inhalts in den Anzeigepuffer 708 durchgeführt. Der Anzeigepuffer 716 wird dann unter Verwendung einer Auffrischrate ausgelesen, um zu bewirken, dass der Bitmap-Grafikinhalt auf einer Anzeige 718 angezeigt wird. Optional kann der Grafikinhalt in einen „Back“-Puffer oder „Zusatzspeicher“ geschrieben werden, der dann in den Anzeigepuffer kopiert wird, oder ein „Ping-Pong“-Schema kann verwendet werden, in dem der Back-Puffer und der Anzeigepuffer in Übereinstimmung mit der Auffrischrate ausgetauscht werden.
Eine beispielhafte native Grafik-Thrower-Catcher-Architektur ist in 8 gezeigt, einschließlich einer Thrower-Vorrichtung 800, die native(n) Grafikbefehle und -Inhalt zu einer Catcher-Vorrichtung 802 über einen Link 804 wirft. Wie durch ähnliche Bezugsziffern in 7 und 8 angegeben, ist die Grafikarchitektur der Thrower-Vorrichtung 800 der Grafikarchitektur der Grafikvorrichtung 700 ähnlich. Währenddessen werden Komponenten, die das Grafik-Rendering-Untersystem 706 umfassen, auf der Catcher-Vorrichtung 802 repliziert, wie durch das Grafik-Rendering-Untersystem 706R dargestellt ist. Die Catcher-Vorrichtung 802 beinhaltet ferner einen Anzeigepuffer 805 und eine Anzeige 806, die allgemein auf eine dem Anzeigepuffer 708 und der Anzeige 710 ähnliche Weise arbeiten, aber unterschiedliche Puffergrößen und/oder Konfigurationen aufweisen können, und die Auflösung der Anzeige 806 und der Anzeige 710 kann gleich oder verschieden sein.
Das Werfen von nativen/nativem Grafikbefehlen und -Inhalt wird durch jeweilige Thrower- und Catcher-Komponenten auf der Thrower-Vorrichtung 800 und der Catcher-Vorrichtung 800 ermöglicht, die einen nativen Grafik-Thrower 808 und einen nativen Grafik-Catcher 810 umfassen. Diese Komponenten helfen dabei, das Werfen nativer Grafikbefehle und von Inhalt auf die folgende Weise zu ermöglichen.
Bei einer Ausführungsform ist der native Grafikwerfer 808 als ein virtueller Grafiktreiber oder dergleichen implementiert, der eine Schnittstelle bereitstellt, die dem Grafik-Rendering-Untersystem 706 ähnlich ist. Grafikbefehle und -Inhalt, die sowohl dem Software-Rendering-Pfad als auch dem Hardware-Rendering-Pfad entsprechen und die von Grafik-APIs 704 ausgegeben werden, werden an den nativen Grafik-Thrower 808 gesendet. In Abhängigkeit von dem Betriebsmodus kann der native Grafik-Thrower 808 als ein Fangstelle-und-Durchleitungsgrafiktreiber konfiguriert sein oder er kann als ein abfangender Grafiktreiber arbeiten. Bei Operation als ein Fangstelle-und-Durchleitungsgrafiktreiber werden native(r) Grafikbefehle und -Inhalt gefangen, gepuffert und an den nativen Grafik-Catcher 810 gesendet. Es wird auch ermöglicht, dass die gepufferten Befehle zu dem Grafik-Rendering-Untersystem 706 auf eine transparente Weise durchgeleitet werden, so dass die Grafik auf der Thrower-Vorrichtung 800 als genauso wie die Grafikvorrichtung 700 arbeitend erscheint. Bei einem anfangenden Grafiktreiber werden die Grafikbefehle auf der Thrower-Vorrichtung 800 nicht durchgeleitet.
Wie leicht zu beobachten ist, implementiert die Thrower-Catcher-Architektur aus 8 eine geteilte Grafikarchitektur, wobei das Grafik-Rendering-Untersystem zu der Catcher-Vorrichtung „bewegt“ (oder anderweitig auf dieser repliziert) ist. Aus der Perspektive des Grafik-Rendering-Untersystems 706R gibt der native Grafik-Catcher 810 Grafikbefehle und -Inhalt entlang sowohl des Software(SWF)- als auch des Hardware-Rendering-Pfades aus, als ob dieser Inhalt direkt durch die APIs 704 bereitgestellt würde. Das Ergebnis ist, dass Grafikinhalt auf der fernen Drahtlosvorrichtung (d. h. der Catcher-Vorrichtung 802) mit einer ähnlichen Geschwindigkeit wie die Grafik, die auf einer Grafikvorrichtung selbst gerendert wird (wenn ähnliche Hardwarekomponenten für die Grafik-Rendering-Untersysteme 706 und 706R implementiert sind), gerendert werden kann. Es tritt im Wesentlichen keine Latenz durch den Throwing-Prozess für Grafikbefehle und - Inhalt auf und das Ausmaß einer Verzögerung, die aus einer solchen Latenz resultiert, ist allgemein für den Benutzer nicht wahrnehmbar, insbesondere für Grafikbefehle und -Inhalt, die über den Hardware-Rendering-Pfad gerendert werden. Das größte Ausmaß der Latenz wird typischerweise das Werfen eines großen Bildes (z. B. eines großen JPEG- oder PNG-Bildes) einschließen, was durch Übertragen der komprimierten Bilddatei selbst von dem Thrower zu dem Catcher implementiert werden kann.
Um die Initialisierung und den Betrieb des Links 804 zu unterstützen, beinhaltet sowohl die Thrower-Vorrichtung 800 als auch die Catcher-Vorrichtung 802 Link-Stapelungsmodule 812 und 814. Bei manchen Ausführungsformen arbeitet die Thrower-Vorrichtung 800 als eine Quelle und arbeitet die Catcher-Vorrichtung 802 als eine Senke und es gibt entsprechende Software zum Ermöglichen einer Quelle/Senke-Link-Konfiguration. Zum Beispiel umfasst der Link 804 bei einer Ausführungsform einen Wi-Fi-Direct®(WFD)-Link, der eine WFD-Quelle und eine WFD-Senke beinhaltet. Optional können eine INTEL®-WiDi-Verbindung oder eine INTEL®-WiGig-Verbindung verwendet werden.
Android-Grafik-Rendering
9 zeigt ein Diagramm, das die Android-Software-Architektur 900 veranschaulicht. Die Android-Software-Architektur beinhaltet einen Linux-Kernel 902, Bibliotheken 904, Android Runtime 906, Application-Framework 908 und Anwendungen 910.
Der Linux-Kernel 902 belegt die unterste Schicht in dem Android-Softwarestapel und stellt eine Ebene einer Abstraktion zwischen der Android-Vorrichtungshardware und den oberen Schichten des Android-Softwarestapels bereit. Während ein Teil des Linux-Kernels 902 einen Code mit Linux-Kernel-Komponenten für Desktops und Server teilt, gibt es manche Komponenten, die speziell durch Google für Android implementiert werden. Eine neuere Version von Android, Android 4.4 (auch bekannt als „KitKat“) basiert auf dem Linux-Kernel 3.4 oder neuer (es wird angemerkt, dass die tatsächliche Kernel-Version von der bestimmten Android-Vorrichtung und dem Chipsatz abhängt). Die veranschaulichten Komponenten des Linux-Kernels 902 beinhalten einen Anzeigetreiber 912, einen Kameratreiber 914, einen Bluetooth-Treiber 916, einen Flash-Speicher-Treiber 918, einen Binder-Treiber 920, einen USB-Treiber 922, einen Tastenfeld-Treiber 924, einen Wi-Fi-Treiber 926, einen Audiotreiber 928 und eine Leistungsverwaltung 930.
Auf dem Linux-Kernel 902 befinden sich Bibliotheken 904, die Middleware, Bibliotheken und APIs, die in C/C++ geschrieben sind, und Anwendungen 910, die auf dem Application-Framework 908 laufen, umfasst. Die Bibliotheken 904 sind durch einen Android-Vorrichtungsanbieter für eine bestimmte Hardwareabstraktion, wie etwa eine spezielle CPU, kompiliert und vorinstalliert. Die Bibliotheken beinhalten einen Oberflächenmanager 932, ein Medien-Framework 934, eine SQLite-Datenbank-Engine 936, ein OpenGL-ES(Embedded System - eingebettetes System) 938, eine FreeType-Schriftartbibliothek 940, WebKit 942, eine Skia-Grafikbibliothek (SGL: Skia Graphics Library) 944, eine SSL(Secure Socket Layer - sichere Socket-Schicht)-Bibliothek 946 und die libc-Bibliothek 948. Der Oberflächenmanager 932, auch als „SurfaceFlinger“ bezeichnet, ist ein Grafikzusammensetzungsmanager, der Grafikinhalt für Oberflächen zusammenstellt, die Außerbildschirm-Bitmaps umfassen und die mit anderen Oberflächen kombiniert werden, um den Grafikinhalt zu erzeugen, der auf einer Android-Vorrichtung angezeigt wird, wie unten ausführlicher besprochen ist. Das Medien-Framework 934 beinhaltet Bibliotheken und Codecs, die für verschiedene Multimediaanwendungen, wie etwa Abspielen und Aufzeichnen von Videos, verwendet werden und viele Formate, wie etwa AAC, H.264 AVC, H.263, MP3 und MPEG-4, unterstützen. Die SQLite-Datenbank genießt Verwendungen zum Speichern von und Zugreifen auf Daten und unterstützt verschiedene SQL-Datenbankfunktionen.
Die Android-Softwarearchitektur setzt mehrere Komponenten zum Rendern von Grafik ein, einschließlich Open-GL-ES 938, SGL 944, die FreeType-Schriftartbibliothek 940 und WebKit 942. Weitere Einzelheiten des Android-Grafik-Renderns sind unten unter Bezugnahme auf 8 veranschaulicht.
Android Runtime 906 setzt die Dalvik-virtuelle-Maschine(VM) 950 und Kernbibliotheken 952 ein. Android-Anwendungen werden in Java geschrieben (es wird angemerkt, dass Android 4.4 auch in C/C++ geschriebene Anwendungen unterstützt). Herkömmliche Java-Programmierung setzt eine Java-virtuelle-Maschine (JVM) ein, um Java-Bytecode auszuführen, der durch einen Java-Compiler erzeugt wird, der zum Kompilieren von Java-Anwendungen verwendet wird. Im Gegensatz zu JVMs, die Stapelmaschinen sind, verwendet die Dalvik-VM eine registerbasierte Architektur, die weniger, typischerweise komplexere Virtuelle-Maschine-Anweisungen erfordert. Dalvik-Programme werden unter Verwendung von Android-API-s in Java geschrieben, zu Java-Bytecode kompiliert und zu Dalvik-Anweisungen nach Bedarf umgewandelt. Kernbibliotheken 952 unterstützen ähnliche Java-Funktionen, die in Java-SE (Standard Edition) enthalten sind, aber speziell zum Unterstützen von Android maßgeschneidert sind.
Das Application-Framework 908 beinhaltet Baublöcke auf hoher Ebene, die zum Implementieren von Android-Anwendungen 910 verwendet werden. Diese Baublöcke beinhalten einen Aktivitätsmanager 954, einen Windows-Manager 956, Inhaltsanbieter 958, ein Betrachtungssystem 960, einen Benachrichtigungsmanager 962, einen Package-Manager 964, einen Telefonie-Manager 966, einen Ressourcenmanager 968, einen Standort-Manager 970 und einen XMPP(Extenisble Messaging and Presence Protocol)-Dienst 972.
Die Anwendungen 910 beinhalten verschiedene Anwendungen, die auf einer Android-Plattform laufen, sowie Widgets, wie durch eine Home-Anwendung 974, eine Kontaktanwendung 976, eine Telefonanwendung 978 und einen Browser 980 dargestellt ist. Die Anwendungen können für den bestimmten Typ der Android-Plattform maßgeschneidert sein, beispielsweise würde ein Tablet ohne mobile Funkunterstützung keine Telefonanwendung haben und kann zusätzliche Anwendungen haben, die für die größere Größe eines Bildschirms eines Tablets (im Vergleich zu einer typischen Android-Smartphone-Bildschirmgröße) gestaltet sind.
Die Android-Software-Architektur bietet eine Vielfalt an Grafik-Rendering-APIs für 2D- und 3D-Inhalt an, die mit Herstellerimplementierungen von Grafiktreibern interagieren. Jedoch zeichnen Anwendungsentwickler Grafikinhalt auf zwei Wege auf den Anzeigebildschirm: mit Canvas oder OpenGL.
10 veranschaulicht ausgewählte Android-Grafikkomponenten. Diese Komponenten sind als Bildstromerzeuger 1000, Framework/Nativ/libs/gui-Module 1002, Bildstromverbraucher 1004 und eine Hardwareabstraktionsschicht (HAL) 1006 gruppiert. Ein Bildstromerzeuger kann alles sein, was Grafikpuffer zum Verbrauch produziert. Beispiele beinhalten einen Medienabspieler 1008, eine Kameravorschauanwendung 1010, Canvas-2D 1012 und OpenGL-Es 1014. Die Frameworks/Nativ/libs/gui-Module 1002 sind C++-Module und beinhalten Surface.cpp 1016, iGraphicsBufferProducer 1018 und GLConsumer.cpp 1020. Die Bildstromverbraucher 1004 beinhalten SurfaceFlinger 1022 und OpenGL-ES-Anwendungen 1024. Die HAL 1006 beinhaltet einen Hardware-Composer 1026 und einen Grafikspeicherallokator (Gralloc) 1028. Die in 10 dargestellten Grafikkomponenten beinhalten auch einen WindowsManager 1030.
Der gebräuchlichste Verbraucher von Bildströmen ist SurfaceFlinger 1022, der Systemdienst, der die momentan sichtbaren Oberflächen verbraucht und sie dann auf die Anzeige unter Verwendung von Informationen zusammenstellt, die durch den WindowManager 1024 bereitgestellt werden. SurfaceFlinger 1022 ist der einzige Dienst, der den Inhalt der Anzeige modifizieren kann. SurfaceFlinger 1022 verwendet OpenGL und einen Hardware-Composer zum Zusammenstellen einer Gruppe von Oberflächen. Andere OpenGL-ES-Apps 1024 können ebenso Bildströme verbrauchen, wie etwa die Kamera-App, die einen Bildstrom einer Kameravorschau 1010 verbraucht.
WindowManager 1030 ist der Android-Systemdienst, das ein Fenster steuert, das ein Behälter für Ansichten ist. Ein Fenster wird immer durch eine Oberfläche unterstützt. Dieser Dienst beaufsichtigt Lebenszyklen, Eingabe- und Fokusereignisse, Bildschirmorientierung, Übergänge, Animationen, Position, Transformationen, z-Ordnung und viele andere Aspekte eines Fensters. WindowManager 1030 sendet sämtliche Fenstermetadaten an SurfaceFlinger 1022, so dass SurfaceFlinger diese Daten zum Zusammenstellen von Oberflächen auf der Anzeige verwenden kann.
Der Hardware-Composer 1026 ist die Hardwareabstraktion für das Anzeigeuntersystem. SurfaceFlinger 1022 kann eine gewisse Zusammenstellungsarbeit an den Hardwarecomposer 1026 delegieren, um Arbeit von OpenGL und der GPU abzugeben. SurfaceFlinger 1022 fungiert als nur ein anderer OpenGL-ES-Client. Somit verwendet SurfaceFlinger OpenGL-ES, wenn es beispielsweise aktiv einen Puffer oder zwei in einen dritten zusammenstellt. Dies verringert die Leistung für das Zusammenstellen als wenn die GPU die gesamte Berechnung durchführt. Der Hardware-Composer 1026 führt die andere Hälfte der Arbeit durch. Diese HAL-Komponente ist der zentrale Punkt für das gesamte Android-Grafikrendern. Der Hardware-Composer 1026 unterstützt verschiedene Ereignisse, einschließlich VSYNC und Hotplug für Plug-and-Play-HDMI-Unterstützung.
android.graphics.Canvas ist eine 2D-Grafik-API und ist die beliebteste Grafik-API unter Entwicklern. CanvasOperationen zeichnen den Vorrat und kundenspezifische android.view.Views in Android. In Android wird eine Hardwarebeschleunigung für Canvas-APIs mit einer Zeichnungsbibliothek erreicht, die OpenGLRenderer genannt wird und die Canvas-Operationen in OpenGL-Operationen übersetzt, so dass sie auf der GPU ausgeführt werden können.
Beginnend mit Android 4.0 ist hardwarebeschleunigtes Canvas standardmäßig aktiviert. Folglich ist eine Hardware-GPU, die OpenGL-ES 2.0 (oder neuer) unterstützt, für Android-4.0- und neuere Vorrichtungen zwingend. Android 4.4 erfordert eine OpenGL-ES-3.0-Hardwareunterstützung.
Zusätzlich zu Canvas ist die andere Hauptart, auf die Entwickler Grafik rendern, durch Verwenden von OpenGL ES, um eine Oberfläche direkt zu rendern. Android stellt OpenGL-ES-Schnittstellen in dem android.opengl-Package bereit, das Entwickler verwenden können, um ihre GL-Implementierungen mit dem SDK (Software Development Kit) mit nativen APIs, die in dem Android-NDK (Android Native Development Kit) bereitgestellt sind, abzurufen.
11 veranschaulicht graphisch Konzepte, die Oberflächen und die Zusammenstellung der Oberflächen durch SurfaceFlinger 1022 und den Hardware-Composer betreffen, um den grafischen Inhalt zu erzeugen, der auf einer Android-Vorrichtung angezeigt wird. Wie oben erwähnt, werden Anwendungsentwickler mit zwei Mitteln zum Erzeugen von graphischem Inhalt versorgt: Canvas und OpenGL. Jedes setzt eine API ein, die einen Satz von Grafikbefehlen zum Erzeugen von grafischem Inhalt umfasst. Der Grafikinhalt wird zu einer Oberfläche „gerendert“, die ein Bitmap umfasst, das in dem Grafikspeicher 1100 gespeichert wird.
11 zeigt einen Grafikinhalt, der durch zwei Anwendungen 1102 und 1104 erzeugt wird. Die Anwendung 1102 ist eine Fotobetrachtungsanwendung und verwendet einen Canvas-Grafikstapel 1106. Dieser beinhaltet eine Canvas-API 1108, SGL 1110, die Skia-2D-Grafiksoftwarebibliothek und die Android-Oberflächenklasse 1112. Die Canvas-API 1106 ermöglicht, dass Benutzer Grafikinhalt über Canvas-Zeichenbefehle auf virtuelle Ansichten (als Oberflächen bezeichnet) zeichnen, die als Bitmaps in dem Grafikspeicher 1100 gespeichert werden. Skia unterstützt das Rendern von 2D-Vektorgrafik und Bildinhalt, wie etwa GIFs, JPEGs und PNGs. Skia unterstützt auch Android's Freetype-Text-Rendering-Untersystem, wobei es auch verschiedene Grafikverbesserungen und -effekte unterstützt, wie etwa Antialiasing, Transparenz, Filter, Shader usw. Die Oberflächenklasse 1110 beinhaltet verschiedene Softwarekomponenten zum Ermöglichen einer Interaktion mit Android-Oberflächen. Die Anwendung 1102 rendert Grafikinhalt auf eine Oberfläche 1114.
Die Anwendung 1104 ist eine Spieleanwendung, die Canvas für ihre Benutzeroberfläche verwendet und OpenGL für ihren Spieleinhalt verwendet. Sie setzt eine Version eines Canvas-Grafikstapels 1106 ein, um einen Benutzeroberflächengrafikinhalt auf eine Oberfläche 1116 zu rendern. Die OpenGL-Zeichenbefehle werden durch einen OpenGL-Grafikstapel 1118 verarbeitet, der eine OpenGL-ES-API 1120, eine eingebettete Systemgrafikbibliothek (EGL) 1122, eine Hardware-OpenGL-ES-Grafikbibliothek (HGL) 1124, eine Android-Software-OpenGL-ES-Grafikbibliothek (AGL) 1126, eine Grafikverarbeitungseinheit (GPU) 1128, einen Pixelflinger 1130 und eine Oberflächenklasse 1110 beinhaltet. Der OpenGL-Zeicheninhalt wird auf eine Oberfläche 1132 gerendert.
Der Inhalt der Oberflächen 1114, 1116 und 1132 wird unter Verwendung des SurfaceFlinger 1022 und des Hardware-Composers 1026 selektiv kombiniert. Bei diesem Beispiel weist die Anwendung 1104 den momentanen Fokus auf und dementsprechend werden Bitmaps, die den Oberflächen 1116 und 1132 entsprechen, in einen Anzeigepuffer 1134 kopiert.
Die Rolle von SurfaceFlinger besteht darin, Puffer aus Daten von mehreren Quellen anzunehmen, sie zusammenzustellen und sie an die Anzeige zu senden. Bei früheren Versionen von Android erfolgte dies durch Software-Blitting zu einem Hardwarerahmenpuffer (z. B. /dev/graphics/fb0), aber so wird es nicht mehr gemacht.
Wenn eine Anwendung in den Vordergrund tritt, fragt der WindowMananger-Service SurfaceFlinger nach einer Zeichenoberfläche. SurfaceFlinger erzeugt eine „Schicht“ - deren primäre Komponente eine Pufferwarteschlange bildet - für die SurfaceFlinger als der Verbraucher fungiert. Ein Binder-Objekt für die Erzeugerseite wird durch den WindowManager zu der Weiter geleitet, die dann mit dem Senden von Einzelbildern direkt an SurfaceFlinger beginnen kann.
Für die meisten Anwendungen wird es drei Schichten auf dem Bildschirm zu einer beliebigen Zeit geben: der „Statusbalken“ an der Oberseite des Bildschirms, die „Navigationsleiste“ an der Unterseite oder Seite und die Benutzeroberfläche und/oder der Anzeigeinhalt der Anwendung. Manche Anwendungen werden mehr oder weniger aufweisen, z. B. weist die Home-Anwendung eine getrennte Schicht für das Hintergrundbild auf, während ein Vollbildspiel den Statusbalken verstecken könnte. Jede Schicht kann unabhängig aktualisiert werden. Die Status- und Navigationsbalken werden durch einen Systemprozess gerendert, während die Anwendungsschichten durch die Anwendung gerendert werden, ohne Koordination zwischen den Beiden.
Vorrichtungsanzeigen frischen mit einer gewissen Rate auf, typischerweise 60 Einzelbilder pro Sekunde (fps: frames per second) auf Smartphones und Tablets. Falls die Anzeigeinhalte mitten in der Auffrischung aktualisiert werden, wird „Tearing“ sichtbar sein; somit ist es wichtig, die Inhalte zwischen Zyklen zu aktualisieren. Das System empfängt ein Signal von der Anzeige, wenn es sicher ist, die Inhalte zu aktualisieren. Dies wird als das VSYNC-Signal bezeichnet.
Die Auffrischrate kann mit der Zeit variieren, z. B. liegen manche Mobilvorrichtungen in Abhängigkeit von momentanen Bedingungen in dem Bereich von 58 bis 62 fps. Für einen HDMI-angeschlossenen Fernseher könnten dies theoretisch auf 24 oder 48 Hz abfallen, um einem Video zu entsprechen. Weil der Bildschirm nur einmal je Auffrischungszyklus aktualisiert werden kann, wäre das Zusenden von Puffern zur Anzeige bei 200 fps eine Verschwendung von Arbeitsaufwand, da die meisten der Einzelbilder nie gesehen werden würden. Anstatt immer aktiv zu werden, wenn eine App einen Puffer zusendet, wacht SurfaceFlinger auf, wenn die Anzeige für etwas neues bereit ist.
Wenn das VSYNC-Signal ankommt, geht SurfaceFlinger nach neuen Puffern suchend durch seine Liste von Schichten. Falls es einen neuen findet, erfasst es ihn; falls nicht, verwendet es weiterhin den zuvor erfassten Puffer. SurfaceFlinger will immer etwas zum Anzeigen haben, somit wird es an einem Puffer festhalten. Falls keine Puffer jemals auf einer Schicht zugesendet wurden, wird die Schicht ignoriert.
Sobald SurfaceFlinger sämtliche Puffer für sichtbare Schichten gesammelt hat, fragt es den Hardware-Composer, wie die Zusammenstellung durchgeführt werden sollte. Der Hardware-Composer 1026 wurde zuerst in Android 3.0 eingeführt und hat sich über die Jahre kontinuierlich weiterentwickelt. Sein Primärzweck besteht darin, den effizientesten Weg zum Zusammenstellen von Puffern mit der verfügbaren Hardware zu bestimmen. Als ein HAL-Komponente ist seine Implementierung vorrichtungsspezifisch und üblicherweise durch den Anzeigehardware-OEM implementiert.
Der Wert dieses Ansatzes ist einfach zu erkennen, wenn „überlappende Ebenen“ betrachtet werden. Der Zweck überlappender Ebenen besteht darin, mehrere Puffer miteinander zusammenzustellen, aber in der Anzeigehardware statt der GPU. Zum Beispiel unter der Annahme, dass ein typisches Android-Telefon in Porträtorientierung vorliegt, könnte mit dem Statusbalken an der Oberseite und dem Navigationsbalken an der Unterseite der App-Inhalt überall sonst sein. Die Inhalte für jede Schicht befinden sich in separaten Puffern (d. h. auf separaten Oberflächen). Die Zusammenstellung könnte durch Rendern des App-Inhalts in einen Scratch-Puffer, dann Rendern des Statusbalkens über ihm, dann Rendern der Navigationsleiste darauf und schließlich Weiterleiten des Scratch-Puffers an die Anzeigehardware gehandhabt werden. Oder es könnten alle drei Puffer an die Anzeigehardware geleitet werden und ihr gesagt werden, die Daten von unterschiedlichen Puffern für unterschiedliche Teile des Bildschirms zu lesen. Der letztere Ansatz kann erheblich effizienter sein.
Wie zu erwarten ist, variieren die Fähigkeiten unterschiedlicher Anzeigeprozessoren erheblich. Die Anzahl an Überlagerungen, ob Schichten gedreht oder vermischt werden können, und Beschränkungen hinsichtlich Positionierung und Überlappung können durch eine API schwierig auszudrücken sein. Somit arbeitet der Hardware-Composer 1026 wie folgt.
Zuerst versorgt SurfaceFlinger 1022 den Hardware-Composer 1026 mit einer vollständigen Liste von Schichten und fragt „Wie willst du dies handhaben?“. Der Hardware-Composer 1026 reagiert, indem jede Schicht zu einer „Überlagerung“ oder „OpenGL-ES(GLES)-Zusammenstellung“ gemacht wird. SurfaceFlinger 1022 sorgt für eine beliebige GLES-Zusammenstellung, wobei der Ausgabepuffer an den Hardware-Composer 1026 geleitet wird, und lässt den Hardware-Composer 1026 den Rest handhaben.
Eine beispielhafte Android-Grafik-Thrower-Catcher-Architektur ist in 8a gezeigt, einschließlich einer hybriden Android-Thrower-Vorrichtung 800a, die Android-Grafikbefehle und -Inhalt zu einer Android-Catcher-Vorrichtung 802 über einen Link 804 wirft. Verschiedene Aspekte der Android-Grafik-Thrower-Catcher-Architektur aus 8a sind jenen in der oben besprochenen 8 ähnlich, einschließlich verschiedener Komponenten, die die gleichen Referenzziffern in den beiden 8 und 8a teilen. Entsprechend wird sich das Folgende auf eine Implementierung von Einzelheiten konzentrieren, die besonders für das Implementieren eines Android-Grafik-Thrower -Catcher sind.
Wie oben besprochen, verwenden Android-Anwendungen 910 Canvas-Zeichenbefehle und OpenGL-Zeichenbefehle zum Erzeugen von Grafikinhalt, der durch eine Android-Anwendung angezeigt wird. Die Canvas- und OpenGL-Befehle werden durch Android-Grafik-APIs 816 implementiert, die anfänglich den Befehl entlang des Hardware-Rendering-Pfades für OpenGL-Befehle und des Software-Rendering-Pfades für Canvas-Befehle teilen. Ausgewählte Canvas-Befehle werden über den Skia-zu-OpenGL-Block 818 von Skia- zu OpenGL-äquivalenten Befehlen umgewandelt und jene OpenGL-Befehle werden über den Hardware-Rendering-Pfad weiterleitet.
Die Android-Grafik-Rendering-Untersysteme 806a und 706Ra beinhalten einen Software-Rendering-Block 712a, der eine Skia-Laufzeitbibliothek 944 beinhaltet, um Skia-Befehle als assoziierten Inhalt (z. B. Bildinhalt) über den Software-Rendering-Pfad zu rendern. Weitere Komponenten beinhalten die Bitmap-Puffer 716a, SurfaceFlinger 1022, eine GPU 714 und einen Hardware-Composer 1026.
8a stellt ferner einen Android-Grafik-Thrower 808a und einen Android-Grafik-Catcher 810a dar. Diese Komponenten sind dem nativen Grafik-Thrower 808 und dem nativen Grafik-Catcher 810 ähnlich, mit der Ausnahme, dass sie dazu konfiguriert sind, Android-Grafikbefehle und assoziierten Inhalt, einschließlich OpenGL-Befehlen, und Canvas- und/oder Skia-Befehle und assoziierten Inhalt zu werfen.
12a veranschaulicht die Android-Thrower-Catcher-Architektur, die OpenGL- und Android-Skia-Grafikinhalt über mehrere Sockets parallel wirft. Auf der Thrower-Seite beinhalten die Komponenten einen Throw-Manager 1200, einen lokalen Grafiktreiber 1202, einen Betriebssystem-Kernel 1204 und eine Anwendung 1206. Auf der Catcher-Seite beinhalten die Komponenten eine(n) Entfernungsvorrichtung/Bildschirm 1208 einschließlich einer nativen Anwendung 1210 und SurfaceFlinger 1022. Allgemein ist die/der ferne Vorrichtung/Bildschirm 1208 repräsentativ für einen beliebigen Typ von Vorrichtung, die als ein Catcher konfiguriert werden kann.
Um Grafik zu werfen, muss zuerst ein Link zwischen dem Thrower und Catcher initialisiert werden, wie durch Initialisieren von Link-Kommunikationsaustausch 1212 dargestellt ist, was durch einen doppelköpfigen Pfeil angegeben wird, um anzugeben, dass es einen Kommunikationsaustausch zwischen dem Thrower und Catcher gibt. Allgemein werden die bestimmten Link-Initialisierungsoperationen eine Funktion der bestimmten physischen Link-Verbindung und des verwendeten Protokolls, wobei solche Operationen für einen Fachmann in der Kommunikationstechnik und außerhalb des Schutzumfangs dieser Offenbarung wohlbekannt sind.
Sobald der Link initialisiert wurde, sendet der lokale Grafiktreiber 1202 eine Nachricht 1214 an die/den ferne(n) Vorrichtung/Bildschirm 1208, um nach ihren/seinen Parametern und Fähigkeiten zu fragen. Zum Beispiel kann dies unter anderem Bildschirmgröße, Auflösung, Datenformate der/des fernen Vorrichtung/Bildschirms 1208, welche Typen von Grafik sie/er unterstützt, wie etwa OpenGL und DirectX und potentiell andere Informationen in Bezug auf Grafikparameter und Fähigkeiten der/des fernen Vorrichtung/Bildschirms 1208 beinhalten, die über eine Nachricht 1216 zurückgesendet werden.
Beim Empfang der Nachricht 1216 wertet eine als ein Entscheidungsblock 1218 dargestellte Logik in dem lokalen Grafiktreiber 1202 die Daten aus und bestimmt, ob sie OK sind oder ob sie repariert werden müssen. Falls die Daten als OK betrachtet werden, werden sie an den OS-Kernel 1204 weitergeleitet. Falls nicht, werden sie in einem Datenreparaturblock 1220 repariert, bevor sie an den OS-Kernel 1204 weitergeleitet werden.
Zu diesem Zeitpunkt werden mehrere Sockets geöffnet, wie durch einen Nachrichtenaustausch 1222 dargestellt ist. Die mehreren Sockets werden dann eingesetzt, um mehrere OpenGL-Befehle und native Android-Rastergrafikbefehle parallel zu transportieren.
Wie dargestellt, gibt die Anwendung 1206 mehrere native Android-Grafikbefehle 1222 und 1223 an den lokalen Grafiktreiber 1202 aus. Die nativen Android-Grafikbefehle 1222 können OpenGL-Befehle und Anwendungsgrafikbefehle, die durch den lokalen Grafiktreiber 1202 in OpenGL-Befehle umgewandelt werden, und native rasterbasierte Grafikbefehle 1223 beinhalten, die nicht in OpenGL-Befehle umgewandelt werden können und als Rastergrafikbefehle 1226 gesendet werden, um durch die/den ferne(n) Vorrichtung/Bildschirm 1208 unter Verwendung eines Software-Rendering-Pfades gerendert zu werden.
Beim Unterstützen von Echtzeit-Grafik-Rendering wird das Senden und Verarbeiten der OpenGL-Befehle 1224 und Rastergrafikbefehle 1226 unter Verwendung eines Sequenzierungsschemas in Kombination mit Statusinformationen abgestimmt. Bei einer Ausführungsform beinhaltet jeder OpenGL-Befehl 1224, der über eine Nachricht 1228 gesendet wird, die durch die native Anwendung 1210 zu empfangen ist, eine Sequenznummer. Wie ferner durch Blöcke innerhalb der nativen Anwendung 1210 veranschaulicht ist, beinhalten andauernde Operationen, die durch die native Anwendung durchgeführt werden, das Empfangen von OpenGL-Befehlen in einem Block 1230, Gruppieren von Sequenzen von OpenGL-Befehlen in einem Block 1232 und Zusenden der gruppierten Sequenzen aus OpenGL-Befehlen an die GPU in einem Block 1234.
Die nativen Rastergrafikbefehle 1226 werden parallel mit den OpenGL-Befehlen gesendet. Diese können in Abhängigkeit davon, ob mehrere Sockets zum Transportieren der nativen Rastergrafikbefehle verwendet werden oder nicht, sequenziert werden oder nicht. Beim Empfang durch die native Anwendung 1210 werden die nativen Rastergrafikbefehle 1226 auf eine ähnliche Weise dazu gehandhabt, wie diese unter Verwendung eines softwarebasierten Rendering-Pfades auf einer Android-Hostvorrichtung gerendert werden. Jedoch gibt es einige zusätzliche Überlegungen.
Bei einem herkömmlichen Ansatz greift der Android-Grafik-Software-Rendering-Pfad auf Rastergrafikobjekte in einem lokalen Speicher zu, was bei den heutigen Hardwarefähigkeiten im Wesentlichen augenblicklich ist. Jedoch wird der Inhalt dieser gleichen Rastergrafikobjekte über den Link von dem Thrower zu dem Catcher gesendet, was eine gewisse endliche Latenz (wenngleich sehr gering) erfordert. Im Gegensatz dazu ist für OpenGL-Befehle, die keine Texturdaten enthalten (oder relativ kleine Texturen enthalten), die Latenz, die aus dem Senden der OpenGL-Befehle über den Link resultiert, im Wesentlichen nicht wahrnehmbar und bei Kombination mit hardwarebasierter Rendering-Unterstützung für OpenGL (z. B. durch eine GPU) ist die Echtzeitferngrafik-Rendering-Leistungsfähigkeit unter der Android-Thrower-Catcher-Architektur sehr gut und ist erheblich schneller als ein Screen-Casting-Ansatz, wie etwa Miracast.
Um das Timing der Anzeige des gerenderten Inhalts auf dem Catcher abzustimmen, verarbeitet SurfaceFlinger 1022 in Kombination mit dem Hardware-Composer (nicht gezeigt), wie oben beschrieben, OpenGL-Befehlsstatusinformationen, die VSYNC-Timing-Informationen beinhalten, und werden Einzelbildpuffer ausgetauscht, nachdem Ereignisse abgeschlossen wurden, wie durch einen Block 1236 dargestellt ist. Zum Beispiel wird gewünscht, dass jeder neue Einzelbildpuffer einen vollständigen Satz von Grafikinhalt enthält, wie etwa einen vollen Bildinhalt und korrekt geordnete Sequenzen von OpenGL-Befehlsinhalt, der durch die GPU gerendert wurde. Falls der Grafikinhalt eines Einzelbildpuffers unvollständig ist, wird er nicht ausgetauscht, um als der Anzeigepuffer verwendet zu werden, was dazu führt, dass der existierende Anzeigepufferinhalt mehrere Male unter Verwendung der Anzeigeauffrischrate von der/dem fernen Vorrichtung/Bildschirm 1208 angezeigt wird.
12b veranschaulicht eine alternative Implementierung für die Ausführungsform aus 12a. Bei dieser Ausführungsform wird ein einzelner Socket verwendet, um die OpenGL-Befehlssequenz über den Link zu transportieren. Die nativen Rastergrafikbefehle und/oder OpenGL-Befehlsstatusinformationen können über denselben Socket wie die OpenGL-Befehlssequenz oder über separate Sockets transportiert werden.
Windows-Grafikarchitektur
Zusätzlich zu dem Werfen von Android-Grafikinhalt können die Thrower-Catcher-Fernanzeigeschemen implementiert werden, die nativen Microsoft-Windows-Grafikinhalt werfen. Microsoft-Windows stellt einige C++/COM-APIs für Grafik bereit, wie in 13 gezeigt ist. Auf der linken Seite des Diagramms ist die alte Grafikvorrichtungsschnittstelle (GDI: Graphics Device Interface) 1300, die ursprüngliche Grafikschnittstelle für Windows. GDI+ 1302 wurde in Windows XP als ein Nachfolger für die GDI 1300 eingeführt. Auf die GDI+-Bibliothek durch einen Satz von C++-Klassen zugegriffen, der flache C-Funktionen umhüllt, wie durch die flache GDI+API 1304 dargestellt ist. Das .Net-Framework stellt auch eine verwaltete Version von GDI+ in dem System.Drawing-Namensraum bereit.
Die DirectX-APIs 1306 beinhalten Direct2D 1308, DirectWrite 1310, Direct3D 1312, Direct Graphics Intrastructure (DXGI) 1314 und einen Softwarerasterbildungselement 1316. Direct2D 1308 ist eine API für 2D-Grafik und ist der Nachfolger für sowohl GDI als auch GDI+. Direct3D 1312 wird für 3D-Grafik eingesetzt. DirectWrite 1310 ist eine Textlayout- und-Rasterbildung-Engine. Man kann entweder GDI 1300 oder Direct2D 1308 verwenden, um den gerasterten Text zu zeichnen. DXGI 1314 führt Aufgaben auf niedriger Ebene durch, wie etwa das Präsentieren von Einzelbildern zur Ausgabe. Die meisten Anwendungen verwenden DXGI nicht direkt. Stattdessen dienst es als eine Zwischenschicht zwischen dem Grafiktreiber und Direct3D. Die Windows-Grafikarchitektur beinhaltet auch eine Grafiktreiberschicht, die eine GDI-Display-Device-Interface(DDI: Anzeigevorrichtungsschnittstelle) 1318 und eine Direct-X(DX)-DDI 1320.
Obwohl GDI 1300 und GDI+ 1302 in Windows weiterhin unterstützt werden, werden Direct2D 1308 und DirectWrite 1310 für neue Programme empfohlen. In manchen Fällen kann eine Mischung der Technologien praktikabler sein. Für diese Situationen sind Direct2D 1308 und DirectWrite 1310 dazu gestaltet, mit GDI 1300 zusammenzuarbeiten.
Dieser moderne Grafikansatz dient dazu, Grafikberechnungen, die durch die Grafikverarbeitungseinheit (GPU) anstelle der CPU durchgeführt werden, wirksam einzusetzen. Moderne GPUs sind für diese Typen von Berechnung stark optimiert, die beim Rendering von Grafik verwendet werden. Allgemein ist es umso besser, je mehr von dieser Arbeit von der CPU zu der GPUI verschoben wird.
Während die GDI 1300 eine Hardwarebeschleunigung für gewisse Operationen unterstützt, sind viele GDI-Operationen an die CPU gebunden. Direct2D 1308 ist auf Direct3D 1312 geschichtet und nutzt die durch die GPU bereitgestellte Hardwarebeschleunigung vollständig aus. Falls die GPU die für Direct2D 1308 benötigten Funktionen nicht unterstützt, dann fällt Direct2D 1308 auf das Software-Rendering unter Verwendung des Softwarerasterbildungselements 1316 zurück. Insgesamt übertrifft Direct2D 1308 GDI 1300 und GDI+ 1302 in den meisten Situationen. Direct2D unterstützt auch Vektorgrafiken, die mathematische Formeln zur Repräsentation von Linienzeichnungen einsetzen. Diese Formeln hängen nicht von der Bildschirmauflösung ab, somit können sie zu willkürlichen Abmessungen dimensioniert werden. Vektorgrafiken sind insbesondere nützlich, wenn ein Bild skaliert werden muss, um unterschiedliche Monitorgrößen oder Bildschirmauflösungen zu unterstützen.
14 stellt die Windows-Display-Driver-Model(WDDM - Windows-Anzeigetreibermodell)-Architektur 1400 dar. Die Architektur ist zwischen Benutzermoduskomponenten und Kernel-Modus-Komponenten aufgeteilt, wie gezeigt ist. Die Benutzermoduskomponenten beinhalten eine Anwendung 1402 (die tatsächlich nicht Teil der WDDM-Architektur ist, sondern stattdessen Eingaben für die WDDM-Architektur bereitstellt), ein Direct3D-Laufzeitmodul 1404, einen Benutzermodusanzeigetreiber 1406, ein OpenGL-Laufzeitmodul 1408, ein Win32-GDI-Modul 1010, eine Kernel-Modus-Zugriff-Dynamik-Link-Bibliothek (DLL: Dynamic Link Library) 1412 und einen OpenGLinstallierbaren-Client-Treiber (ICD: installable Client Driver) 1414. Die Kernel-Modus-Komponenten beinhalten ein DirectX-Grafik-Kernel-Untersystem (Dxgkml.sys) 1416, ein Win32K.sys-Modul 1418 und einen Mini-DisplayPort-Treiber 1420. Dxgkml-sys 1416 beinhaltet einen DisplayPort-Treiber, einen Videospeichermanager und einen GPU-Planer.
15 zeigt eine Ausführungsform einer Windows-Grafik-Catcher-Thrower-Architektur 1500, bei der ein Windows-Grafik-Thrower 1502 native(n) Windows-Grafikbefehle und -Inhalt über einen Link zu einem Windows-Grafik-Catcher 1504 wirft. Wie in dem oberen Teil aus 15 gezeigt, beinhaltet der Windows-Grafik-Thrower 1502 die Benutzermodusgrafikkomponenten der Windows-Grafikarchitektur sollte in 14. Währenddessen beinhaltet der Windows-Catcher unter dieser Teilungsgrafikarchitekturimplementierung die Kernel-Modus-Grafikkomponenten aus 14.
Um das Werfen von nativem Windows-Grafikinhalt zu ermöglichen, beinhaltet der Windows-Grafik-Thrower 1502 einen nativen Windows-Grafik-Thrower 1508, während der Windows-Grafik-Catcher 1504 einen nativen Windows-Grafik-Catcher 1510 beinhaltet. Bei der veranschaulichten Ausführungsform ist der native Windows-Grafik-Thrower 1506 als ein virtueller Vorrichtungstreiber implementiert, der dazu konfiguriert ist, aus der Perspektive von Benutzermoduskomponenten so zu erscheinen, als arbeite er als ein herkömmlicher Windows-Grafikvorrichtungstreiber, der GDI-DDI 1318 und DX-DDI 1320 aus 13 beinhaltet. Jedoch werden eine erweiterte GDI-DDI 1318a und DX-DDI 1320a stattdessen implementiert, die dazu konfiguriert sind, den Grafikinhalt, den sie empfangen, zu einer passenden erweiterten GDI-DDI 1318b und DX-DDI 1320b auf dem nativen Windows-Grafik-Catcher 1510 weiterzuleiten. GDI-DDI 1319b und DX-DDI 1320b sind virtuelle Vorrichtungstreiber, die dazu konfiguriert sind, an die bei der Unterseite von 15 dargestellten Kernel-Modus-Windows-Grafikkomponenten anzubinden. Bei der veranschaulichten Ausführungsform ist der native Windows-Grafik-Catcher 1510 als eine Windows-Anwendung implementiert, die entweder Softwaremodule zum Implementieren einer virtuellen GDI-DDI 1318b und DX-DDI 1320b beinhaltet, oder an Softwaremodule anbindet, die separat implementiert sind (wie etwa Dienste).
16 zeigt eine andere Ausführungsform einer nativen Grafik-Thrower-Catcher-Architektur, unter der eine Windows-Thrower-Vorrichtung 1600 Android-Grafikbefehle und -Inhalt zu einer Android-Catcher-Vorrichtung 802a wirft. Bei einer Ausführungsform teilen sich die Android-Catcher-Vorrichtung 802a in 8a und 16a die gleichen Komponenten (wie auf Android-Grafik-Catching und -Rendering angewandt). Wie veranschaulicht, sind die Benutzermoduskomponenten für die Windows-Thrower-Vorrichtung 1600 die in 14 und 15 gezeigten herkömmlichen Windows-Benutzermodusgrafikkomponenten, wie oben besprochen. Ein Windows-zu-Android-Grafik-Wandler-und-Thrower 1602 wird verwendet, um Windows-Grafikbefehle und -Inhalt in entsprechende(n) Android-Grafikbefehle und Inhalt umzuwandeln und dann die (den) umgewandelten Android-Grafikbefehle und Inhalt zu werfen. Der Windows-zu-Android-Grafik-Wandler-und-Thrower 1602 beinhaltet einen erweiterten nativen Windows-Grafik-Thrower 1508a, der Dx-DDI 1320a und GDI-DDI 1318a beinhaltet. Er beinhaltet einen Windows-zu-Android-Grafikwandler 1604 einschließlich eines Direct-X-zu-OpenGL-Wandlers 1606 und eines GDI/GDI+-zu-Skia-Grafikwandlers 1608.
Wie der Name impliziert, empfängt der Direct-X-zu-OpenGL-Wandler 1606 Direct-X-Befehle, die durch DX-DDI 1320a hindurchgeleitet werden, und wandelt diese Befehle in entsprechende OpenGL-Befehle um. Ein oder mehrere verschiedene existierende Direct-X-zu-OpenGL-Wandler können zu diesem Zweck verwendet werden. Zum Beispiel kann bei einer Ausführungsform die quelloffene Direct3D-zu-OpenGL-Übersetzungsschicht von Dota 2 der Valve Corporation verwendet werden. Der Code, als „ToGL“ benannt, ist von GitHub verfügbar. Ein anderer quelloffener Direct-X-zu-OpenGL-Wandler ist von dem Grafikchiphersteller ATI Technologies verfügbar.
Der GDI/GDI+-zu-Skia-Grafikwandler empfängt GDI- und/oder GDI+-Grafikbefehle über GDI-DDI 1318 und wandelt sie in äquivalente Skia-Grafikbefehle um. Allgemein werden die GDI/GDI+-Grafikbefehle dazu neigen, einen Rasterinhalt zu betreffen, wie etwa Bilder, obwohl er auch anderen Inhalt beinhalten kann. Ein Bildinhalt basiert typischerweise für eine DDI als entweder ein Zeiger zu einem Bitmap-Inhalt, der bereits in einen Bitmap-Puffer geschrieben ist, oder einem Zeiger zu dem Bildinhalt in seiner gespeicherten Form, was typischerweise einen herkömmlichen Grafikstandard, wie etwa unter anderem JPEG, PNG. GIF usw. umfassen kann. Der Bildinhalt kann auch in einem eigenen komprimierten Format, wie etwa als eine Wavelet-basierte komprimierte Form, gespeichert werden. Manche Anwendungen, wie etwa Google Chrome, setzten intern Skia zum Rendern von Inhalt ein. Wenn diese Anwendungen auf Windows-Plattformen (wie etwa Windows 7, Windows 8.1 usw.) eingesetzt werden, werden die Skia-Befehle in Windows-Zeichenbefehle umgewandelt, die GDI/GDI+-Zeichenbefehle beinhalten können. Umwandeln in die andere Richtung (z. B. von GDI/GDI+) schließt allgemein den Umkehrprozess ein.
Der Windows-zu-Android-Grafik-Wandler-und-Thrower gibt OpenGL-befehle und Skia-Grafikbefehle (wie zutreffend) aus und wirft sie zu dem Android-Grafik-Catcher 810a auf der Android-Catcher-Vorrichtung 802a. Der Android-Grafik-Catcher 810a gibt dann die OpenGL- und Skia-Grafikbefehle an das Android-Grafik-Rendering-Untersystem 706Ra auf eine ähnliche Weise weiter, wie oben unter Bezugnahme auf 8a besprochen ist.
Die 17a und 17b zeigen alternative Ausführungsformen zum Einrichten eines Links und Werfen nativer (nativem) Android-Grafikbefehle und -Inhalt gemäß der Ausführungsform aus 16. Wie durch ähnlich nummerierte Komponenten in 12a, 12b, 17a und 17b dargestellt, sind viele der Komponenten in 17a und 17b jenen ähnlich, die oben unter Bezugnahme auf 12a und 12b besprochen sind. Zusätzlich zu diesen Komponenten zeigt 17a einen Windows-zu-Android-Grafik-Wandler-und-Thrower 1602, der einen Windows-zu-Android-Grafikwandler 1604, einen OS-Kernel 1700, eine Windows-Anwendung 1702 und Windows-Grafikbefehle 1704 einschließlich DirectX-Befehlen 1706 und GDI/GDI+-Befehlen 1708 beinhaltet.
Der Windows-zu-Android-Grafikwandler ist dazu konfiguriert, Direct-X-Befehle 1706 in OpenGL-Befehle 1710 und GDI/GDI+-Befehle 1708 in native Android-Rastergrafikbefehle 1712 (z. B. Skia-Befehle) auf die oben unter Bezugnahme auf 16 beschriebene Weise umzuwandeln. Die OpenGL-Befehle 1710 und die nativen Android-Rastergrafikbefehle werden dann an die/den ferne(n) Vorrichtung/Bildschirm 1208 auf eine jener oben für 12a und 12b beschriebene ähnliche Weise gesendet, wobei die Ausführungsform aus 17a mehrere Sockets verwendet, um die OpenGL-Befehle 1710 zu transportieren, während die Ausführungsform aus 17b einen einzigen Socket verwendet.
Als eine Alternative dazu, dass die Windows-zu-Android-Grafikbefehl- und - Inhaltumwandlung auf dem Thrower erfolgt, werden bei einer Ausführungsform diese Operationen durch den Catcher durchgeführt. Ein Implementierungsbeispiel dieses Ansatzes ist in 18 gezeigt, wobei eine Windows-Thrower-Vorrichtung 1800 DirectX- und GDI/GDI+-Grafikbefehle und -Inhalt zu der Android-Catcher-Vorrichtung 1802 wirft, die einen Windows-zu-Android-Grafik-Wandler-und-Catcher 1804 beinhaltet. Diese Komponente beinhaltet den gleichen Windows-zu-Android-Grafikwandler 1604 wie in 16 gezeigt, mit der Ausnahme, dass sich nun der Windows-zu-Android-Grafikwandler auf der Catcher-Vorrichtung statt auf der Thrower-Vorrichtung befindet.
Kleine-Daten-Engine
Es gibt verschiedene Bereiche, in denen sich Sensoren und Vorrichtungen etablieren oder eine Etablierung erwartet wird. Mit Googles Übernahme von Nest, der Heimautomatisierungsfirma, können wir erwarten, dass unser Heime irgendwann vollautomatisiert und mit den Clouds verbunden sein werden. Gesundheit ist ein anderer großer Bereich, in dem Wearable-Sensortechnologien etabliert werden. Heutzutage sind die meisten dieser Wearables mit Gesundheitsfokus entweder direkt mit der Cloud verbunden oder sind auf ein assoziiertes Smartphone für einen Teil ihrer Berechnung und Analyse und als ein Konnektivitätsmedium zu der Cloud angewiesen. Automotives IVI und Fahrzeugeffizienz sind ein anderer Bereich, in dem immer mehr Firmen eine Cloud-Konnektivität ankündigen und anbieten, um verschiedene kritische Parameter in Echtzeit zu überwachen (Verkehr, fahrzeugkritische Betriebssensoren) und Benutzern mit verschiedenen Angeboten und Versorgern helfen. Einzelhandel und Bestellungsbezahlung ist ein anderer großer Bereich für Datensammlung und -Analyse.
Obwohl viele Staaten daran arbeiten, eine Standarddatenschutzrichtlinie für Cloud-Berechnung-basierte Organisationen zu verfassen, besteht nach wie vor ein Mangel des Bewusstseins über und der Implementierung dieser Richtlinien (selbst wenn sie existieren). Sensoren und Cloud-Konnektivität weisen bedeutende Privatsphären-, Flexibilitäts- und Gerechtigkeitseinschränkungen auf. Die derzeitigen Industrieansätze haben Funktionalität gegenüber Privatsphäre und Sicherheit bevorzugt.
Das Sammeln von Daten von Sensoren und Vorrichtungen auf eine sichere Weise ist eine herausfordernde Aufgabe. Heutzutage schieben die meisten der Vorrichtungen ihre Daten entweder zu irgendeinem zentralen Punkt (wie etwa einem assoziierten Smartphone, Heim-Gateway usw.) unter Verwendung einer Drahtlosverbindung (z. B. BLUETOOTH) oder durch direktes Sprechen zu der Cloud (z. B. Google Glass) unter Verwendung eines Mobilnetzes. Ein großer Teil des Datentransfers erfolgt in nichtverschlüsselter Form. Eine direkte Cloud-Konnektivität erfordert einen hohen Leistungsverbrauch von der Vorrichtung. Außerdem erfordert sie, dass jede Vorrichtung eine einzigartige Internetverbindung aufweist. Andererseits erfordert die Zentralpunktverbindung (Gateway-Modell) nur eine Internetverbindung für mehrere Vorrichtungen und kann ein Niederleistungssensornetz einsetzen, um sich mit dem Gateway zu verbinden, entsprechend wird weniger Leistung je Vorrichtung verbraucht. Eine Verschlüsselung bringt eine Leistungs-, Leistungsfähigkeits- und Kostenbelastung für die Sensoren mit sich. [Wir haben Hardwareverschlüsselung-Engines für iA entwickelt und glauben, dass eine Lichtgewichtsvariante mit vereinfachter Schlüsselstruktur für eine Sensordatensicherheit notwendig ist, dies ist Teil des Kleine-Daten-Engine-Vorschlags.]
Der Großteil der Daten wird aus zwei Gründen in der Cloud gespeichert: universeller Zugriff und Datengewinnung. In letzter Zeit wurden mehr Fragen über den Datenschutz der Daten gestellt, wie etwa: (a) wer kann die Daten verwenden; und (b) welche Daten können von der Außengemeinschaft gesehen werden. Manche dieser Daten sind sehr heikel und eine Ausnutzung kann zu Missbrauch und großem finanziellen Verlust führen. Gesundheitsdaten eines Individuums sind ein Beispiel für manche der privatesten Daten, die eine sorgfältige Zugriffskontrolle benötigen. Die größte Herausforderung für die medizinische Industrie besteht darin, die Gesundheitsdaten zu gewinnen, ohne sie zu sehen. Manche Vorschläge für eine anonyme Datengewinnung wurden sowohl von wohl bekannten als auch von weniger bekannten Firmen und Organisationen gemacht. Jedoch musst die Effektivität dieser Systeme immer noch validiert werden.
In den meisten dieser Fälle müssen nicht alle der Daten in nichtverschlüsselter Form in den öffentlichen Bereich eingegeben werden. Zum Beispiel wollen Fahrer von Kraftfahrzeugen ihre Fahrtgeschwindigkeitsaufzeichnungen und Autowartungsaufzeichnungen nicht mit dem öffentlichen Bereich teilen. Viele Leute sind abgeneigt, ihre Markenvorzüge zu teilen, da sie erkennen, dass dieser Typ von Informationen oft von Vertriebsfirmen und dergleichen missbraucht wird. Gleichermaßen wollen Leute nicht ihre Ernährungs- und Lebensmittelpräferenzen mit der Öffentlichkeit teilen. Die Kleine-Daten-Engine behandelt dieses Problem auf eine einzigartige Weise, durch lokale sichere Verarbeitung.
Datenverarbeitung kann in zwei Kategorien unterteil werden: Zuerst die Verarbeitung, die die Sensordaten mit dem Rest der Gemeinschaftsdaten kombiniert und dann einige interessante und beachtliche Informationen aus ihnen gewinnt. Zum Beispiel: wie die eigene Elektrizitätsrechnung im Vergleich zu der von den Nachbarn aussieht, die mutmaßlich das gleiche Wetter erleben. Zweitens die Integration neuer lokaler Daten mit zuvor etablierten Einzelhandels-, Gesundheits-, Automobil- und Heimdaten.
Kombinieren von kleinen Daten und Integrieren ist ein Teil der Datenverarbeitung, die Verarbeitung mit großen Daten ein anderer. Eine Verarbeitung von großen Daten kann ferner in zwei Kategorien unterteilt werden: erstens lokales Kombinieren und Verarbeiten. Zweitens Kombinieren mit öffentlichen Daten und Verarbeiten. In Abhängigkeit von der Benutzerpräferenz kann man sich für lokales Verarbeiten an lokalen privaten Daten und Cloud-basiertes oder fernes Verarbeiten für öffentliche Daten entscheiden. Unglücklicherweise stellen momentane Systeme eine solche Flexibilität nicht bereit. Die gesamte Verarbeitung erfolgt in der Cloud. Die Kleine-Daten-Engine wird ermöglichen, dass Benutzer sich für lokales Verarbeiten und Privatsphäre entscheiden, während eine Offene-Innovation-Sandbox verwendet wird.
Datenempfehlungen können in beliebiger Form, wie Angebote, Vorschläge, Warnungen usw., erfolgen, um das Leben von Verbrauchern angenehmer zu gestalten. Datenempfehlungen können für ein Individuum oder auf großer Ebene für ein Gebiet oder für eine Gemeinschaft verwendet werden. Datenempfehlungen können Individuen oder interessierten Käufern verkauft werden. Die große Frage ist, ob Individuen ihre Empfehlungsangebote anderen zeigen und sie sie einsetzten lassen wollen. Welche Art von Diskretion kann ein Endbenutzer dabei haben? Welche Art von Diskretion können Individuen haben? Möglicherweise könnte es wünschenswert sein, einen Teil der Informationsgewinnung zu erlauben, um sie der Außengemeinschaft zu zeigen, die indirekt Individuen oder Gruppen helfen kann, während es wünschenswert sein kann, andere Teile niemals mit der Öffentlichkeit zu teilen. Zum Beispiel will jemand seine unterdurchschnittliche Fahrerfahrung im Vergleich zu der Außengemeinschaft nicht teilen, will aber zur gleichen Zeit seine überdurchschnittliche Autowartungsaufzeichnung teilen.
Momentane Datenarchitekturen präsentieren zu viele Endbenutzerbedenken und andere Einschränkungen. Vielmehr sollte ein ideales Datenökosystem Folgendes bereitstellen:
Ein hoch flexibles und anpassbares System vom Blickpunkt aller interessierten Parteien.

Endbenutzer können den Privatsphäreknopf basierend auf unterschiedlichen Daten ändern.
Benutzer können ändern, welche Cloud sie speichern wollen und wo sie eine Datenverarbeitung (z. B. lokale oder ferne Verarbeitung) wollen.

Ein sehr sicheres und zuverlässiges System, das vertrauenswürdig ist.

Bevorzugt könnten alle Parteien einander basierend auf der Systemgestaltung des Informationsflusses vertrauen.

Gleichwertige Interessensvertreter sämtlicher Parteien, um zu vermeiden, dass irgendeiner von ihnen zu viel Aufmerksamkeit bekommt.

Benutzer halten ihre Daten und können sie an irgendjemanden verkaufen, unabhängig davon, wessen Sensoren und Vorrichtung in dem persönlichen Ökosystem installiert sind oder ob eine lockere Bindung zwischen Vorrichtung und Cloud besteht.
Basierend auf Benutzerpräferenzen können Daten gespeichert, gewonnen werden und können Informationen an mehrere Käufer ohne Beschränkung von der Benutzerseite verkauft werden.

Das optimale Nutzungsniveau der verbundenen Ressourcen in das System, um die Kosten herabzubringen.

Reduzieren der erforderten Internetverbindung und dementsprechend der Leistung zum Übertragen von Daten.
Am bevorzugtesten eine Vorrichtung zum Verwalten sämtlicher Sensoren in verschiedenen Bereichen.

Vermeiden von Missbrauch der gewonnenen Daten auf eine direkte oder indirekte Weise.

Sämtliche Daten sollten durch irgendeine zentrale Vorrichtung hindurchgehen, die der Benutzer besitzt und von diesem mit strikter Sicherheit und bevorzugter konfigurierter Sicherheit, Flexibilitätsoptionen gewartet wird.

Die Kleine-Daten-Engine (LDE) ist ein Manager für ein Sensor-Cloud-Konnektivitätsökosystem des Benutzers, der Datensammlung, Datenspeicherung, Datenverarbeitung und Datenempfehlung verwaltet. Sie ist eine zentrale Vorrichtung, die ein Individuum besitzt und pflegt. Die Engine ist hinsichtlich Privatsphäre und Kompatibilität vollständig anpassbar. Basierend auf den benötigten Funktionen und einer Benutzeranpassungskonfigurationsdatenspeicherung können eine Verarbeitung und Empfehlung auf eine von einem Benutzer bevorzugte definierte Weise gleichzeitig durch die LDE und in der Cloud erfolgen oder können vollständig lokal in der LDE erfolgen. Die LDE respektiert die Endbenutzerpräferenzen und -Diskretion. Sie ermöglicht auch, dass der Benutzer sich mit vielfältigen Clouds als eine Datenspeicherung, Datengewinner oder Informationskäufer verbindet, und treibt dementsprechend den fairen Wettbewerb an, um eine optimale Ressourcennutzung und eine günstige Lösungsbereitstellung für die Gemeinschaft sicherzustellen.
Die LDE-Architektur ist dazu gestaltet, Benutzern die Flexibilität hinsichtlich Funktionen, Verwaltung und Privatsphäre des Systems zu geben. Dies wird durch eine Engine unterstützt, um sämtliche Sensoren und Vorrichtungen eines Benutzers zu verwalten. Die Architektur ist auch sehr flexibel hinsichtlich Privatsphäre und Funktionen, wodurch ermöglicht wird, dass Benutzer die LDE gemäß ihren Bedürfnissen maßschneidern. Die LDE unterstützt auch Offline-Funktionen und -Funktionalität, wodurch ermöglicht wird, dass sie in nichtverbundenen Umgebungen verwendet wird.
19 zeigt eine Übersicht auf hoher Ebene ausgewählter Komponenten in einer LDE-Architektur 1900 gemäß einer Ausführungsform. Beispielhafte Datensätze sind oberhalb der Architektur 1900 dargestellt, einschließlich Gesundheitspflegedaten 1902, Heimdaten 1904, Internetgeschmacksdaten 1906, Einkaufsmusterdaten 1908 und Reisedaten 1910. Es versteht sich, dass diese lediglich einige Typen von Daten sind, die durch eine LDE gespeichert werden können.
Wie durch lokales Integrieren 1912 gezeigt, sind sämtliche der Daten, die den Gesundheitspflegedaten 1902, Heimdaten 1904, Internetgeschmacksdaten 1906, Einkaufsmusterdaten 1908 und Reisedaten 1910 entsprechen, an einem Ort, z. B. auf der einen Vorrichtung, integriert. Eine lokale Analyse kann an den Daten durch einen Lokales-Analysieren-Block 1914 durchgeführt werden, was zu einer oder mehreren persönlichen Empfehlungen führen kann, wie unten ausführlicher beschrieben ist. Ein Benutzer kann auch wählen, die ausgewählten Daten mit anderen und/oder verschiedenen Datendiensten, wie etwa Cloud-gehosteten Datendiensten, zu teilen. Dies wird durch einen Block 1916, der als „Minimales Veröffentlichen“ bezeichnet ist, und einen Block 1918, der als Analysieren in der Cloud bezeichnet ist, unterstützt.
20 zeigt eine Architektur 2000 für den Analysestapel der LDE in Bezug auf das Verarbeiten von Sensordaten. Die Architektur 2000 beinhaltet Rohsensordaten 2002, Sensordatenbibliotheken 2004, LDE-Bibliotheken 2006. Die LDE-Bibliotheken ermöglichen eine Integration mit Drittanbieteranwendungen, einschließlich Einzelhandel-Apps 2008, Heim-Apps 2010 und Gesundheit-Apps 2012, die jeweils als Einzelhandelsempfehlungen 2014, Heimempfehlungen 2016 bzw. Gesundheitsempfehlungen 2018 bereitstellend gezeigt sind.
Allgemein kann die LDE-Architektur-Datensammlung von den Sensoren auf andauernder Echtzeitbasis und/oder periodisch (z. B. über Umfragen oder dergleichen) durchgeführt werden. Bei einer Ausführungsform hängt dies von der Nähe der LDE zu den Sensoren ab. Zum Beispiel kann ein Benutzer die Daten von Automobilsensoren, während er sich in dem Auto befindet, und von zu Hause abrufen, während er sich zu Hause befindet. Ein gegebener Sensor wird allgemein eine minimale lokale Speicherung für Rohdaten oder halbverarbeitete Daten in Abhängigkeit von dem Sensortyp beinhalten. Bei einer Ausführungsform wird jeder Sensor mit der LDE unter Verwendung eines Authentifizierungs- und Autorisierungsprotokolls vorregistriert und werden heikle Daten in einer verschlüsselten Form an die LDE übertragen.
Bei einer Ausführungsform beinhaltet die LDE 1 TB oder mehr an lokaler Speicherung in der Vorrichtung selbst. Allgemein besteht kein Bedarf, die Rohsensordaten auf der LDE zu speichern; stattdessen sind nur die verarbeiteten Daten zu speichern. Zum Beispiel wird eine Echtzeitbestimmung von über den Tag hinweg verbrannten Kalorien von einer Kaloriesensorvorrichtung nicht gespeichert, stattdessen kann die LDE die pro Tag oder Stunde verbrannten Kalorien speichern. Die LDE kann auch als ein Cache in einer Gesamtdatenspeicherungsarchitektur, einschließlich Cloud-basierter Speicherung, fungieren. Zum Beispiel werden Daten, die durch die LDE von Sensoren gesammelt werden, verschlüsselt und an die von dem Benutzer bevorzugte Cloud gesendet und der Verschlüsselungsschlüssel kann in einer sicheren Cloud über einen sicheren Schlüsselbund eines Benutzers oder andere wohlbekannte Techniken gespeichert werden.
Bei einer Ausführungsform beinhaltet die LDE eine Hardware-Analyse-SoC-Engine und eine wohldefinierte API, auf der ein App-Ökosystem aufgebaut werden kann. Wie in 19 gezeigt, kann die Datenverarbeitung in zwei Teile, lokal und fern (in der Cloud), in Abhängigkeit von der Benutzerkonfiguration, Internetverbindung und dem Anfragetyp aufgeteilt werden. Eine öffentliche Datenverarbeitung kann in der Cloud oder lokal erfolgen. Eine private Datenverarbeitung erfolgt immer lokal. Eine lokale Verarbeitung beinhaltet eine Datenintegration von verschiedenen Sensoren und das Durchführen einer Analyse an integrierten Daten. Zum Beispiel können, während man nach einen Ort zum Mittagessen sucht, nahgelegene Restaurants aus der öffentlichen Cloud abgerufen werden, während die Ernährungspräferenz und Fahrgeschwindigkeit lokal aus privaten Daten abgerufen werden können, und Empfehlungen können erzeugt werden, indem identifiziert wird, welche Restaurants geeignet sind (um die Ernährungspräferenzen zu erfüllen) und wie lange es dauert, sie zu erreichen. Als eine Mobilvorrichtung weist die LDE den Vorteil auf, mit mehreren Bereichen zu reden, und ist dazu in der Lage, Informationen viel besser als andere existierende Lösungen zu synthetisieren.
Ähnlich der Datenverarbeitung kann eine Datenempfehlung aus einer öffentlichen Cloud oder aus der LDE entnommen werden oder sie kann eine Mischung aus beidem sein. Basierend auf dem Anfragetyp wird die LDE die Verarbeitung zu der Cloud oder lokal zur Analyse verschieben und die Empfehlung aus der Cloud nehmen und sie mit lokalen Empfehlungsdaten integrieren und sie an den Benutzer senden.
21 zeigt eine Software-API 2100 für die LDE gemäß einer Ausführungsform. In ihrem Kern beinhaltet die Software-API 2100 eine Integrator-und-Analyse-Engine 2102, die Eingabeeinstellungen 2104, wie etwa Privatsphäreeinstellungen, Speicherungseinstellungen, Cloud-Einstellungen und Analyseeinstellungen, empfängt. Die Integrator-und-Analyse-Engine 2102 empfängt eine Eingabe von Heimsensoren 2106, Gesundheitssensoren 2108, Autosensoren 2110 und Einzelhandelssensoren 2112, wobei außerdem angemerkt wird, dass die Integrator-und-Analyse-Engine Eingaben von anderen Typen von Sensoren (nicht gezeigt) empfangen kann. Die Integrator-und-Analyse-Engine 2102 liefert Eingaben an eine Heim-API 2114, eine Gesundheit-API 2116, eine Auto-API 2118 und eine Einzelhandel-API 2120. Jede dieser APIs stellt eine Programmierschnittstelle mit einer verwandten Drittanbieteranwendungsklasse bereit, die wiederum assoziierte Empfehlungen bereitstellt. Zum Beispiel beinhalten die Drittanbieteranwendungen Heim-Apps 2122, Gesundheit-Apps 2124, Auto-Apps 2126 und Einzelhandel-Apps 2128, die jeweils eine jeweilige Empfehlung vornehmen, die als Heimempfehlung 2130, Wearable-Empfehlung 2132, Autoempfehlung 2134 und Einzelhandel-Empfehlung 2136 dargestellt sind.
22 veranschaulicht ein persönliches Analysenutzungsmodell 2200 gemäß einer Ausführungsform. Das persönliche Analysenutzungsmodell 2200 ist als eine Tabelle angelegt, die eine Einzelhandelsspalte 2202, eine Heimspalte 2204 und eine Gesundheitsspalte 2206, eine Erfassen-Zeile 2208, eine Integrieren-Zeile 2210 und eine Empfehlen-Zeile 2212 beinhaltet. Der Prozessfluss bewegt sich von dem Empfangen von Sensordaten (d. h. wie in der Erfassen-Zeile 2208 dargestellt), Integrieren der Daten (Integrieren-Zeile 2210) und Erzeugen einer Empfehlung (Empfehlen-Zeile 2212) abwärts. Beispielsweise kann das Analysemodell für die Gesundheit eines Benutzers Erfassen des Pulses, der Hauttemperatur, der Bewegungsaktivität (z. B. Gehen, Fahrradfahren usw.), Schlaf und Ernährungsinformationen des Benutzers beinhalten. Die Informationen werden mit Eingaben aus der Einzelhandelsspalte 2202 und der Heimspalte 2204 integriert und verarbeitet, um einen Kalender, Speiseoptionen, Heimumgebungsdaten und Wetterdaten zu produzieren. Empfehlungen werden dann bereitgestellt, einschließlich empfohlener Übungen, Essensverbesserungen und regelmäßiger Aktivitäten.
23 zeigt eine Implementierungsarchitektur 2300, die eine weitere Integration von oben besprochenen Komponenten veranschaulicht. Die Implementierungsarchitektur 2300 beinhaltet Heimsensoren 2302, Wearable-Sensoren 2304, Autosensoren 2306, Einzelhandelssensoren 2308, sichere Datensammler 2310, 2312, 2314 und 2316, sichere Datenspeicherung 2318, einen Datenintegrator und Kombinieren 2320, Prozessdaten 2322, eine Analyse-Engine 2324, eine Heimempfehlung 2326, eine Wearable-Empfehlung 2328, eine Autoempfehlung 2330, eine Einzelhandelsempfehlung 2332, eine Heim-API 2334, eine Wearable-API 2336, eine Auto-API 2338, eine Einzelhandel-API 2340, Drittanbieteranwendungen 2342 und eine Cloud 2344.
Prozessdaten 2322 repräsentieren Daten, die durch verschiedene Verarbeitungssensoreingaben und andere Eingabedaten erzeugt werden. Wie oben unter Bezugnahme auf 19 besprochen, kann ein Benutzer selektiv den Teil der Prozessdaten 2322, den der Benutzer wünscht, an die Cloud 2344 veröffentlichen. Dies ermöglicht eine Cloud-basierte Analyse der Daten, die durch die Analyse-Engine 2324 empfangen werden. Empfehlungen einschließlich einer oder mehrerer einer Heimempfehlungen 2326, Wearable-Empfehlung 2328, Autoempfehlung 2330 und Einzelhandelsempfehlung 2332 werden durch die Analyse-Engine 2324 erzeugt, entweder vollständig lokal oder kombiniert mit Cloud-basierten Empfehlungen.
Beispielhafte Rechnerkartenverpackung
Gemäß weiteren Aspekten der Ausführungsformen kann eine Prozessorplatine innerhalb eines Gehäuses angeordnet sein, wie durch die Rechnerkarte 2400 aus 24a, 24b und 24c veranschaulicht ist. Die Verpackung für die Rechnerkarte 2400 beinhaltet ein Gehäuse, das eine Gehäusehülle 2402 umfasst, an der eine Abdeckungsplatte 2404 montiert ist. Wie in 24b gezeigt, ist eine Prozessorplatine 2500 innerhalb des Gehäuses angeordnet und beinhaltet einen Randverbinder 2502, der extern zugänglich (d. h. nicht innerhalb des Gehäuses angeordnet) ist. Wie in 24c gezeigt, beinhaltet eine Rechnerkarte 2400 bei einer Ausführungsform eine Taste 2406 und optionale LEDs 2408. Bei einer Ausführungsform ist die Rechnerkarte 2400 innerhalb des Backpacks 2402 angeordnet und sein Randverbinder 2502 ist mit einen Gegenverbinder gekoppelt der innerhalb des unteren Teils des Backpacks 2402 (nicht gezeigt) angeordnet ist. Bei einer alternativen Konfiguration kann eine Rechnerkarte in die Rückseite eines Backpacks oder eine ähnliche Vorrichtung eingefügt werden, wodurch ermöglicht wird, dass die Rechnerkarte aus dem Backpack entfernt wird, ohne dass die Entfernung des Android-Telefons aus dem Backpack erforderlich ist. Bei verschiedenen Optionen kann ein Backpack verschiedene Ressourcen beinalten, wie etwa eine Batterie und eine assoziierte Batterieleistungsversorgung und eine Ladeschaltungsanordnung. Außerdem kann die Rechnerkarte selbst eine Batterie beinhalten.
25 zeigt eine Ausführungsform einer Prozessorplatine 2500, die in der Rechnerkarte 2400 verwendet wird. Die Prozessorplatine 2500 beinhaltet einen Randverbinder 2502, der verwendet wird, um ein E/A-Signal und eine Spannungsschnittstelle zu anderen Komponenten bereitzustellen. Die Prozessorplatine 2500 beinhaltet ferner einen SoC 2504, ein Paar von DRAM-Chips 2506 und 2508, eine nichtflüchtige Speicherung, die einen Flash-Chip 2510 umfasst, einen PMIC-Chip (PMIC: Power Management Integrated Circuit - integrierter Leistungsverwaltungsschaltkreis) 2512 und einen BIOS-Chip 2514. Außerdem würde eine Prozessorplatine verschiedene andere Komponenten und Schaltkreiselemente beinhalten, die einem Fachmann wohlbekannt sind und daher nicht separat identifiziert sind.
26 stellt eine Ausführungsform einer Docking-Station 2600 dar, in der eine Rechnerkarte 2400 installiert werden kann, um zu ermöglichen, dass die Rechnerkarte mit Leistung versorgt wird (für Rechnerkarten, die keine eingebauten Batterien haben) und mit einem Hostcomputer über einen USB-Link kommuniziert. Die Docking-Station 2600 beinhaltet eine Docking-PCB 2602, einen Docking-Verbinder 2604, eine Batterie 2606, einen USB-Verbinder 2608, der mit der Docking-PCB 2602 über ein Drehgelenk 2610 verbunden ist, eine Taste 2612 und eine LED 2614. Die Docking-Station 2600 ist so konfiguriert, dass, wenn die Rechnerkarte 2400 in einer geschlitzten Öffnung an der Oberseite der Docking-Station installiert ist, ihr Randverbinder 2502 mit dem Docking-Verbinder 2604 zusammengefügt wird.
Eine Rechnerkarte kann als eine einzige Vorrichtung dienen, die einen Zugriff auf Daten und Anwendungen auf einem breiten Bereich von Vorrichtungen bereitstellt. Ein Beispiel hierfür ist in 27 veranschaulicht, wobei eine Rechnerkarte 2400 vom Typ Eine-Vorrichtung 2700 dazu konfiguriert ist, eine Eine-Vorrichtung 2700 zu implementieren, die auf Daten und Anwendungen von einem Laptop-Computer 2702, einem Smartphone 2704, einem Musikabspieler 2706, einer Computerbrille 2708, einem Smart-Fernseher 2710, einem Tablet 2712, einem Herzfrequenzüberwachungsgerät 2714, einer Smartwatch 2716 und einem Desktop-Computer 2718 zugreifen kann. Wie oben beschrieben, können ausgewählte Daten und Berechnungen privat gemacht werden, wodurch eine Daten-„Sandbox“ um solche Daten herum bewirkt wird.
Allgemein kann eine Rechnerkarte dazu konfiguriert sein, mit einer beliebigen der vorausgehenden Vorrichtungen über einen drahtgebundenen Link oder einen drahtlosen Link zu kommunizieren. Beispielsweise sind zwei Typen von drahtlosen Verbindungen in 28a und 28b veranschaulicht. In 28a ist eine Rechnerklarte 2400 in einer Docking-Station 2600 installiert, die mit einem Laptop-Computer 2800 über ein USB-2.0- oder -3.0-Kabel 2802 verbunden ist. Die Docking-Station 2600 kann durch einen Laptop-Computer 2800 über eine USB-Leistung mit Leistung versorgt werden oder es kann ein optionaler Leistungsadapter 2804 bereitgestellt werden. In 28b ist eine Rechnerklarte 2400 in einer Docking-Station 2600 installiert, die mit einem Monitor oder Fernseher 2806 über ein HDMI-Kabel 2808 verbunden ist. Der Monitor oder Fernseher 2806 kann Benutzereingaben über verschiedene Typen von Vorrichtungen, wie etwa eine drahtlose Tastatur 2810, empfangen. Allgemein kann die Docking-Station 2600 durch eine eingebaute Batterie oder einen optionalen Leistungsadapter 2804 mit Leistung versorgt werden.
29a und 29b stellen zwei Beispiele für Drahtlosverbindungen zwischen einer Rechnerkarte und einer Anzeigevorrichtung dar. In 29a ist eine Rechnerkarte 2400 über einen Drahtlos-Link 2902 mit einem Tablet 2900 verbunden. In 29b ist eine Rechnerkarte 2400 über einen Drahtlos-Link 2906 mit einem Smart-Fernseher 2904 verbunden. Allgemein können Drahtlos-Links unter Verwendung existierender oder zukünftiger Protokolle, einschließlich unter anderem Wi-Fi (jede Version von IEEE 802.11) und BLUETOOTH (jede Version), implementiert werden. Bei manchen Ausführungsformen kann ein Wi-Fi-Direct(WFD)-Link verwendet werden, wie etwa ein Peer-to-Peer-WFD-Link. Bei anderen Ausführungsformen kann eine INTEL®-WiDi- oder -WiGig-Verbindung verwendet werden.
Gemäß weiteren Aspekten mancher Ausführungsformen ist ein einheitliches DatenSpeicherung-und-Zugriff-Schema bereitgestellt, das ermöglicht, dass ein Benutzer einer Rechnerkarte auf Daten von einer Vielzahl von Quellen zugreift und dann diese Daten in einheitlichen Ordnern oder Behältern präsentiert werden. 30 zeigt ein Implementierungsschema, um dieses Ziel zu ermöglichen. Wie veranschaulicht, zeigt 30 ein erstes Profil, das ein Android-Profil umfasst, und ein zweites Profil, das ein Windows-8.1- oder Chrome-Profil umfasst. Die Android-Profil-Komponenten beinhalten einen Datei-Browser 3000 in einem Benutzerraum, der mit einem Datei-Caching-Agenten 3002 kommuniziert, der an ein Dateisystem in dem Benutzerraum (FUSE) 3004 anbindet. Das Windows-8.1- oder Chrome-Profil beinhaltet einen Windows-Dateibeobachter-Dienst 3006 in dem Benutzerraum, der mit einem Dateiabfängertreiber 3008 in dem Systemraum interagiert und mit dem Datei-Browser 300 über einen USB-Socket 3010 kommuniziert. Eine Windows-Explorer-Dateianwendung 3012 ist ebenfalls in dem Benutzerraum dargestellt.
Der Datei-Caching-Agent 3002 ist dazu konfiguriert, Dateien zu cachen, die in einer Cloud-basierten Speicherung, wie etwa durch eine Dropbox-Cloud 3014 und eine Google-Drive-Cloud 3016 dargestellt, gespeichert werden. Bei einer Ausführungsform sind Verschlüsselungsdienste durch McAfee bereitgestellt, wie durch eine McAfee-Cloud 3018 dargestellt ist. Unter diesem Schema werden Cloud-gehostete Daten unter Verwendung eines Verschlüsselungsschlüssels verschlüsselt, der von der McAfee-Cloud 3018 unter Verwendung eines sicheren Authentifizierungsschemas erhalten wird, unter dem nur jemand mit ordnungsgemäßen Anmeldedaten auf diese Daten zugreifen kann. Zur gleichen Zeit kann der Datei-Caching-Agent 3002 die Rechnerkartendaten (einschließlich Daten, die von anderen Vorrichtungen empfangen wurden) sichern, wodurch ermöglicht wird, dass der Benutzer die Daten für eine Rechnerkarte wiederherstellt, sollte die Rechnerkarte verloren oder kaputt gehen.
31 zeigt eine Datenverwaltungsarchitektur, die eine sichere vorrichtungsunabhängige Datenverwaltungsplattform 3100 beinhaltet, die einen Zugriff auf mehrere Datenquellen 3102 ermöglicht und mehrere Verwendungsmodelle einschließlich neuer Verwendungen 1104, Privatsphärenverwaltung 3106, intelligenten Teilens 3108, Datenorganisation über Quellen hinweg 3110 und quellenunabhängigen Datenzugriffs 3112 unterstützt. Die sichere vorrichtungsunabhängige Datenverwaltungsplattform 3100 unterstützt verschiedene Funktionen, einschließlich Datei-Streaming 3114, Verwendungsinstrumentation 4116, Sicherheitsmerkmalen 3118, Benutzer-On-Boarding 3120, V2+-Metadatenechtzeitsuche 3124, Suchen und Filtern 3126 und Auto-Verknüpfung 3128.
Die sichere vorrichtungsunabhängige Datenverwaltungsplattform 3100 ist dazu konfiguriert, zu ermöglichen, dass Benutzer ihre Daten unabhängig von dem Standort schnell finden und sicher auf diese zugreifen, verwalten, und auf einer beliebigen Vorrichtung teilen, wie etwa unter anderem Smartphones 310, Tablets 3132, Laptops 3134, Desktopcomputern 3136, Cloud-Diensten und anderen Smart-Vorrichtungen. Zum Beispiel kann auf die Daten eines Benutzers auf Cloud-Diensten, wie etwa Facebook, Dropbox, Amazon, flickr, iCloud, Instagram und Gmail, sicher zugegriffen werden und können sie auf eine einheitliche Weise präsentiert werden (wie etwa Integrieren von E-Mail von mehreren Konten in einer einzigen Ansicht).
32 und 33 zeigen Implementierungsbeispiele einer Rechnerkarte 100 und einer Android-Hostvorrichtung 3202. Eine Rechnerkarte 3200 beinhaltet ein Prozessor-SoC 3204, mit dem ein Speicher 3206 und eine USB-Schnittstelle 3208 operativ gekoppelt sind. In Abhängigkeit von ihrer (ihren) beabsichtigten Implementierung(en) kann die Rechnerkarte 3200 null oder mehr Drahtloskommunikation(WCOMM)-Schnittstellen beinhalten, wie durch eine Wi-Fi(IEEE 802.11)-Schnittstelle 3210 und eine BLUETOOTH®-Schnittstelle 3212 dargestellt ist.
Die Android-Hostvorrichtung 3202 ist allgemein repräsentativ für verschiedene Typen von Vorrichtungen, die ein Android-Betriebssystem verwenden. Solche Vorrichtungen beinhalten unter anderem Mobiltelefone, Tablets, Netbooks (z. B. Chromebooks) und Wearable-Vorrichtungen, wie etwa Google Glass und Android-Armbanduhren. Zu veranschaulichenden Zwecken ist die Android-Hostvorrichtung als ein Prozessor-SoC 2314 einschließlich einer GPUI 3216, die operativ mit einem Speicher 3218 gekoppelt ist, eine USB-Schnittstelle 3220, eine Wi-Fi-Schnittstelle 3222 und eine BLUETOOTH®-Schnittstelle 3224 beinhaltend dargestellt. Eine Android-Hostvorrichtung kann ferner andere Drahtloskommunikationsschnittstellen, wie etwa ein Mobilfunkkommunikationssystem (z. B. ein LTE-Mobilfunkkommunikationssystem), beinhalten. Obwohl die GPU 3216 als Teil des Prozessor SoC 3214 dargestellt ist, können bei manchen Implementierungen die GPU und das Prozessor-SoC separate Komponenten umfassen.
Allgemein können die verschiedenen E/A-Schnittstellen, wie etwa Drahtloskommunikationsschnittstellen, die in manchen der Figuren hier gezeigt sind, als separate Komponenten dargestellt sein. Wie später ausführlicher besprochen wird, können diese E/A-Schnittstellen in einem Prozessor-SoC implementiert werden, wobei in diesem Fall die separat gezeigten E/A-Schnittstellen einen Port, einen Verbinder oder eine Antenne repräsentieren.
Bei der in 32 veranschaulichten Ausführungsform ist die Rechnerkarte dazu konfiguriert, ein Microsoft-Windows-Betriebssystem zu implementieren. Das Windows-Betriebssystem kann allgemein beliebige derzeitige oder zukünftige Windows-Betriebssysteme, wie etwa Windows 8.1 oder (in 201 zu veröffentlichen) Windows 10 beinhalten. Zudem sind die Microsoft-Windows-Betriebssysteme vollständige Betriebssysteme, die ursprünglich für die Verwendung auf Desktop-Computern, Laptop-Computern, ausgewählten Tablets und dergleichen gestaltet wurden.
Im Einzelnen sind die ausgewählten Komponenten eines Windows-Betriebssystems 3226 als in einen Speicher 3206 geladen dargestellt, einschließlich Grafikbibliotheken und APIs (Application Program Interfaces - Anwendungsprogrammierschnittstellen) 3228 und Grafiktreibern 3230. Auch in dem Speicher 320β6 dargestellt sind Symbole für mehrere Windows-Anwendungen 3232 und ein virtueller Anzeigepuffer 3234, der zum Layout und Rendern einer virtuellen Windows-GUI (Graphical User Interface - grafische Benutzeroberfläche) 3236 verwendet wird. Die Windows-Anwendungen 3232 laufen in dem „Benutzer“-Raum, während der Ausdruck „Kernel“ hier in dem Kontext von Betriebssystemkomponenten verwendet werden kann, die herkömmlicherweise als in einem Betriebssystem-Kernel implementiert betrachtet werden, wobei angemerkt wird, dass unter manchen Architekturansichten Treiber und Bibliotheken als in separaten Betriebssystemschichten vorliegend betrachtet werden können, die außerhalb des OS-Kernels sind, oder in dem Benutzerraum implementiert sein können.
Die Android-Hostvorrichtung 3202 führt ein Android-Betriebssystem 3238 aus, das als in den Speicher 3218 geladen dargestellt ist und Grafikbibliotheken und APIs 3240 einen Grafiktreiber 3242 beinhaltet. Mehrere Android-Anwendungen 3244 einschließlich eines Windows-Remote-Desktop(RD)-Clients 3246 sind ebenfalls als in den Speicher 3218 geladen dargestellt, sowie ein Anzeigepuffer 3248, das verwendet wird, um Pixel-Bitmap-Inhalt zu speichern, der auf einer physischen Anzeige 3250 der Android-Hostvorrichtung 3202 angezeigt wird.
Bei einem Verwendungsszenario ist die Rechnerkarte 3200 in Kommunikation mit der Android-Hostvorrichtung 3202 über ein USB-Kabel, eine USB-Docking-Station oder ein USB-Plug-In (z. B. weist die Rechnerkarte 3200 USB-Schnittstelle-Stecker ähnlich einem USB-Flash-Laufwerk auf), wodurch ein physischer USB-Link durchgeführt wird. Bei einer Ausführungsform ist der USB-Link als ein IP-über-USB(IP/USB)-Link 3252 implementiert.
Bei einer Ausführungsform wird ermöglicht, dass ein Benutzer Windows-Anwendungen, die auf der Rechnerkarte 3200 laufen, betrachtet und mit diesen interagiert, während sie auf der Anzeige 3250 der Android-Hostvorrichtung 3202 angezeigt werden. Dies wird durch „Werfen“ von Grafikinhalt fern von der Rechnerkarte 3200 über den IP/USB-Link 3252 zu der Android-Hostvorrichtung 3202 ermöglicht, wie durch einen Strom von Grafik(Gfx)-Paketen 3254 dargestellt ist. Benutzereingaben, die an die Android-Hostvorrichtung 3202 geliefert werden (z. B. über Berührungseingaben), werden in Windows-Eingaben umgewandelt und an das Windows-Betriebssystem 3226 geliefert, wie druch einen Strom von Benutzereingabe(UI: User Input)-Paketen 3256 dargestellt ist.
33 stellt ausgewählte Aspekte einer Softwarearchitektur dar, die implementiert wird, um es zu ermöglichen, Szenarien zu verwenden, die eine Rechnerkarte einsetzten, die auf einer Windows-OS- und einer Android-Hostvorrichtung laufen. Die Softwarearchitektur beinhaltet eine Windows-Domäne 3300, eine Android-Domäne 3302 und eine Internet-Domäne 3304. Sowohl die Windows-Domäne 3300 als auch die Android-Domäne 3302 sind ferner in einen Benutzerraum 3306 und einen Systemraum 3308 unterteilt.
Die Windows-Domäne 3300 beinhaltet einen fernen Server 3310, der mit einem Manager 3312 in der Android-Domäne 3302 kommuniziert. Bei der in 33 veranschaulichten Ausführungsform wird eine Kommunikation zwischen dem fernen Server 3310 und dem Manager 3312 über einen IP/USB-Link 3252 ermöglicht. Alternativ dazu können der ferne Server 3310 und der Manager 3312 unter Verwendung von einem der verschiedenen Drahtloskommunikation-Links kommunizieren, die hier beschrieben und veranschaulicht sind.
Zusätzlich zu dem Kommunizieren mit dem fernen Sever 3310 ist der Manager 3312 auch als dazu in der Lage dargestellt, auf verschiedene Internet-Ressourcen über durch das Internet 3314 ermöglichte Verbindungen zuzugreifen. Die beispielhaften Internet-Ressourcen sind in 33 als Clouds dargestellt und beinhalten einen Heim-Cloud-Server 3316, einen Google-Cloud-Dienst 3318, Apple-iCloud-Dienste 3320, Microsoft-OneDrive-Dienste und Dropbox-Dienste 3324. Bei verschiedenen Verwendungen kann der Manager 3312 dazu verwendet werden, auf Internet-Ressourcen für Anwendungen und Dienste zuzugreifen, die in der Android-Domäne 3302 laufen, oder kann als ein Gateway zum Ermöglichen arbeiten, dass Anwendungen und Dienste, die in der Windows-Domäne 330 laufen, auf die Internet-Domäne 3304 zugreifen.
Der Einfachheit und Zweckmäßigkeit halber ist der IP/USB-Link 3252 als ein direkter Link zwischen dem fernen Server 3310 und dem Manager 3312 gezeigt. Jedoch kann, wie hier beschrieben und veranschaulicht, ein IP/USB-Kommunikation-Link ein logischer Link sein, der ein oder mehrere physische USB-Links umfasst.
Bei einer Ausführungsform wird eine Implementierung eines IP-Kommunikation-Links über einen oder mehrere physische USB-Links durch existierende Vernetzungssoftwarestapel in Kombination mit eingebauten USB-Hardwareschnittstellen ermöglicht. Dies ist in 33 als Netzstapel 3326 und 3328 dargestellt. Die Schicht 1 umfasst eine USB-Physische-Schicht (PHY) 3328, die als herkömmliche USB-Verbindung unter Verwendung wohlbekannter standardisierter Techniken konfiguriert ist. Allgemein kann USB-PHY 3328 einem beliebigen existierenden oder zukünftigen USB-Link entsprechen, wie etwa einem USB-2.0- oder USB-3.0-Link. Die softwarebasierten Vernetzungsschichten in der Android-Domäne 3302 beinhalten eine Medienzugriffskanal(MAC: Media Access Channel)-Schicht 3330A, eine IP-Schicht 3332A, eine Transportschicht 3334A, eine Sitzungsschicht 3336A, eine Präsentationsschicht 3338A und eine Anwendungsschicht 3340A und eine Privatprotokollschicht 3342A. Die softwarebasierten Vernetzungsschichten in der Windows-Domäne 3300 beinhalten eine MAC-Schicht 3330W, eine IP-Schicht 3332W, eine Transportschicht 3334W, eine Sitzungsschicht 3336W, eine Präsentationsschicht 3338W und eine Anwendungsschicht 3340W und eine Privatprotokollschicht 3342W.
Bei einer Ausführungsform setzen die MAC-, IP-, Transport-, Sitzungs-, Präsentations- und Anwendungsschicht existierende Vernetzungssoftwarekomponenten ein, die durch ein Android- und Windows-Betriebssystem bereitgestellt werden, und sind unter Verwendung wohlbekannter Techniken implementiert. Zum Beispiel setzt im Zusammenhang des Internetzugriffs die IP-Schicht IPv4- oder IPv6-Adressen ein, implementiert die Transportschicht eines oder mehrere der TCP- und UDP-Protokolle, wird die Sitzungsschicht für IP-Sockets verwendet, wird die Präsentationsschicht zur Verschlüsselung verwendet und wird die Anwendungsschicht für HTTP (das Hypertext-Transport-Protokoll) verwendet. Bei einer Ausführungsform ist die MAC-Schicht als eine Ethernet-MAC-Schicht implementiert und von den Schichten oberhalb der MAC-Schicht erscheint die PHY-Schicht als ein Ethernet-Link. Bei einer Ausführungsform wird dies über USB-PHY 3328 ermöglicht. Bei einer optionalen Konfiguration wird ein „Shim“ 3344 zwischen USB-PHY 3328 und den MAC-Schicht-Softwarekomponenten implementiert, wobei das Shim eine Ethernet-PHY-Schnittstelle für die MAC-Schicht freilegt. Infolgedessen können die existierenden Android- und Windows-Vernetzungssoftwarekomponenten entweder ohne Modifikationen oder mit minimalen Änderungen implementiert werden.
Die Privatprotokollschichten 3342A und 3342W werden verwendet, um eine zusätzliche Funktionalität bereitzustellen, wie etwa Sicherheitsmaßnahmen und Anwendungsfunktionalität. Aspekte des privaten Protokolls können als bei der Sitzungs- und/oder Präsentations- und/oder Anwendungsschicht oder Benutzer-/Anwendungsschicht implementiert betrachtet werden.
Gemäß weiteren Aspekten mancher Ausführungsformen wird eine einheitliche Oberfläche bereitgestellt, die gleichzeitig Zugriff auf sowohl Android- als auch Windows-Anwendungen ermöglicht. Beispiele für die einheitliche Oberfläche sind in 34 und 35 gezeigt. Wie veranschaulicht, beinhaltet die einheitliche Schnittstelle in 34 ein Feld 3400 von Android-Anwendungen und ein Feld 3402 von Windows-Anwendungen. Außerdem enthält ein drittes Feld 3404 Symbole zum Zugriff auf Ansammlungen von Dateien über beide Betriebssysteme hinweg, einschließlich aller Dateien, aller Kontakte und aller E-Mails.
Wie in 35 gezeigt, kann ein Benutzer wählen, auf Daten entsprechend einem Profil 3500 zuzugreifen, und sich Ordner präsentieren lassen, die gemäß dem ausgewählten Profil organisiert sind. Bei diesem Beispiel beinhalten für das Profil 1 die Ordner die Clouds 3502 des Benutzers, die organisierten Dateien 3504 und eine einheitliche Cloud-Ansicht 3505, unter der Dateien und/oder Inhalt eines bestimmten Typs (z. B. E-Mail, Kontakt, Kalender usw.) in einheitlichen Ordern angesammelt sind.
Doppelrechnerkarteneinrichtung
Zusätzlich zum Einsetzen einer einzigen Rechnerkarte kann die Einrichtung unter Verwendung mehrerer Rechnerkarten implementiert werden. Ein Beispiel für eine Doppelrechnerkarten-„Klappgehäuse“-Einrichtung 3600, wie etwa ein Laptop-, Notebook- oder Chromebook-Computer, ist in 36a und 36b gezeigt. Die Doppelkarteneinrichtung 3600 beinhaltet ein Paar von Steckplätzen, in denen jeweilige Rechnerkarten 4100a und 4100b in den Schlitzen 3602 und 3604 installiert sind. Die Doppelkarteneinrichtung 3600 beinhaltet ferner herkömmliche Komponenten, die in typischen Laptops, Notebooks und Chromebooks gefunden werden, wie etwa eine Tastatur 36062, einen Anzeigebildschirm 3808 und ein Berührungsfeld 3610, sowie verschiedene Typen von Ports.
Allgemein kann die Doppelrechnerkarteneinrichtung eine „dumme“ Hostvorrichtung sein, die eine reduzierte Schaltungsanordnung (im Vergleich zu einer herkömmlichen Einrichtung eines ähnlichen Typs) beinhaltet, um verschiedene Kommunikationsschnittstellen mit den Rechnerkarten zu unterstützen und um eine E/A-Kommunikation mit der Tastatur, der Anzeige, dem Berührungsfeld und zutreffenden Ports, einschließlich sowohl Kommunikation-Ports (z. B. USB, Thunderbolt) als auch externer Anzeige-Ports (wie etwa DisplayPort und HDMI-Ports), zu unterstützen.
Zusätzlich zu der Doppelsteckplatzhosteinrichtung und -Vorrichtungen kann eine Rechnerkartenhosteinrichtung dazu konfiguriert sein, eine einzige Rechnerkarte zu verwenden. Zum Beispiel zeigt 36c eine Einzelrechnerkartenhosteinrichtung 3600a mit einer der Doppelkarteneinrichtung 3600 ähnlichen Konfiguration. Die Einzelrechnerkartenhosteinrichtung 3600a arbeitet auf eine ähnliche Weise wie die Doppelrechnerkarteneinrichtung 3600, wenn eine einzige Karte in einem der zwei Steckplätze der Einrichtung installiert ist.
Blockdiagramme jeweiliger Ausführungsformen der Prozessorplatinen 3700 und 3800, die in einer Doppelrechnerkarteneinrichtung installiert werden können, sind in 37 und 38 gezeigt. Die Prozessorplatine 3700 beinhaltet ein Paar von USB-Typ-C-Ports 3702 und 3704, die dazu konfiguriert sind, mit USB-Typ-C-Gegenverbindern auf einer Rechnerkarte, wie durch eine Windows-Rechnerkarte 3604 und eine Android-Rechnerkarte 3602 dargestellt, gekoppelt zu werden. Jedoch wird angemerkt, dass der gleiche Typ einer Rechnerkarte in den Rechnerkartensteckplätzen installiert werden kann. Jeder der USB-Typ-C-Ports 3702 und 3704 ist mit einem ähnlichen Satz von Komponenten gekoppelt, wie durch USB-3.0-Typ-A-Schnittstellen 3706 und 3708, Hubs 3710 und 3712 und WiFi/Bluetooth-Chips 3714 und 3716 dargestellt.
Die Prozessorplatine 3700 beinhaltet auch Komponenten, die schaltbar mit den USB-Typ-C-Ports 3702 und 3704 verbunden werden können, einschließlich eines Hubs 3718, Audios 3730, einer Trackpad-Schnittstelle 3722, einer Berührungsbildschirmschnittstelle 3724 und einer Tastaturschnittstelle 3726 und einer EDP-Anzeige 3728. Die Prozessorplatine 3700 beinhaltet ferner Multiplexer 3730 und 3732, Mikrocontroller (uCs) 3734 und 3736, einen Lüfter 3738, einen Ein/Aus-Schalter 3740 und einen Betriebssystem(OS: Operating System)-Schalter 3742 und einen Deckelschalter 3744.
Während des Betriebs wird, falls eine einzige Rechnerkarte in einen der Doppelsteckplätze eingefügt ist, die Logik der Prozessorplatine detektieren, dass sie eingefügt ist und wird die Rechnerkarte kommunikativ mit Audio 3720, der Trackpad-Schnittstelle 3722, der Berührungsbildschirmschnittstelle 3724, der Tastaturschnittstelle 3726 und der EDP-Anzeige 3728 sowie mit dem WiFi/Bluetooth-Chip 3714 oder 3716entsprechend dem Steckplatz gekoppelt, in dem die Rechnerkarte installiert ist.
Falls die Rechnerkarte das erste Mal in einem Steckplatz einer Hostvorrichtung installiert wird, wird die Rechnerkarte mit dem Mikrocontroller 3734 oder 3736 kommunizieren, um Konfigurationskennungen und Parameter, wie etwa eine Trackpad-Schnittstelle-Kennung, eine Berührungsbildschirmkennung, eine Tastaturkennung und eine Anzeigekennung, zu erhalten. Bei einem Windows-Betriebssystem werden die Konfigurationskennungen verwendet, um zu bestimmen, welche Treiber für die verschiedenen Peripherievorrichtungen und Komponenten auf der Einrichtung, in der die Rechnerkarte installiert ist, zu verwenden sind. Dies funktioniert auf eine ähnliche Weise wie Windows arbeitet, wenn es für ein herkömmliches Computersystem, wie einen Laptop-, Notebook- oder Desktop-Computer, installiert und hochgefahren wird.
Bei einer Ausführungsform speichert die Rechnerkarte Hostvorrichtungskonfigurationsinformationen für eine oder mehrere Vorrichtungen und Einrichtungen, in denen sie installiert wurde, unter Verwendung von Datenstrukturen, wie etwa eines Arrays oder einer Tabelle. Eine Hostvorrichtungskennung wird verwendet, um zu identifizieren, wo in dem Array oder der Tabelle die Konfigurationsinformationen gespeichert sind, und ermöglicht, dass eine Rechnerkarte, die zuvor in einer Hostvorrichtung installiert wurde und sich in einem Ruhezustand befindet, aus dem Ruhezustand aufwacht und ihre Treiber auf eine Weise konfiguriert, die ermöglicht, dass die Rechnerkarte den Betrieb fortsetzt, ohne neugestartet werden zu müssen. Beim Abschließen des Verwendens einer Rechnerkarte mit einer ersten Hostvorrichtung kann die Rechnerkarte in einen Ruhe(oder Schlaf)-Zustand gesetzt werden, von der ersten Hostvorrichtung entfernt werden, in einer zweiten Hostvorrichtung mit einer unterschiedlichen Konfiguration installiert werden und den Betrieb dort fortsetzen, wo er beendet wurde, als sie in den Ruhe- oder Schlafzustand auf der ersten Hostvorrichtung gesetzt wurde. Dieses Erlebnis stellt eine Flexibilität bereit, die mit herkömmlichen Rechnervorrichtungen nicht verfügbar ist, da das Transferieren von OS-Betriebszuständen zwischen Rechnervorrichtungen entweder unmöglich ist oder eine erhebliche Zeitmenge in Anspruch nehmen würde und das Verlinken der Vorrichtungen hinsichtlich einer Kommunikation erfordern würde.
Falls zwei Rechnerkarten in einer Doppelsteckplatzvorrichtung installiert sind, ist die Vorrichtung dazu konfiguriert, jede Rechnerkarte, einschließlich ihres Betriebssystemtyps, zu erkennen und zu ermöglichen, dass jede Rechnerkarte als die „aktive“ Rechnerkarte ausgewählt wird. Zum Beispiel wird angenommen, dass man eine erste Rechnerkarte, die Windows 10 ausführt, und eine zweite Rechnerkarte, die eine Version von Android ausführt, hat. Durch Verwenden des OS-Schalters 3742 kann der Benutzer der Vorrichtung zwischen den zwei Rechnerkarten schalten, um die Rechnerkarte, die das Betriebssystem ausführt, das der Benutzer momentan verwenden will, zu der aktiven Karte zu machen. Die Logik und Schalt-Schaltungsanordnung auf der Prozessorplatine 3700, einschließlich der Multiplexer 3730 und 3732, der Hubs 3710, 3712 und 3718, und eine zusätzliche Schaltungsanordnung und Logik (nicht gezeigt) werden verwendet, um die Hostvorrichtung zum Verwenden der Rechnerkarte zu konfigurieren, die als die aktive Karte ausgewählt ist.
Benutzer können auch zwischen den zwei Rechnerkarten in einer Doppelsteckplatzhostvorrichtung wechseln, ohne die Hostvorrichtung herunterzufahren. Der Benutzer wird die momentan aktive Rechnerkarte zunächst in einen Ruhezustand setzen und dann die andere Rechnerkarte auswählen, die die aktive Rechnerkarte werden soll, wobei diese Rechnerkarte aus ihrem Ruhezustand aufgeweckt wird und ihren Betrieb fortsetzt.
Die Prozessorplatine 3800 beinhaltet ein Paar von USB-Typ-C-Steckern (d. h. Plug-In-Ports oder Verbinder) 3802 und 3804, Schalter S1, S2 und S3, einen Schalter 3806, USB-Hochgeschwindigkeit-Hubs 3808 und 3810, WiFi-Chips 3812 und 3814, eine Host-zu-Host-Brücke 3816, USB-Ports 3818 und 3820, eine Lüftersteuerung 3822 und einen Lüfter 3824, eine Batterie 3826, die mit einem lokalen Ladeelement 3828 und lokalen Spannungsregler 3830 gekoppelt ist, einen USB-Leistungseingang 3832 und LEDs 3834. Die Prozessorplatine 3800 beinhaltet ferner einen USB-Tastatur-, Video- und Maus(KVM)-Schalter 3836, eine Tastatursteuerung (KBC) 3838, die mit einer Tastatur (KB) 3840 gekoppelt ist, einen Bluetooth-Chip 3842 und Audiochip 3844 und einen Mikro-USB-Port 3846. Die Prozessorplatine 3800 ist auch mit einem LCD-Bildschirm 3848 verbunden.
Wenn eine einzige Rechnerkarte in einem der Doppelsteckplätze installiert ist und mit einem USB-Stecker 3802 oder 3804 gekoppelt ist und der Benutzer den S1- oder S2-Leistungsschalter (wie zutreffend) aktiviert, detektiert das System die Anwesenheit der Rechnerkarte und gibt es einen Austausch von Konfigurationsinformationen, die verwendet werden, um sowohl die Hostvorrichtung zu konfigurieren als auch die angemessenen Treiber für das OS zu konfigurieren, das auf der Rechnerkarte läuft. Die Konfiguration der Hostvorrichtung beinhaltet Konfigurieren des KVM-Schalters 3836, um mit dem angemessenen USB-Stecker zu kommunizieren, mit dem die Rechnerkarte gekoppelt ist. Eine Schaltlogik in zusätzlichen Komponenten auf der Prozessorplatine 3800 wird auch verwendet, um die Hostvorrichtung zum Interagieren mit der Rechnerkarte über ihre USB-C-Schnittstelle zu konfigurieren.
Die Prozessorplatine 3800 ist auch dazu konfiguriert, Leistung an beide Rechnerkartensteckplätze zu liefern, um die Batterie in der Rechnerkarte wiederaufzuladen, wenn sie in einem der Steckplätze der Hostvorrichtung installiert ist. (Der Einfachheit halber ist die Schaltungsanordnung, die den Leistungsunterabschnitt der Prozessorplatine 3800 mit den USB-C-Steckern 3802 und 3804 koppelt, nicht gezeigt.)
Wenn zwei Rechnerkarten in jeweiligen Steckplätzen in einer Doppelsteckplatzhostvorrichtung installiert sind, wird ermöglicht, dass der Benutzer durch Verwenden des S3-Schalters dazwischen schaltet, welche Rechnerkarte die aktive Karte ist. Zum Beispiel wird die Aktivierung des S3-Schalters die aktive Rechnerkarte von einer Karte zu der anderen umschalten. Bei einer Ausführungsform kann ein ähnlicher Schalter als entweder eine aktive Rechnerkarte entfernend oder den Leistungsschalter für den Rechnerkartensteckplatz aktivierend erscheinen. Beispielsweis wird angenommen, dass sich eine erste Rechnerkarte 1 in einem Steckplatz „1“ befindet und mit dem USB-C-Stecker 3802 gekoppelt ist, während sich eine zweite, nichtaktive Rechnerkarte 2 in einem Steckplatz „2“ befindet und mit dem USB-C-Stecker 3804 gekoppelt ist. Entweder beim Entfernen der Rechnerkarte 1 aus dem Steckplatz „1“ oder beim Ausschalten des Leistungsschalters S1 wird die aktive Rechnerkarte zu der Rechnerkarte 2 wechseln. In Verbindung mit dem Wechseln zu einer neuen aktiven Rechnerkarte wird die Schalt-Schaltungsanordnung in der Prozessorplatine 3800 die Verbindungspfade zwischen den verschiedenen Peripherie- und E/A-Vorrichtungen, wie etwa der Tastatur, dem Berührungsfeld, dem Berührungsbildschirm, dem Videobildschirm oder der Videoanzeige, USB-Ports usw., und den Signalleitungen, die mit dem USB-C-Stecker gekoppelt sind, für den neuen aktiven Steckplatz rekonfigurieren.
39 zeigt eine Ausführungsform einer Rechnerkarte 3900, die einen USB-Typ-C-Verbinder 3902 als eine einzige einheitliche Schnittstelle einsetzt. Die Rechnerkarte 3900 beinhaltet ferner eine interne Leistungsschnittstelle 3904, eine USB-3-Schnittstelle 3906 und eine DisplayPort-Schnittstelle 3908, ein PMIC(integrierter Leistungsverwaltungsschaltkreis)- und-Leistung-Untersystem 3910, eine SSD-BGA-Speicherungsvorrichtung 3912 (SSD: Solid State Drive - Festkörper; BGA: Ball Grid Array - Kugelgitteranordnung), ein Intel®-Architektur(IA)-SoC 3914 mit einem dynamischen Direktzugriffsspeicher (DRAM), der mit dem SoC unter Verwendung von Packet-on-Package(PoP)-Packaging gekoppelt ist, eine Systemruhebatterie 3916, ein Fingerabdrucklesegerät 3918 und LEDs 3920.
Zusätzlich zu den in 39 gezeigten Komponenten kann eine Rechnerkarte, die einen USB-Typ-C-Verbinder einsetzt, eine andere Schaltungsanordnung beinhalten, wie etwa in anderen Rechnerkarteausführungsformen hier, einschließlich der Rechnerkarte 100 aus 1, veranschaulicht. Jedoch wird, statt einen Docking-Verbinder mit mehreren Verbindern einzusetzen, ein einziger USB-Typ-C-Verbinder verwendet.
40 zeigt eine Ausführungsform einer Schnittstellenschaltungsanordnung zwischen einem USB-Typ-C-Verbinder 4000, einer CPU 4002 und einem PMIC 4004. Die vier Hochgeschwindigkeit-USB-Typ-C-Spuren 4006 werden über einen Multiplexer 4008 gemultiplext, wobei zwei Leitungen auf der linken Seite des Multiplexers 4008 mit einer USB-3.0-Schnittstelle 4010 gekoppelt sind, während vier Leitungen mit einer DisplayPort-Schnittstelle 4012 gekoppelt sind. Die zwei Seitenbandbenutzung(SBU: Sideband Use)-Signale 4014 werden mit einem Multiplexer 4016 gekoppelt, der verwendet wird, um selektiv zu ermöglichen, dass eine I²C-Hilfsschnittstelle 4018 mit Vorrichtungen kommuniziert, die mit dem USB-Verbinder 4000 gekoppelt sind. Die zwei USB-2.0-Signale 4020 sind mit einer USB-2.0-Schnittstelle 4022 gekoppelt. Währenddessen werden die zwei Steuerkanal(CC: Control Channel)-Signale 4024 mit einer Typ-C-PD-Schnittstelle 4026 auf der PMIC 4004 gekoppelt.
41a und 41b zeigen perspektivische Ansichten einer Rechnerkarte 4100, die einen USB-Typ-C-Verbinder 4102 und ein Fingerabdrucklesegerät 4104 beinhaltet. Die Rechnerkarte 4100 beinhaltet ferner eine Leiterplatte einschließlich der Schaltungsanordnung und der Komponenten der Rechnerkarte 3900. Bei einer Ausführungsform sind die Höhe (H) und Breite (W) der Rechnerkarte näherungsweise die gleichen Abmessungen wie eine Standardkreditkarte, während die Dicke näherungsweise vier Kreditkarten beträgt.
42 zeigt eine Ausführungsform einer Mobil-Docking-Station 4200, die dazu konfiguriert ist, an eine Rechnerkarte anzubinden, die eine USB-Typ-C-Schnittstelle einsetzt. Die Mobil-Docking-Station 4200 beinhaltet einen USB-C-Stecker 4202, der kommunikativ mit einem Hochgeschwindigkeit-USB-Hub 4204 und einer DisplayPort(DP)-Schnittstelle 4206 gekoppelt ist (z. B. unter Verwendung einer Schaltungsanordnung, die jener in 40 gezeigten ähnlich ist). Der Hochgeschwindigkeit-USB-Hub 4204 ist mit einem WiFi-Chip 4208, USB-Ports 4210, 4212 und 4214, einem Bluetooth-Chip 4216 und einem Audiochip 4218 und einem Mikro-USB-Port 4220 gekoppelt. Die Mobil-Docking-Station 4200 beinhaltet ferner Leistungssystemkomponenten und -Schnittstellen, einschließlich einer Batterie 4222, eines lokalen Ladeelements 4224, eines lokalen Spannungsreglers 4226, eines USB-Ports 4228 und LEDs 4230.
Allgemein wird eine Mobil-Docking-Station zusätzlich zu den in 42 gezeigten Komponenten eine eingebettete Logik und Schaltungsanordnung beinhalten, um verschiedene Funktionen, einschließlich Konfigurationsfunktionen, zu unterstützen. Bei einer Ausführungsform beinhaltet eine „Smart“-Mobil-Docking-Station 4200 einen Prozessor, der eingebettete Firmware oder Software ausführt (nicht gezeigt), die ermöglicht, dass die Mobil-Docking-Station Aspekte einer Peripheriekonfiguration handhabt und auf eine solche Weise an eine Rechnerkarte angebunden wird, die viel der Konfigurationsaufgaben abnimmt, wie unten ausführlicher beschrieben ist.
43 zeigt einen beispielhaften Verwendungsfall für eine Rechnerkarte, bei dem eine Rechnerkarte 4100 in einen Steckplatz in einer Docking-Station 4200 eingefügt ist, die über ein DisplayPort-Kabel 4302 mit einem Monitor 4300 verbunden ist. Bei dem Verwendungsfall wäre die Mobil-Docking-Station 4200 auch kommunikativ mit einer Tastatur und Zeigevorrichtung, wie etwa einer Maus (beide nicht gezeigt), gekoppelt. Zum Beispiel könnten die Tastatur und/oder Maus Vorrichtungen mit Bluetooth-Funktion sein, die über Bluetooth mit der Mobil-Docking-Station 4200 in der Kommunikation gekoppelt sind. Optional können die Tastatur und/oder Maus eine drahtgebundene Verbindung, wie etwa durch eine USB-Tastatur oder -Maus verwendet, einsetzen.
Die Ausführungsform aus 43 arbeitet auf eine ähnliche Weise wie ein Desktop-Computer, mit einer Tastatur und Maus und mit einem Monitor gekoppelt, oder wie ein Laptop- oder Notebook-Computer mit einer externen Anzeige gekoppelt. Bei dem veranschaulichten Beispiel führt die Rechnerkarte 4100 eine vollständige Desktop-Version eines Betriebssystems (wie etwa Windows 10 oder eine Version von Linux) aus und beinhaltet Treiber zur Verwendung mit verschiedenen Peripherievorrichtungen, wie etwa Monitoren, Tastaturen und Zeigevorrichtungen.
Ein anderer Formfaktor für eine Hostvorrichtung ist ein Tablet. Allgemein kann ein Host-Tablet einen oder mehrere Steckplätze beinhalten, die dazu konfiguriert sind, an eine oder mehrere jeweilige Rechnerkarten anzubinden. Zum Beispiel zeigt 44 die Unterseite eines Doppelsteckplatz-Tablets 4400 mit einem Paar von Steckplätzen 4402 und 4404, die dazu konfiguriert sind, eine Rechnerkarte 4100 zu empfangen. Ein Auswurfmechanismus 4406 und 4408 ist für jeden der Steckplätze 4402 und 4404 bereitgestellt, wobei das Verschieben eines Auswerfers 4408 und 4410 bewirken wird, dass eine Rechnerkarte in einem entsprechenden Steckplatz 4402 oder 4404 ausgeworfen wird.
Bei einer Ausführungsform beinhaltet eine Rechnerkarte eine Logik zum automatischen Eintreten in einen Ruhezustand, wenn sie aus einem Steckplatz oder einer Docking-Station entfernt wird. Zum Beispiel tritt die Rechnerkarte bei einer Ausführungsform in einen tiefsten Ruhezustand ein, der s0i3 genannt wird (entsprechend einem Zustand, bei dem die geringste Menge an Leistung verbraucht wird), wenn sie aus dem Steckplatz oder aus einer Docking-Station entfernt wird. Als eine Option kann eine Rechnerkarte auch über einen Leistungsschalter für den Steckplatz, in dem die Rechnerkarte installiert ist, in einen Ruhezustand, einschließlich des s0i3-Zustands, versetzt werden. Die Rechnerkarte wird auch automatisch aus dem s0i3-Ruhezustand „aufwachen“, wenn sie in einen Rechnerkartensteckplatz in einer Hostvorrichtung eingefügt wird.
45 zeigt ein Flussdiagramm 4500, das Operationen und eine Logik beinhaltet, die als Reaktion darauf durchgeführt werden, dass eine Rechnerkarte, die sich momentan in einem Ruhezustand befindet, in einen Rechnerkartensteckplatz in einer Hosteinrichtung oder -vorrichtung eingefügt wird. Der Prozess beginnt bei dem Startblock 4502, bei dem ein Benutzer die Rechnerkarte in den Steckplatz einfügt. Bei einem Block 4504 wird die Einfügung der Karte durch sowohl den Host als auch die Karte selbst detektiert und wacht die Karte aus ihrem Ruhezustand auf und richtet eine Kommunikation mit ihrem Host ein.
In einem Block 4506 wird eine Bestimmung vorgenommen, ob die Hosteinrichtung oder -vorrichtung der gleiche Host ist, aus dem die Rechnerkarte zuletzt entfernt wurde. Falls er der gleiche Host ist, besteht keine Notwendigkeit, irgendwelche Treiber zu rekonfigurieren, wodurch ermöglicht wird, dass die Logik zu einem Block 4514 weitergeht, bei dem das Betriebssystem der Rechnerkarte Operationen auf dem Host vollständig fortsetzt.
Bei einer Ausführungsform sind die Rechnerkarte und der Host dazu konfiguriert, eine dynamische Rekonfiguration auf eine Art und Weise zu unterstützen, die ermöglicht, dass die Rechnerkarte Operationen auf einem unterschiedlichen Host (als mit dem sie zuletzt verwendet wurde) fortsetzt, ohne dass die Rechnerkarte neugestartet werden muss. Entsprechend wird, falls die Hosteinrichtung oder -vorrichtung verschieden von dem zuletzt mit der Rechnerkarte verwendeten Host ist, die Antwort des Entscheidungsblocks 4506 nein sein und wird die Logik zu einem Block 4508 weitergehen, bei dem die Karte den Host befragen wird, um eine anwendbare Tastatur-, Video- und Maus(KVM)-Konfiguration zu bestimmen. (Es wird angemerkt, dass das „M“ aus der Gepflogenheit verwendet wird, aber tatsächlich der zutreffenden Zeigevorrichtung entspricht, ob in der Tat diese Vorrichtung tatsächlich eine Maus oder irgendeine andere Eingabevorrichtung, wie etwa ein Trackpad, ist oder nicht.) In Abhängigkeit von der Konfiguration der Hosteinrichtung oder -vorrichtung kann ein Teil dieser Operation an die Hostvorrichtung abgegeben werden, wobei die Hostvorrichtung herausfindet, was ihre KVM-Konfiguration ist und entsprechende Konfigurationsinformationen an die Rechnerkarte liefert. Zum Beispiel können, weil eine Doppel- oder Einzelsteckplatzeinrichtung, wie etwa ein Laptop, Notebook, Chromebook oder Tablet, eine eingebaute Anzeige und eine oder mehrere Zeigevorrichtungen (z. B. kann eine Klappgehäuseeinrichtung sowohl ein Berührungsfeld als auch einen Berührungsbildschirm haben, während ein Tablet einen Berührungsbildschirm haben wird) beinhalten wird, die KVM-Konfigurationsinformationen im Voraus vorerzeugt werden.
In dem Fall einer Mobil-Docking-Station können verschiedene Typen von Monitoren mit unterschiedlichen Auflösungen und Fähigkeiten und unterschiedliche Typen von Tastaturen und Eingabevorrichtungen verwendet werden. Infolgedessen wird die KVM-Konfiguration allgemein dynamisch bestimmt, wenn die Rechnerkarte in den Steckplatz in der Mobil-Docking-Station eingefügt wird. Bei manchen Ausführungsformen kann ein Teil dieser Aufgabe an die Mobil-Docking-Station abgegeben werden. Zum Beispiel kann die Mobil-Docking-Station dazu konfiguriert sein, kommunikativ von selbst mit einer oder mehreren KVM-Vorrichtungen gekoppelt zu werden (d. h. unabhängig davon, ob eine Rechnerkarte in der Mobil-Docking-Station installiert ist). Dies kann beide KVM-Vorrichtungen beinhalten, die über ein drahtgebundenes und/oder drahtloses Mittel (wie etwa über ein USB-Kabel, Bluetooth oder einen anderen Drahtlos-Link) verbunden sind.
Zusätzlich zu KVM-Vorrichtungen kann eine Hostvorrichtung ein/en oder mehrere E/A-Peripheriegeräte und/oder Ports aufweisen, auf die durch eine Rechnerkarte zugegriffen werden kann. Entsprechend werden in einem Block 4510 zusätzliche E/A-Peripheriegeräte und Ports, wie zutreffend, aufgelistet und konfiguriert. Als Nächstes werden in einem Block 4512 zutreffende Betriebssystemtreiber, einschließlich der KVM-Treiber und beliebiger zutreffender E/A-Peripheriegeräte- und Port-Treiber, dynamisch rekonfiguriert. Dieser Typ dynamischer Treiberinformationen wird durch verschiedene Betriebssysteme, einschließlich Windows 10 und mancher Linux-Betriebssysteme, unterstützt. Bei manchen Ausführungsformen können Vorrichtungen vom Plug-n-Play-Typ und entsprechende Treiber verwendet werden. Beispielsweise ist es üblich, Plug-n-Play-Monitore, -Tastaturen und - Eingabevorrichtungen zu haben. Sobald die entsprechenden Treiber konfiguriert wurden, geht die Logik zu Block 4514 weiter, wo das Betriebssystem Operationen auf der Hosteinrichtung oder -vorrichtung fortsetzt.
Bei einer Ausführungsform kann eine Rechnerkarte KVM- und andere optionale E/A-Peripheriegeräte- und Port-Konfigurationsinformationen für eine Mobil-Docking-Station aufbewahren. Zum Beispiel ist vorgesehen, dass eine Mobil-Docking-Station als eine Heim-Docking-Station verwendet werden kann, die normalerweise mit einem Monitor verbunden ist und drahtgebundene oder drahtlose Verbindungen zu einer Tastatur und/oder Zeigevorrichtungen hat (anerkennend, dass viele der heutigen Monitore Berührungsbildschirme aufweisen, die auch für eine Zeigevorrichtungsfunktionalität verwendet werden können). Eine Mobil-Docking-Station kann auch einen Ruhezustand und/oder andere Betriebsmodi haben, die Drahtlos-Links in Ruhe- oder Inaktivzuständen beibehalten, wenn entsprechende Eingabevorrichtungen für eine Weile nicht verwendet wurden. Als Reaktion auf eine Aktivierung einer solchen Eingabevorrichtung (wie etwa Bewegen einer Maus oder Drücken einer Taste oder der Leertaste auf der Tastatur) wird der Drahtlos-Link zu der Eingabevorrichtung aufwachen und in seinen normalen Betriebszustand zurückkehren. Bei einer Ausführungsform gibt eine Mobil-Docking-Station die Plug-n-Play-Fähigkeiten von Peripherievorrichtungen, die mit ihren Ports verbunden sind, und/oder Konfigurationsinformationen in Bezug auf momentan freie Ports bekannt.
Bei manchen Ausführungsformen können Hosteinrichtungen und -vorrichtungen so konfiguriert sein, dass sie eine universell eindeutige Kennung (UUID: Universally Unique Identifier) aufweisen, die verwendet wird, um den Host für eine Rechnerkarte zu identifizieren. Die Rechnerkarte kann eine Nachschlagetabelle oder dergleichen pflegen, die Host-UUIDs mit Konfigurationsinformationen für diese Hosts verknüpft. Bei diesem Ansatz wird, wenn eine Rechnerkarte in einem Host installiert wird, die UUID des Hosts an die Rechnerkarte kommuniziert, um dabei zu helfen, die Konfiguration passender Treiber für den Host zu ermöglichen.
Zusätzlich zu dem Unterstützen des Wechselns zwischen unterschiedlichen Betriebssystemen kann eine Doppelsteckplatzhostvorrichtung dazu konfiguriert sein, Rechnerkartenklonen und -migration zu unterstützen. Beim Klonen werden Daten auf der zu klonenden Karte auf eine Zielklonkarte kopiert. Allgemein wird Klonen die gleichen Rechnerkarten einsetzen. Bei einer Migration werden die Anwendungen und Daten von einer momentanen Rechnerkarte zu einer neuen Rechnerkarte migriert. Typischerweise werden die momentane und neue Rechnerkarte entweder verschieden sein (z. B. weist die Karte, zu der migriert wird, eine schnellere Hardware auf) und/oder wird die neue Rechnerkarte eine neuere Version des Betriebssystems aufweisen.
Eine Ausführungsform von Operationen und Logik, die ausgeführt werden, um das Klonen einer Rechnerkarte zu ermöglichen, ist in einem Flussdiagramm 4600 aus 46 gezeigt. Der Prozess beginnt bei einem Startblock 4602, bei dem der Benutzer die zu klonende Karte in einen Steckplatz und die Zielkarte, die der Klon werden soll, in den anderen Steckplatz eingefügt hat. Bei einem Block 4604 wählt der Benutzer eine Klonoperation über eine auf dem Host laufende Software aus. Bei unterschiedlichen Ansätzen kann die Software, die für die Klonoperation verwendet wird, aus der zu klonenden Karte geladen werden oder kann der Host eine eingebaute Software haben, die ermöglicht, dass der Host gewisse Operationen, wie etwa Klonen, durchführt, ohne Software auf einer der Rechnerkarten auszuführen.
In einem Block 4606 gibt der Benutzer Sicherheitsanmeldedaten ein und/oder verwendet das Fingerabdrucklesegerät zum Authentifizieren des Benutzers als ein zulässiger Benutzer der Karte. Falls die Authentifizierung fehlschlägt, wie in einem Entscheidungsblock 4608 bestimmt wird, wird die Operation abgebrochen und wird dem Benutzer eine Fehlernachricht, wie etwa „Benutzer ist nicht zum Durchführen des Klonens autorisiert“, angezeigt. Falls die Benutzerauthentifizierung erfolgreich ist, wird die Antwort in dem Entscheidungsblock 4608 JA sein und wird die Logik zu einem Block 4612 weitergehen, bei dem Daten in einem nichtflüchtigen Speicher der Karte in einen entsprechenden nichtflüchtigen Speicher auf der Zielklonkarte unter Verwendung einer Bit-für-Bit-Kopie kopiert werden. Optional kann ein Schema mit blockweisem Kopieren eingesetzt werden.
Sobald das Kopieren der Daten abgeschlossen wurde, werden ein oder mehrere Tests in einem Block 4614 durchgeführt, um zu verifizieren, dass die Daten korrekt kopiert wurden und ein Betrieb der Zielklonkarte korrekt ist. Zum Beispiel könnte ein bitweiser oder blockweiser Vergleich zwischen den zwei Karten durchgeführt werden. Auch können verschiedene Tests auf der Zielkarte ausgeführt werden, um ihren Gesundheitszustand und Betrieb zu testen. Sobald der/die Test(s) erfolgreich abgeschlossen ist/sind, wird der Benutzer in einem Block 4616 darüber informiert, dass die Karte erfolgreich geklont wurde.
Allgemein wird eine Migration zu einer neuen Rechnerkarte mit dem gleichen Betriebssystem jenen in dem Flussdiagramm 4600 gezeigten ähnliche Operationen einschließen. Bei einem Fall kann eine Bit-für-Bit-Kopie für wenigstens einen Teil der Daten, die zu der Zielklonkarte zu kopieren sind, nicht zutreffen. Zum Beispiel kann eine neue Rechnerkarte mehr nichtflüchtigen Speicher beinhalten oder kann eine Speicherorganisation einsetzen, die verschieden von der Karte ist, die geklont wird.
Operationen und Logik zum Implementieren einer Ausführungsform einer Migrationsoperation zu einem neuen Betriebssystem sind in einem Flussdiagramm 4700 aus 47 gezeigt. Der Prozess beginnt bei einem Startblock 4702, bei dem der Benutzer die zu migrierende Karte in einen Steckplatz und die Zielmigrationskarte, zu der migriert werden soll, in den anderen Steckplatz eingefügt hat. Bei einem Block 4704 wählt der Benutzer eine Migrationsoperation über eine auf dem Host laufende Software aus. Bei einer Ausführungsform wird eine Migration über eine Software ermöglicht, auf die sowohl von der zu migrierenden Karte als auch der Zielkarte zugegriffen wird. Entsprechend ist bei manchen Ausführungsformen eine Doppelsteckplatzhosteinrichtung oder -Vorrichtung dazu konfiguriert, eine gleichzeitige Ausführung von Software, die auf beiden Rechnerkarten ausgeführt wird, zu ermöglichen. Allgemein wird, weil lediglich eine Rechnerkarte auf einmal (nativ) auf die KVM-Vorrichtungen für den Host zugreift, eine API eingesetzt, um zu ermöglichen, dass der Benutzer auf Software zugreift, die auf der Rechnerkarte läuft, die nicht nominal „aktiv“ ist, wobei angemerkt wird, dass während einer Migration beide Rechnerkarten in ihren eigenen jeweiligen aktiven Modi arbeiten.
In einem Block 4706 gibt der Benutzer Sicherheitsanmeldedaten ein und/oder verwendet das Fingerabdrucklesegerät zum Authentifizieren des Benutzers als ein zulässiger Benutzer der Karte. Falls die Authentifizierung fehlschlägt, wie in einem Entscheidungsblock 4708 bestimmt wird, wird die Operation abgebrochen und wird dem Benutzer eine Fehlernachricht, wie etwa „Benutzer ist nicht zum Durchführen der Migration autorisiert“, angezeigt. Falls die Benutzerauthentifizierung erfolgreich ist, wird die Antwort in dem Entscheidungsblock 4708 JA sein und wird die Logik zu einem Block 4712 weitergehen.
In Block 4712 untersucht die Migrationssoftware die Konfiguration von Betriebssystemen, Anwendungen und Dateien auf der Quellen- und Zielrechnerkarte. Dem Benutzer werden Anwendungen und Dateien zum Migrieren zusammen mit Empfehlungen präsentiert. Zum Beispiel beinhaltet die Migration bei einer Ausführungsform eine Migration von Anwendungen, was sowohl die Migration des ausführbaren Codes und von Daten für die Anwendung als auch eine Erzeugung von neuen Registrierungsinformationen auf der Zielmigrationskarte beinhaltet. Bei einer Ausführungsform wird ein Ansatz eingesetzt, der dem von PC Mover® verwendeten ähnlich ist. Bei PC Mover® gibt es einen Migrationscode sowohl auf dem Quellen(Migration von)-Computer als auch dem Ziel(Migration zu)-Computer. Vor dem Ausführen der Migration wird Code auf dem Quellencomputer ausgeführt, um die Anwendungen aufzuzählen, die auf dem Quellencomputer installiert sind, und um den Quellencomputer für die Migration vorzubereiten. Während dieses Prozesses wird der Migrationscode über das Zielbetriebssystem informiert und wird eine Bestimmung darüber vorgenommen, welche Anwendungen zum Bestehen eines Migrationstests zwischen der Version des Betriebssystems auf dem Quellencomputer und der Version des Betriebssystems in dem Zielcomputer, zu dem migriert wird, verifiziert wurden. Bei einer Ausführungsform wird dem Benutzer eine Liste von Anwendungen zum Migrieren präsentiert, die Indizien beinhaltet, die angeben, welche Anwendungen als erfolgreich durch den Softwarebereitsteller migriert verifiziert wurden, welche Anwendungen als nicht erfolgreich migriert verifiziert wurden und welche Anwendungen noch zu bestimmen sind.
Als Nächstes wird in einem Block 4712 die Migration von ausgewählten Anwendungen und Dateien durchgeführt. Bei manchen Ausführungsformen wird dies eine gleichzeitige Ausführung von Software sowohl auf der Quellen- als auch Zielrechnerkarte einschließen. Zum Beispiel wird eine virtuelle Netzwerkverbindung zwischen den Rechnerkarten eingerichtet und werden Anwendungscode und Daten von der Quellenrechnerkarte zu der Zielrechnerkarte auf eine Weise kopiert, die der von PC Mover® verwendeten ähnlich ist. Jedoch wird bei der herkömmlichen Verwendung von PC Mover® zum Migrieren von Daten zwischen Computern PC-Mover®-Migrationscode auf jedem Computer ausgeführt und es muss irgendeine Art von physischer Verbindung zwischen den zwei Computern geben, die durch den Benutzer eingerichtet werden muss. Bei den Doppelsteckplatzausführungsformen wird eine beliebige Konfiguration von Informationen zum Einrichten einer Kommunikation zwischen der Quellen- und Zielrechnerkarte automatisch durchgeführt, ohne dass irgendeine Benutzerbeteiligung notwendig ist.
Nachdem die Migration abgeschlossen wurde, werden eine oder mehrere Testoperationen in einem Block 4716 durchgeführt, um eine erfolgreiche Migration zu der Zielkarte zu verifizieren. Falls sämtliche Tests bestanden werden, wird der Benutzer in einem Block 4716 informiert, dass die Migration erfolgreich war. Dem Benutzer kann auch eine Liste von von dem Benutzer zur Migration ausgewählten Anwendungen präsentiert werden, für die keine erfolgreiche Migration detektiert wurde.
Weitere Einzelheiten einer Ausführungsform eines „Smart“-Armbands 4800 ist in 48 gezeigt. Das Smart-Armband 4800 beinhaltet eine Aufnahmevorrichtung 4802, in der eine Rechnerkarte 4804 installiert ist. Die Aufnahmevorrichtung 4802 beinhaltet ein oder mehrere Mikrofone 4806, eine Kopfhörersteckeraufnahme 4808, die dazu konfiguriert ist, mit einem Kopfhörerstecker zu interagieren, und einen oder mehrere optionale Lautsprecher 4810. Bei einer Ausführungsform ist die Kopfhörersteckeraufnahme 4808 dazu konfiguriert, Signale von einem Mikrofon zu empfangen, das Teil eines tragbaren Headsets 4809 oder dergleichen ist, wie etwa bei Vorrichtungen wie Smartphones bereitgestellt. Intern beinhaltet die Rechnerkarte 4804 einen Softwarecode zum Durchführen einer natürlichen Sprachverarbeitung 4812, Sprach-zu-Text-Umwandlung 4814 und einer Text-zu-Sprach-Umwandlung 4816.
Während des Betriebs des Smart-Armbands 4800 wird ermöglicht, dass ein Benutzer Operationen, die Dinge wie etwa Musikabspielen betreffen, über verbale Steuereingabe steuert, wie etwa spiele „Let it be“ oder „Purple Rain“ ab, „überspringen“, „nächstes“, „zurück“ usw. Im Grunde kann jegliche physische Steuerung für Musikabspielen unter Verwendung entsprechender verbaler Befehle implementiert werden.
49a und 49b zeigen eine Draufsicht und Seitenansicht einer dünnen Docking-Station 4900, in die eine Rechnerkarte 4100 eingefügt ist. Die dünne Docking-Station 4900 beinhaltet einen DC-Leistungseingang 4902, ein Paar von USB-Ports 4904 und 4906, einen HDMI-Port 4908, eine RJ-45-Ethernet-Buchse 4910, einen DisplayPort 4912 und eine Einschalttaste 4914 und LEDs 4916.
Modell für Rechnerkarte von einem Markenhändler
Bei einer Ausführungsform ist eine Rechnerkarte durch einen Markenhändler (oder Drittpartei für den Markenhändler) vorkonfiguriert, um ein Einzelhandelseinkaufserlebnis zu verbessern. Zum Beispiel stellt 50 eine Verwendung einer Lord&Taylor(9-Rechnerkarte 5000 dar, die in einer Docking-Station 4200 installiert ist, die über ein DisplayPort-Kabel 4302 mit einem Monitor 4300 verbunden ist. Bei dem Markenhändlerverwendungsmodell empfängt ein Benutzer eine Rechnerkarte von der Marke von einem Einzelhändler oder kauft eine Rechnerkarte von der Marke von dem Einzelhändler oder einem anderen Geschäft in Person. Bei manchen Fällen ist der Preis für die Rechnerkarte von der Marke reduziert (relativ zu den Kosten von Rechnerkarten ohne Markenbezug mit ähnlicher Leistungsfähigkeit) oder kann sogar kostenlos sein. Bei einer Ausführungsform ist die Software auf der Rechnerkarte dazu konfiguriert, die Webseite des Einzelhändlers automatisch beim Starten der Karte aufzurufen. Zum Beispiel hat in 50 die Software einen Browser unter Verwendung der URL 5002 für die Lord&Taylor®-Einstiegsseite 5004 (z. B. die Seite, zu der der Browser beim Eintritt auf lordandtaylor.com in der Adressleiste des Browsers umgeleitet wird) aufgerufen. Die Home-Seite für den Browser kann auch dazu vorkonfiguriert sein, die Home-Seite oder Einstiegsseite des Einzelhändlers zu verwenden.
Bei einer Ausführungsform werden die Zugangsinformationen des Benutzers basierend auf den mit der Karte assoziierten Benutzerinformationen vorbesetzt. Bei einer Ausführungsform können Einkäufe unter Verwendung des Fingerabdrucklesegeräts authentifiziert werden, was eine zusätzliche Sicherheitsebene bereitstellt. Jede Karte hat eine UUID (wie etwa eine Benutzerkontonummer oder eine alphanumerische Kette). Bei einer Ausführungsform wird die UUID verwendet, um die Online-Verwendung der Rechnerkarte mit dem Einzelhändler zu verfolgen. Zum Beispiel kann ein Servlet für die Webseite eine HTTP-Anforderung an die Client-Hostvorrichtung senden, die nach einer UUID fragt, oder während eines anfänglichen Handshakes mit der Webseite kann die UUID in einem/einer HTTP-Header oder -Nachricht bereitgestellt werden.
Weitere Aspekte des hierin beschriebenen Gegenstands sind in den folgenden nummerierten Abschnitten dargelegt:

1. Eine Rechnerkarte, die näherungsweise die gleichen Breiten- und Höhenabmessungen wie eine Standardkreditkarte aufweist und dazu konfiguriert ist, ein Desktop-Betriebssystem und eine oder mehrere Anwendungen auszuführen, wobei die Rechnerkarte ferner zu Folgendem konfiguriert ist:
- Ausführen des Betriebssystems und wenigstens einer Anwendung, wenn sie in einer ersten Hosteinrichtung installiert ist;
- Detektieren, dass die Rechnerkarte aus der ersten Hosteinrichtung entfernt wird, Speichern eines momentanen Operationszustands des Betriebssystems und der wenigstens einen Anwendung und Setzen der Rechnerkarte in einen Ruhezustand,
- als Reaktion darauf, dass sie in der ersten Hosteinrichtung oder einer zweiten Hosteinrichtung installiert wird;
- Aufwecken aus dem Ruhezustand und Fortsetzen der Operation des Betriebssystems und der wenigstens einen Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der ersten Hosteinrichtung entfernt wurde.
2. Die Rechnerkarte aus Abschnitt 1, wobei die erste Hosteinrichtung mit einem ersten Satz aus Tastatur-, Video- und Maus(KVM)-Ressourcen assoziiert ist und die zweite Hosteinrichtung mit einem zweiten Satz von KVM-Ressourcen assoziiert ist, wobei die Tastatur- und/oder Video- und/oder Mausressource in dem ersten und zweiten Satz von KVM-Ressourcen verschieden ist und wobei die Rechnerkarte ferner dazu konfiguriert ist, sich selbst als Reaktion darauf, dass sie in der zweiten Hosteinrichtung installiert wird, zu rekonfigurieren, um den zweiten Satz von KVM-Ressourcen zu verwenden.
3. Die Rechnerkarte aus Abschnitt 1 oder 2, wobei die Rechnereinrichtung, wenn sie in der zweiten Hosteinrichtung installiert wird, ferner zu Folgendem konfiguriert ist:
- Abfragen der zweiten Hosteinrichtung, um jede der KVM-Ressourcen zu bestimmen, die mit der zweiten Hosteinrichtung assoziiert sind; und
- Rekonfigurieren von wenigstens einem Betriebssystemtreiber, der mit einer KVM-Ressource assoziiert ist, die mit der zweiten Host-Einrichtung assoziiert ist und verschieden von einer entsprechenden KVM-Ressource ist, die mit der ersten Hosteinrichtung assoziiert ist.
4. Die Rechnerkarte aus einem der vorhergehenden Abschnitte, wobei die Rechnereinrichtung einen USB-Typ-C-Verbinder beinhaltet und dazu konfiguriert ist, bei Installation in einer Hosteinrichtung mit einem USB-Typ-C-Stecker zusammengefügt zu werden.
5. Die Rechnerkarte aus Abschnitt 4, wobei die Rechnereinrichtung dazu konfiguriert ist, DisplayPort-Grafiksignale zu erzeugen, die über den USB-Typ-C-Verbinder an eine Videoanzeigevorrichtung gesendet werden.
6. Die Rechnerkarte aus einem der vorhergehenden Abschnitte, wobei die erste und/oder zweite Hosteinrichtung eine Klappgehäuseeinrichtung mit eingebauter Tastatur, eingebautem Videobildschirm und wenigstens einer eingebauten Zeigervorrichtung umfasst und die Rechnerkarte dazu konfiguriert ist, in einem Steckplatz in der Klappgehäuseeinrichtung installiert zu werden.
7. Die Rechnerkarte aus einem der vorhergehenden Abschnitte, wobei die Rechnerkarte dazu konfiguriert ist, in einem ersten Steckplatz einer Doppelsteckplatzhosteinrichtung installiert zu werden, die eine zweite Rechnerkarte in einem zweite Steckplatz installiert aufweist, und wobei die Rechnerkarte eine Logik zum Ermöglichen des Klonens der Rechnerkarte zu der zweiten Rechnerkarte beinhaltet.
8. Die Rechnerkarte aus einem der vorhergehenden Abschnitte, wobei die Rechnerkarte dazu konfiguriert ist, in einem ersten Steckplatz einer Doppelsteckplatzhosteinrichtung installiert zu werden, die eine zweite Rechnerkarte in einem zweiten Steckplatz installiert aufweist, und wobei die Rechnerkarte eine Logik zum Ermöglichen einer Migration zu der zweiten Rechnerkarte beinhaltet.
9. Die Rechnerkarte aus einem der vorhergehenden Abschnitte, wobei die Rechnerkarte dazu konfiguriert ist, in einem ersten Steckplatz einer Doppelsteckplatzhosteinrichtung installiert zu werden, die eine zweite Rechnerkarte in einem zweiten Steckplatz installiert aufweist, und wobei die Rechnerkarte eine Logik zum Ermöglichen einer Migration für die zweite Rechnerkarte zu der Rechnerkarte beinhaltet.
10. Eine Rechnerkarte, die Folgendes umfasst:
- ein Gehäuse, das eine Hauptplatine mit mehreren daran montierten Komponenten und Verdrahtungspfaden, die die mehreren Komponenten elektrisch koppeln, enthält, wobei die Komponenten Folgendes beinhalten:
  - einen Universal-Serial-Bus(USB)-Typ-C-Verbinder;
  - ein Prozessor-System-on-Chip(SoC), das einen Grafikprozessor zum Erzeugen von Videografikdaten und mehrere Eingabe/Ausgabe(E/A)-Schnittstellen einschließlich einer DisplayPort-Schnittstelle und wenigstens einer USB-Schnittstelle beinhaltet;
  - eine Schnittstellenschaltungsanordnung, die Signalleitungen, die mit dem USB-Typ-C-Verbinder assoziiert sind, mit entsprechenden Schnittstellen auf dem Prozessor-SoC einschließlich der DisplayPort-Schnittstelle und wenigstens einer USB-Schnittstelle operativ koppelt;
  - einen dynamischen Direktzugriffsspeicher (DRAM), der kommunikativ mit dem Prozessor-SoC gekoppelt ist;
  - eine nichtflüchtige Speichervorrichtung, die operativ mit dem Prozessor-SoC gekoppelt ist und darin gespeicherte Anweisungen aufweist, die dazu konfiguriert sind, auf dem Prozessor-SoC ausgeführt zu werden, wobei die Anweisungen ein Desktop-Betriebssystem beinhalten, wobei die Anweisungen bei Ausführung ermöglichen, dass die Rechnerkarte wenn sie mit einem USB-Typ-C-Stecker in einer Hosteinrichtung gekoppelt ist, Folgendes durchführt:
    - Senden von DisplayPort-Videosignalen an einen Videobildschirm, der in der Hosteinrichtung eingebaut ist, und/oder einen Videomonitor, der kommunikativ mit der Hosteinrichtung gekoppelt ist; und
    - Empfangen einer Tastatureingabe von einer Tastatur, die in der Hosteinrichtung eingebaut ist, oder einer Tastatur, die kommunikativ mit der Hosteinrichtung gekoppelt ist; und
    - Empfangen einer Zeigervorrichtungseingabe von einer Zeigervorrichtung, die in der Hosteinrichtung eingebaut ist, und/oder einer Zeigervorrichtung, die kommunikativ mit der Hosteinrichtung gekoppelt ist.
11. Die Rechnerkarte aus Abschnitt 10, wobei die Rechnerkarte eine Breite und Höhe aufweist, die näherungsweise gleich einer Standardkreditkarte sind.
12. Die Rechnerkarte aus Abschnitt 10 oder 11, wobei die Anweisungen Anweisungen beinhalten, die einem Desktop-Betriebssystem entsprechen.
13. Die Rechnerkarte aus Abschnitt 12, wobei das Desktop-Betriebssystem ein Microsoft-Windows-Betriebssystem ist.
14. Die Rechnerkarte aus Abschnitt 12, wobei die Anweisungen ferner eine oder mehrere Anwendungen beinhalten und wobei eine Ausführung der Anweisungen ermöglicht, dass die Rechnerkarte Folgendes durchführt:
- Ermöglichen einer Operation des Betriebssystems und wenigstens einer Anwendung unter Verwendung einer Hosteinrichtung;
- als Reaktion auf das Entfernen der Rechnerkarte aus der ersten Hosteinrichtung Speichern eines momentanen Zustands des Betriebssystems und wenigstens einer Anwendung und Setzen des Prozessor-SoC in einen Ruhezustand;
- als Reaktion auf das Reinstallieren der Rechnerkarte in der Hosteinrichtung Aufwecken des Prozessor-SoC und Fortsetzen der Operation des Betriebssystems und der wenigstens einen Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der Hosteinrichtung entfernt wurde.
15. Die Rechnerkarte aus Abschnitt 12, wobei die Anweisungen ferner eine oder mehrere Anwendungen beinhalten und wobei eine Ausführung der Anweisungen ermöglicht, dass die Rechnerkarte Folgendes durchführt:
- Ermöglichen einer Operation des Betriebssystems und wenigstens einer Anwendung unter Verwendung einer ersten Hosteinrichtung, wobei die erste Hosteinrichtung assoziierte Tastatur-, Video- und Maus(KVM)-Ressourcen aufweist, die eine eingebaute Tastatur, einen eingebauten Videobildschirm und wenigstens eine eingebaute Zeigevorrichtung oder eine externe Tastatur, einen externen Videomonitor und wenigstens eine externe Zeigevorrichtung umfasst, die kommunikativ mit der ersten Hosteinrichtung gekoppelt sind;
- als Reaktion auf das Entfernen der Rechnerkarte aus der ersten Hosteinrichtung Speichern eines momentanen Zustands des Betriebssystems und wenigstens einer Anwendung und Setzen des Prozessor-SoC in einen Ruhezustand;
- als Reaktion auf das Installieren der Rechnerkarte in einer zweiten Hosteinrichtung, die assoziierte KVM-Ressourcen einschließlich wenigstens einer Tastatur- und/oder Video- und/oder Mausressource, die von den KVM-Ressourcen für die erste Hosteinrichtung verschieden ist, aufweist,
- Aufwecken des Prozessor-SoC,
- Rekonfigurieren der Rechnerkarte, um mit den KVM-Ressourcen zu arbeiten, die mit der zweiten Hosteinrichtung assoziiert sind; und
- Fortsetzen der Operation des Betriebssystems und der wenigstens einen Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der ersten Hosteinrichtung entfernt wurde.
16. Die Rechnerkarte aus Abschnitt 15, wobei eine Ausführung der Anweisungen ferner ermöglicht, dass die Rechnerkarte Folgendes durchführt:
- Abfragen der zweiten Hosteinrichtung, um jede der KVM-Ressourcen zu bestimmen, die mit der zweiten Hosteinrichtung assoziiert sind; und
- Rekonfigurieren von wenigstens einem Betriebssystemtreiber, der mit einer KVM-Ressource assoziiert ist, die mit der zweiten Host-Einrichtung assoziiert ist und verschieden von einer entsprechenden KVM-Ressource ist, die mit der ersten Hosteinrichtung assoziiert ist.
17. Die Rechnerkarte aus einem der Abschnitte 10-16, wobei das Prozessor-SoC eine Ausführung von x86-Anweisungen unterstützt.
18. Die Rechnerkarte aus einem der Abschnitte 10-17, die ferner ein Leistungsuntersystem einschließlich einer Batterie, einer Batterieladeschaltungsanordnung und einer Spannungsregelschaltungsanordnung umfasst, welches dazu konfiguriert ist, Leistung an Komponenten auf der Rechnerkarte zu liefern und wenigstens eine Komponente, die operativ mit dem Prozessor-SoC gekoppelt ist, und wenigstens eine Komponente, die operativ mit dem USB-Typ-C-Verbinder gekoppelt ist, aufweist.
19. Die Rechnerkarte aus einem der Abschnitte 10-18, wobei das Leistungsuntersystem einen integrierten Leistungsverwaltungsschaltkreis (PMIC) beinhaltet und die Schnittstellenschaltungsanordnung den PMIC mit Signalleitungen koppelt, die mit dem USB-Typ-C-Verbinder assoziiert sind.
20. Die Rechnerkarte aus einem der Abschnitte 10-19, die ferner ein Fingerabdrucklesegerät umfasst, das kommunikativ mit dem Prozessor-SoC gekoppelt ist.
21. Ein System, das Folgendes umfasst:
- eine Rechnerkartenhosteinrichtung, die eine Tastatur, einen Videobildschirm und ein Berührungsfeld und/oder einen Berührungsbildschirm, der mit dem Videobildschirm assoziiert ist, einschließt und wenigstens einen Rechnerkartensteckplatz aufweist;
- eine Rechnerkarte, die näherungsweise die gleichen Breiten- und Höhenabmessungen wie eine Standardkreditkarte aufweist und dazu konfiguriert ist, ein Desktop-Betriebssystem und eine oder mehrere Anwendungen auszuführen, wobei die Rechnerkarte, wenn sie in einem Rechnerkartensteckplatz der Rechnerkartenhosteinrichtung installiert ist, ferner zu Folgendem konfiguriert ist:
  - Abfragen der Rechnerkartenhosteinrichtung, um Konfigurationsinformationen zu bestimmen, die der Tastatur, dem Videobildschirm und dem wenigstens Berührungsfeld und einen Berührungsbildschirm entsprechen; und
  - Konfigurieren von Treibern in dem Betriebssystem dazu, zu ermöglichen, dass die Rechnerkarte mit der Tastatur, dem Videobildschirm und dem wenigstens einen Berührungsfeld und Berührungsbildschirm arbeitet.
22. Das System aus Abschnitt 21, wobei die Rechnerkartenhosteinrichtung eine Klappgehäuseeinrichtung umfasst, die eine physische Tastatur und einen Videobildschirm in einen Klappdeckel integriert aufweist.
23. Das System aus Abschnitt 21 oder 22, wobei die Rechnerkartenhosteinrichtung eine Tablet-Einrichtung umfasst, die einen Berührungsbildschirm aufweist und eine virtuelle Tastatur über den Berührungsbildschirm implementiert.
24. Das System aus einem der Abschnitte 21-23, wobei die Rechnerkarte zu Folgendem konfiguriert ist:
- Ausführen des Betriebssystems und wenigstens einer Anwendung, wenn sie in einem Steckplatz der Rechnerkartenhosteinrichtung installiert ist;
- Detektieren, dass die Rechnerkarte aus der Rechnerkartenhosteinrichtung entfernt wird, Speichern eines momentanen Operationszustands des Betriebssystems und der wenigstens einen Anwendung und Setzen der Rechnerkarte in einen Ruhezustand,
- als Reaktion darauf, dass sie in einem Steckplatz in der Rechnerkartenhosteinrichtung installiert wird,
- Aufwecken aus dem Ruhezustand und Fortsetzen der Operation des Betriebssystems und der wenigstens eine Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der Rechnerkartenhosteinrichtung entfernt wurde.
25. Das System aus einem der Abschnitte 21-24, wobei die Rechnerkartenhosteinrichtung einen ersten und zweiten Rechnerkartensteckplatz beinhaltet und wobei die Rechnerkarte dazu konfiguriert ist, einen Klon von sich selbst durch Durchführen einer Klonoperation mit einer zweiten Rechnerkarte zu erschaffen, wenn die erste und zweite Rechnerkarte in jeweiligen Rechnerkartensteckplätzen in der Rechnerkartenhosteinrichtung installiert sind.
26. Mobilrechnervorrichtung, die einen Prozessor umfasst, der operativ mit einer drahtgebundenen und/oder drahtlosen Kommunikationsschnittstelle gekoppelt ist und operativ mit einem Speicher gekoppelt ist, in dem computerlesbare Anweisungen gespeichert sind, die, wenn sie durch den Prozessor ausgeführt werden, bewirken, dass die Mobilrechnervorrichtung Folgendes durchführt:
- Herstellen einer Link-Verbindung mit einer zweiten Vorrichtung, die eine Anzeige und ein Betriebssystem aufweist, das native Grafikbefehle einsetzt, um Inhalt zu der Anzeige zu rendern; und
- Werfen von nativen Grafikbefehlen zu der zweiten Vorrichtung.
27. Die Mobilrechnervorrichtung aus Abschnitt 26, wobei die zweite Vorrichtung eine Android-Vorrichtung umfasst und die nativen Grafikbefehle OpenGL-Befehle beinhalten.
28. Die Mobilrechnervorrichtung aus Abschnitt 27, wobei die nativen Grafikbefehle Skia-Befehle beinhalten.
29. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-28, wobei die computerlesbare Anweisung ein Microsoft-Windows-Betriebssystem beinhaltet.
30. Die Mobilrechnervorrichtung aus Abschnitt 29, wobei das Microsoft-Windows-Betriebssystem ein Desktop-Betriebssystem umfasst.
31. Die Mobilrechnervorrichtung aus Abschnitt 29, wobei die nativen Grafikbefehle DirectX-Grafikbefehle beinhalten.
32. Die Mobilrechnervorrichtung aus Abschnitt 31, wobei die nativen Grafikbefehle GDI(Graphics Display Interface - Grafikanzeigeschnittelle)- und/oder GDI+-Zeichenbefehle beinhalten.
33. Die Mobilrechnervorrichtung aus Abschnitt 29, wobei die zweite Vorrichtung eine Android-Vorrichtung umfasst und die nativen Grafikbefehle native Android-Grafikbefehle beinhalten.
34. Die Mobilrechnervorrichtung aus Abschnitt 33, wobei die Anweisungen ein Modul beinhalten, das zum Umwandeln nativer Windows-Grafikbefehle einschließlich DirectX-Befehlen in native Android-Grafikbefehle einschließlich OpenGL-Befehlen und Werfen der OpenGL-Befehle zu der Android-Vorrichtung konfiguriert ist.
35. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-34, wobei die drahtgebundene und/oder drahtlose Kommunikationsschnittstelle eine Universal-Serial-Bus(USB)-Schnittstelle umfasst und die Mobilrechnervorrichtung mit der zweiten Vorrichtung über ein USB-Kabel verlinkt ist.
36. Die Mobilrechnervorrichtung aus Abschnitt 35, wobei der Link zwischen der Mobilrechnervorrichtung und der zweiten Rechnervorrichtung einen oder mehrere Sockets umfasst, die über den USB-Link implementiert sind.
37. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-36, wobei die drahtgebundene und/oder drahtlose Kommunikationsschnittstelle eine High-Definition-Media-Interface(HDMI)-Schnittstelle umfasst.
38. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-37, wobei die drahtgebundene und/oder drahtlose Kommunikationsschnittstelle eine IEEE-802.11-basierte Drahtlosschnittstelle umfasst.
39. Die Mobilrechnervorrichtung aus Abschnitt 38, wobei die Mobilrechnervorrichtung und die zweite Vorrichtung über einen Peer-to-Peer-Wi-Fi-Direct-Link gekoppelt sind.
40. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-39, wobei die Mobilrechnervorrichtung und die zweite Vorrichtung über eine INTEL-Wireless-Display(WiDi)-Verbindung oder eine INTEL-WiGig(Wireless with Gigabit Capability)-Verbindung gekoppelt sind.
41. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-40, wobei der Prozessor und der Speicher auf einer Prozessorplatine mit Breiten- und Höhenabmessungen montiert sind, die näherungsweise die Größe einer Kreditkarte oder kleiner sind.
42. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-41, wobei die Mobilrechnervorrichtung keine integrierte Anzeige beinhaltet.
43. Die Mobilrechnervorrichtung aus Abschnitt 42, wobei die Anweisungen mehrere Anwendungen beinhalten und wobei eine Ausführung der Anweisungen ermöglicht, dass die Mobilrechnervorrichtung Eingaben von der zweiten Vorrichtung empfängt, um eine Fernsteuerung der mehreren Anwendungen zu ermöglichen.
44. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-43, wobei der Prozessor eine Ausführung von x86-Anweisungen unterstützt.
45. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-44, wobei der Prozessor mehrere Niederleistungskerne beinhaltet.
46. Die Mobilrechnervorrichtung aus einem der Abschnitte 26-45, wobei der Prozessor mehrere kleine Kerne und wenigstens einen großen Kern beinhaltet und der Prozessor dazu konfiguriert ist, in einem Modus mit reduzierter Leistung zu arbeiten, in dem die Ausführung von Anweisungen durch wenigstens einen der mehreren kleinen Kerne durchgeführt wird, und wobei der Prozessor ferner dazu konfiguriert ist, in einem Hochleistungsmodus zu arbeiten, in dem die Ausführung von Anweisungen durch wenigstens einen großen Kern durchgeführt wird.
47. Eine Mobilrechnervorrichtung, die Folgendes umfasst:
- eine Prozessorplatine, die Folgendes beinhaltet:
  - einen Prozessor;
  - eine drahtgebundene und/oder eine drahtlose Kommunikationsschnittstelle, die operativ mit dem Prozessor gekoppelt ist;
  - einen Speicher, der operativ mit dem Prozessor gekoppelt ist; und
  - eine nichtflüchtige Speicherung, in der
  - mehrere Anweisungen gespeichert sind, die ein Betriebssystem umfassen,
  - mehrere Anweisungen gespeichert sind, die Anwendungen umfassen, die zum Laufen auf dem Betriebssystem konfiguriert sind; und
  - mehrere Anweisungen gespeichert sind, die mehrere Softwaremodule umfassen,
  - wobei eine Ausführung der Anweisungen ermöglicht, dass die Mobilrechnervorrichtung Folgendes durchführt:
    - Herstellen eines Kommunikations-Links mit einer zweiten Vorrichtung;
    - Abrufen von Daten von der zweiten Vorrichtung und von Daten, die durch eine oder mehrere der mehreren Anwendungen erzeugt werden; und
    - Präsentieren einer einheitlichen Ansicht der Daten, die von der zweiten Vorrichtung abgerufen werden, und der Daten, die durch die eine oder die mehreren der mehreren Anwendungen erzeugt werden.
48. Die Mobilrechnervorrichtung aus Abschnitt 47, wobei die mehreren Module einen Datei-Caching-Agenten beinhalten, der Daten, die erzeugt werden und/oder von der Mobilrechnervorrichtung abgerufen werden, mit einem oder mehreren Cloud-gehosteten Datendiensten synchronisiert.
49. Die Mobilrechnervorrichtung aus Abschnitt 47 oder 48, wobei das Betriebssystem in der Mobilrechnervorrichtung ein erster Typ von Betriebssystem ist, das verschieden von einem Betriebssystem ist, das von der zweiten Mobilrechnervorrichtung verwendet wird.
50. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-49, wobei die Prozessorplatine Breiten- und Höhenabmessungen aufweist, die näherungsweise die Größe einer Kreditkarte oder kleiner sind, und das Betriebssystem Kernel-Komponenten umfasst, die einer vollständigen Version eines Microsoft-Windows-Betriebssystems entsprechen, das dazu konfiguriert ist, auf einem Desktop- oder Laptop-Computer implementiert zu werden.
51. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-50, wobei eine Ausführung der Anweisungen ermöglicht, dass die Mobilrechnervorrichtung Folgendes durchführt:
- Empfangen von Sensordaten von mehreren Sensoren über die drahtgebundene und/oder drahtlose Kommunikationsschnittstelle; und
- sicheres Speichern der Sensordaten auf der Mobilrechnervorrichtung.
52. Die Mobilrechnervorrichtung aus Abschnitt 51, wobei eine Ausführung der Anweisungen ferner ermöglicht, dass die Mobilrechnervorrichtung Folgendes durchführt:
- Verarbeiten wenigstens eines Teils der Sensordaten; und
- Ermöglichen, dass ein Benutzer einen Teil der verarbeiteten Sensordaten selektiv in einem Cloud-gehosteten Dienst veröffentlicht.
53. Die Mobilrechnervorrichtung aus Abschnitt 51, wobei eine Ausführung der Anweisungen ferner ermöglicht, dass die Mobilrechnervorrichtung Folgendes durchführt:
- Verarbeiten wenigstens eines Teils der Sensordaten; und
- Erzeugen von Empfehlungen für einen Benutzer der Mobilrechnervorrichtung basierend auf den Sensordaten, die verarbeitet werden.
54. Die Mobilrechnervorrichtung aus Abschnitt 53, wobei ein Teil der Anweisung eine Analyse-Engine umfasst, die dazu konfiguriert ist, Analysen von Daten von einem Cloud-basierten Dienst zu empfangen und die Analysen der Daten zu verarbeiten, um eine oder mehrere Benutzerempfehlungen zu erzeugen.
55. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-54, wobei die Anweisungen ein sicheres Vorrichtungsdatenverwaltungsmodul beinhalten, das ermöglicht, dass die Mobilrechnervorrichtung, wenn die Anweisungen ausgeführt werden, auf Daten von mehreren verschiedenen Typen von Vorrichtungen zugreift und die Daten sicher speichert, auf die auf der Mobilrechnervorrichtung und/oder einem Cloud-basierten Speicherungsdienst, der für die Mobilrechnervorrichtung zugänglich ist, zugegriffen wird.
56. Die Mobilrechnervorrichtung aus Abschnitt 55, wobei die Ausführung des sicheren Vorrichtungsdatenverwaltungsmoduls ermöglicht, dass die Mobilrechnervorrichtung auf Daten von mehreren verschiedenen Cloud-basierten Diensten zugreift und die Daten sicher speichert, auf die auf der Mobilrechnervorrichtung und/oder einem Cloud-basierten Speicherungsdienst, der für die Mobilrechnervorrichtung zugänglich ist, zugegriffen wird.
57. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-56, wobei die Anweisungen eine Integrator-und-Analyse-Engine und mehrere Anwendungsprogrammschnittstellen (APIs) umfassen, die dazu konfiguriert sind, bei Ausführung zu ermöglichen, dass die Mobilrechnervorrichtung Folgendes durchführt:
- Empfangen von Eingaben von mehreren Sensoren;
- Integrieren und Analysieren der Eingaben von den mehreren Sensoren;
- Ausgeben von Daten, die integriert und/oder analysiert wurden, an die mehreren APIs,
- wobei die mehreren APIs dazu konfiguriert sind, zu ermöglichen, dass Drittanbieteranwendungen auf die Daten zugreifen, die zu den APIs ausgegeben werden.
58. Die Mobilrechnervorrichtung aus Abschnitt 57, wobei eine Ausführung der Anweisungen ermöglicht, dass die Mobilrechnervorrichtung ein persönliches Analyseverwendungsmodell implementiert, das Folgendes beinhaltet:
- Sammeln von Erfassungsdaten von mehreren Verwendungskategorien;
- Integrieren der gesammelten Erfassungsdaten über wenigstens zwei der mehreren Verwendungskategorien; und
- Erzeugen von Empfehlungen für jede der mehreren Verwendungskategorien.
59. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-58, wobei die Mobilrechnervorrichtung keine integrale Anzeige beinhaltet und wobei die einheitliche Ansicht der Daten durch die Mobilrechnervorrichtung präsentiert wird, die Grafikbefehle zu der zweiten Vorrichtung wirft.
60. Die Mobilrechnervorrichtung aus Abschnitt 59, wobei die Mobilrechnervorrichtung dazu konfiguriert ist, native Windows-Grafikbefehle einschließlich DirectX-Befehlen zu der zweiten Vorrichtung zu werfen.
61. Die Mobilrechnervorrichtung aus Abschnitt 59, wobei die zweite Vorrichtung eine Android-Vorrichtung ist, die einen Android-Grafik-Catcher beinhaltet, wobei das Betriebssystem ein Microsoft-Windows-Betriebssystem umfasst und wobei die Mobilrechnervorrichtung dazu konfiguriert ist, native Windows-Grafikbefehle einschließlich DirectX-Befehlen in native Android-Grafikbefehle einschließlich OpenGL-Befehlen umzuwandeln und die OpenGL-Befehle zu dem Android-Grafik-Catcher zu werfen.
62. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-61, wobei die drahtgebundene und/oder drahtlose Kommunikationsschnittstelle, die operativ mit dem Prozessor gekoppelt ist, eine Universal-Serial-Bus(USB)-Schnittstelle umfasst und wobei das Herstellen eines Kommunikations-Links mit einer zweiten Vorrichtung Implementieren von wenigstens einem Socket über einen USB-Link zwischen der Mobilrechnervorrichtung und der zweiten Vorrichtung umfasst.
63. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-62, wobei die Mobilrechnervorrichtung eine Rechnerkarte einschließlich eines Gehäuses umfasst, in dem die Prozessorplatine angeordnet ist, wobei die Prozessorplatine einen Randverbinder beinhaltet und das Gehäuse so konfiguriert ist, dass der Randverbinder extern zu dem Gehäuse ist, und die Rechnerkarte Breiten- und Höhenabmessungen aufweist, die näherungsweise die Größe der Breite und Höhe einer Kreditkarte oder kleiner sind.
64. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-64, wobei der Prozessor eine Ausführung von x86-Anweisungen unterstützt.
65. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-64, wobei der Prozessor mehrere kleine Kerne und wenigstens einen großen Kern beinhaltet und der Prozessor dazu konfiguriert ist, in einem Modus mit reduzierter Leistung zu arbeiten, in dem die Ausführung von Anweisungen durch wenigstens einen der mehreren kleinen Kerne durchgeführt wird, und wobei der Prozessor ferner dazu konfiguriert ist, in einem Hochleistungsmodus zu arbeiten, in dem die Ausführung von Anweisungen durch wenigstens einen großen Kern durchgeführt wird.
66. Die Mobilrechnervorrichtung aus einem der Abschnitte 47-65, wobei der Prozessor mehrere Niederleistungskerne beinhaltet.

Obwohl einige Ausführungsformen unter Bezugnahme auf bestimmte Implementierungen beschrieben wurden, sind andere Implementierungen gemäß einigen Ausführungsformen möglich. Außerdem müssen die Anordnung und/oder Reihenfolge von Elementen oder anderen Merkmalen, die in den Zeichnungen veranschaulicht und/oder hier beschrieben sind, nicht auf die bestimmte veranschaulichte und beschriebene Weise angeordnet sein. Viele andere Anordnungen sind gemäß einigen Ausführungsformen möglich.
In jedem in einer Figur gezeigten System können die Elemente in einigen Fällen jeweils eine gleiche Bezugsziffer oder eine unterschiedliche Bezugsziffer aufweisen, um anzudeuten, dass die repräsentierten Elemente unterschiedlich und/oder ähnlich sein könnten. Jedoch kann ein Element flexibel genug sein, um unterschiedliche Implementierungen aufzuweisen und mit einigen oder allen der hier gezeigten oder beschriebenen Systeme zu arbeiten. Die in den Figuren gezeigten verschiedenen Elemente können die gleichen oder unterschiedliche sein. Welches als ein erstes Element bezeichnet wird, und welches ein zweites Element genannt wird, ist willkürlich.
In der Beschreibung und in den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ zusammen mit ihren Ableitungen verwendet werden. Es sollte klargestellt werden, dass diese Begriffe nicht als Synonyme füreinander beabsichtigt sind. Stattdessen kann bei bestimmten Ausführungsformen „verbunden“ verwendet werden, um anzugeben, dass sich zwei oder mehr Elemente in direktem physikalischen oder elektrischen Kontakt miteinander befinden. „Gekoppelt“ kann bedeuten, dass sich zwei oder mehr Elemente in direktem physikalischen oder elektrischen Kontakt befinden. Allerdings kann „gekoppelt“ auch bedeuten, dass sich zwei oder mehr Elemente nicht in direktem Kontakt miteinander befinden, aber dennoch zusammenwirken oder miteinander interagieren.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Ein Verweis in der Beschreibung auf „eine Ausführungsform“, „(genau) eine Ausführungsform“ „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Charakteristik, das bzw. die in Verbindung mit den Ausführungsformen beschrieben wird, in wenigstens einigen Ausführungsformen, aber nicht notwendigerweise allen Ausführungsformen der Erfindungen enthalten ist. Die verschiedenen Auftritte von „einer Ausführungsform“, „(genau) einer Ausführungsform“ oder „einigen Ausführungsformen“ beziehen sich nicht notwendigerweise alle auf die gleichen Ausführungsformen.
Nicht alle hier beschriebenen und veranschaulichten Komponenten, Merkmale, Strukturen, Charakteristiken usw. müssen in einer bestimmten Ausführungsform oder bestimmten Ausführungsformen enthalten sein. Falls die Spezifikation angibt, dass zum Beispiel eine Komponente, ein Merkmal, eine Struktur oder eine Charakteristik enthalten sein „kann“ oder „könnte“, muss diese bestimmte Komponente, diese bestimmte Merkmal, diese bestimmte Struktur oder diese bestimmte Charakteristik nicht enthalten sein. Falls sich die Beschreibung oder der Anspruch auf „ein“ Element bezieht, bedeutet dies nicht, dass es nur eines von dem Element gibt. Falls sich die Beschreibung oder die Ansprüche auf „ein zusätzliches“ Element beziehen, schließt dies nicht aus, dass es mehr als eines des zusätzlichen Elements gibt.
Ein Algorithmus wird hier und allgemein als eine selbstkonsistente Sequenz von Vorgängen oder Operationen betrachtet, die zu einem angestrebten Ergebnis führt. Diese beinhalten physikalische Manipulationen physikalischer Größen. Üblicherweise, jedoch nicht notwendigerweise, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Es hat sich bisweilen, hauptsächlich aus Gründen der üblichen Verwendung, als zweckmäßig erwiesen, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen zu bezeichnen. Es sollte jedoch klargestellt werden, dass alle diese und ähnliche Begriffe den geeigneten physikalischen Größen zugeordnet werden sollen und lediglich auf diese Größen angewendete zweckmäßige Bezeichnungen sind.
Wie oben diskutiert, können verschiedene Aspekte der Ausführungsformen hier durch entsprechende Software- und/oder Firmwarekomponenten und -anwendungen, wie zum Beispiel von einem eingebetteten Prozessor oder dergleichen ausgeführte Software und/oder Firmware, ermöglicht werden. Somit können Ausführungsformen dieser Erfindung als ein Softwareprogramm, Softwaremodule, Firmware und/oder verteilte Software, die auf einer Art von Prozessor, Verarbeitungskern oder eingebetteter Logik einer virtuellen Maschine, die auf einem Prozessor oder Kern läuft oder auf oder in einem computerlesbaren oder maschinenlesbaren nichtflüchtigen Speicherungsmedium anderweitig implementiert oder realisiert ist, ausgeführt werden, verwendet werden oder diese unterstützen. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium beinhaltet jeglichen Mechanismus zur Speicherung oder zum Übertragen von Informationen in einer Form, die von einer Maschine (zum Beispiel einem Computer) gelesen werden kann. Zum Beispiel beinhaltet ein computerlesbares oder maschinenlesbares, nichtflüchtiges Speicherungsmedium einen beliebigen Mechanismus, der Informationen in einer Form bereitstellt (das heißt speichert und/oder überträgt), auf die ein Computer oder eine Rechnermaschine (zum Beispiel Rechnergerät, elektronisches System usw.), wie zum Beispiel beschreibbare/nicht beschreibbare Medien (zum Beispiel Read-Only-Memory (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeicherungsmedien, optische Speicherungsmedien, Flash-Speichergeräte usw.), zugreifen kann. Der Inhalt kann direkt ausführbar („Objekt-“ oder „ausführbare“ Form), Quellcode oder Differenzcode („Delta“- oder „Patch“-Code) sein. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium kann auch eine Speicherung oder eine Datenbank beinhalten, von der Inhalt heruntergeladen werden kann. Das computerlesbare oder maschinenlesbare nichtflüchtige Speicherungsmedium kann auch ein Gerät oder ein Produkt beinhalten, auf dem zum Zeitpunkt des Verkaufs oder der Lieferung Inhalt gespeichert ist. Somit kann das Liefern eines Geräts mit gespeichertem Inhalt oder das Anbieten von Inhalt zum Herunterladen über ein Kommunikationsmedium so verstanden werden, dass ein Herstellungsartikel bereitgestellt wird, der ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium mit solchem hier beschriebenen Inhalt umfasst.
Verschiedene hier beschriebene Komponenten, die oben als Prozesse, Server oder Werkzeuge bezeichnet werden, können ein Mittel zum Ausführen der beschriebenen Funktionen sein. Die von verschiedenen hier beschriebenen Komponenten ausgeführten Operationen und Funktionen können durch Software implementiert werden, die auf einem Verarbeitungselement, über eingebettete Hardware oder dergleichen, oder einer beliebigen Kombination von Hardware und Software läuft. Solche Komponenten können als Softwaremodule, Hardwaremodule, Spezialhardware (zum Beispiel anwendungsspezifische Hardware, ASICs, DSPs usw.), eingebettete Steuerungen, fest verdrahtete Schaltungen, Hardwarelogik usw. implementiert werden. Softwareinhalt (zum Beispiel Daten, Anweisungen, Konfigurationsinformationen usw.) können über einen Herstellungsartikel bereitgestellt werden, der ein computerlesbares oder maschinenlesbares nichtflüchtiges Speicherungsmedium beinhaltet, das Inhalt bereitstellt, der Anweisungen darstellt, die ausgeführt werden können. Der Inhalt kann zur Folge haben, dass ein Computer verschiedene hier beschriebene Funktionen/Operationen durchführt.
Wie hier verwendet, kann eine Auflistung von durch den Ausdruck „wenigstens eines von“ verbundenen Gegenständen jegliche Kombination der aufgelisteten Begriffe bedeuten. Beispielsweise kann die Phrase „wenigstens eines von A, B oder C“ A; B; C; A und B; A und C; B und C oder A, B und C bedeuten.
Die obige Beschreibung veranschaulichter Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, soll nicht erschöpfend sein oder die Erfindung auf die offenbarten präzisen Formen beschränken. Obgleich spezielle Ausführungsformen und Beispiele für die Erfindung hier zu veranschaulichenden Zwecken beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Geltungsbereichs der Erfindung möglich, wie Fachleute auf dem betreffenden Gebiet erkennen werden.
Diese Modifikationen können angesichts der obigen ausführlichen Beschreibung an der Erfindung vorgenommen werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so ausgelegt werden, dass sie die Erfindung auf die bestimmten in der Beschreibung und den Zeichnungen offenbarten Ausführungsformen beschränken. Vielmehr soll der Geltungsbereich der Erfindung vollständig durch die folgenden Ansprüche bestimmt werden, die gemäß eingeführter Lehren für die Anspruchsinterpretation ausgelegt werden sollen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62152929 [0001]

Claims

Rechnerkarte, die näherungsweise die gleichen Breiten- und Höhenabmessungen wie eine Standardkreditkarte aufweist und dazu konfiguriert ist, ein Desktop-Betriebssystem und eine oder mehrere Anwendungen auszuführen, wobei die Rechnerkarte ferner zu Folgendem konfiguriert ist: Ausführen des Betriebssystems und wenigstens einer Anwendung, wenn sie in einer ersten Hosteinrichtung installiert ist; Detektieren, dass die Rechnerkarte aus der ersten Hosteinrichtung entfernt wird, Speichern eines momentanen Operationszustands des Betriebssystems und der wenigstens einen Anwendung und Setzen der Rechnerkarte in einen Ruhezustand, als Reaktion darauf, dass sie in der ersten Hosteinrichtung oder einer zweiten Hosteinrichtung installiert wird; Aufwecken aus dem Ruhezustand und Fortsetzen der Operation des Betriebssystems und der wenigstens einen Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der ersten Hosteinrichtung entfernt wurde.
Rechnerkarte nach Anspruch 1, wobei die erste Hosteinrichtung mit einem ersten Satz aus Tastatur-, Video- und Maus(KVM)-Ressourcen assoziiert ist und die zweite Hosteinrichtung mit einem zweiten Satz von KVM-Ressourcen assoziiert ist, wobei die Tastatur- und/oder Video- und/oder Mausressource in dem ersten und zweiten Satz von KVM-Ressourcen verschieden ist und wobei die Rechnerkarte ferner dazu konfiguriert ist, sich selbst als Reaktion darauf, dass sie in der zweiten Hosteinrichtung installiert wird, zu rekonfigurieren, um den zweiten Satz von KVM-Ressourcen zu verwenden.
Rechnerkarte nach Anspruch 1 oder 2, wobei die Rechnereinrichtung, wenn sie in der zweiten Hosteinrichtung installiert wird, ferner zu Folgendem konfiguriert ist: Abfragen der zweiten Hosteinrichtung, um jede der KVM-Ressourcen zu bestimmen, die mit der zweiten Hosteinrichtung assoziiert sind; und Rekonfigurieren von wenigstens einem Betriebssystemtreiber, der mit einer KVM-Ressource assoziiert ist, die mit der zweiten Host-Einrichtung assoziiert ist und verschieden von einer entsprechenden KVM-Ressource ist, die mit der ersten Hosteinrichtung assoziiert ist.
Rechnerkarte nach einem der vorhergehenden Ansprüche, wobei die Rechnereinrichtung einen USB-Typ-C-Verbinder beinhaltet und dazu konfiguriert ist, bei Installation in einer Hosteinrichtung mit einem USB-Typ-C-Stecker zusammengefügt zu werden.
Rechnerkarte nach Anspruch 4, wobei die Rechnereinrichtung dazu konfiguriert ist, DisplayPort-Grafiksignale zu erzeugen, die über den USB-Typ-C-Verbinder an eine Videoanzeigevorrichtung gesendet werden.
Rechnerkarte nach einem der vorhergehenden Ansprüche, wobei die erste und/oder zweite Hosteinrichtung eine Klappgehäuseeinrichtung mit eingebauter Tastatur, eingebautem Videobildschirm und wenigstens einer eingebauten Zeigervorrichtung umfasst und die Rechnerkarte dazu konfiguriert ist, in einem Steckplatz in der Klappgehäuseeinrichtung installiert zu werden.
Rechnerkarte nach einem der vorhergehenden Ansprüche, wobei die Rechnerkarte dazu konfiguriert ist, in einem ersten Steckplatz einer Doppelsteckplatzhosteinrichtung installiert zu werden, die eine zweite Rechnerkarte in einem zweiten Steckplatz installiert aufweist, und wobei die Rechnerkarte eine Logik zum Ermöglichen des Klonens der Rechnerkarte zu der zweiten Rechnerkarte beinhaltet.
Rechnerkarte nach einem der vorhergehenden Ansprüche, wobei die Rechnerkarte dazu konfiguriert ist, in einem ersten Steckplatz einer Doppelsteckplatzhosteinrichtung installiert zu werden, die eine zweite Rechnerkarte in einem zweiten Steckplatz installiert aufweist, und wobei die Rechnerkarte eine Logik zum Ermöglichen einer Migration zu der zweiten Rechnerkarte beinhaltet.
Rechnerkarte nach einem der vorhergehenden Ansprüche, wobei die Rechnerkarte dazu konfiguriert ist, in einem ersten Steckplatz einer Doppelsteckplatzhosteinrichtung installiert zu werden, die eine zweite Rechnerkarte in einem zweiten Steckplatz installiert aufweist, und wobei die Rechnerkarte eine Logik zum Ermöglichen einer Migration für die zweite Rechnerkarte zu der Rechnerkarte beinhaltet.
Rechnerkarte, die Folgendes umfasst: ein Gehäuse, das eine Hauptplatine mit mehreren daran montierten Komponenten und Verdrahtungspfaden, die die mehreren Komponenten elektrisch koppeln, enthält, wobei die Komponenten Folgendes beinhalten: einen Universal-Serial-Bus(USB)-Typ-C-Verbinder; ein Prozessor-System-on-Chip(SoC), das einen Grafikprozessor zum Erzeugen von Videografikdaten und mehrere Eingabe/Ausgabe(E/A)-Schnittstellen einschließlich einer DisplayPort-Schnittstelle und wenigstens einer USB-Schnittstelle beinhaltet; eine Schnittstellenschaltungsanordnung, die Signalleitungen, die mit dem USB-Typ-C-Verbinder assoziiert sind, mit entsprechenden Schnittstellen auf dem Prozessor-SoC einschließlich der DisplayPort-Schnittstelle und wenigstens einer USB-Schnittstelle operativ koppelt; einen dynamischen Direktzugriffsspeicher (DRAM), der kommunikativ mit dem Prozessor-SoC gekoppelt ist; eine nichtflüchtige Speichervorrichtung, die operativ mit dem Prozessor-SoC gekoppelt ist und darin gespeicherte Anweisungen aufweist, die dazu konfiguriert sind, auf dem Prozessor-SoC ausgeführt zu werden, wobei die Anweisungen ein Desktop-Betriebssystem beinhalten, wobei die Anweisungen bei Ausführung ermöglichen, dass die Rechnerkarte, wenn sie mit einem USB-Typ-C-Stecker in einer Hosteinrichtung gekoppelt ist, Folgendes durchführt: Senden von DisplayPort-Videosignalen an einen Videobildschirm, der in der Hosteinrichtung eingebaut ist, und/oder einen Videomonitor, der kommunikativ mit der Hosteinrichtung gekoppelt ist; und Empfangen einer Tastatureingabe von einer Tastatur, die in der Hosteinrichtung eingebaut ist, oder einer Tastatur, die kommunikativ mit der Hosteinrichtung gekoppelt ist; und Empfangen einer Zeigervorrichtungseingabe von einer Zeigervorrichtung, die in der Hosteinrichtung eingebaut ist, und/oder einer Zeigervorrichtung, die kommunikativ mit der Hosteinrichtung gekoppelt ist.
Rechnerkarte nach Anspruch 10, wobei die Rechnerkarte eine Breite und Höhe aufweist, die näherungsweise gleich einer Standardkreditkarte sind.
Rechnerkarte nach Anspruch 10 oder 11, wobei die Anweisungen Anweisungen beinhalten, die einem Desktop-Betriebssystem entsprechen.
Rechnerkarte nach Anspruch 12, wobei das Desktop-Betriebssystem ein Microsoft-Windows-Betriebssystem ist.
Rechnerkarte nach Anspruch 12, wobei die Anweisungen ferner eine oder mehrere Anwendungen beinhalten und wobei eine Ausführung der Anweisungen ermöglicht, dass die Rechnerkarte Folgendes durchführt: Ermöglichen einer Operation des Betriebssystems und wenigstens einer Anwendung unter Verwendung einer Hosteinrichtung; als Reaktion auf das Entfernen der Rechnerkarte aus der ersten Hosteinrichtung Speichern eines momentanen Zustands des Betriebssystems und wenigstens einer Anwendung und Setzen des Prozessor-SoC in einen Ruhezustand; als Reaktion auf das Reinstallieren der Rechnerkarte in der Hosteinrichtung Aufwecken des Prozessor-SoC und Fortsetzen der Operation des Betriebssystems und der wenigstens einen Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der Hosteinrichtung entfernt wurde.
Rechnerkarte nach Anspruch 12, wobei die Anweisungen ferner eine oder mehrere Anwendungen beinhalten und wobei eine Ausführung der Anweisungen ermöglicht, dass die Rechnerkarte Folgendes durchführt: Ermöglichen einer Operation des Betriebssystems und wenigstens einer Anwendung unter Verwendung einer ersten Hosteinrichtung, wobei die erste Hosteinrichtung assoziierte Tastatur-, Video- und Maus(KVM)-Ressourcen aufweist, die eine eingebaute Tastatur, einen eingebauten Videobildschirm und wenigstens eine eingebaute Zeigevorrichtung oder eine externe Tastatur, einen externen Videomonitor und wenigstens eine externe Zeigevorrichtung umfasst, die kommunikativ mit der ersten Hosteinrichtung gekoppelt sind; als Reaktion auf das Entfernen der Rechnerkarte aus der ersten Hosteinrichtung Speichern eines momentanen Zustands des Betriebssystems und wenigstens einer Anwendung und Setzen des Prozessor-SoC in einen Ruhezustand; als Reaktion auf das Installieren der Rechnerkarte in einer zweiten Hosteinrichtung, die assoziierte KVM-Ressourcen einschließlich einer Tastatur- und/oder Video- und/oder Mausressource, die von den KVM-Ressourcen für die erste Hosteinrichtung verschieden ist, aufweist, Aufwecken des Prozessor-SoC, Rekonfigurieren der Rechnerkarte, um mit den KVM-Ressourcen zu arbeiten, die mit der zweiten Hosteinrichtung assoziiert sind; und Fortsetzen der Operation des Betriebssystems und der wenigstens einen Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der ersten Hosteinrichtung entfernt wurde.
Rechnerkarte nach Anspruch 15, wobei eine Ausführung der Anweisungen ferner ermöglicht, dass die Rechnerkarte Folgendes durchführt: Abfragen der zweiten Hosteinrichtung, um jede der KVM-Ressourcen zu bestimmen, die mit der zweiten Hosteinrichtung assoziiert sind; und Rekonfigurieren von wenigstens einem Betriebssystemtreiber, der mit einer KVM-Ressource assoziiert ist, die mit der zweiten Hosteinrichtung assoziiert ist und verschieden von einer entsprechenden KVM-Ressource ist, die mit der ersten Hosteinrichtung assoziiert ist.
Rechnerkarte nach einem der Ansprüche 10-16, wobei das Prozessor-SoC eine Ausführung von x86-Anweisungen unterstützt.
Rechnerkarte nach einem der Ansprüche 10-17, die ferner ein Leistungsuntersystem einschließlich einer Batterie, einer Batterieladeschaltungsanordnung und einer Spannungsregelschaltungsanordnung umfasst, welches dazu konfiguriert ist, Leistung an Komponenten auf der Rechnerkarte zu liefern und wenigstens eine Komponente, die operativ mit dem Prozessor-SoC gekoppelt ist, und wenigstens eine Komponente, die operativ mit dem USB-Typ-C-Verbinder gekoppelt ist, aufweist.
Rechnerkarte nach einem der Ansprüche 10-18, wobei das Leistungsuntersystem einen integrierten Leistungsverwaltungsschaltkreis (PMIC) beinhaltet und die Schnittstellenschaltungsanordnung den PMIC mit Signalleitungen koppelt, die mit dem USB-Typ-C-Verbinder assoziiert sind.
Rechnerkarte nach einem der Ansprüche 10-19, die ferner ein Fingerabdrucklesegerät umfasst, das kommunikativ mit dem Prozessor-SoC gekoppelt ist.
System, das Folgendes umfasst: eine Rechnerkartenhosteinrichtung, die eine Tastatur, einen Videobildschirm und ein Berührungsfeld und/oder einen Berührungsbildschirm, der mit dem Videobildschirm assoziiert ist, einschließt und wenigstens einen Rechnerkartensteckplatz aufweist; eine Rechnerkarte, die näherungsweise die gleichen Breiten- und Höhenabmessungen wie eine Standardkreditkarte aufweist und dazu konfiguriert ist, ein Desktop-Betriebssystem und eine oder mehrere Anwendungen auszuführen, wobei die Rechnerkarte, wenn sie in einem Rechnerkartensteckplatz der Rechnerkartenhosteinrichtung installiert ist, ferner zu Folgendem konfiguriert ist: Abfragen der Rechnerkartenhosteinrichtung, um Konfigurationsinformationen zu bestimmen, die der Tastatur, dem Videobildschirm und dem wenigstens einen Berührungsfeld und Berührungsbildschirm entsprechen; und Konfigurieren von Treibern in dem Betriebssystem dazu, zu ermöglichen, dass die Rechnerkarte mit der Tastatur, dem Videobildschirm und dem wenigstens einen Berührungsfeld und Berührungsbildschirm arbeitet.
System nach Anspruch 21, wobei die Rechnerkartenhosteinrichtung eine Klappgehäuseeinrichtung umfasst, die eine physische Tastatur und einen Videobildschirm in einen Klappdeckel integriert aufweist.
System nach Anspruch 21 oder 22, wobei die Rechnerkartenhosteinrichtung eine Tablet-Einrichtung umfasst, die einen Berührungsbildschirm aufweist und eine virtuelle Tastatur über den Berührungsbildschirm implementiert.
System nach einem der Ansprüche 21-23, wobei die Rechnerkarte zu Folgendem konfiguriert ist: Ausführen des Betriebssystems und wenigstens einer Anwendung, wenn sie in einem Steckplatz der Rechnerkartenhosteinrichtung installiert ist; Detektieren, dass die Rechnerkarte aus der Rechnerkartenhosteinrichtung entfernt wird, Speichern eines momentanen Operationszustands des Betriebssystems und der wenigstens einen Anwendung und Setzen der Rechnerkarte in einen Ruhezustand, als Reaktion darauf, dass sie in einem Steckplatz in der Rechnerkartenhosteinrichtung installiert wird, Aufwecken aus dem Ruhezustand und Fortsetzen der Operation des Betriebssystems und der wenigstens eine Anwendung in dem gleichen Zustand, in dem das Betriebssystem und die wenigstens eine Anwendung waren, als die Rechnerkarte aus der Rechnerkartenhosteinrichtung entfernt wurde.
System nach einem der Ansprüche 21-24, wobei die Rechnerkartenhosteinrichtung einen ersten und zweiten Rechnerkartensteckplatz beinhaltet und wobei die Rechnerkarte dazu konfiguriert ist, einen Klon von sich selbst durch Durchführen einer Klonoperation mit einer zweiten Rechnerkarte zu erschaffen, wenn die erste und zweite Rechnerkarte in jeweiligen Rechnerkartensteckplätzen in der Rechnerkartenhosteinrichtung installiert sind.