WO2016187338A1

WO2016187338A1 - Multi-component data object

Info

Publication number: WO2016187338A1
Application number: PCT/US2016/033131
Authority: WO
Inventors: Andrew Martin MCGILL; Wolfgang Strasser
Original assignee: Axtc, Inc.
Priority date: 2015-05-21
Filing date: 2016-05-18
Publication date: 2016-11-24

Abstract

Various embodiments relate to systems and methods for a multi-component data object that is semi-autonomous, semi-public, and socially-active. The multi-component data object has user profile, time information, location information, communication channels, and recommender functions as core attributes, and may also contain descriptors, requestors, visibility information, publishing information and a confidence value.

Description

MULTI-COMPONENT DATA OBJECT

PRIORITY CLAIM

[0001] This application claims priority to and benefit from United States Provisional Application No. 62/165,145, filed on May 21 , 2015, entitled "MULTI- COMPONENT DATA OBJECT," which is hereby incorporated by reference in its entirety for all purposes.

TECHNICAL FIELD

[0002] Various embodiments of the present technology generally relate to communication and scheduling. More specifically, some embodiments relate to a multi-component data object that consolidates communication and scheduling information.

BACKGROUND

[0003] Business and leisure travelers may experience complex communication and scheduling scenarios, both with other travelers and with local residents. The travel may include travel over large distances or smaller movements within a city or region. For example, a business traveler may be an LTE technology expert, art fan, and hobby soccer player from San Francisco who once studied for two years at Barcelona University. The business traveler may have a trip planned to Barcelona to attend the Mobile World Business Congress and also for personal vacation time. The business traveler may want to notify his family where he will be and how he can be reached while he is in Barcelona. The business traveler may also want to notify colleagues the dates that he will be out-of-office. The business traveler may additionally want to notify social media contacts, business contacts, other LTE experts, other Americans traveling near Barcelona during the same time period, former alumni of Barcelona University, and/or interested residents of Barcelona that he will be near Barcelona for pleasure and business, and that he is willing to arrange meetings during his stay in Barcelona. In addition, while planning the trip to Barcelona, the business traveler may be willing to receive special offers from airlines, car rental companies, hotels, and other service providers that may aid in planning the trip.

[0004] Existing travel planning, communication, and scheduling systems do not allow a business traveler to coordinate such a trip efficiently.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Embodiments of the present technology will be described and explained through the use of the accompanying drawings in which:

[0006] Figure 1 illustrates an example of a networked-based environment in which some embodiments of the present technology may be utilized;

[0007] Figure 2 illustrates an example of a multi-component data object;

[0008] Figure 3A illustrates an example of multi-component data object owner addresses;

[0009] Figure 3B illustrates an example of a list of multi-component data objects;

[0010] Figure 4 illustrates an example of a timeline used by the multi- component data object system;

[0011] Figure 5 illustrates an example of a user interface for displaying information associated with a multi-component data object;

[0012] Figure 6 illustrates a block diagram with components of a multi- component data object system, according to various examples; and

[0013] Figure 7 illustrates an example of a method for coordinating an event based on a multi-component data object.

[0014] The drawings are not to scale. For example, the dimensions of some of the elements in the figures may be expanded or reduced to help improve the understanding of the embodiments of the present technology. Similarly, some components and/or operations may be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments of the present technology. Moreover, while the technology is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the technology to the particular embodiments described. On the contrary, the technology is intended to cover all modifications, equivalents, and alternatives falling within the scope of the technology as defined by the appended claims.

DETAILED DESCRIPTION

[0015] Various embodiments of the present technology generally relate to a multi-component data object. In particular, some embodiments relate to systems and methods for a multi-component data object that is semi-autonomous, semi-public, and socially-active. The multi-component data object has an address, a text and multimedia-based user profile, time and location information, a real-time communication channel, and a recommendation function as core attributes, and may also contain descriptors, requestors, visibility, and publishing or distribution information.

[0016] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present technology. It will be apparent, however, to one skilled in the art that embodiments of the present technology may be practiced without some of these specific details. While, for convenience, embodiments of the present technology are described with reference to the multi-component data object in isolation, embodiments of the present technology create system that can be used in any context to help users consolidate information and coordinate interactions and/or events. In addition, embodiments are equally applicable to various other infrastructures within computer systems.

[0017] Moreover, the techniques introduced here can be embodied as special- purpose hardware (e.g., circuitry), as programmable circuitry appropriately programmed with software and/or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions that may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, compact disc readonly memories (CD-ROMs), magneto-optical discs, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), application- specific integrated circuits (ASICs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.

Terminology

[0018] Brief definitions of terms, abbreviations, and phrases used throughout this application are given below.

[0019] The terms "connected" or "coupled" and related terms are used in an operational sense and are not necessarily limited to a direct physical connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed there between, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.

[0020] The phrases "in some embodiments," "according to some embodiments," "in the embodiments shown," "in other embodiments," and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the present technology, and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments.

[0021] If the specification states a component or feature "may", "can", "could", or "might" be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

[0022] The term "module" or "engine" refers broadly to general or specific- purpose hardware, software, or firmware (or any combination thereof) components. Modules and engines are typically functional components that can generate useful data or other output using specified input(s). A module or engine may or may not be self-contained. Depending upon implementation-specific or other considerations, the modules or engines may be centralized or functionally distributed. An application program (also called an "application") may include one or more modules and/or engines, or a module and/or engine can include one or more application programs.

General Description

[0023] Figure 1 illustrates an example of a networked-based environment 100 in which some embodiments of the present technology may be utilized. The embodiments illustrated in Figure 1 show computing devices 105A-105N that can be any computing device capable of receiving user input as well as transmitting and/or receiving data via the network 1 15. Computing devices 105A-105N can also have user interfaces 105A-105N, which allow, for example, a user to use the computing devices. In one embodiment, computing devices 105A-105N may be a conventional computer system (e.g., a desktop or laptop computer) or a mobile device having computer functionality (e.g., a mobile telephone, a smartphone, wearable computer, etc.). In addition to, or instead of screen-based user interfaces, computing devices 105A-105N may also have acoustical (e.g. sound, voice recognition) or haptical (e.g. vibration) user interfaces, or no user interface at all (e.g. , when the device is only receiving data or data is stored only for transport).

[0024] Examples of a user on computing devices 105A-105N include, but are not limited to, a user on his or her mobile device or personal computer, a user on his or her mobile device or personal computer using a mobile application or software program, and the like. Computing devices 105A-105N can execute a browser application or a customized client to enable interaction, using network 1 15, between the computing devices 105A-105N and one or more servers 120A-120N for handling server responses. Computing devices 105A-105N may include user interfaces 1 10A- 1 10N.

[0025] Computing devices 105A-105N may be configured to use network 1 15 to communicate with one or more servers 120A-120N. In addition or alternatively, the computing devices 105A-105N may be configured to use a peer-to-peer network. In addition or alternatively, computing devices 105A-105N may be configured to perform some functions while offline without network access and acting as standalone devices.

[0026] In accordance with various embodiments, network 1 15 can include any combination of local area and/or wide area networks, using both wired and wireless communication systems. In one embodiment, network 1 15 uses standard communications technologies and/or protocols. Thus, network 1 15 may include links using technologies such as Ethernet, 802.1 1 , worldwide interoperability for microwave access (WiMAX), 3G, 4G, LTE, CDMA, digital subscriber line (DSL), and/or short range and PAN and WPAN network technologies, including but not limited to USB, FireWire, Bluetooth, NFC, INSTEON, IrDA, Wireless, USB, Bluetooth, Z-Wave, ZigBee, Body Area Network, etc.

[0027] Similarly, the networking protocols used on network 1 15 may include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP) and file transfer protocol (FTP). Data exchanged over network 1 15 may be represented using technologies and/or formats including hypertext markup language (HTML), extensible markup language (XML), JSON, or MongoDB object (BSON) formats. In addition, all or some links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).

