DE102015120189A1

DE102015120189A1 - Darstellen einer Fahrzeit zu und von einem Event in einem elektronischen Kalender

Info

Publication number: DE102015120189A1
Application number: DE102015120189.5A
Authority: DE
Inventors: Suzanne Marion Beaumont; Rod D. Waltermann; Grigori Zaitsev
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2014-11-20
Filing date: 2015-11-20
Publication date: 2016-05-25
Also published as: US20160148163A1; CN105631640A

Abstract

In einem Aspekt umfasst ein Gerät einen Prozessor und einen Speicher, auf den der Prozessor zugreifen kann. Der Speicher enthält Instruktionen, die durch den Prozessor ausführbar sind, um wenigstens eine Fahrzeit zu einem Event vorherzusagen, das in den elektronischen Kalender eingetragen ist, und von dem Event, das in dem elektronischen Kalender angezeigt wird, weg. Die Instruktionen sind auch ausführbar, um die Fahrzeit in dem elektronischen Kalender darzustellen.

Description

I. Gebiet
Die vorliegende Anmeldung bezieht sich im Allgemeinen auf ein Darstellen einer Fahrzeit zu und/oder von einem Event in einem elektronischen Kalender.
II. Hintergrund
Typischerweise gibt ein Nutzer manuell Ereignisse in einen elektronischen Kalender ein (z.B. "blockieren" von Zeit für das Event). Oft berücksichtigt die blockierte Zeit jedoch keine anderen Planungsfaktoren, es sei denn der Nutzer erinnert sich auch daran, sie zu berücksichtigen. Das kann aufwändig sein und wenn es vergessen wird, Terminplanungskonflikte verursachen.
Zusammenfassung
Dementsprechend umfasst ein Gerät in einem Aspekt einen Prozessor und einen Speicher, auf den der Prozessor zugreifen kann. Der Speicher enthält Instruktionen, die durch den Prozessor ausführbar sind, um basierend auf einem ersten Datum und einer ersten Zeit einen ersten Eintrag für ein erstes Event in einen elektronischen Kalender einzutragen, und um wenigstens teilweise basierend auf dem ersten Datum und der ersten Zeit, ein zweites Datum und eine zweite Zeit zu bestimmen, während der ein zweiter Eintrag, der ein persönliches Meeting betrifft, nicht in den elektronischen Kalender eingetragen werden kann.
In einem anderen Aspekt beinhaltet ein Verfahren ein Schätzen einer Fahrzeit wenigstens eines von zu einem in den elektronischen Kalender eingetragenen Event und von dem Event, das in dem elektronischen Kalender angezeigt ist, und ein Darstellen der Zeit zum Fahren in dem elektronischen Kalender.
In noch einem anderen Aspekt enthält ein computerlesbares Speichermedium, das keine Trägerwelle ist, Instruktionen, die durch einen Prozessor ausführbar sind, um Informationen zu identifizieren, die eine Transitzeit wenigstens eines von zu einem Event, das in dem elektronischen Kalender angezeigt ist, und von dem Event, das in dem elektronischen Kalender angezeigt ist, betreffen, und um die Informationen in dem elektronischen Kalender anzuzeigen.
Die Details der vorliegenden Prinzipien sowohl in Bezug auf ihre Struktur als auch ihren Einsatz können besser mit Bezug auf die begleitenden Zeichnungen verstanden werden, in denen sich gleiche Referenzzeichen auf gleiche Elemente beziehen, und wobei:
Kurze Beschreibung der Zeichnungen
1 ein Blockdiagramm eines beispielhaften Systems gemäß den vorliegenden Prinzipien ist;
2 ein Blockdiagramm eines Netzwerks von Geräten gemäß den vorliegenden Prinzipien ist;
3 ein Flussdiagramm, das ein Beispiel eines Algorithmus gemäß den vorliegenden Prinzipien zeigt, ist;
4 bis 7 beispielhafte Nutzerschnittstellen (UI) gemäß den vorliegenden Prinzipien sind; und
8 eine beispielhafte Datentabelle gemäß den vorliegenden Prinzipien ist.
Detaillierte Beschreibung
Diese Offenbarung bezieht sich allgemein auf geräte-basierte Informationen. Mit Bezug auf beliebige der Computersysteme, die hierin erörtert werden, kann ein System Server- und Client-Komponenten umfassen, die über ein Netzwerk derart verbunden sind, dass Daten zwischen den Client- und Server-Komponenten ausgetauscht werden können. Die Client-Komponenten können ein oder mehrere Datenverarbeitungsgeräte umfassen, einschließlich Fernsehern (z.B. Smart-TVs, internetfähige TVs), Computern, wie Desktops, Laptops und Tablet-Computern, sowie sogenannte umrüstbare Geräte (die z.B. eine Tablet-Konfiguration und eine Laptop-Konfiguration aufweisen) und anderen mobilen Geräten, einschließlich Smartphones. Diese Client-Geräte können als nicht-begrenzende Beispiele Betriebssysteme von Apple, Google oder Microsoft betreiben. Ein Unix- oder ähnliches wie ein Linux-Betriebssystem kann benutzt werden. Diese Betriebssysteme können einen oder mehrere Browser ausführen, wie einen Browser, der von Microsoft oder Google oder Mozilla produziert wird, oder andere Browserprogramme, welche auf Web-Anwendungen zugreifen können, die durch Internetserver über ein Netzwerk wie dem Internet, einem lokalen Intranet oder einem virtuellen privaten Netzwerk gehostet werden.
Wie hierin verwendet, beziehen sich Instruktionen auf computerimplementierte Schritte zum Verarbeiten von Informationen in dem System. Instruktionen können in Software, Firmware oder Hardware implementiert sein; daher werden darstellende Komponenten, Blöcke, Module, Schaltkreise und Schritte im Sinne ihrer Funktionalität vorgestellt.
Ein Prozessor kann ein beliebiger konventioneller Einzel- oder Multi-Chip-Prozessor für allgemeine Zwecke sein, der Logik mittels verschiedener Leitungen, wie Adressleitungen, Datenleitungen und Steuerleitungen und Registern und Schieberegistern, ausführen kann. Darüber hinaus können beliebige logischen Blöcke, Module und Schaltkreise, die hierin beschrieben werden, zusätzlich zu einem Prozessor für allgemeine Zwecke, in oder durch einen Digital Signal Processor (DSP), ein Field Programmable Gate Array (FPGA) oder andere programmierbare Logikschaltungen, wie eine anwendungsspezifische integrierte Schaltung (ASIC), diskrete Gate- oder Transistorlogik, diskrete Hardwarekomponenten, oder beliebige Kombinationen davon, welche derart konstruiert sind, dass sie die Funktionen, die hierin beschrieben werden, ausführen, implementiert oder ausgeführt werden. Ein Prozessor kann durch einen Controller oder eine Zustandsmaschine bzw. Logikschaltung oder eine Kombination von Computergeräten implementiert werden.
Beliebige Software und/oder Anwendungen, die mittels Flussdiagrammen und/oder Nutzerschnittstellen hierin beschrieben werden, können verschiedene Unterroutinen, Prozeduren usw. umfassen. Es ist wichtig zu verstehen, dass Logik, die als z.B. durch ein Modul durchführbar veröffentlicht wurde, an andere Software-Module weitergegeben und/oder in einem einzigen Modul zusammengefasst und/oder in einer gemeinsamen Bibliothek zur Verfügung gestellt werden kann.
Wenn Logik in Software implementiert ist, kann sie in einer geeigneten Sprache wie beispielsweise, aber nicht begrenzt auf, C# oder C++ geschrieben sein und kann diese in einem computerlesbaren Speichermedium (das z.B. keine Trägerwelle sein kann) wie einem Arbeitsspeicher (RAM), einem Festwertspeicher (ROM), einem elektrisch löschnar programmierbarem Festwertspeicher (EEPROM), einem Compact-Disk Festwertspeicher (CD-ROM) oder einem anderen optischen Plattenspeicher, wie einer Digital Versatile Disc (DVD), einen magnetischen Plattenspeicher oder anderen magnetischen Speichergeräten, einschließlich entfernbarer Speichersticks usw. gespeichert und übertragen werden. Eine Verbindung kann ein computerlesbares Medium einrichten. Derartige Verbindungen können zum Beispiel fest verdrahtete Leitungen, einschließlich Faseroptiken und Koaxialleitungen und paarweise verdrillte Leitungen, beinhalten. Derartige Verbindungen können drahtlose Kommunikationsverbindungen, einschließlich Infrarot- und Funkverbindungen, beinhalten.
Beispielsweise kann ein Prozessor über seine Eingabeleitungen auf Informationen aus einem Datenspeicher, wie etwa einem computerlesbaren Speichermedium, zugreifen und/oder kann der Prozessor drahtlos auf Informationen von einem Internetserver durch Aktivieren eines drahtlosen Transceivers, um Daten zu senden und zu empfangen, zugreifen. Typischerweise werden Daten wenn sie empfangen werden durch zwischen der Antenne und den Registern des Prozessors angeordnete Schaltungen von analogen zu digitalen Daten konvertiert, und von einem digitalen zu einem analogen Zustand, wenn sie übertagen werden. Der Prozessor verarbeitet dann die Daten durch seine Schieberegister, um berechnete Daten auf Ausgabeleitungen zum Darstellen der berechneten Daten auf dem Gerät auszugeben.
Komponenten, die in einem Ausführungsbeispiel vorhanden sind, können in anderen Ausführungsbeispielen in jeder geeigneten Kombination verwendet werden. Zum Beispiel kann jede der unterschiedlichen Komponenten, die hierin beschrieben werden und/oder in den Figuren gezeigt werden, mit anderen Ausführungsbeispielen kombiniert, ausgetauscht oder von Ausführungsbeispielen ausgeschlossen werden.
"Ein System, das wenigstens eines von A, B und C aufweist" (entsprechend "ein System, das wenigstens eines von A, B oder C aufweist" und "ein System, das wenigstens eines von A, B, C aufweist"), umfasst Systeme, die A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen und/oder A, B und C zusammen, aufweisen, etc.
"Ein System, das eines oder mehrere von A, B und C aufweist" (ähnlich wie "ein System, das eines oder mehrere von A, B oder C aufweist" und "ein System, das eines oder mehrere von A, B, C aufweist"), umfasst Systeme, die A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen und/oder A, B und C zusammen, aufweisen, etc.
Der Ausdruck "Schaltkreis" oder "Schaltung" wird in der Zusammenfassung, der Beschreibung und/oder den Ansprüchen verwendet. Wie im Stand der Technik gut bekannt, umfasst der Ausdruck "Schaltung" alle verfügbareren Integrationsgrade, z.B. von diskreten Logikschaltkreisen bis hin zu dem höchsten Grad der Schaltkreisintegration, wie einer VLSI, und umfasst programmierbare Logikkomponenten, die derart programmiert sind, dass sie die Funktionen eines Ausführungsbeispiels ausführen, sowie von Prozessoren für allgemeine oder spezielle Zwecke, die derart mit Instruktionen programmiert sind, dass sie diese Funktionen ausführen.
Nun insbesondere mit Bezug auf 1, zeigt diese ein beispielhaftes Blockdiagramm eines Informationshandhabungssystems und/oder eines Computersystems 100. Man beachte, das in einigen Ausführungsbeispielen das System 100 ein Desktopcomputersystem sein kann, wie eines der ThinkCentre^® oder ThinkPad^® Serien von Personal Computern, die durch Lenovo (US) Inc. aus Morrisville, NC, verkauft werden, oder eine Workstation, wie die ThinkStation^®, welche durch Lenovo (US) Inc. aus Morrisville, NC, verkauft wird; wie jedoch durch die Beschreibung hierin offensichtlich ist, können ein Client-Gerät, ein Server oder eine andere Maschine gemäß den vorliegenden Prinzipien andere Merkmale oder nur einige der Merkmale des Systems 100 umfassen. Das System 100 kann auch z.B. eine Spielekonsole wie eine XBOX^® oder Playstation^® sein.
Wie in 1 gezeigt, umfasst das System 100 einen sogenannten Chipsatz 110. Ein Chipsatz bezieht sich auf eine Gruppe von integrierten Schaltkreisen, oder Chips, die für ein Zusammenwirken entwickelt sind. Chipsätze werden gewöhnlich als einzelne Produkte vermarktet (Betrachte z.B. Chipsätze, die unter dem Markenzeichen INTEL^®, AMD^® usw. vertrieben werden).
In dem Beispiel der 1 hat der Chipsatz 110 eine bestimmte Architektur, welche in gewissen Grenzen in Abhängigkeit von der Marke und dem Hersteller variieren kann. Die Architektur des Chipsatzes 110 umfasst eine Kern- und Speichersteuergruppe 120 und einen I/O Steuerknoten 150, die Informationen (z.B. Daten, Signale, Anweisungen usw.) über zum Beispiel ein Direct Management Schnittstelle oder Direct Media Schnittstelle (DMI) 142 oder über eine Verbindungssteuerung 144 austauschen. In dem Beispiel der 1 ist die DMI 142 eine Chip-auf-Chip-Schnittstelle (auf die manchmal als eine Verbindung zwischen einer "Northbridge" und einer "Southbridge" bezeichnet wird).
Die Kern- und Speichersteuergruppe 120 umfasst einen oder mehrere Prozessoren 122 (z.B. Einzelkern oder Multikern, usw.) und einen Speichersteuerknoten 126, die Informationen über einen Front Side BUS (FSB) 124 austauschen. Wie hier beschrieben, können verschiedene Komponenten der Kern- und Speichersteuergruppe 120 auf einen einzigen Prozessorchip integriert sein, um zum Beispiel einen Chip herzustellen, der die konventionelle "Northbridge"-artige Architektur ersetzt.
Der Speichersteuerknoten 126 ist mit dem Speicher 140 gekoppelt. Zum Beispiel kann der Speichersteuerknoten 126 eine Unterstützung für einen DDR SDRAM Speicher ermöglichen (z.B. DDR, DDR2, DDR3 usw.). Im Allgemeinen ist der Speicher 140 eine Art Arbeitsspeicher (RAM). Er wird oft als "Systemspeicher" bezeichnet.
Der Speichersteuerknoten 126 umfasst weiterhin eine Low-Voltage Differential Signaling Schnittstelle (LVDS) 132. Die LVDS 132 kann eine sogenannte LVDS-Anzeigeschnittstelle (LDI) zum Unterstützen eines Anzeigegerätes 192 (z.B. ein CRT, ein Flachbildschirm, ein Projektor, eine berührungsempfindliche Anzeige, usw.) sein. Ein Block 138 umfasst einige Beispiele der Technologien, die über die LVDS-Schnittstelle 132 unterstützt werden (z.B. serielles digitales Video, HDMI/DVI, Anzeige-Port). Der Speichersteuerknoten 126 umfasst auch eine oder mehrere PCI-Express-Schnittstellen (PCI-E) 134, zum Beispiel zum Unterstützen von diskreten Grafiken 136. Diskrete Grafiken unter Verwenden einer PCI-E Schnittstelle sind zu einem alternativen Ansatz für einen beschleunigten Grafikknoten (AGP) geworden. Zum Beispiel kann der Speichersteuerknoten 126 einen 16-fachen (x16) PCI-E-Port für eine externe PCI-E-basierende Grafikkarte aufweisen (einschließlich z.B. ein oder mehrere GPUs). Ein Beispielssystem kann eine AGP oder eine PCI-E für die Unterstützung von Grafiken aufweisen.
Der I/O Steuerknoten 150 umfasst eine Vielzahl von Schnittstellen. Das Beispiel der 1 umfasst eine SATA-Schnittstelle 151, eine oder mehrere PCI-E-Schnittstellen 152 (optional eine oder mehrere Legacy-PCI-Schnittstellen), eine oder mehrere USB-Schnittstellen 153, eine LAN-Schnittstelle 154 (allgemeiner gesagt, eine Netzwerkschnittstelle zur Kommunikation über wenigstens ein Netzwerk wie das Internet, ein WAN, ein LAN, usw. unter Leitung des Prozessors bzw. der Prozessoren 122), eine Allzweck-EIN/AUS-Schnittstelle (GPIO) 155, eine Low-Pin-Count-(LPC)Schnittstelle 170, eine Leistungsmanagement-Schnittstelle 161, eine Taktgenerator-Schnittstelle 162, eine Audio-Schnittstelle 163 (z.B. für Lautsprecher 194 zur Ausgabe von Audiosignalen), eine Total Cost of Operation Schnittstelle (TCO) 164, eine System-Management-BUS-Schnittstelle (z.B. ein Multi-Master Serial Computer BUS Interface) 165 und ein Serial Peripheral Flash Memory/Steuerung Schnittstelle(SPI Flash) 166, welches im Beispiel der 1 ein BIOS 168 und Bootcode 190 umfasst. Mit Bezug auf die Netzwerkverbindungen kann der I/O Stuerknoten 150 integrierte Gigabit-Ethernet-Steuerleitungen einschließen, die mit einem PCI-E-Schnittstellen-Port gemultiplext sind. Andere Netzwerkmerkmale können unabhängig von einer PCI-E-Schnittstelle betrieben werden.
Die Schnittstellen des I/O Steuerknoten 150 ermöglichen Kommunikation mit verschiedenen Geräten, Netzwerken, usw. Zum Beispiel ermöglicht die SATA-Schnittstelle 151 ein Lesen, ein Schreiben oder ein Lesen und Schreiben von Informationen auf einem oder mehreren Laufwerken 180, wie HDDs, SDDs oder einer Kombination davon, wobei in jedem Fall aber unter Laufwerken 180 z.B. berührbare, computerlesbare Speichermedien, die keine Trägerwellen sind, verstanden werden. Der I/O Steuerknoten 150 kann auch ein Advanced Host Controller Schnittstelle (AHCI) umfassen, um einen oder mehrere Laufwerke 180 zu unterstützen. Die PCI-E-Schnittstelle 152 ermöglicht drahtlose Verbindungen 182 mit Geräten, Netzwerken, usw. Die USB-Schnittstelle 153 stellt Eingabegeräte 184 wie Keyboards (KB), Mäuse und diverse andere Geräte (z.B. Kameras, Telefone, Speicher, Medienwiedergabegeräte usw.) bereit.
In dem Beispiel der 1 ermöglicht die LPC-Schnittstelle 170 einen Gebrauch von einem oder mehreren ASICs 171, einem Trusted Platform Module (TPM) 172, einem Super-I/O 173, einem Firmenware-Knoten 174, einem BIOS-Support 175 sowie verschiedenen Arten von Speichern 176, wie ROM 177, Flash 178 und nichtflüchtiger RAM (NVRAM) 179. Mit Bezug auf das TPM 172 kann dieses Modul die Form eines Chips, der verwendet werden kann, um Software- und Hardwaregeräte zu authentisieren, aufweisen. Zum Beispiel kann ein TPM in der Lage sein, eine Plattform-Authentifizierung durchzuführen, und kann verwendet werden, um zu verifizieren, dass ein Zugriff suchendes System das erwartete System ist.
Das System 100 kann nach Einschalten derart konfiguriert sein, dass es Bootcode 190 für das BIOS 168, wie in dem SPI-Flash 166 gespeichert, ausführt und danach Daten unter Verwenden der Steuerung eines oder mehrerer Betriebssysteme und Anwendungssoftware (die z.B. in dem Systemspeicher 140 gespeichert ist) verarbeitet. Ein Betriebssystem kann an einer Vielzahl von Orten gespeichert werden und es kann zum Beispiel entsprechend den Instruktionen des BIOS 168 darauf zugegriffen werden.
Weiterhin bezugnehmend auf 1 kann das System 100 einen GPS-Transceiver 191 einschließen, der derart konfiguriert ist, dass er z.B. geografische Positionsinformationen von wenigstens einem Satelliten empfängt und die Informationen dem Prozessor 122 zur Verfügung stellt. Es ist jedoch wichtig zu verstehen, dass ein anderer geeigneter Positionsempfänger, anders als ein GPS-Receiver, gemäß den vorliegenden Prinzipien verwendet werden kann, um z.B. den Ort des Systems 100 zu bestimmen.
Zusätzlich, und obwohl nun zugunsten der Klarheit gezeigt, kann das System 100 in einigen Ausführungsbeispielen ein Gyroskop z.B. zum Wahrnehmen und/oder Messen der Orientierung des Systems 100 und zum Bereitstellen von darauf bezogene Eingaben an den Prozessor 122, einen Beschleunigungsmesser z.B. zum Wahrnehmen einer Beschleunigung und/oder einer Bewegung des Systems 100 und zum Bereitstellen von darauf bezogene Eingaben an den Prozessor 122, einen Audioempfänger/ein Mikrofon zum Bereitstellen einer Eingabe an den Prozessor 122 z.B. basierend auf einem Nutzer, der eine hörbare Eingabe mit dem Mikrofon zur Verfügung stellt, und eine Kamera zum Sammeln von einem oder mehreren Bildern zum Bereitstellen von Eingaben an den Prozessor 122, die sich darauf beziehen, einschließen. Die Kamera kann z.B. eine Thermobildkamera, eine digitale Kamera wie eine Webcam und/oder eine Kamera, die in das System 100 integriert ist und durch den Prozessor 122 zum Sammeln von Bildern und/oder Videos steuerbar ist, sein.
Auch wenn wegen der Klarheit nicht gezeigt, kann das System 100 noch andere Sensoren einschließen, um die vorgestellten Prinzipien einzuhalten, wie z.B. biometrische Sensoren, um Nutzeraktivitäten und biometrische Daten (z.B. Sitzen, Gehen, Herzschlagraten usw.) zu identifizieren, sowie Sensoren zum Wahrnehmen von Umweltfaktoren sowohl von internen als auch externen Räumen (z.B. Temperatursensoren, Umgebungslichtsensoren, usw.).
Bevor weiter zu 2 übergegangen wird, ist wichtig zu verstehen, dass ein Beispiel eines Clientgerätes oder anderer Maschinen/Computer weniger oder mehr Merkmale umfassen kann, als sie bei dem System 100 der 1 gezeigt werden. In jedem Fall ist es wichtig zu verstehen, dass wenigstens basierend auf dem Vorhergehenden das System 100 derart konfiguriert ist, dass es die vorliegenden Prinzipien einhält.
Nun Mit Bezug auf 2, zeigt diese beispielhafte Geräte, die über ein Netzwerk 200 wie z.B. dem Internet, gemäß den vorliegenden Prinzipien kommunizieren. Es ist wichtig zu verstehen, dass z.B. jedes der Geräte, das mit Bezug auf 2 beschrieben wird, wenigstens einige der Merkmale, Komponenten und/oder Elemente des Systems 100, wie oben beschrieben, enthalten kann. In jedem Fall zeigt 2 einen Notebook-Computer 202, einen Desktop-Computer 204, ein tragbares Gerät 206, (wie z.B. eine Smart-Watch, ein Smart-Armband, einen Fitnessmonitor, ein biometrisches Überwachungsgerät, ein Schlafüberwachungsgerät zum Sammeln von Daten über einen Nutzer des Gerätes 206 gemäß den vorgestellten Prinzipien usw.) einen Smart-Fernseher (TV) 208, ein Smartphone 210, einen Tablet-Computer 212 und einen Server 214 gemäß den vorliegenden Prinzipien, wie z.B. einen Internetserver, der z.B. einen Cloud-Speicher, auf welchen die Geräte 202–212 zugreifen können, bereitstellen kann. Es ist wichtig zu verstehen, dass die Geräte 202 bis 214 derart konfiguriert sind, dass sie miteinander über das Netzwerk 200 kommunizieren, um die vorgestellten Prinzipien einzuhalten.
Es ist wichtig zu verstehen, dass ein oder mehrere der Geräte, die in 2 gezeigt werden mit einem einzigen Nutzer wie dem Nutzer eines elektronischen Kalenders, wie hierin beschrieben, assoziiert sind. Nichts desto weniger ist weiter wichtig zu verstehen, dass wenigstens einige der Geräte, die in 2 gezeigt werden, mit verschiedenen Nutzern assoziiert sein können, um somit ein "Crowd Sourcing" von Daten (wie z.B. Umweltfaktoren wie die Temperatur) für das Ausführen der vorliegenden Prinzipien zu ermöglichen.
Bezugnehmend auf 3, zeigt diese eine beispielhafte Logik, die durch ein Gerät wie dem System 100 gemäß den vorliegenden Prinzipien ausgeführt werden kann. Ein Gerät, das die Logik der 3 übernimmt, wird unten der Einfachheit halber als ein "vorliegendes Gerät" bezeichnet. Beginnend beim Block 300 empfängt die Logik eine Eingabe, um einen Eintrag in einen elektronischen Kalender für ein erstes Event, welches zu einem ersten Datum und einer ersten Zeit auftreten soll, zu schaffen. Die Logik geht dann weiter zum Block 302, wo die Logik einen Eintrag in den elektronischen Kalender für das erste Event basierend auf der und/oder in Reaktion auf die Eingabe, die beim Block 300 empfangen wurde, erzeugt.
Nach dem Block 302 geht die Logik weiter zum Block 304. Beim Block 304 sagt die Logik einen oder mehrere Orte voraus, an denen das vorliegende Gerät und/oder der Nutzer (des vorliegenden Gerätes und/oder assoziiert mit dem elektronischen Kalender) vor dem ersten Event und/oder nach dem ersten Event (z.B. allgemein, unmittelbar vor und unmittelbar nach und/oder Schwellwertzeiten bevor und Schwellwertzeiten danach) angeordnet sein wird. Auch beim Block 304 kann die Logik ein oder mehrere Transportmethoden, die der Nutzer zum Fahren verwenden wird, vorhersagen. Die Vorhersage(n) kann(können) beim Block 304, wenigstens teilweise basierend auf Daten in einer Datentabelle, auf die das vorliegende Gerät Zugriff hat, ausgeführt werden. Eine beispielhafte Datentabelle, die gemäß den vorliegenden Prinzipien verwendet werden kann, wird weiter unten mit Bezug auf 8 erörtert.
Weiter mit Bezug auf 3, geht die Logik nach dem Block 304 zu der Entscheidungsraute 306 über. Bei der Raute 306 bestimmt die Logik, ob der(die) Ort(e), an dem das Gerät und/oder der Nutzer vor und nach dem ersten Event sein werden/wird, der(die) beim Block 304 vorhergesagt wird(werden), der gleiche Ort ist, wie der Ort des ersten Events selbst. Z.B. können die Orte vor und nach dem ersten Event sowie der Ort des ersten Events ein Gebäude sein, in dem der Nutzer arbeitet. Eine zustimmende Bestimmung bei der Raute 306 veranlasst die Logik zum Block 308 zu gehen, bei dem die Logik keine zusätzliche Aktion unternimmt, die sich auf den Eintrag des ersten Events in dem elektronischen Kalender bezieht.
Jedoch veranlasst eine negative Bestimmung bei der Raute 306 die Logik anstelle dessen zum Block 310 weiterzugehen, bei dem die Logik die Fahrzeit zu und von dem Ort des ersten Events, basierend auf dem(die) Ort(e), die beim Block 304 vorhergesagt wurde(n), bestimmt. Somit kann die Logik auch beim Block 310 die Fahrzeit zu und von dem Ort des ersten Events bestimmen, basierend auf einem gegenwärtigen Ort des vorliegenden Gerätes und/oder des Nutzers (z.B. wenn die Logik ausführt, was in Bezug auf den Block 310 beschrieben wird zu einer Zeit direkt vor oder nach der Zeit des ersten Events) und/oder der vorhergesagten Transportmethode(n).
Nach dem Block 310 fährt die Logik mit dem Block 312 fort. Beim Block 312 kann die Logik Zeit blockieren, einen Eintrag erzeugen und/oder in anderer Weise einen Zeitraum in dem elektronischen Kalender vor und/oder nach dem ersten Event für die entsprechenden Zeiten zu und von dem Ort des ersten Events reservieren. In einigen Ausführungsbeispielen kann die Logik die Zeit umkehren durch Ändern des ersten Eintrags, welches in dem elektronischen Kalender dargestellt wird, um den Zeitbereich des ersten Events einschließlich der Fahrzeit anzuzeigen. Auch kann die Logik in einigen Ausführungsbeispielen einen neuen Eintrag für die Fahrzeit erzeugen.
Nach Block 312 geht die Logik zum Block 314, wo die Logik in dem elektronischen Kalender anzeigen kann, dass z.B. persönliche (oder alle) Meetings und/oder Events nicht während der Fahrzeit durchgeführt werden können, so dass z.B. eine andere Person, die auf den elektronischen Kalender Zugriff hat, um die Verfügbarkeit des Nutzers des elektronischen Kalenders sicherzustellen, nach einem Anschauen des elektronischen Kalenders des Nutzers feststellen kann, dass der Nutzer während der Fahrzeit nicht für ein Meeting verfügbar ist. Auch kann in einigen Ausführungsbeispielen die Logik in dem elektronischen Kalender beim Block 314 anzeigen, dass z.B. Telefonkommunikationen während der Fahrzeit durchgeführt werden können. Die Logik kann z.B. basierend auf den Nutzereinstellungen für den elektronischen Kalender unter Berücksichtigen, ob der Nutzer wünscht während der Fahrt mit Telefonkommunikationen beschäftigt zu werden, derart verfahren.
Nach Block 314 geht die Logik weiter zum Block 316, wo die Logik fortsetzt den(die) Ort(e) der Anwesenheit des Gerätes zu überwachen, um zu bestimmen, ob (z.B. basierend auf einem gegenwärtigen Ort) Änderungen der blockierten Fahrzeiten und folglich ihrer entsprechenden Einträge in dem elektronischen Kalender durchgeführt werden sollten (z.B. falls festgestellt wird, dass eine der Vorhersagen, die oben erörtert wurden, basierend auf einer Bedingung, die sich geändert hat, nicht präzise ist). Nach Identifizieren von beliebigen derartigen auszuführenden Änderungen kann die Logik beim Block 316 derartige Änderungen entsprechend auch auszuführen.
Unter Fortsetzen der detaillierten Beschreibung zeigt diese nun mit Bezug auf 4, ein beispielhaftes Darstellen 400 eines elektronischen Kalenders, der auf einer Anzeige eines Gerätes, wie dem Gerät, das die Logik der 3 übernimmt, und/oder ein Gerät einer Person, die wünscht, die Verfügbarkeit eines Nutzers, der mit dem elektronischen Kalender assoziiert ist, durch Zugreifen auf den elektronischen Kalender des Nutzers vom Gerät der anderen Person aus sicherzustellen. In einigen Ausführungsbeispielen kann das Darstellen 400 eine Nutzerschnittstelle (UI) sein, über welche der Nutzer und/oder eine andere Person den elektronischen Kalender über die UI manipulieren können/kann (z.B. durch Auswählen eines bestimmten Bereichs des Darstellens 400, um eine Eingabe zu einer Zeit, die dem ausgewählten Bereich entspricht, zu erzeugen).
In jedem Fall, wie aus 4 ersichtlich ist, umfasst das Darstellen 400 einen ersten Eintrag 402 von 8:00 a.m. bis 9:00 a.m., der in dem elektronischen Kalender eine Fahrzeit anzeigt. Beachte auch, dass der Eintrag 402 anzeigt, dass der Nutzer des elektronischen Kalenders für eine Telefonkommunikation zur Verfügung steht, aber nicht für persönliche Meetings. Ein zweiter Eintrag 404 wird auch gezeigt, beachte aber, dass der Eintrag nur anzeigt, dass der Nutzer von 9:00 a.m. bis 12:00 p.m. verfügbar ist.
Ein Eintrag 406 von 12:00 p.m. bis 2:00 p.m. zeigt an, dass der Nutzer für Meetings nicht zur Verfügung steht. Der Eintrag 406 zeigt auch an, dass der Nutzer ein Jackett mitbringen sollte, weil die gegenwärtige Raumtemperatur in dem Raum, in dem ein Event von 12:00 p.m. bis 2:00 p.m. eingetragen ist, stattfinden soll, gegenwärtig achtundsechzig Grad(F) beträgt (was z.B. basierend auf Echtzeitdaten festgestellt werden kann, welche über eine Kommunikation von einem anderen bereits im Raum befindlichen Gerät, das eine Temperaturablesung für den Raum gesammelt hat, empfangen werden kann). Es ist auch wichtig zu verstehen, dass in einigen Ausführungsbeispielen der Nutzer, wenn er auf seinen Kalender zugreift, die Anzeige sehen kann, die das Jackett betrifft, aber eine andere Person, die auf den Kalender des Nutzers von einem anderen Gerät zugreift, um sicherzustellen, dass der Nutzer verfügbar ist, nicht in der Lage sein kann, die Jackett-Anzeige zu sehen (z.B. basierend auf ausschließlich zum Anschauen durch den Nutzer gekennzeichnete Informationen und/oder basierend auf anderen Kalender und/oder Event betrachtenden Erlaubnissen für den Nutzer im Gegensatz zu anderen Menschen). Weiterhin mit Bezug auf den Eintrag 406, umfasst der Eintrag 406 selbst einen anderen Abschnitt 408 von 1:00 bis 2:00 p.m., welcher anzeigt, dass der Nutzer für Telefonkommunikationen zur Verfügung steht, jedoch nicht für persönliche Meetings. Es ist somit wichtig zu verstehen, dass der Eintrag 406 dazu, einen Zusatz für eine Fahrzeit zwischen 1:00 bis 2:00 p.m. gehabt hat (z.B. selbst wenn das Darstellen 400 nicht ausdrücklich etwas Derartiges anzeigt).
Weiterhin mit Bezug auf 4 umfasst das Darstellen 400 noch einen anderen Eintrag 410, der anzeigt, dass der Nutzer von 2:00 p.m. bis 4:00 p.m. verfügbar ist. Als letztes wird ein Eintrag 412 gezeigt, in dem ausdrücklich gezeigt wird, dass das Zeitfenster zwischen 4:00 p.m. und 5:00 p.m. eine Zeit ist, während welcher der Nutzer fahren wird (z.B. basierend auf einer Vorhersage der Fahrzeit, wie hierin erörtert). Der Eintrag 412 zeigt auch, dass der Nutzer für Meetings oder Events von jeglicher Art nicht zur Verfügung steht (z.B. Telefonkommunikationen, persönliche Meetings usw.), was für andere, die den Kalender des Nutzers anschauen, sichtbar sein kann.
Nun wird mit Bezug auf 5 das Darstellen 400 wieder gezeigt. Beachte jedoch, dass der Eintrag 412 nun anzeigt, dass der Nutzer von 3:00 p.m. bis 5:00 p.m. nicht für Meetings oder Events beliebiger Art zur Verfügung steht. Es ist wichtig zu verstehen, dass die Änderung in dem Eintrag 412 basierend auf z.B. einem gegenwärtigen Ort des Nutzers und/oder basierend auf einer Änderung einer Vorhersage für die Fahrzeit des Nutzers und/oder eines Ortes, zu dem hin oder von dem weg zu fahren ist, geändert sein kann. Somit ist es wichtig zu verstehen, dass in einigen Ausführungsbeispielen die Änderung des Eintrags 412, die in 5 gezeigt wird, wie z.B. beim Block 316 der 3 auftreten kann.
Unter Fortsetzen der detaillierten Beschreibung mit Bezug auf 6, zeigt diese eine beispielhafte Nutzerschnittstelle (UI) 600, welche auf einer Anzeige eines Gerätes wie dem System 100 in Übereinstimmung mit den vorliegenden Prinzipien dargestellt werden kann. Die UI 600 umfasst wenigstens einen Hinweis 602 einer Anfrage (z.B. Anfrage einer "Warteliste") für eine Verabredung mit einem Nutzer (die z.B. nach einer Akzeptanz in den elektronischen Kalender des Nutzers eingetragen werden kann und welche durch eine andere Person unter Verwenden eines anderen Gerätes, welches auf den elektronischen Kalender des Nutzes zugreifen kann, eingereicht worden sein kann, um eine Meeting-Anfrage für die Warteliste einzureichen). Beachte, dass der Hinweis 602 den Namen der Person, welche die Verabredung anfragt, zusammen mit der Art der angefragten Verabredung einschließt. In diesem Fall kann eine Person, die sich Rod nennt, eine Telefonkonferenz mit dem Nutzer des elektronischen Kalenders angefragt haben. Beachte auch, dass der Hinweis 602 Informationen umfasst, die ein verfügbares Zeitfenster in dem elektronischen Kalender betreffen, das z.B. automatisch durch das Gerät, auf dem die UI 600 dargestellt wird, und/oder durch den elektronischen Kalender des Nutzers bestimmt wird. In diesem Beispiel enthält der Hinweis 602 eine Information, welche z.B. auf Daten von dem elektronischen Kalender basiert, dass der Nutzer heute ein Zeitfenster von 10:00 a.m. bis 11:00 a.m. zur Verfügung hat.
Der Hinweis 602 wird von einem Akzeptanzauswahlelement 604 und von einem Ablehnungsauswahlelement 606 begleitet. Das auswählende Auswahlelement 604 ist auswählbar, um automatisch, ohne weitere Nutzereingabe, eine Eingabe für eine Telefonkonferenz mit Rod zu der (z.B. durch Rod) angefragten und/oder (z.B. durch den elektronischen Kalender) angezeigten Zeit in dem elektronischen Kalender zu erzeugen, und kann auch auswählbar sein, um automatisch, ohne weitere Nutzereingabe, z.B. eine Bestätigungsmitteilung an das Gerät zu senden, auf dem Rod die Anfrage bereitgestellt hat, und/oder an ein Mitteilungskonto, das mit Rod assoziiert ist (z.B. ein E-Mail-Konto). Weiterhin kann das Auswahlelement 604 in einigen Ausführungsbeispielen auch auswählbar sein, um automatisch, ohne weitere Nutzereingabe, z.B. einen Eintrag in Rods elektronischen Kalender für die Telefonkonferenz von 10:00 a.m. bis 11:00 a.m. zu erzeugen. Somit ist es wichtig zu verstehen, dass in einigen Ausführungsbeispielen elektronische Kalender von entsprechenden Nutzern derart miteinander verbunden sein können und/oder in anderer Weise konfiguriert sein können, dass sie Informationen miteinander teilen.
Wie oben erwähnt, wird für den Hinweis 602 auch ein Ablehnungsauswahlelement 606 gezeigt. Das Ablehnungsauswahlelement 606 ist auswählbar, um automatisch, ohne weitere Nutzereingabe, die Anfrage abzulehnen. In einigen Ausführungsbeispielen kann die Auswahl des Elements 606 z.B. ein Entfernen der Anfrage von der UI 600 und/oder ein Löschen der Anfrage insgesamt sein, während in anderen Ausführungsbeispielen die Auswahl des Elements 606 z.B. die Anfrage vom Eingeben in den elektronischen Kalender des Nutzers in dem angezeigten Zeitfenster ablehnen, aber die Anfrage nicht von der UI 600 entfernen kann (wie z.B. durch Anzeige 602 dargestellt), aber anstelle dessen z.B. der Hinweis 602 revidieren kann, um ein anderes Zeitfenster von dem Kalender des Nutzers anzuzeigen, welches durch den Kalender bestimmt wird, und für das Event zur Verfügung steht. Ob die Anfrage von der UI 600 zu entfernen oder eine andere Zeit basierend auf einer Auswahl des Elements 606 anzuzeigen ist, kann z.B. basierend auf einer Nutzereingabe bestimmt werden.
Weiterhin ist mit der Anzeige 602 ein Auswahlelement 608 eingeschlossen, welches auswählbar ist, um automatisch, ohne weitere Nutzereingabe, Wartelistenprivilegien für den Nutzer, der die Anfrage initiiert hat (in diesem Fall z.B. Rod), zu widerrufen, so dass der Nutzer nachfolgend nicht zusätzliche Anfragen für Verabredungen mit dem Nutzer und/oder ein Erzeugen von Einträgen in den elektronischen Kalender des Nutzers einreichen kann (z.B. ohne weitere Nutzereingabe, die der Person ermöglicht, Anfragen einzureichen) und deshalb der Person nicht erlaubt, zusätzliche Einträge in eine "Wartelisten" der UI wie die, die in 6 gezeigt wird, einzutragen. In einigen Ausführungsbeispielen kann die Auswahl des Elements 608 auch, wie oben gezeigt, die gegenwärtige Anfrage ablehnen.
Die UI 600 umfasst eine andere Anzeige 610 für eine andere beispielhafte Anfrage. Beachte, dass die Anzeige 610 keine empfohlene Zeit einschließt, um ein persönliches Meeting mit Susanne durchzuführen, sondern eine Zeitgröße anzeigt, die Susanne anzeigt, wie lange das Meeting dauert, bis es beendet sein wird. Die Anzeige 610 begleitend ist ein Akzeptanzauswahlelement 612, ein Ablehnungsauswahlelement 614 und eine Aufhebung der Wartelistenprivilegien 616, welche entsprechend auswählbar sind, um Funktionen auszuführen, ähnlich zu denen, die oben mit Bezug auf die Elemente 604, 606 und 608, mutatis mutandis, beschrieben sind.
Nun mit Bezug auf 7, zeigt diese eine beispielhafte UI 700 zum Konfigurieren von Einstellungen einer Applikation und/oder eines Gerätes zum Übernehmen der vorliegenden Prinzipien. Die UI 700 umfasst wenigstens eine erste Einstellung 702 für Wartelistenprivilegien zum Anfragen einer Verabredung mit einem Nutzer auf einem elektronischen Kalender. Die Einstellung 702 zeigt basierend auf Daten in dem elektronischen Kalender des Nutzers an, dass in dem vorliegenden Beispiel die Menschen John, Susanne und Rod gegenwärtig Wartelistenprivilegien haben, um Verabredungen zu vereinbaren. Die Einstellung 702 hat auch ein zusätzliches Auswahlelement 706, das damit assoziiert ist, welches auswählbar ist, um z.B. ein Überlappungsfenster darzustellen und/oder eine andere UI zum Auswählen und Hinzufügen anderer Menschen, denen erlaubt wird, Wartelisten-Verabredungen anzufragen. Die Einstellung 702 umfasst weiterhin ein Auswahlelement 708 zum Entfernen, welches auswählbar ist, um z.B. ein Überlappungsfenster und/oder eine andere UI darzustellen zum Auswählen und Entfernen von Menschen von einer Erlaubnis Verabredungen anzufragen.
Die UI 700 der 7 umfasst auch wenigstens eine Einstellung 710, welche Informationen während einer besonderen Fahrzeit, die z.B. wiederkehrend und/oder vorbestimmt ist wiederzukehren, wie z.B. Fahren zur Arbeit am Morgen oder von der Arbeit am Nachmittag, die anderen zu zeigen sind und/oder Genehmigungen, die für andere erlaubt sein sollten. Somit betrifft die Einstellung 710 in dem vorliegenden Beispiel eine morgendliche Fahrzeit und wird damit ein Auswahlelement 712 assoziiert und ist auswählbar, um den elektronischen Kalender des Nutzers zu konfigurieren, um anzuzeigen, dass Telefonanrufe während des morgendlichen Pendelns des Nutzers erlaubt sind, und um es anderen Menschen zu gestatten, dementsprechend Telefon-Events im elektronischen Kalender des Nutzers einzutragen. Ein Auswahlelement 714 ist auch mit der Einstellung 710 assoziiert und ist auswählbar, um den elektronischen Kalender des Nutzers zu konfigurieren, um anzuzeigen, dass Telefonanrufe während des morgendlichen Pendelns des Nutzers nicht erlaubt sind, und um anderen Menschen dementsprechend das Einstellen von Telefon-Events im elektronischen Kalender des Nutzers zu verbieten.
Man beachte, dass die UI 700 auch eine andere Einstellung 716 einschließen kann, welche die Nachmittagsfahrzeit des Nutzers betrifft. Die Einstellung kann auch Auswahlelemente 718 und 720 umfassen, welche entsprechend auswählbar sind, um Funktionen, ähnlich zu den Elementen 712 und 714, mutatis mutandis, auszuführen.
Nun mit Bezug auf 8 fortsetzend, zeigt diese eine beispielhafte Datentabelle 800, auf die durch ein Gerät zum Ausführen der vorliegenden Prinzipien zugegriffen werden kann. Die Datentabelle 800 kann verwendet werden, um z.B. verfügbare Zeiten und Fahrzeiten zu einem Event vorherzusagen, welche dann in einem elektronischen Kalender, der mit einem Nutzer assoziiert ist, notiert werden können, zusammen mit z.B. Orten zu bestimmten Zeiten und Transportmethoden, die zu und von bestimmten Orten und/oder zu bestimmten Zeiten verwendet werden. Den Eintrag 802 als Beispiel verwendend, kann ein Gerät, das die vorliegenden Prinzipien ausführt, einen Tag der Woche bestimmen, für welchen eine Vorhersage zu machen ist, auf die Tabelle 800 zu zugreifen, und um einen Tag der Woche in der Spalte 804 zu lokalisieren, der dem zu bestimmenden Tag der Woche entspricht.
Sobald eine Anpassung ausgeführt wurde (in diesem Fall Montag) kann das Gerät zu den Informationen fortfahren, die in der Spalte 806 für den Eintrag 802 notiert sind, um einen oder mehrere Zeitbereiche und/oder Blöcke der Zeit zu identifizieren, welche mit den entsprechenden Orten in der Spalte 808 assoziiert sind, an denen der Nutzer und/oder das Gerät, das mit dem Nutzer assoziiert ist, an wenigstens einer vorhergehenden Zeit an dem assoziierten Tag und der Woche gewesen sind. Somit ist in dem vorliegenden Beispiel durch den Eintrag 802 ersichtlich, dass Daten in die Tabelle 800 eingegeben wurden, dass die Nutzer z.B. an Montagen von 12:00 a.m. bis 8:00 a.m. Zuhause sind, während sie von 8:00 a.m. bis 5:00 p.m. in der Arbeit sind und sie dann von 5:00 p.m. bis 11:59 p.m. wieder Zuhause sind. Man beachte auch, dass Transportmethoden in der Spalte 810 angezeigt werden und somit ein Gerät, das Zugriff auf die Tabelle 800 hat, gemäß den vorliegenden Prinzipien z.B. den Eintrag 802 lokalisieren kann und dann die Transportmethoden aus der Spalte 810 bei dem Eintrag 802 identifizieren kann, um somit eine oder mehrere Transportmethoden vorherzusagen, welche wahrscheinlich in der Zukunft z.B. unter ähnlichen Umständen benutzt werden (z.B. ein Pendeln Montagnachmittags von dem gleichen Ort).
Weiterhin mit Bezug auf 8 ist es wichtig zu verstehen, dass die beispielhafte Datentabelle 800 durch ein Gerät, das die vorliegenden Prinzipien ausführt, erzeugt worden sein kann, Daten darin eingefügt und/oder geändert hat, so dass z.B. Zukunftsvoraussagen gemacht werden und sogar genauer sein können als die Vorhergehenden. Zum Beispiel, basierend auf GPS-Daten, welche das Gerät empfängt (z.B. von einem GPS-Transceiver auf dem Gerät), kann das Gerät einen Ort des Gerätes des Nutzers und somit den Nutzer bestimmen, eine Zeit oder Zeitspanne, in der der Nutzer an dem Ort ist, identifizieren und dann in die Datentabelle einen Eintrag entsprechender Zeiten in die Spalte 806 und einen Eintrag entsprechender Orte in die Spalte 808 eingeben. Beachte auch, dass die Daten, die in einer derartigen Datentabelle gezeigt werden, in einigen Ausführungsbeispielen z.B. Datenmittelwerte sein können aus mehrfachen gleichen Wochentagen (z.B. mehrfache Montage), so dass sich der Mittelwert mit fortscheitender Zeit ändern kann. Dennoch zeigt, zusätzlich zu oder anstelle von dem Vorhergehenden, ein Eintrag für eine derartige Datentabelle getrennte Daten für mehrfache gleiche Wochentage.
Ohne Bezug auf irgendeine besondere Figur, ist es wichtig zu verstehen, dass z.B. einer Person, die wünscht basierend auf der Planung des Nutzers (z.B. wie sie in dem elektronischen Kalender des Nutzers gezeigt wird) eine Wartelistenanfrage für eine Verabredung mit einem Nutzer zu erzeugen, eine UI dargestellt werden kann, die verschiedene Eingabefelder zum Eingeben von Informationen umfasst, einschließlich z.B. des Namens der Person und der Firmenangliederung, der Klasse oder Art der Verabredung (z.B. persönlich, Meeting usw.) und der gewünschten Länge der Verabredung mit dem Nutzer. Nach einem Vervollständigen des Eingebens der Informationen in eine derartige UI können die Informationen zu dem Gerät des Nutzers und/oder elektronischen Kalender für z.B. ein Darstellen auf einer Wartelisten-UI wie der UI 600, die oben beschrieben wurde, übertragen werden.
Weiterhin ist es wichtig zu verstehen, dass, während einige der vorliegenden Offenbarungen sich als Alternative zu einem persönlichen Meeting auf Telefonkommunikationen beziehen (z.B. über ein Mobilfunk-Netzwerk, VOIP usw.), noch andere Alternativen zu einem persönlichen Meeting gemäß den vorliegenden Prinzipien verwendet werden können, bspw. während der Fahrzeit. Zum Beispiel können holografische Kommunikationen und/oder körperlose smarte Avatars verwendet werden, genauso wie auch Videokonferenzen. Dementsprechend können elektronische Kalender, welche die vorliegenden Prinzipien ausführen, diese Dinge in einer Zeit, die für Fahrzeit blockiert wurde, anzeigen und können weitere Anfragen für diese Alternativen auf eine "Warteliste", wie auch hierin beschrieben, gesetzt werden. Darüber hinaus ist es wichtig zu verstehen, dass ein elektronischer Kalender sich über eine Schnittstelle mit einer Umgebung eines Nutzers verbinden kann, wie z.B. mit einem an Bord eines Motorfahrzeugs befindlichen Computer, um die Verfügbarkeit von derartigen Alternativen zu ermitteln (z.B. Videokonferenzen und/oder die Fähigkeit holografische Repräsentationen anderer Menschen, mit denen der Nutzer kommuniziert, darzustellen).
Auch ohne Bezug auf irgendeine besondere Figur ist es wichtig zu verstehen, dass eine Kalenderapplikation und/oder deren assoziierten Daten z.B. über einen Cloud-Service, lokal auf einem besonderen Gerät, auf einem Server und/oder einem anderen Ort, auf den die Geräte über ein Netzwerk wie dem Internet zugreifen können, gespeichert sein können.
Auch ist anzumerken, dass Datentabellen, auf die zum Ausführen der vorliegenden Prinzipien zugegriffen werden kann, wie die oben beschriebene Tabelle 800 (und z.B. sogar einen Kalendereintrag selbst), basierend auf Daten und/oder Kommandoeingaben von z.B. einer Vielzahl von Geräten, mit denen ein einzelner Nutzer assoziiert ist, und die alle einen Zugang zu den Datentabellen und den Kalendern aufweisen, erzeugt oder revidiert werden können. Somit können Informationen und Kontext auf einem Smartphone, Tablet-computer und Arbeitscomputer festgestellt und/oder gesammelt werden und in einer Datentabelle und/oder einem Kalender synthetisiert werden.
Es kann nun ersichtlich sein, dass die vorliegenden Prinzipien ein Eintragen einer Zeit auf dem Kalender des Nutzers, um eine Fahrzeit darzustellen, z.B. basierend auf dem Ort der Aktivitäten, die in einen elektronischen Kalender eingegeben werden und dem "Wissen" eines Kalenders oder Gerätes darüber, wo der Nutzer vor und nach einer Aktivität sein wird, bereitzustellen. Kontextartige Computerausgaben wie z.B. das Wissen über den typischen Tag des Nutzers (z.B. basierend auf einem Wochentag, einer Sammlung von bereits geplanten Events und/oder der vergangenen Historie des Nutzers), ein Wissen des Ortes (z.B. sowohl wo der Nutzer gegenwärtig ist als auch den geografischen Ort, der mit den geplanten Events assoziiert ist) und typische Transportmethoden (z.B. basierend auf dem Wochentag, der Sammlung von bereits geplanten Events und/oder der vergangenen Historie des Nutzers) können verwendet werden.
Echtzeitanpassungen an den Kalender können auch ausgeführt werden. Z.B. kann der Kalender flexibel sein, so dass, wenn Annahmen und/oder Vorhersagen, die darüber gemacht werden, wo der Nutzer vor einer Verabredung sein wird, nicht korrekt sind, der Kalender dann selbst-justieren kann. Wenn zum Beispiel eine Nutzerin ein Event an der Schule ihrer Kinder zum mittleren Nachmittag an einem Mittwoch hat, dann könnte ihr Kalender annehmen, dass sie von der Arbeit zu der Schule (z.B. 14,5 Meilen) fahren wird und legt ihre geplante Fahrzeit dafür fest. Wenn sie jedoch auswählt an diesem Tag von zu Hause aus zu arbeiten, dann könnte der Kalender gerade für diese Fahrzeit von Zuhause zu der Schule (z.B. 20 Meilen) neu justiert werden.
Weiterhin können elektronische Kalender gemäß den dargestellten Prinzipien ebenfalls mit Peer-Applikationen (z.B. mit persönlichen Assistenten) zusammenarbeiten. Zum Beispiel kann der Kalender mit Peer-Applikationen arbeiten, so dass, wenn eine Einladung basierend auf einer voraussichtlichen und/oder angezeigten freien Zeit versandt wird, aber die Peer-Applikation bestimmt (z.B. nach Berücksichtigung der Fahrzeit), dass aktuell etwas weniger Zeit verfügbar ist, eine Mitteilung von der Kalenderapplikation dann unterschiedliche Arten der Akzeptanz wie "akzeptiert, wird aber X Minuten später" und/oder "akzeptiert, aber Startzeit verschiebt sich um X Minuten " und/oder "akzeptiert, aber Ankunftsendzeit X Minuten später" einschließen kann.
Darüber hinaus können unterschiedliche Arten der Anzeigen von "belegter" Zeit und "freier" Zeit in dem Kalender verwendet werden. Zum Beispiel kann der Kalender unterschiedliche Typen von Kalendereinträgen identifizieren, wie "Fahrzeit" und/oder "Meeting-Zeit". Für den Nutzer kann die "Fahrzeit" weiterhin nutzbar sein und der Kalender kann für das Disponieren von bestimmten Arten von Aktivitäten zusätzlich während dieser "Belegt"-Periode ermöglichen und/oder z.B. "nur Telefon" in dieser Zeit anzeigen. Für jemand, der versucht ein persönliches Meeting mit dem Nutzer zu dieser Zeit zu planen, kann die "Fahrzeit" jedoch als Belegt-Zeit, in welcher der Nutzer nicht erreichbar ist (z.B. für jede Art von Event), zu sehen sein.
Darüber hinaus kann ein elektronischer Kalender und/oder ein Gerät, das die vorliegenden Prinzipien ausführt, eine Anhäufung von "Mikro-Wissens"-Quellen nutzen. Zum Beispiel kann der Kalender das Wissen über ein Layout eines Gebäudes nutzen, um Mikro-Navigationstipps anzubieten, wenn ein Nutzer beabsichtigt, dort ein Meeting abzuhalten, sowie ein Berechnen der geplanten Einflüsse. Beim Fahren zu z.B. neuen Orten, an denen spezifische Gebäude/Meeting-Räume dem Nutzer nicht bekannt sind, kann somit ein Anhäufen von Quellendaten von anderen Geräten verwendet werden. Spezifischer kann dieses "Wissen" durch "Quellen-anhäufenden"-Sensorausgaben von allen Geräten, die vorhanden oder flüchtig an dem Ort sind, gewonnen werden, um eine Standortkarte zu erzeugen. GPS-Transceiver und/oder andere Sensoren sowie eine Koppelnavigation können ebenso für diese Zwecke verwendet werden (z.B. um Durchgänge innerhalb eines Gebäudes zu identifizieren). Auf eine Quelle von Blaupausen kann auch zugegriffen werden, um Gebäudelayout-Informationen zu bekommen. Der Kalender kann dann z.B. eine Standortkarte von kontextartigen Daten bilden und sogar z.B. ein Darstellen der Standortkarte, welche die kontextartigen Daten einschließt, darstellen.
Ein Kalender gemäß den vorliegenden Prinzipien kann auch Wissensquellen von anderen Gerätesensoren (z.B. Temperatursensoren) einsetzen, die dort vorhanden sind, wohin der Nutzer geht, um vorbereitende Ratschläge für die Verabredung anzubieten (z.B. in Kundenmitteilungen (z.B. Textmitteilungen oder E-Mail) als Teil einer Erinnerung an das Event usw.) wie z.B., dass der Meeting-Raum auf der kühlen Seite liegt, so dass der Nutzer einen Sweater mitnehmen möchte, dass der Meeting-Raum auf der warmen Seite liegt, so dass der Nutzer etwas Wasser mitnehmen möchte, dass der Meeting-Raum geräuschvoll ist, so dass der Nutzer nahe beim Vortragenden sitzen möchte, oder dass niemand den Fahrstuhl für das Meeting verwendet und dass jeder die Treppe nimmt, so dass der Nutzer einige Minuten früher gehen möchte.
Weiterhin kann ein Wissen über den Nutzer genutzt werden. Zum Beispiel kann der Kalender Wissen über bevorzugte Plätze und/oder Aktivitäten des Nutzers nutzen, um vorzuschlagen, was zu tun oder wohin zwischen Verabredungen zu gehen ist. Wenn z.B. der Nutzer sein Kind zu zwei Arztterminen bringen muss, die drei Stunden auseinander geplant sind, kann dies als "Freizeit" für eine oder anderthalb Stunden zwischen den Verabredungen übersetzt werden. Der Kalender kann auf die Route schauen, die höchstwahrscheinlich genommen wird und ein spätes Mittagessen in einem bevorzugten Restaurant des Nutzers vorschlagen. Als anderes Beispiel kann die Kalenderapplikation mehrere Orte identifizieren, an denen Wi-Fi verfügbar ist und der Nutzer Arbeit zwischen den zwei Verabredungen erledigen könnte. Als noch ein anderes Beispiel kann der Kalender wissen, dass der Nutzer sehr an Landschaftsmalerei interessiert ist, und vorschlagen eine Galerie zu besuchen, die während der freien Zeit geöffnet hat. Auch kann der Kalender wissen, dass eine bevorzugte Laufroute für den Nutzer nahebei ist und vorschlagen, einen kurzen Lauf entlang der Route zu machen. Der Kalender kann auch auf einen Ort der Verabredung blicken, eine Freizeit zwischen den Verabredungen vorhersagen und dem Nutzer vorschlagen (z.B. über eine UI, die auf einer Anzeige dargestellt wird), dass es keine Zeit gibt, um zum Büro zurückzukehren und, anstelle dessen, einen Dialog mit dem Nutzer darüber zu beginnen, was in der Zwischenzeit zu tun ist (z.B. unverzüglich Optionen bereitzustellen, wie zu dem oben erörterten Lauf zu gehen).
Die vorliegenden Prinzipien können auch Transportmethoden und der Tageszeit verwenden und/oder vorhersagen. Z.B. kann der Kalender Felder für "Transportmethoden" bereitstellen (z.B. wenn der Nutzer einen Eintrag erzeugt), so dass eine Fahrt mit dem Auto, Fahrrad, zu Fuß oder mit öffentlichen Verkehrsmitteln wie einem Bus oder einer U-Bahn empfohlen und/oder berücksichtigt werden kann. Mit voranschreitender Zeit würde der Kalender weitgehend an das Wissen angepasst werden, wie lange es benötigt wird, bestimmte oder ähnliche Routen unter Verwenden unterschiedlicher Transportarten zu befahren. Der Kalender könnte auch Applikationen dritter Parteien nutzen, welche ebenfalls assistierende Informationen bereitstellen können. Zum Beispiel könnte die Applikation selbst ein Google "Mazer" sein oder auf öffentliche Informationen über öffentliche Transitrouten oder typische Verkehrsflussmuster der öffentlichen Straßen zugreifen. Diese Art von Informationen kann dann verwendet werden, um die Fahrzeit zu schätzen. Zum Beispiel kann bestimmt und/oder vorhergesagt werden, dass eine Fahrt mit dem Auto von der Arbeit zur Schule an einem Dienstag zwanzig Minuten um 10:00 a.m. betragen könnte, aber fünfundvierzig Minuten um 5:00 p.m. Als ein anderes Beispiel kann bestimmt und/oder vorhergesagt werden, dass ein Fünf-Meilen-Lauf, welcher zwei stark befahrene Straßen überquert, fünfundvierzig Minuten um 7:00 a.m. dauern könnte, aber fünfundfünfzig Minuten am Abend.
Noch weiterhin kann ersichtlich sein, dass eine Kalenderapplikation, welche die vorliegenden Prinzipien ausführt, Wahrscheinlichkeiten für Verabredungen eintragen kann. Beispielsweise kann der Kalender Außenwetterinformationen verwenden, um vorherzusagen, ob Verabredungen eingehalten werden oder nicht, und entsprechend die Wahrscheinlichkeit, dass dort freie Zeit ist, ändern. Wenn sich z.B. die Regenchance von zehn Prozent auf achtzig Prozent erhöht, kann der Kalender dann bestimmen, dass die Wahrscheinlichkeit, den Nachmittagslauf zu machen, niedrig ist und somit die Wahrscheinlichkeit des Umwandelns von Beschäftigungszeit in freie Zeit steigt. An diesem Punkt kann der Kalender eine Warteliste für Verabredungsanfragen unter gerade dieser Berücksichtigung ermöglichen (z.B. Empfehlungen der Wartelistentermine, die besucht werden können, bereitstellen).
Auch könnten Wahrscheinlichkeiten, Verabredungen beizubehalten, auch durch ein Berechnen einer "Leistungsaufzählung" für jeden Teilnehmer des Meetings bestimmt werden. Zum Beispiel könnte mit einer Vielzahl von Kalenderapplikationen, welche die vorliegenden Prinzipien ausführen, und welche jeweils mit verschiedenen Meeting-Teilnehmern assoziiert sind, der Kalender einer Person (oder z.B. eines anderen Meeting-Teilnehmers auf seiner Seite) die Meeting-Zeit, wie sie auf diesem Kalender der Person erscheint, verstellen (z.B. automatisch durch Lernen der Gewohnheiten und Eigenschaften der Person), so dass dieser Person, welche sich gewöhnlich verspätet, eine andere Startzeit für ein Meeting durch ihren Kalender mitgeteilt wird, das dieses in Wirklichkeit z.B. zehn Minuten später beginnt, so wie z.B. auf den Kalendern aller übrigen dargestellt wird. Als ein anderes Beispiel, dass derartige gewöhnlich sich verspätende Personen betrifft, kann der Kalender jedes anderen Meeting-Teilnehmers z.B. ein flexibles Zeitfenster auf deren Kalendern anzeigen, während der Kalender der sich verspätenden Person eine feste Zeit anzeigt. Als noch ein anderes Beispiel, dass die sich gewöhnlich verspätende Personen betrifft, können, wenn sich diese Person verspätet und ein Meeting-Zeit sich über ihre geplantes und/oder vorhergesagtes Ende ausdehnt, zukünftige Meeting-Einträge im Kalender anderer, welche die gleiche sich verspätende Person betreffen, berücksichtigen und/oder vorhersagen, dass sich das nächste Meeting über den Zeitpunkt, an dem es sonst beendet würde, ausdehnen wird.
Um nur noch eine weiteres Beispiel zu nennen, das eine Kalenderapplikation, welche die vorliegenden Prinzipien ausführt, betrifft, kann, wenn ein Nutzer herumfährt und der Kalender auf die Informationen zugreift, dass er und andere Geräte keiner großen Beschleunigung auf der gleichen Straße in dem gleichen Gebiet ausgesetzt sind (z.B. basierend auf Informationen von entsprechenden Trägheitssensoren auf jedem Gerät), der Kalender bestimmen, dass der Nutzer in einem Verkehrsstau steckt. Wenn somit eine Kalenderapplikation bestimmt, dass ein Nutzer zu spät zu einem Meeting in einem großen Raum kommt, der sich schnell auffüllt (wie z.B. basierend auf Daten von den Geräten anderer Menschen bestimmt werden kann, die derartige Daten bereitstellen), kann eine Mitteilung an den Nutzer (bzw. die Nutzerin) des Kalenders bereitgestellt werden, ein Fernglas mitzubringen, weil er (bzw. sie) sonst nicht in der Lage sein könnten, den vorderen Bereich des Raumes zu sehen.
Abschließend ist es wichtig zu verstehen, dass obwohl z.B. eine Softwareapplikation zum Ausführen der vorliegenden Prinzipien mit einem Gerät wie dem System 100 verkauft werden kann, die vorliegenden Prinzipien beispielsweise dort angewandt werden können, wo eine derartige Applikation z.B. von einem Server auf ein Gerät über ein Netzwerk wie dem Internet heruntergeladen wird. Darüber hinaus können die vorliegenden Prinzipien beispielsweise angewandt werden, wo z.B. eine derartige Applikation auf einem computerlesbaren Speichermedium, das verkauft und/oder bereitgestellt wird, beinhaltet ist, wobei das computerlesbare Speichermedium keine Trägerwelle und/oder per se ein Signal ist.
Während insbesondere hierin ein "Darstellen einer Fahrzeit zu und von einem Event in einem elektronischen Kalender" gezeigt und im Detail beschrieben wird, ist es wichtig zu verstehen, dass der Gegenstand, welcher durch die vorliegende Anmeldung offenbart wird, nur durch die Ansprüche begrenzt ist.