[0028] In some embodiments, computing devices 105A-105N can retrieve or submit information to one or more servers 120A-120N. In some examples, the servers 120A-120N may be configured as a server cluster. Servers 120A-120N can reply to the computing devices 105A-105N with several responses, including multi- component data object information. Servers 120A-120N can connect to one or more databases 130A-130N. In some examples, the databases 130A-130N may be configured as a database cluster. Databases 130A-130N can store a variety of information including information the user is interested in accessing. While Fig. 1 illustrates servers 120A-120N in a centralized structure, other embodiments can include a cloud configuration and/or a peer-to-peer network and storage system. [0029] In accordance with various embodiments, computing devices 105A- 105N may request data components of a multi-component data object stored on one or more of the databases 130A-130N or one or more of the servers 120A-120N. The user interfaces 1 10A-1 10N may display information associated with the multi- component data object, and allow users to interact with servers 120A-120N.

[0030] In accordance with some embodiments, servers 120A-120N may provide a variety of data access to computing devices 105A-105N. Examples of data access can include user profile information, user time and location information, a list of all multi-component data objects owned or co-owned by the user, a variety of filtered lists of multi-component data objects to recommend as potentially being of relevance to the user, a variety of filtered lists of multi-component data objects to recommend as potentially being of relevance to an advertiser, a list of multi- component data objects that is a search-result list for a search conducted by user, multi-media information or a list of multi-media information that is related to a user or to a multi-component data object, including images and videos, user social media information, and other types of information described herein. For example, one or more databases 130A-130N can include information such as the list of all multi- component data objects owned or co-owned by a user, a user's profile on Facebook, Google+, Linkedln, Twitter, etc.

[0031] In some embodiments, the computing devices 105A-105N may solicit one or more servers 120A-120N to establish a text, telephony, VOIP, audio, and/or video-based, asynchronous or synchronous (live) communication channel with another user, either with no specific context, or with a context based on one or several multi-component data objects. In some embodiments, the computing devices 105A-105N may solicit from one or more servers 120A-120N a list of multi- component objects that are related to the multi-component object that the user is currently interacting with on the computing device 105A-105N.

[0032] In some embodiments, one or more servers 120A-120N are used to monitor accounts and information stored in databases 130A-130N. Servers 120A- 120N can include various data processing and analytic tools that allow for implementation, creation, updating, deletion, and communication of a multi- component data object. In some embodiments, servers 120A-120N are used to store the individual components of a multi-component data object, and transmit the components to one or more computing devices 105A-105N. In addition, servers 120A-120N may access one or more databases 130A-130N having stored thereon the components of a multi-component data object.

[0033] In some embodiments, computing devices 105A-105N request information associated with the components of a multi-component data object from the user and from one or more servers 120. The computing devices 105A-105N may then generate the multi-component data object and communicate the multi- component data object to the servers 120A-120N.

[0034] Servers 120A-120N may be implemented in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through network 1 15. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. Distributed computing may be employed to load balance and/or aggregate resources for processing.

[0035] In some embodiments, computing devices 105A-105N send a multi- component data object over the network to be stored and or viewed on another computing device 105A-105N (peer-to-peer).

[0036] Databases 130A-130N may include various database components that can be implemented in the form of a database that is relational, NON-SQL, sequential, hierarchical, scalable, and/or secure. Examples of such database include DB2, MySQL, Oracle, Microsoft SQL Server, Sybase, MongoDB and the like. Alternatively, these databases may be implemented using various standard data- structures, such as an array, hash, list, struct, structured text file (e.g., XML), table, JSON objects, BSON objects, and/or the like. Such data structures may be stored in memory and/or in structured files.

Technical Overview

[0037] A multi-component data object combines and extends the concept of the calendar item, the concept of the trip as an element of a travel itinerary, and the concept of a social media post. The multi-component data object is a semi-public object that provides different levels of information (including all or none) and different levels of requests to different groups of people. In addition, the multi-component data object is a socially-active object that through its time and location components and its profile descriptors and requestors is related to and interacts with multi-component data objects owned by other users. The multi-component data object is also semi- autonomous in that it can be published in a stand-alone fashion on other publishing channels like websites and/or embedded into other electronic publishing objects like web blogs. The multi-component data object is therefore a semi-autonomous, semi- public, socially-active data object. The multi-component data object includes user profile, time, and location information, an asynchronous communication channel (text, rich text with attachments), and a recommendation function as its core attributes, and also may contain descriptors, requestors, a synchronous communication channel (telephony, live audio or VOIP, live video communication), visibility and publishing information, as described below.

[0038] A user may generate a single multi-component data object by instructing a mobile application running on computing device 105A-105N and/or servers 120A- 120N to compile relevant information for the multi-component data object. For example, the user may enter a general description of a trip into the mobile app, such as "Barcelona" or "Mobile World Congress." The computing device 105A-105N and/or server 120A-120N may then gather the relevant information based on the general description entered by the user. Alternatively, the user may enter a specific location or geographic area, such as "Austria" or "Salzburg" or "Salzburg, Getreidegasse 10" and a time interval, such as "May 10 - May 25, 2015". Alternatively, a multi-component data object may be generated automatically in response to other actions taken by the user. For example, a multi-component data object may be created automatically when the user buys an airline ticket and agrees to the automatic creation of the multi-component data object, which, for instance, may contain the flight destination and trip duration. In another example, a multi- component data object may be created automatically or after user's approval, when the the computing device 105A-105N detects, through location sensors (e.g. GPS, WLAN, etc.), that the user completed a change of his/her local position and the amount of change is above a certain threshold.

[0039] The multi-component data object is a complex data object. The multi- component data object may reside in an access-protected database 130A-130N of a server 120A-120N. The attributes of the multi-component data object may be created automatically by software residing on one or more servers 120A-120N from analysis of a primary user's known profile data in social media, from previous multi- component data objects generated for the primary user, and/or from profile or configuration data or contact data or travel itineraries that the user previously made available to the system.

[0040] A second user may view different aspects and/or different levels of detail (including none or all) of the multi-component data object's data content through a mobile application running on the computing devices 105A-105N. The content the second user may view may depend on how the second user is socially and/or geographically related to the primary user. In this context, socially related may include the concepts of being related through social media on the Internet, such as Facebook, Google+, Linkedln, Twitter, etc. Geographically related may include various concepts, such as the second user having a current geographical position near the primary user's travel destination, the second user having a home location near the primary user's home location, or a birthplace near the primary user's birthplace, etc.

[0041] By looking at the primary user's other social media profiles (e.g. , Facebook) the second user may also see a subset of the multi-component data object's content that was automatically included with the primary user's approval during the initial setup of the primary user's account on the mobile application. The multi-component data object allows the primary user to carry out complex communication, scheduling, and forward-looking social planning scenarios, among other uses, as further described herein.

Multi-Component Data Object

[0042] Referring now to Figure 2, an example of a multi-component data object 205 is shown. The multi-component data object 205 may include a data object owner address 210, a location range 235, and a time range 240. The data object owner address 210 is an identification of the user associated with the particular multi- component data object 205. The data object owner address 210 may be a globally unique identification within the multi-component data object system, similar to the function that an email address serves as a globally unique identifier within an email system. Every multi-component data object is logically attached to a data object owner address, similar to how an email is attached to an email address.

[0043] In some embodiments, a multi-component data object may be co-owned by several users and therefore may be attached to more than one data object owner address 210. An example of a shared multi-component data object may occur when two users plan a trip together in advance, or when two users meet during a trip. In these examples, the multi-component data object 205 is assigned to more than one data object owner addresses 210. The location range 235 may include data associated with any subset of space or any subset of a known virtual space. For example, the location range 235 may be a point, polygon or geographical area on the Earth's surface, in any format, such as a postal address string, an event address, a geographic area, a singleton or polygon of latitude/longitude data pairs, or a virtual location in an online board or computer online game.

[0044] The time range 240 may include data associated with any subset of time. For example, the time range 240 may be a start date-time value plus an end date-time value (time interval), a combination of time intervals, or a start time plus one or several duration time intervals. In addition, the time range 240 may be an empty subset of time or a single point in time. The date-time values may have any well-defined format, in any locale, such as March, March 13, 13.03.2014, 10:30am on March 13, 2014, etc.

[0045] User information components may also be included in the multi- component data object 205. The user information components may include user real name 215, user images 220, user profile descriptors 225, and user profile requestors 230. Other information components associated with the multi-component data object 205 may also be included. The other information components may include data object descriptors 245, data object requestors 250, destination images 255, distribution filters 265, visibility filters 270, and data object communications 275 (text, telephony, audio (VOIP), or video, asynchronous or synchronous).

[0046] The user real name 215 corresponds to the real name (or the pseudonym) of the primary user who generated the multi-component data object 205.

[0047] The visibility filter 270 may include privacy information about which components of the multi-component data object 205 other users may view. The visibility filter 230 may allow a primary user to a-priori configure, or precisely design and maintain, a privacy level for each multi-component data object. The visibility filter 230 allows the primary user to decide which subgroups of his various social networks or the native social network will see which level of detail about when he will be where and what he will be doing or seeking in the location range 235.

[0048] For example, the primary user may generate a general multi-component data object 205 that includes a "Default Visibility Filter." The "Default Visibility Filter" may be defined in the user's profile settings, and may be applied to all newly created general multi-component data objects 205, unless the primary user decides to override the default with specific visibility filters 270 defined for this particular multi- component data object 205.

[0049] Another example of the visibility filter 270 may allow the primary user to create a multi-component data object 205 where only his wife and children can see the exact hour and building of his current stay, whereas his business contacts would only see the day and city, and his Facebook friends would only see the month and state of his current stay, and the rest of the world would see nothing, even if they have his real name 215 and/or his data object owner address 210.

[0050] The distribution filter 265 may include a list of where a primary user's multi-component data objects 205 will be automatically re-published, and to which level of detail. The distribution filter 265 may allow the primary user to precisely define to which of his social networks (Facebook, Twitter, Google+, etc.) the multi- component data objects 205 are distributed. The primary user may define a "Default Distribution Filter" in his user profile settings which will then be applied to all his newlv created multi-component data objects 205, unless the primary user decides to override the default with specific distribution filter 265 defined for a particular multi- component data object 205. For example, the primary user may decide to create a multi-component data object 205 that is only distributed to his Linkedln friends. The distribution or re-publishing of the multi-component data objects 205 to certain publishing channels will normally require the primary user to at least once login with his credentials into the desired re-publishing channels. This may occur using well- known, standardized authentication mechanisms (e.g. login via Facebook, login via Google Account) that ask the user to provide credentials but prevents the originating system (i.e., the system that holds the multi-component data objects) from seeing the credentials.

[0051] The data object communications component 275 may include information about the various communications formats and protocols (e.g., text, telephone, audio, video) that messages may be sent and/or received. All multi- component data objects 205 may contain a built-in communication channel, such as text chat, but may also allow image messages, audio messages, live mobile phone calls, audio chat, and/or live video chat. In order to prevent spamming, stalking and other unwanted communication, a user may configure these communication channels to require opt-in. Opting-in to a communication channel means the primary user explicitly approved a new communication request in a specific channel before another user is connected to him.

[0052] The data object communications 275 may allow other users, both friends and users that have no pre-existing relationship with a primary user, to communicate with the primary user, and to discuss, plan, and agree on meetings at the location range 235 and during the time range 240 that are included in the multi-component data object 205. In this way, the data object communications 275 are context- sensitive to the multi-component data object 205. The data object communications 275 may be searched, naturally aged, archived, and/or removed based on parameters of the multi-component data object 205.

[0053] In some examples, the data object communications 275 associated with a multi-component data object 205 may be analyzed, e.g. for keywords, for the purposes of targeted advertising. For example, display ads may be presented in the system or a profile may be generated that can be used by affiliates for targeted advertising.

[0054] The data object communications 275, such as live audio and video chat, may also help to verify some of the descriptors that a user provided to describe himself / herself (e.g. photo, age bracket) and establish trust that is required between strangers to agree to actually meet in real life.

[0055] The data object requestors 250 may include a list of various attributes or key-value pairs that the primary user of the multi-component data object 205 is looking for from other users, such as potential travel partners, for this particular multi- component data object 205. For example, for his trip to Barcelona, the primary user may be seeking other users who have a descriptor "age-bracket " with the value "35- 40", or seeking business contacts who have a descriptor "subject matter expertise" that contains the value "LTE" that will be near the same location range 235 at the same time range 240 as the primary user. The data object requestors 250 (together with the data object descriptors 245, further described below) may enable better social matching or dating, whether for leisure or business.

[0056] The data object descriptors 245 may include a list of various attributes or key-value pairs that the primary user of the multi-component data object 205 is offering to other users, for this particular multi-component data object 205. For example, for his trip to Barcelona's "GSM World Congress", the primary user may offer his own "subject matter expertise" in "LTE" technology to other users of the multi-component data object system who are near the same location range 235 at the same time range 240 as the primary user. The data object descriptors 245 may enable better social matching or dating, whether for leisure or business.

[0057] The data object requestors 250 of a primary user's multi-component data object 205 may be matched with data object descriptors 245 of a second user's multi-component data object. The confidence in a match between data object requestors 250 and data object descriptors 245 may increase based on the temporal and geographic conditions of the primary user and the second user. For example, as the time approaches for the primary user to board a flight to a location where the second user is currently, the confidence of a match between the primary user's data object requestors 250 and the second user's data object descriptors 245 may increase.

[0058] The user descriptors 225 may include a list of various attributes or key- value pairs of the primary user himself, such as personal profile attributes (e.g., "age- bracket" = "45-50"). These user descriptors 225 may form the first and default section of the descriptors for any multi-component data object 205 that the primary user creates.

[0059] The user images 220 may include images or other multimedia objects of the primary user, including audio and video objects, or references to text, audio and video objects stored in other web sites (e.g. Instagram). The user images 220 may include images or videos about the primary user that more clearly communicate to viewers what type of person the primary user is and what he looks like. In addition, the user images 220 may help with identifying and authenticating the primary user to other users who intend to meet him in real life.

[0060] The user requestors 230 may include a list of various attributes or key- value pairs that the primary user would like to request from other users (e.g., "language" = "English"). These user requestors may form the first and default section of the requestors for any multi-component data object 205 that the primary user creates.

[0061] The destination images 255 may include images of a country, region, landscape, city, landmark, building, general location or the logo or images of an event where the primary user intends to be. The destination images 255 may allow the primary user to display several images or videos about the location range 235 that more clearly communicates to viewers what aspects the primary user is interested in. The destination images 255 may also allow for a competition among users about the "best" location images, resulting in a "gamification" of the destination images 255.

[0062] The multi-component data object 205 may include different combinations of components based on the scenarios and attributes of the users of the multi- component data object system. The Location-only Multi-Component Data Object

[0063] For example, the multi-component data object 205 may omit the time range 240. This type of multi-component data object 205 may have many use cases, such as when a traveler is flexible on travel dates, but has a specific destination planned. In this case, the multi-component data object 205 may allow the traveler to receive special offers from service providers for certain time intervals before the traveler has decided on when to make a trip but already has a fixed location. Alternatively or in addition, the multi-component data object 205 may allow the traveler to locate travel partners to the fixed location at various different times.

The Time-only Multi-Component Data Object