Claims

Ein erstes Gerät, umfassend: – einen Prozessor; und – einen Speicher, auf den der Prozessor zugreifen kann und der Instruktionen enthält, die durch den Prozessor ausführbar sind, zum: – Eintragen eines ersten Eintrags in einen elektronischen Kalender für ein erstes Event basierend auf einem ersten Datum und einer ersten Zeit; – Bestimmen, wenigstens teilweise basierend auf dem ersten Datum und der ersten Zeit, eines zweites Datums und einer zweiten Zeit, während denen ein zweiter Eintrag, der ein persönliches Meeting betrifft, nicht in den elektronischen Kalender eingetragen werden kann.
Das erste Gerät nach Anspruch 1, wobei das erste Datum und das zweite Datum das gleiche Datum sind, und wobei die zweite Zeit an die erste Zeit angrenzend ist.
Das erste Gerät nach Anspruch 1, wobei die Instruktionen ausführbar sind, zum: – Bestimmen, wenigstens teilweise basierend auf dem ersten Datum und der ersten Zeit, des zweiten Datums und der zweiten Zeit, während der ein beliebiger Eintrag, der ein beliebiges Event betrifft, nicht in den elektronischen Kalender eingetragen werden kann.
Das erste Gerät nach Anspruch 1, wobei die Bestimmung wenigstens teilweise basierend auf einer Vorhersage der Fahrzeit von einem ersten Ort zu einem zweiten Ort ausgeführt wird, wobei der zweite Ort ein Ort ist, an dem das erste Event stattfinden soll.
Das erste Gerät nach Anspruch 4, wobei der erste Ort ein Ort ist, an dem sich das erste Gerät gegenwärtig befindet.
Das erste Gerät nach Anspruch 4, wobei der erste Ort ein Ort ist, an dem sich das erste Gerät voraussichtlich zu einer Zeit vor dem ersten Datum und der ersten Zeit befindet.
Das erste Gerät nach Anspruch 1, wobei die Bestimmung wenigstens teilweise basierend auf einer Vorhersage der Fahrzeit von einem ersten Ort zu einem zweiten Ort ausgeführt wird, wobei der erste Ort ein Ort ist, an dem das erste Event stattfinden soll.
Das erste Gerät nach Anspruch 7, wobei der zweite Ort ein Ort ist, an dem sich das erste Gerät voraussichtlich zu einer Zeit nach dem ersten Datum und der ersten Zeit befindet.
Das erste Gerät nach Anspruch 7, wobei der zweite Ort ein Ort ist, an dem ein zweites Event stattfinden soll, das nachfolgend zu dem ersten Event ist.
Das erste Gerät nach Anspruch 1, wobei die Instruktionen ausführbar sind, zum: – Vorhersagen einer Transportmethode zwischen dem ersten Ort, an dem das erste Event stattfindet, und einem zweiten Ort; – wobei die Bestimmung wenigstens teilweise auf dem ersten Datum und der ersten Zeit basiert und wenigstens teilweise auf der Vorhersage einer Transportmethode basiert.
Das erste Gerät nach Anspruch 1, wobei die Instruktionen ausführbar sind, zum: – Bestimmen, ob telefonische Kommunikationen während des zweiten Datums und der zweiten Zeit durchgeführt werden können.
Das erste Gerät nach Anspruch 11, wobei die Instruktionen ausführbar sind, um: – in Reaktion auf eine Bestimmung, dass telefonische Kommunikationen während des zweiten Datums und der zweiten Zeit geführt werden können, ein Hinweis erzeugt wird, der auf einem zweiten Gerät, welches auf den Kalender zugreift und welches unterschiedlich vom ersten Gerät ist, darstellbar ist, wobei der Hinweis wenigstens Informationen bereitstellt, dass eine Person, die mit dem elektronischen Kalender assoziiert ist, während des zweiten Datums und der zweiten Zeit für die telefonischen Kommunikationen verfügbar ist.
Das erste Gerät nach Anspruch 12, wobei der Hinweis Informationen bereitstellt, dass die Person während des zweiten Datums und der zweiten Zeit nicht für ein persönliches Meeting zur Verfügung steht.
Ein Verfahren, umfassend: – Schätzen einer Fahrzeit wenigstens eines von zu einem Event, das in einem elektronischen Kalender eingegeben ist, und von dem Event, das in dem elektronischen Kalender angezeigt wird; und – Darstellen der Fahrzeit in dem elektronischen Kalender.
Das Verfahren nach Anspruch 14, wobei die Fahrzeit in dem elektronischen Kalender durch ein Ändern des Eintrags für das Event dargestellt wird, wobei der Eintrag für das Event Informationen umfasst, welche ein erstes Datum und einen ersten Zeitbereich, an dem das Event stattfinden soll, betreffen, um die Fahrzeit mit aufzunehmen.
Das Verfahren nach Anspruch 14, wobei die Fahrzeit in dem elektronischen Kalender wenigstens teilweise durch Erzeugen einer Aufteilung in dem elektronischen Kalender für eine Zeit, zu der die Fahrzeit voraussichtlich stattfindet, dargestellt wird.
Ein Computerlesbares Speichermedium, das keine Trägerwelle ist, wobei das computerlesbare Speichermedium Instruktionen, die durch einen Prozessor ausführbar sind, enthält, zum: – Identifizieren einer Information, die wenigstens eine Fahrzeit zu einem Event, das in dem elektronischen Kalender angezeigt wird, und von dem Event, das in dem elektronischen Kalender angezeigt wird, betreffen; und – Anzeigen der Information in dem elektronischen Kalender.
Das computerlesbare Speichermedium nach Anspruch 17, wobei die Information wenigstens teilweise durch eines von einem Erzeugen eines ersten Eintrags für die Transitzeit in dem elektronischen Kalender und einem Hinzufügen der Transitzeit zu einem zweiten Eintrag für das Event in dem elektronischen Kalender angezeigt wird.
Das computerlesbare Speichermedium nach Anspruch 17, wobei die Information eine erste Information ist, und wobei die Instruktionen ausführbar sind, zum: – Identifizieren einer zweiten Information, welche eine Änderung der Transitzeit betrifft; und – in Reaktion auf die Identifizierung der zweiten Information, Anpassen des Hinweises in dem elektronischen Kalender, um die Änderung an der Transitzeit anzuzeigen.
Das computerlesbare Speichermedium nach Anspruch 17, wobei der elektronische Kalender mit einem ersten Gerät assoziiert ist, und wobei die Instruktionen ausführbar sind, zum: – Zugreifen auf eine Datenstruktur, die Daten umfassen, die vorhergehende Ortsinformationen für das erste Gerät zu vorhergehendem Datumsangaben und vorhergehenden Zeiten betreffen; und – Identifizieren der Informationen, welche die Transitzeit betreffen, wenigstens teilweise basierend auf wenigstens einem Teil der Daten.