[0064] As another example, the multi-component data object 205 may omit the location range 235. This type of multi-component data object 205 may have many use cases, such as when a traveler is flexible on destination, but has specific dates set aside for travel. For example, the traveler may have a trip planned during a fixed time interval 240 (e.g., Christmas) but has not decided where to go. In this case, the multi-component data object 205 may allow the traveler to find travel partners based on his Descriptors and Requestors. Also, in this case, the multi-component data object 205 may allow the traveler to receive special offers from service providers for this fixed time range 240, and for many possible different destinations. This type of multi-component data object 205 may also allow a user who cannot go to remote destinations, but who is open to receiving incoming calls through the built-in communication channels, to receive communications during the provided time range 240 from users that are compatible to his Descriptors and Requestors.

The Basic Time-Location Multi-Component Data Object

[0065] As yet another example, the multi-component data object 205 may include the location range 235 and the time range 240, while not necessarily providing the data object requestors 250, the data object descriptors 245, the visibility filter 270, and the distribution filter 265, among other components. This type of simple multi-component data object 205 may also have many use cases. [0066] For example, a traveler may plan to travel during a very general time interval (e.g. 2016) and for a very general location (e.g. Africa), but has not yet decided on any specifics. This type of multi-component data object 205 may allow the traveler to leave everything besides time and location open in order to maximize his chances to meet any people interested in the general location during the general time frame.

[0067] As another example, a traveler may plan to travel during a more specific time interval (e.g. May 10-20, 2016) to a more specific location (e.g. London). The traveler may publish the time and location components of the multi-component data object 205 for other users to see his travel plans in order to coordinate with the traveler.

[0068] As another example, a resident of a city (e.g., Dubai) may want to meet with travelers during a specific time range (e.g., March 2015) and therefore creates a multi-component data object 205 with this particular location range 235 and time range 240. The resident may include requestors in the multi-component data object 205 such that the resident is matched with travelers who are visiting Dubai during the specified time range.

[0069] Also in these examples, the multi-component data object 205 may allow the traveler and/or the resident to receive special targeted advertising from an advertising network or from service providers for the particular time range 240, and for the particular location range 235.

The General Multi-Component Data Object

[0070] In its general form, the multi-component data object 205 includes one or more of the other information components, such as the user real name 215, the visibility filter 270, the distribution filter 265, the data object communications 275, the data object requestors 250, the data object descriptors 245, the destination images 255, the user descriptors 225, the user requestors 230, and the user images 265.

Data Object Owner Address

[0071] The data object owner address 210 is a globally unique identifier that serves as a pointer to one or more multi-component data objects 205. Where an email address is a globally unique identifier used to simplify a virtual meeting or communication with a specific person who is connected to different computers and networks at different times, the data object owner address 210 is a globally unique identifier used to (a) enable or simplify a real life meeting and face-to-face communication with one or several persons who are or plan to be at varying places at varying times with varying interests, and/or (b) enable or simplify a virtual communication or virtual meeting with one or several persons, where the context of the virtual meeting or communication is a specific location range 235, a specific time range 240, and/or other information components that are defined in the multi- component data object 205. A data object owner address 210 may have a similar format and syntax as an email address (for instance with a user name and the name or Internet domain name of a service provider or host) or it may have a special format and syntax. The special format and syntax may allow the data object owner address 210 to be recognizable and unique within the domain of a specific local carrier system of multi-component data objects 205. The special format and syntax may also allow the data object owner address 210 to be globally recognizable and unique (similar to email addresses or Twitter handles).

[0072] Figure 3A illustrates an example of a scenario where multiple data object owner addresses 210A-210N are owned by the same user, John Doe, 215A. John Doe may have different data object owner addresses 210A-210N for different purposes. For example, John Doe may have a data object owner addresses 21 OA for personal meetings, a data object owner addresses 210B for business meetings, and a data object owner address 21 ON for hobby meetings.

[0073] The multiple data object owner addresses 210A-210N may have a format and syntax that allows them to be globally recognizable. The globally recognizable format and syntax of the data object owner addresses 210A-210N may give the multi-component data object 205 the ability to be a new means of communication. For example, when two or more people have their first leisure or business or hobby meeting, at the end of the meeting they may exchange not only their email addresses and phone numbers (for instance on a business card), but also their data object owner addresses 210 for relevant multi-component data objects. These data object owner addresses 210 may facilitate the planning of the participants' future face-to-face meetings, without requiring the participants to predict any of their future whereabouts at the moment when they exchange their data object owner addresses 210. In addition, each person, through the use of pre-defined or ad-hoc visibility filters 270, may be able to control the amount of disclosure and privacy of his/her plans, for every other person, depending on the degree of their relationship in social networks.

[0074] There are several policies to create a meaningful format, syntax, and/or name space for the data object owner addresses 21 OA-21 ON:

• Policy 1 : Re-use the name space for email addresses and use an email address format and syntax. An existing or newly created email address may be used to denote a data object owner address 210. This policy may have advantages in reusing existing formats, identifiers, and name spaces for new or additional purposes. However additional information or context information may be necessary for the data object owner address 210 to be recognizable as a data object owner address 210 instead of an email address.

• Policy 2: Create a new global name space and a new format and syntax for the data object owner address 210 in such a way that the new syntax and format are globally recognizable and the data object owner addresses are globally unique. Under this policy, a data object owner address 210 may be globally recognizable, and usable as a data object owner address 210 in most contexts in public and private communication.

• Policy 3: In this scenario, there are several or even many service providers (nationally or internationally) that each operate a carrier system for multi- component data objects 205. These carrier systems may be private or public, and they may be for a specific or general purpose. Each of these service providers may establish their own proprietary name spaces and formats and syntaxes for the data object owner addresses 210 that their carrier systems create. Within the domain of each service provider the data object owner addresses may be recognizable and unique. [0075] Even in this multi-service provider scenario, the interoperability and global uniqueness of the data object owner addresses 210 could be a-priori or a- posteriori established, by adding to each data object owner address 210 the unique name or domain name of the service provider that created this data object owner address 210.

[0076] In order to create a global name space and make the data object owner address 210 globally recognizable and usable, a new explicit or implicit address type identifier may be introduced. This may be a text string of a reasonably short length, e.g. "flyp", or a single character or symbol or special symbol, known or newly created, e.g. % or * or > or F.

[0077] A full data object owner address 210 may then include two or more text and/or numerical elements in any order, one of them being the address type identifier, the second one being the unique data object Identification from a database storage system that contains many or all multi-component data objects 205. In a multi-service provider scenario, the data object owner address 210 may also include a third element that may be the unique identifier, unique name, or Internet domain name of a data object service provider (similar to the practice seen with emails). For example, data object owner address 210 may be "%jdoe", ">johndoe.serviceproviderA", or "johndoexserviceproviderB.com.

Multi-Component Data Object Stream

[0078] Figure 3B illustrates another example of a scenario where a data object owner address 210B is a pointer to a list of multi-component data objects 205A- 205C. The list of multi-component data objects 205A-205C may be referred to as a multi-component data object stream. While Figure 3B illustrates the multi-component data object stream belonging to a single user, John Doe, in some examples, a multi- component data object stream may include multi-component data objects 205 belonging to different users. The elements of a multi-component data object stream may or may not be sorted, such as according to location range 235 or time range 240 parameters, or according to creation date.

[0079] A mobile application may create and display a list of multi-component data obiects 205 (owned by one or various users), rather than just one multi- component data object 205. In some examples, the multi-component data objects 205 in the displayed list may be ordered by "creation time" or by the "trip start time" that is associated with the time range 240 of each multi-component data object 205, or by its location range 235. In some examples, a mobile application may automatically add newly created multi-component data objects 205 to the displayed list. In this way, the mobile application may create the visual impression of a multi- component data object stream.

Geo-Temporal Graphs and Timelines

[0080] A list of multi-component data objects 205 may be seen as a list of objects in space-time, or as a Geo-Temporal Graph. A Geo-Temporal Graph may be sorted by the time range parameters 240 of the data objects 205, for example by a "start time." In this case, the list may be referred to as a "Geo-Temporal Timeline" or simply "Timeline." In this general case, the data objects 205 in the Timeline may contain time range values in the past, the present, and the future.

[0081] In some examples, the user may share a Geo-Temporal Graph with other users, and receive Geo-Temporal Graphs from other users, in particular forward-looking ones. The associated shared forward-looking timelines may allow users to view overlaps and coordinate meetings based on the information in their respective multi-component data objects 205.

[0082] In the particular case where all time range values that occur in a Timeline are situated in the future, the notion of a "Forward-Looking Timeline" becomes visible, as opposed to a mostly backward-looking timeline of other media streams. The Forward-Looking Timeline has important practical use cases, examples of which are described below.

[0083] In another particular case of the concept of "Timeline," it may often be practically meaningful and helpful to include into the Timeline all those multi- component data objects 205 whose time ranges 240 belong to a defined neighborhood of a certain point in time (the "Time Segment"). [0084] In yet another particular case, the certain point in time may be the present moment, which means that the Timeline would comprise the past back to a certain point, the present, and the future up to a certain point.

[0085] In still another particular case, the Timeline may extend along the entire time axis, from the remote past into the distant future.

[0086] As an example, a user John Doe who - over the coming days— plans to visit a city C that last week has seen political unrest or suffered a hurricane may be interested in seeing the time-sorted stream of all multi-component data objects 205 created by users showing C as a location range and showing time ranges between 1 week ago and 2 weeks into the future, because he may want to communicate with those people who have first-hand recent knowledge of the situation in C and those people who are also planning to visit city C over the coming days.

[0087] There are also several different sub-types of Timelines that may be of specific practical interest for particular users and/or for particular organisations. These sub-types of Timelines may include, for example:

[0088] Personal Geo-Temporal Graph, Personal Timeline: A Geo-Temporal Graph (whether forward-looking or general) that comprises multi-component data objects owned by the same user John Doe (or in some specific examples, belonging to one of John Doe's data object owner addresses 210). Such a Geo-Temporal Graph may be referred to as a Personal Geo-Temporal Graph. When the Personal Geo-Temporal Graph is sorted by the time range component 240 it may be referred to as a Personal Timeline, and if it is also forward-looking, a Forward-Looking Personal Timeline. The Personal Geo-Temporal Graph has various practical uses, including, for example:

• Geo-Temporal Repository: the Personal Geo-Temporal Graph may serve as a repository to John Doe of which of his whereabouts he made available to the public, or in combination with a visibility-filter 270, those whereabouts that he made available to certain subsets of his social networks and/or the public. • Geo-Temporal Advertising: the Forward-Looking Personal Timeline may help John Doe to attract some highly targeted offers from advertisers, in particular from those industries that routinely offer time-based and/or location-based services (such as hotels and rental car companies). The information that is visible to the service providers and marketers may be restricted to a certain level of information detail.

• Hot Meeting Proposals: The knowledge of John Doe's Personal Geo-Temporal Graph or Forward-Looking TimeLine also may enable his world-wide personal and business friends and contacts to make "hot" proposals for future face-to-face meetings (because these proposals can target known locations and times as indicated by his Geo-Temporal Graph) and therefore have a much higher probability of being accepted than "cold" meeting proposals.

• Automated Meeting Proposals: Based on John Doe's Personal Geo-Temporal Graph, the system that carries the multi-component data objects 205 may be able to identify overlaps where other users with compatible data object descriptors or requestors (or friends) will be at or near the same location at or around the same time as indicated in one of John Doe's multi-component data objects 205.

[0089] Local Timeline: A Geo-Temporal Graph that exclusively consists of multi-component data objects having the same or a very similar location range 235 (e.g., Paris) may be referred to as a Local Timeline or Geo-Temporal Node, and if it is also forward-looking, a Forward-Looking Local Timeline or Forward-Looking Geo- Temporal Node. The Local Timeline has various practical uses both for individual people and for organisations, including, for example:

• Social Travel Planning: A user Pia Smith may want to see the different lists of people that are traveling to a city (such as Paris) at different time ranges 240 (i.e. the segments of a Geo-Temporal Node) before she decides at what time range she wants to go there.

• Social Location Marketing: A city (such as Paris) may want to include segments of "their" Local Geo-Temporal Graph in their marketing material or online presence as a marketing trick to demonstrate how attractive their city is to a variety of travelers.

• Targeted Local Advertising: An advertiser or service provider that intends to offer products or services in a particular location (e.g a new restaurant in Paris) can use the Geo-Temporal Node for this location to specifically target their offers to people coming to this destination.

[0090] Interest-based Geo-Temporal Graph: A timeline that comprises multi- component data objects that are all sharing the same subset of data object descriptors 245 (or alternatively, sharing the same subset of data object requestors 250, the same subset of user descriptors 225, or the same subset of user requestors 230) (e.g., a "classic music event") may be referred to as an Interest-based Geo- Temporal Graph, and if it is also forward-looking, a Forward-Looking Interest-based Timeline or Geo-Temporal Graph. The Interest-based Geo-Temporal Graph has various practical uses both for individual people and for organisations, including, for example:

• Special-Interest Travel Planning: A user that has specific interests (e.g. classic music events) may pick his future travel destinations based on a Forward- Looking Interest-based Timeline that tells him where such special interest events will happen and when in the future they will happen.

• Special-Interest Local Advertising: An advertiser or service provider that is offering special interest products (such as classical music by a certain artist) to a wider or even global geography, may get a very highly focussed and localized target list from a suitable Forward-Looking Interest-based Timeline.

[0091] Socio-Geo-Temporal Graph: All multi-component data objects 205 belonging to a particular user may be referred to as the user's "Socio-Geo-Temporal- Graph of 1 st Order". All multi-component data objects 205 belonging to the particular user or to one of his "friends" (friends with respect to the multi-component data object system and/or Facebook and/or Google+ and/or Twitter, etc.), may be referred to as the user's "Socio-Geo-Temporal Graph of 2nd Order." The uses and concepts described above also apply to these Socio-Geo-Temporal Graphs. In addition, the Socio-Geo-Temporal Graph may have other uses, including, for example:

• Interest-based Travel Recommendations: The system may analyze a user John Doe's Socio-Geo-Temporal Graph and compare it with the Socio-Geo-Temporal Graphs of other users with similar user descriptors and requestors and then propose travel destinations for John Doe that he has not yet visited but that have been visited by those other users with similar descriptors and requestors.

• Social Travel Recommendations: The system may analyze a user John Doe's Socio-Geo-Temporal Graph of 2nd Order and recommend to visit those destinations that his friends have visited or will visit.

• Travel Predictions: Figure 4 illustrates an example of a Socio-Geo-Temporal Graph (or Timeline) 450 used by the multi-component data object system. The Timeline 450 may be used by the multi-component data object system to make predictions about the user. The predictions may be based on one or more different data channels 405. For example, the multi-component data object system may predict a future location of the user based on the list of previous locations of the user. The multi-component data object system may monitor the geo-location sensor of the mobile device data channel 405E for location information. At time TO, the system may recognize Location A 415A. At time T1 , the system may recognize Location B 415B. At time TN, the system may recognize Location N 415N. Based on the locations 415A=415n, the system may predict a future location of the user, Prediction A 420, at time TN+1 .

Targeted Advertising and Increased Precision Pricing

[0092] Increased Precision Pricing: The service providers and marketers may provide advertising that completes empty information components of a multi- component data object 205. For example, the multi-component data object 205 may include information indicating that a user wants to visit Europe at a general point in time. The service providers and marketers may then provide more specific times and places to visit in Europe in accordance with the user's preferences. The information provided by the service providers and marketers may also be based on the Confidence Values of various multi-component data objects. (For the description of Confidence Values, see below.) For example, if it is determined that a user possesses one or several multi-component data objects 205 that have achieved high confidence values and whose location range is in or near Paris, then the value of advertising for places to visit in Paris may increase. As the advertisements become more precisely targeted to a user, the cost of the advertising may also increase. This may be referred to as "Increased Precision Pricing" or "Zoom-In Pricing."

Geo-Temporal Messaging (the "GTM")

[0093] An SMS message is currently a well-suited format for a "personal short message," and a Twitter "tweet" is currently a well-suited format for a "public short message." In a similar way, the multi-component data object 205 may be a well- suited format to serve another important and frequently used sub-sector of the human communication protocol - the "public geo-temporal message." A public geo- temporal message (or "GTM" for short) is a message where a person tells friends and the public "when he is going to be where." The activity may be referred to as "geo-temporal messaging".

[0094] If the multi-component data object 205 also includes visibility filters 270, distribution filters 265, data object requestors 250, data object descriptors 245 or a subset or combination of these components, then the multi-component data object 205 may be referred to as a "generalized geo-temporal message."

Recommendation Function

[0095] In some examples, the multi-component data object system includes a recommendation function. As an example, a male 40-year-old user John Doe may travel to Paris from August 10 to 20, with an interest in museums and quality restaurants. The recommendation function allows the system to generate customized recommendations based on the user's preferences and the Time Range 240 and Location Range 235, the Data Object Descriptors 245 and Data Object Requestors 250 of the multi-component data object 205. The recommendation function allows the user to locate other multi-component data objects 205 and their owners that are a sufficiently compatible (or a good match) to the user's multi- component data object in certain ways. [0096] The recommendation function may generate matches based on travel to exactly or approximately the same destination, a time interval that is near or overlaps with his time range, people that are friends, or friends of friends, in his social media, people that in their Descriptors share some of the traits that the user is looking for (in his Requestors) and that in their Requestors seek some things that user has on offer (in his Descriptors).

[0097] In one example, the primary user may browse other users' multi- component data objects and may locate a second user having a multi-component data object that is a close match for the location range 235 and time range 240 of the primary user. However, the second user might not be a person that the primary user is interested in meeting. In this case, the primary user may use the recommendation function of one of his own, or one of the second user's, multi-component data objects to locate other similar users based on the attributes.

[0098] The recommendation function may generate recommendations based on two different aspects - compatibility to a user's attributes, and compatibility to a multi-component data object's attributes. In some examples, the user's attributes may correspond to the user requestors 230 and the user descriptors 225. The multi- component data object's attributes may correspond to the data object requestors 250 and the data object descriptors 245. In many cases, these attributes may be different.

[0099] For example, the primary user may have non-variable user descriptors 225 that include "profession"="technologist", "age-bracket"="30-40" and "food- type"="vegetarian", and an invariable user requestor 230 that includes "language"="English" (because the primary user only speaks English). These user descriptors 225 and user requestors 230 may include the predominant and static elements of the primary user's profile. In some examples, the user descriptors 225 and user requestors 230 may be derived from data obtained from other sources, such as when the primary user joins the multi-component data object system through other systems (e.g. "joining via Facebook").

[00100] The data object requestors 250 and the data object descriptors 245 may be more situation-dependent and variable than the user requestors 230 and the user descriptors 225. For example, the primary user may have a multi-component data object with a data object descriptor 245 that includes "Nfe-style"="active", and data object requestors 250 that include "sex"="female", "age-bracket"="20-30", "interesf- 'movies", "business"="IRRELEVANT". Another multi-component data object of the primary user may have different data object requestors 250 that include "business"="mobile technologies", "interest"="LTE technology", "age- brackef- 'IRRELEVANT", "sex"="IRRELEVANT".

[00101] The multi-component data object system utilizes the user-based requestors and descriptors and the data object-based requestors and descriptors as conceptually separate entities. However, this separation is managed so as to be compatible with practical, Ul, and technical requirements.

[00102] In some examples, when a multi-component data object is created, the user requestors 230 and user descriptors 225 are used as the default data object requestors 250 and default data object descriptors 245 (e.g., "auto-population"). After that, the user may or may not override some of the auto-populated elements and then add descriptors and requestors that are specific to the particular multi- component data object.

[00103] Auto-population may liberate the user from entering his user requestors 230 and user descriptors 225 manually into the newly created multi-component data object. The user may later override the default descriptors and requestors when needed. In this way, a meaningful multi-component data object can be created in cases when the user has had no opportunity or no time to create any specific data object-based descriptors or requestors (for example, in the 1 -Click Multi-Component Data Object and the Automatic Multi-Component Data Object, described below).

[00104] Auto-population may also allow the recommendation function to compute a list of recommendations for the primary user by restricting its algorithms to the data object descriptors 245 and data object requestors 250, because they already contain the data from the user descriptors 225 and user requestors 230. User Interface

[00105] Figure 5 illustrates an example of a user interface 500 for displaying information associated with a multi-component data object 205. The information associated with a multi-component data object 205 may be arranged into a multi- component data object frame 505. The user interface 500 may include multiple multi- component data object frames 505A-505N. The top of the user interface 500 may include a navigation bar 510 and user profile 515. The navigation bar 510 may allow a user to navigate to other areas of the user interface 500. The user profile 515 may allow a user to view and edit their user profile information.

[00106] The multi-component data object frame 505 includes information from a multi-component data object 205. A user image 520 corresponds to one or more user images 220. A destination image 525 corresponds to one or more destination images 255. User real name 530 corresponds to the user real name 215. Location 535 corresponds to the location range 235. Time 540 corresponds to the time range 240. Requestors 545 corresponds to the data object requestors 250 and/or to the user requestors 230. Descriptors 550 correspond to the data object descriptors 245 and/or the user descriptors 225.

[00107] The bottom of the multi-component data object frame 505 includes interfaces for distribution 555, visibility 560, communication 565, recommendation 570 and commenting 575. The distribution interface 555 may allow the creator-user to set or modify distribution filters 265. The visibility interface 560 may allow the creator-user to set or modify visibility filters 270. The commenting interface 575 may allow other users to comment on the primary user's multi-component data objects. In alternative implementations of the user interface, some or all of the interfaces for distribution 555, visibility 560, communication 565, recommendation 570, and commenting 575 may be contained in a second view (e.g., the "detail view") of the multi-component data object, rather than in its main display.

[00108] The communications interface 565 may allow a user to send or receive communications using the data object communications 275. System policy or a secondary user's current preferences may require that the communications interface 565 be equipped with opt-in mechanisms for each type of communication (text, audio, live audio, live video, etc.) so that the primary user first needs to apply and the secondary user needs to approve before the primary user can actually exchange messages with the secondary user within this particular type of communication. Also, based on system interference or secondary user's explicit action (e.g., by pressing a button), the primary user who once successfully communicated with the secondary user, may now be temporarily or eternally blocked from doing so.

[00109] The communications interface 565 may also allow a primary user to send an invite to one or several secondary users to share a given multi-component data object 205 of the primary user. It may be the intention of the primary user to offer one or several privileges with regard to the multi-component data object 205 to the invited users. The privileges may include one or a combination of the following: that the invited users are allowed to read some or all of the details of the multi- component data object 205 that are normally not visible to other users, and/or that the invited users become co-editors of some or all of the data of the multi-component data object 205, and/or that the invited users have the ability to further share the multi-component data object 205 to other users, grant co-ownership, or transfer ownership of the multi-component data object 205 to the invited users. If one or several of the secondary user accept the invite, then the given multi-component data object 205 will have a list attached that contains the data object owner addresses 210 of the users that accepted the invitation, together with the specific aforementioned privileges that they were assigned and accepted. In some examples, the given multi-component data object 205 may be displayed in the user interface 500 of both the primary user and the secondary users who were assigned those aforementioned privileges.

[00110] Activating the recommendation interface 570 on a primary multi- component data object 205 may allow a primary user to produce a "Recommended Set" of secondary multi-component data objects that were mostly but not necessarily created by secondary users and that are sufficiently "similar" or "compatible" or "near" to the primary multi-component data object. In this context, the terms "similar", "compatible", "near" and any other terms that are typically used in describing Recommended Sets may be defined by technical concepts and criteria that are based on the values of the individual components of the data object 205. These concepts and criteria may be referred to as the "Recommendation Concept." The Recommendation Concept may have the characteristics of one of many possible "correlation measures" or "cluster concepts" or "distance metrics" (or a combination of these) where these terms may or may not be restricted to their narrow meanings in mathematics or statistical sciences. For instance, one possible cluster concept may be based on the well-known EM algorithm for k-medians clustering. Also, in this same context, the term "sufficiently" in the expression "sufficiently near" may be defined more accurately by technical criteria, such as a "threshold" or "radius value" that serves as an input parameter for the Recommendation Concept and makes sense within the aforementioned correlation measure, cluster concept, or distance measure.

[00111] In some examples, the decision whether a secondary multi-component data object 205 is "sufficiently near" (or "compatible" or "similar") to the primary multi- component data object 205 may be derived from a mathematical algorithm (e.g., the "Recommendation Algorithm") that performs comparisons and/or calculations on the component values of a large subset or all multi-component data objects supported by the multi-component data object system. The Recommendation Interface 570 may include an Activation Element (such as a "Button") and a Configuration Element (such as a "Slider" or a "Radio Button") that resides on the multi-component data object frame 505, or on a Detail Page that belongs to the multi-component data object 205. The Configuration Element, when set by the user, may produce a qualitative value (e.g. , "close", "very close", "cluster") or quantitative numerical value (e.g., -3, -2, -1 , 0, 1 , 2, 3, etc., or -1 .5, -1 .0, -0.5, 0, 0.1 , 0.5, 1 .0, 1 .5, etc.) that defines the term "sufficiently" in the expression "sufficiently near" and fulfils the purpose of the "threshold" or "radius value" in the Recommendation Concept (e.g. "correlation measure", "cluster concept" or "distance metrics") that underlies the Recommendation Algorithm currently employed by the multi-component data object system. The negative values of the Configuration Element may have a practically meaningful interpretation in certain Recommendation Concepts. When the Activation Element is pressed for a given multi-component data object 205, the Recommendation Interface 570 applies the Recommendation Algorithm and the Configuration Element to produce the Recommended Set qualified by the Configuration Element (i.e. , a list of all other multi-component data objects that are compatible to the given multi-component data object 205 based on a setting of the Slider Configuration Element and based on the currently employed Recommendation Algorithm).

[00112] The Configuration Element may be implemented in various ways, such as pressing the Button activation element for shorter or longer time intervals, or as a slider-type user interface, or as a multiple choice user interface element (such as a radio button), or the configuration value may be pre-set by the user or the system under user settings. The possible values of the Configuration Element serve as an input and may be interpreted within the Recommendation Algorithm that implements the currently employed Recommendation Concept.

[00113] A user may scroll through the multiple multi-component data object frames 505A-505N. Each frame 505A-505N may correspond to a different multi- component data object of the user, or of other users. The multi-component data object frames 505A-505N of the other users may correspond to the multi-component data objects produced by the recommendation function. The user may interact with the other users by using the communication interface 565 of that particular multi- component data object frame 505.

The 1 -click Multi-Component Data Object

[00114] In some examples, a user creates a multi-component data object 205 without manually entering a location range 235, a time range 240, or any other of the components of the data object . The user interface 500 of a mobile application and the user's profile settings may be configured to allow for such automatic multi- component data object creation. With this configuration, the user may click one button in the mobile application, then the mobile application may automatically create a meaningful multi-component data object 205 based on other contextual information. Alternatively to clicking one button, the user may click an existing Ul button in a specific way, for instance a long-click, or may swipe a Ul screen element.

[00115] In one example, the user interface 500 of the mobile application includes a button that, when pressed by the user, creates a specific multi-component data object 205 that uses the current date and time as the time range 240, and the current geo-position as the location range 235, and then uses the user's pre-configured data in his user profile to add data like user real name 215, user descriptors 225, user requestors 230, user images 220, visibility filter 270, distribution filter 265, data object requestors 250, data object descriptors 245, or any other information components for which the user created default values in his profile. Additionally, the mobile application may use stock images or an internal database to supply a list of images for the user's current location, and then use the images for the destination images 255 of the multi-component data object 205.

[00116] The geo-position of a user may be determined precisely or sufficiently close for practical purposes by a combination of algorithms and sensors, including reading a mobile device's APS data or GPS location sensor, using translation API's to receive actual addresses, and using a user's WiFi station data and/or I P addresses and I P geomapping databases to determine the user's approximate whereabouts. Current date and time may be obtained by the mobile application from the operating system of the user's computing device 105A-105N or from the network that the computing device is connected to.

[00117] In another example, the mobile application analyzes and compares the computing device's recent geo-positions to determine whether the device has moved a certain distance that is bigger than a threshold. If the movement exceeds the threshold, then the mobile application may consider the user to have travelled and to be in a new location. In this situation, the mobile application may prompt the user and notify him of the move and ask whether he wants to create a multi-component data object by clicking a button. Clicking the button may then create a new multi- component data object 205 using the current time (as measured by the computing device) plus a pre-defined duration interval as a time range 240 and using the new geo-position for a location range 235, or in an alternative implementation, update an existing multi-component data object 205 using the new geo-position for a location range 235 and the current time plus a pre-defined duration interval as the time range 240 . [00118] In yet another example, a user may create and store in his user profile a list of locations where he frequently resides. A mobile application may have a specific dropdown element or similar Ul element that offers the user a choice to create a pre-defined multi-component data object 205 using one of the frequent locations as the location range 235, and the current time stamp plus a pre-defined duration interval as the time range 240.

[00119] In another example, a third-party application, such as a flight booking web site, may have a business partnership with the multi-component data object system and may embed a multi-component data object creation button on a "Purchase Completed Page" of their application's purchasing process. When a user clicks the multi-component data object creation button, the third-party application may automatically create a multi-component data object 205 for the purchased trip in the name of the user, by accessing the data object system's API.

The Automatic Multi-Component Data Object

[00120] In some examples, a primary user may agree in his user profile settings that a multi-component data object 205 is automatically created under certain predefined conditions. For example, whenever a mobile application detects a change of location that is bigger than a threshold, the mobile application generates a new multi- component data object 205. As another example, whenever a certain fixed time interval has passed, the mobile application generates a new multi-component data object 205. As yet another example, whenever the computing device is turned on, a new multi-component data object 205 may be generated. As another example, whenever the user uses a specific other mobile application on the computing device, the other mobile application may trigger the generation of a new multi-component data object 205. Other pre-defined conditions that can be detected by the computing device may also generate a new multi-component data object 205, or update an existing multi-component data object 205. The multi-component data object 205 may be generated using the current geo-position for the location range 235 and the current time stamp (plus a pre-defined duration interval) for the time range 240. The other information components of the multi-component data object 205 may be created according to the default values in the user's user profile settings. This type of multi-component data object 205 may be referred to as an auto-generated multi- component data object. The user interface of the mobile application may have an option to toggle the generation of automatic multi-component data objects on and off.

Multi-Component Data Object Modules

[00121] Figure 6 shows a block diagram with components of a multi-component data object system 600, in accordance with one or more embodiments of the present disclosure. According to an embodiment shown in Fig. 6, the multi-component data object system 600 includes memory 605, one or more processors 610, data object owner address module 615, user real name module 620, user images module 625, user descriptors module 630, user requestors module 675, destination images module 635, data object descriptors module 640, data object requestors module 645, data object communications module 650, distribution filter module 655, visibility filter module 660, location range module 665, time range module 670, user requestors module 675, confidence value module 680, recommender system module 685, and user interface (Ul) module 690. Other embodiments may include some, all, or none of these modules and components along with other modules, applications, and/or components. Still yet, some embodiments may incorporate two or more of these modules into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.

[00122] Memory 605 can be any device, storage media, mechanism, or populated data structure used for storing information. In accordance with some embodiments of the present invention, memory 605 can encompass any type of, but is not limited to, volatile memory, nonvolatile memory, and dynamic memory. For example, memory 405 can be random access memory, memory storage devices, optical memory devices, magnetic media, floppy disks, magnetic tapes, hard drives, solid state disk (SSD), SIMMs, SDRAM, DIMMs, RDRAM, DDR RAM, SODIMMS, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), compact disks, DVDs, and/or the like. In accordance with some embodiments, memory 605 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memories, processor cache memories, relational databases, NOSQL databases, flat databases, and/or the like. In addition, those of ordinary skill in the art will appreciate many additional devices and techniques for storing information which can be used as memory 605.

[00123] Memory 605 may be used to store instructions for running one or more applications or modules on processor(s) 610. For example, memory 605 could be used in one or more embodiments to house all or some of the instructions needed to execute the functionality of data object owner address module 615, user real name module 620, user images module 625, user descriptors module 630, user requestor module 675, destination images module 635, data object descriptors module 640, data object requestors module 645, data object communications module 650, distribution filter module 655, visibility filter module 660, location range module 665, time range module 670, user requestors module 675, confidence value module 680, recommender system module 685, and/or user interface (Ul) module 690. In addition, memory 605 may be used for storing data (e.g., user profile data).

[00124] The data object owner address module 615 may be configured to generate and/or store an identification of a user associated with a particular multi- component data object. The location range module 665 may be configured to generate and/or store data associated with any subset of space or any subset of a known virtual space. The time range module 670 may be configured to generate and/or store data associated with any subset of time. The user real name module 620 may be configured to generate and/or store the real name (or pseudonym) or parts of it of the primary user who generated the multi-component data object. The visibility filter module 660 may be configured to generate and/or store privacy information about which components of the multi-component data object other users may view. The distribution filter module 655 may be configured to generate and/or store a list of where a primary user's multi-component data objects will be automatically re-published, and to which level of detail. The data object communications module 650 may be configured to generate and/or store information about the various communications channels (e.g., text, audio, video) that messages may be sent and/or received. [00125] The data object requestors module 645 may be configured to generate and/or store a list of various attributes or key-value pairs that the creator of the multi- component data object 205 is looking for, with the help of this particular multi- component data object 205. The data object descriptors module 640 may be configured to generate and/or store a list of various attributes or key-value pairs that the creator of the multi-component data object 205 is offering to other users, by virtue of this particular multi-component data object 205. The user descriptors module 630 may be configured to generate and/or store a list of various attributes or key-value pairs of the primary user himself, such as personal profile attributes. The user requestors module 675 may be configured to generate and/or store a list of various attributes or key-value pairs that the primary user seeks in other users, such as personal profile attributes. The user images module 625 may be configured to generate and/or store images or multimedia objects or references to multimedia objects of the primary user, including references to user images stored in other social media systems. The destination images module 635 may be configured to generate and/or store images or multimedia objects or references to multimedia objects of a city, a country, a geographical region, a landscape, a landmark, a building, a general location, or an event where the primary user intends to be.

[00126] The confidence value module 680 may be configured to determine the level of probability that the data (mostly time and location) contained in the multi- component data object 205 are correct and valid and that its creator will actually be at said location at said time. The recommender system module 685 may be configured to determine the "group of recommended multi-component data objects 205" that are recommended for the user. The Ul module 690 may be used to generate one or more graphical user interface screens. These screens can be used to display information (e.g., one click buttons) to users. In some embodiments, the graphical user interface screens can be used by the users to define or select information components for a user's user profile or for a particular multi-component data object. The multi-component data object system 600 may include different combinations of components based on the scenarios and attributes of the users of the multi-component data object system 600. Event Coordination

[00127] Figure 7 illustrates an example of a method for coordinating an event based on a multi-component data object. At block 705, the method includes determining location information. The location information may be determined from the location range 235 of the multi-component data object 205. At block 710, the method includes determining time information. The time information may be determined from the time range 240 of the multi-component data object 205. At block 715, the method includes determining user information. The user information may be determined by locating at least one other user with similar time and location information as the multi-component data object 205. At block 720, the method may include coordinating an event based at least in part on the location information, the time information, and the user information. The event may be coordinated such that the primary user of the multi-component data object meets with the other user associated with the user information at a time and location within the location range 235 and the time range 240.

[00128] From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

[00129] The components described above are meant to exemplify some types of possibilities. In no way should the aforementioned examples limit the scope of the technology, as they are only exemplary embodiments.

[00130] The above Detailed Description of embodiments of the disclosure is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific examples for the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the technology, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative combinations or sub-combinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel, or may be performed at different times. Also, while processes and blocks may be performed in centralized computing systems, they may also be performed in distributed computing architectures.

[00131] In conclusion, the present technology provides novel systems, methods and arrangements for a multi-component data object. While detailed descriptions of one or more embodiments of the technology have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the technology. For example, while the embodiments described above refer to particular features, the scope of this technology also includes embodiments having different combinations of features and embodiments that do not include all of the described features.

Claims

CLAIMS What is claimed is:

1 . A system comprising:

a memory; and

a processor;

wherein the memory stores a multi-component data object comprising:

a location range,

a time range, and

a data object address; and

wherein the processor locates the multi-component data object from the memory based on the data object address.

2. The system of claim 1 , wherein the location range comprises data associated with a subset of space.

3. The system of claim 1 , wherein the time range comprises data associated with any subset of time.

4. The system of claim 1 , wherein the multi-component data object further comprises privacy information about which components of the multi-component data object other users may view.

5. The system of claim 1 , wherein the multi-component data object further comprises information about communications channels that messages may be sent and received.

6. The system of claim 1 , wherein the multi-component data object further comprises a list of attributes that the primary user is looking for from other users.

7. The system of claim 1 , wherein the multi-component data object further comprises a list of attributes that the primary user is offering to other users.

8. A method comprising:

determining location information;

determining time information;

determining user information based at least in part on the time information and the location information; and

coordinating an event based at least in part on the location information, the time information, and the user information.

9. The method of claim 8, further comprising:

determining a list of attributes that a primary user is looking for from other users; and

coordinating the event based at least in part on the list of attributes.

10. The method of claim 8, further comprising:

determining a list of attributes that the primary user is offering to other users; and

coordinating the event based at least in part on the list of attributes.

1 1 . A system comprising:

a processor; and

a memory, the memory storing instructions for running one or more modules on the processor, the memory comprising:

a data object owner address module to generate an identification of a primary user associated with the multi-component data object, a location range module to generate data associated with a subset of space,

a time range module to generate data associated with any subset of time,

a user real name module to generate a real name of the primary user, a visibility filter module to generate privacy information about which components of the multi-component data object other users may view,

a distribution filter module to generate a list of where and in what parts the multi-component data object will be automatically republished,

a data object communications module to generate information about communications channels that messages may be sent and received,

a data object requestors module to generate a list of attributes that the primary user is looking for from other users, with assistance of the multi-component data object,

a data object descriptors module to generate a list of attributes that the primary user is offering to other users, with assistance of the multi-component data object

a user descriptors module to generate a list of attributes of the primary user,

a user requestors module to generate a list of attributes that the primary user seeks in other users,

a user images module to generate multimedia objects of the primary user,

a destination images module to generate multimedia objects of a general location where the primary user intends to be, a confidence value module to determine a likelihood for the validity of the data in the multi-component data object, and

a recommender system module to generate a recommended set of data objects, according to a recommendation algorithm.