Systems and methods for protecting data by linking devices

Abstract

A system, method, and computer-readable storage medium for linking devices to protect data. One method includes receiving a merge request associated with a merge location from an inviting device; establishing one or more data channels with the inviting device; providing a merge request to each of a plurality of invited devices; establishing one or more data channels with a first invited device; generating and providing to the first invited device a first proposed route to the merge location and a first location of one of the plurality of invited devices or at least one of the inviting devices via a first graphical user interface of an application; collecting environmental data of the inviting device and the plurality of invited devices; providing the location of the first invited device; and disconnecting one or more data channels connecting one or more processors to the first invited device.

Description

Technical Field

[0001] This application claims the priority of U.S. Provisional Application No. 63 / 494,947, filed on April 7, 2023, the entire disclosure of which is incorporated herein by reference for all purposes.

Background Art

[0002] In a computer network environment such as the Internet, entities such as individuals or enterprises access content displayed on mobile applications. Individuals and enterprises that provide content may want to protect data by linking devices.

Summary of the Invention

Means for Solving the Problems

[0003] Several implementations relate to computer implementation methods for coordinating devices to protect data, the computer implementation method comprising receiving a merge request associated with a merge location from an inviting device by one or more processors. The method further comprises establishing one or more data channels with the inviting device by one or more processors. The method further comprises providing a merge request to each of a plurality of invited devices by one or more processors, the merge request including a merge location. The method further comprises establishing one or more data channels with the first invited device by one or more processors in response to receiving a first acceptance of a merge request from the first invited device among the plurality of invited devices. The method further includes, by one or more processors, generating a first proposed route to a merging location and a first location of one of a plurality of invited devices or at least one of the inviting devices via a first graphical user interface (GUI) of the application, and providing these to the first invited device, wherein the first proposed route is based on the first geographic location of the first invited device. The method further includes, by one or more processors, establishing one or more data channels with a second invited device in response to receiving a second acceptance of a merging request from a second invited device among the plurality of invited devices. The method further includes, by one or more processors, generating a second proposed route to the merging location via a second GUI of the application, and presenting this to the second invited device, wherein the second proposed route is based on the second geographic location of the second invited device. The method further includes collecting environmental data from the inviting device and multiple invited devices via one or more data channels using one or more processors.The method further includes, by one or more processors, providing the inviting device with the locations of a first invited device and a second invited device based on environmental data via a third GUI of the application, the locations of the first invited device and the second invited device being presented on the third GUI of the application. The method further includes, by one or more processors, disconnecting one or more data channels connecting one or more processors to at least one of the first invited device or the second invited device in response to determining that at least one of the first invited device or the second invited device has completed a merge request at a merge location.

[0004] In some implementations, a merge request is associated with a predetermined merge with a predetermined invited device, and the computer implementation method further includes determining the predetermined merge based on social media data by one or more processors, the predetermined merge being determined based on identifying trends in the social media data, and a first proposed route being presented on a first invited device, the presentation including estimated time of arrival (ETA) for the inviting device, the first invited device, and the second invited device, respectively.

[0005] In some implementations, the method further includes determining stop points along a first proposed route or a second proposed route by one or more processors, and providing intermediate locations to at least one of the first invited device or the second invited device by one or more processors.

[0006] In some implementations, the method further includes: one or more processors receiving a list of items associated with a merge request; one or more processors determining one or more stop points within the region of the merge request that include one or more items from a list of items in stock; one or more processors providing one or more stop points as selectable elements via a first GUI of the application in response to receiving a first acceptance, where determining the stop points and providing intermediate locations is in response to receiving a selection of one of the selectable elements; and one or more processors updating the list of items to indicate that at least one item from the list of items belongs to a first inviting device.

[0007] In some implementations, the method involves updating one or more stop points by one or more processors based on either a first proposed route or a second proposed route, each of the provided stop points further includes updating one or more stop points, each of which further includes an incentive presented together with one of the selectable elements.

[0008] In some implementations, the method further includes, in response to determining that at least one of the first invited device or the second invited device has arrived at the meeting place, sharing the geographic location of the inviting device with at least one of the first invited device or the second invited device by one or more processors.

[0009] In some implementations, a merge request is a public merge request configured to share the merge request with a merge marketplace, and the computer implementation method further includes generating the merge request via an application using one or more processors and providing it to multiple publicly invited devices, the merge request includes a merge location, and the multiple publicly invited devices are determined based on an enrollment dataset.

[0010] In some implementations, the first acceptance includes privacy parameters for sharing data from the first invited device, and these privacy parameters include multiple data sharing levels associated with the type and amount of data being shared.

[0011] In some implementations, the first of multiple data sharing levels configures one or more processors to share the data of the first invited device with at most the inviting device; the second of multiple data sharing levels configures one or more processors to share the data of the first invited device with at most the inviting device and one of the multiple invited devices; and the third of multiple data sharing levels configures one or more processors to share the data of the first invited device with the inviting device and one of the multiple invited devices.

[0012] In some implementations, the first of multiple data sharing levels configures one or more processors to share the unprotected data of the first invited device with at most the inviting device; the second of multiple data sharing levels configures one or more processors to share the unprotected data of the first invited device with the inviting device and one of the multiple invited devices; and the third of multiple data sharing levels configures one or more processors to share the unprotected and protected data of the first invited device with the inviting device and one of the multiple invited devices.

[0013] In some implementations, the first invited device is associated with the application's profile, and the first proposed route is based on the profile's default location.

[0014] In some implementations, the first and second GUIs include look-and-feel (LF) themes based on the merge request or merge location, the merge request provided to multiple invited devices includes a customized invitation containing content corresponding to the merge request or merge location, the first location of one of the multiple invited devices or the inviting device becomes the first visual indicator if one of the multiple invited devices or the inviting device is sharing a location, and the first location of one of the multiple invited devices or the inviting device becomes the second visual indicator if one of the multiple invited devices or the inviting device is not sharing a location.

[0015] In some implementations, the computer implementation method further includes activating one or more security features on the first invited device in response to receiving a first acceptance, the one or more security features including enabling a third-party device to track the first invited device and establishing a separate data channel between the third-party device and the first invited device for communication or exchange of messages.

[0016] In some implementations, the received merging location is a general location, and the computer implementation method further includes, in response to receiving a first acceptance of a merging request, determining the central location of the merging location by one or more processing circuits based on a first geographic location of the first invited device and the geographic location of the inviting device, and the first proposed route to the merging location is to the central location.

[0017] In some implementations, generating and providing a first suggested route to a meeting point via a first GUI of an application includes at least one of the following optional elements: a first optional element including requesting a rideshare or carpool for the meeting; a second optional element including a suggestion for transportation by the inviting device or multiple invited devices; or a third optional element including media recommendations that the first invited device can output as audio during the first suggested route to the meeting point.

[0018] Several implementations relate to a data protection system for coordinating devices to protect data, the data protection system includes a data processing system which includes memory and one or more processors configured to receive merge requests associated with a merge location from an inviting device. The one or more processors are further configured to establish one or more data channels with the inviting device. The one or more processors are further configured to provide a merge request to each of a plurality of invited devices, the merge request including a merge location. The one or more processors are further configured to establish one or more data channels with a first invited device in response to receiving a first acceptance of a merge request from the first invited device among the plurality of invited devices. One or more processors are further configured to generate and provide to the first invited device, via the application's first graphical user interface (GUI), a first proposed route to a merging location and a first location for one of the multiple invited devices or at least one of the inviting devices, the first proposed route being based on the first geographic location of the first invited device. One or more processors are further configured to establish one or more data channels with a second invited device in response to receiving a second acceptance of a merging request from the second invited device among the multiple invited devices. One or more processors are further configured to generate and present a second proposed route to a merging location to the second invited device, via the application's second GUI, the second proposed route being based on the second geographic location of the second invited device. One or more processors are further configured to collect environmental data from the inviting device and the multiple invited devices via one or more data channels. One or more processors are further configured to provide the inviting device with the locations of a first invited device and a second invited device based on environmental data, via a third GUI of the application, where the locations of the first invited device and the second invited device are presented on the third GUI of the application.One or more processors are further configured to disconnect one or more data channels connecting the data processing system to at least one of the first or second invited devices in response to determining that at least one of the first or second invited devices has completed a merge request at the merge location.

[0019] In some implementations, a merge request is associated with a predetermined merge with a predetermined invited device, and one or more processors are further configured to determine the predetermined merge based on social media data, the predetermined merge is determined based on identifying trends in the social media data, and a first proposed route is presented on a first invited device, the presentation including estimated time of arrival (ETA) for the inviting device, the first invited device, and the second invited device, respectively.

[0020] In some implementations, one or more processors are further configured to determine stopping points along a first proposed route or a second proposed route and to provide intermediate locations for at least one of the first invited device or a second invited device.

[0021] In some implementations, one or more processors are further configured to receive a list of items associated with a merge request, determine one or more stop points within the region of the merge request that include one or more items from a list of items in stock, provide one or more stop points as selectable elements via a first GUI of the application in response to receiving a first acceptance, provide one or more stop points, update the list of items to indicate that at least one item from the list of items belongs to a first inviting device, and update one or more stop points based on either a first or second proposed route, each of the provided stop points further includes an incentive presented with one of the selectable elements.

[0022] Several implementations relate to computer implementation methods for coordinating devices to protect data, the computer implementation method comprising receiving a merge request including a merge location by one or more processors. The method further comprises providing acceptance of the merge request to a protection system by one or more processors. In response to the acceptance, the method further comprises establishing a data channel with the protection system by one or more processors. The method further comprises receiving and presenting a proposed route to the merge location and the location of one of a plurality of invited devices or at least one of the inviting devices via a graphical user interface (GUI) of an application by one or more processors, the proposed route being based on a first geographic location of one or more processors. The method further comprises collecting and providing environmental data via a data channel by one or more processors. The method further comprises receiving and presenting the location of at least one of a plurality of invited devices or the inviting device via a GUI of an application by one or more processors. The method is further configured such that, in response to one or more processors determining that a merge request has been completed at a merge location, one or more processors disconnect the data channel connecting one or more processors to the protection system.

[0023] Some implementations include receiving a merge request that includes a merge location, providing the acceptance of the merge request to a protection system, establishing a data channel with the protection system in response to the acceptance, receiving and presenting, via a graphical user interface (GUI) of an application, a proposed route to the merge location and the location of at least one of a plurality of invited devices or at least one of the inviting devices, wherein the proposed route is based on a first geographic location of a user device, receiving and presenting the location of at least one of the plurality of invited devices or the inviting device via the GUI of the application, and disconnecting a data channel connecting one or more processors and the protection system in response to one or more processors determining that the merge request has been completed at the merge location, for a user device including one or more processing circuits.

Brief Description of the Drawings

[0024] [Figure 1] A block diagram depicting an implementation of a system for coordinating devices to protect data according to some embodiments. [Figure 2] A flowchart of a computer-implemented method for coordinating devices to protect data according to some embodiments. [Figure 3] A flowchart of a computer-implemented method for coordinating devices to protect data according to some embodiments. [Figure 4A] A diagram illustrating an example of a graphical user interface according to some embodiments. [Figure 4B] A diagram illustrating an example of a graphical user interface according to some embodiments. [Figure 4C] A diagram illustrating an example of a graphical user interface according to some embodiments. [Figure 4D]FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4E] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4F] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4G] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4H] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4I] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4J] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 4K] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 5A] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 5B] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 5C] FIG. showing an example of a graphical user interface according to some embodiments. [Figure 6-1] FIG. showing an example of protecting data associated with a merge according to some embodiments. [Figure 6-2] FIG. showing an example of protecting data associated with a merge according to some embodiments. [Figure 6-3] FIG. showing an example of protecting data associated with a merge according to some embodiments. [Figure 6-4] FIG. showing an example of protecting data associated with a merge according to some embodiments. [Figure 7A]This diagram illustrates graphical user interfaces through several examples. [Figure 7B] This diagram illustrates graphical user interfaces through several examples. [Figure 8] This block diagram shows exemplary computing systems suitable for use in the various configurations described herein. [Figure 9] This is a flowchart of a computer implementation method for recommending and playing media based on predicted movement duration, based on several embodiments. [Modes for carrying out the invention]

[0025] It will be understood that some or all of the drawings are illustrative representations for explanatory purposes only. The drawings are provided to illustrate one or more embodiments, and it is expressly understood that they are not used to limit the scope or meaning of the claims.

[0026] This disclosure pertains to systems and methods for protecting data and connecting devices. Protecting data and connecting devices enhances the privacy of personally specific consumer data, and its graphical user interface (GUI) enables further improvements to mapping systems that can connect devices while protecting data, including executing merge requests. This approach enables data / mapping systems and architectures to provide the ability to connect multiple devices while maintaining consumer data privacy, improving the overall design of data / mapping systems and architectures. Accordingly, aspects of this disclosure address data protection issues by designing and providing connecting systems that obfuscate consumer data while enabling multiple consumers to merge.

[0027] In addition, various aspects of the methods and systems described herein relate to recommending and playing audiovisual media at an adjusted playback speed based on the predicted travel duration along a navigation route. Adjusting the playback speed of audiovisual media improves the way media is consumed while traveling by increasing the completion rate of audiovisual media in a single travel block, thereby enhancing the enjoyment, retention, comprehension, and value (e.g., monetary value) of the reproduced audiovisual media. Furthermore, aspects of this disclosure realize various technical improvements to audiovisual playback and media sharing technologies. Conventional methods for audiovisual media playback reproduce content at a single default playback speed (e.g., fast), resulting in the problem that if the media duration exceeds the travel duration, media consumption is not completed while traveling. Aspects of this disclosure enable automatic adjustment of the playback speed of output audiovisual media based on dynamic navigation conditions so that media can be fully consumed while traveling, even if the default playback duration of the media exceeds the travel duration. Additional aspects of this disclosure provide targeted media recommendations to the user based on the predicted travel duration. In addition, this disclosure enables improved sharing of audiovisual content among stakeholders within a group by disclosing methods and systems that provide multiple users within the group with a single audiovisual medium to consume while traveling to a common destination, while ensuring that each user can fully consume the audiovisual medium during their respective navigation to the common destination.

[0028] Next, refer to Figure 1, a block diagram illustrating several embodiments of the implementation of System 100 for linking devices to protect data. System 100 includes client devices 110a and 110b (collectively referred to herein as "client devices 110"), a linkage system 130, a data source 160, and a data acquisition engine 180. In various implementations, the components of System 100 communicate via a network 120. Network 120 can include computer networks such as the Internet, local area networks, wide area networks, metro area networks or other area networks, intranets, satellite networks, voice or data mobile phone communication networks, combinations thereof, or any other type of electronic communication network. In various implementations, Network 120 facilitates secure communication between the components of System 100. As a non-exclusive example, network 120 may implement transport layer security (TLS), secure sockets layer (SSL), hypertext transfer protocol secure (HTTPS), and / or any other secure communication protocol.

[0029] Generally, the client device 110 can run software applications (such as application 112, e.g., a web browser, an installed application, or another application) to retrieve content from other computing systems and devices via the network 120. Such applications may be configured to obtain interfaces from the collaborative system 130 (e.g., a navigation interface for navigating to a merge). In one implementation, the client device 110 can run a web browser application that provides an interface (e.g., from the merge circuit 135) on the viewport of the client device 110. The web browser application providing the interface can operate by receiving input such as a web address or other uniform resource locator (URL) from an input device (such as input / output circuit 118, e.g., a pointing device, keyboard, touchscreen, or another form of input device). In response, one or more processors in the client device 110, which executes commands from the web browser application, can request data from another device (e.g., a collaborative system 130) connected to the network 120, which is referenced by a URL address. The other device can then provide web page data and / or other data to the client device 110, thereby presenting an interface through the viewport of the client device 110. Thus, the browser window presents the interface to facilitate user interaction with the interface.

[0030] In another implementation, the client device 110 can run a mobile application, which provides an interface (e.g., from the merging circuit 135) on the viewport of the client device 110. The mobile application providing the interface can operate by receiving input from an input device (such as the input / output circuit 118) to select the mobile application on the viewport of the client device (e.g., to launch the application). In response, one or more processors of the client device 110 executing instructions from the mobile application can request data from another device (e.g., the interoperability system 130) connected to the network 120, which is referenced by a URL address. The other device can then provide application data and / or other data to the client device 110, thereby presenting the interface on the viewport of the client device 110. Thus, the mobile application presents the interface to facilitate user interaction with the interface.

[0031] The client device 110 (also referred to herein as the “mobile device”) can be a mobile computing device, a smartphone, a tablet, a smartwatch, a smart sensor, or any other device configured to facilitate the reception, display, and interaction with content (e.g., web pages, mobile applications). The client device 110 may include applications 112 (indicated as applications 112a and 112b) for receiving and displaying content and receiving user interaction with the content. For example, application 112 may be a web browser. In addition, or alternatively, application 112 may be a mobile application associated with a particular entity. The client device 110 may also include input / output circuits 118 for communicating data over the network 120 (e.g., sending and receiving data to and from the collaborative system 130).

[0032] In various implementations, application 112 interacts with the interfacing system 130 to receive and provide environmental data (also referred to as “activity data”), application content, network content, and online content. For example, application 112 may receive information resources from the interfacing system 130. These information resources may include web-based content (e.g., web pages) or application-based content (e.g., applications installed on client device 110). These information resources may include instructions (e.g., scripts, executable code, etc.) that, when interpreted by application 112, cause application 112 to display a graphical user interface (GUI), such as an interactive web page and / or an interactive mobile application, to the user. In various implementations, application 112 may include one or more application interfaces for presenting applications (e.g., mobile applications, web-based applications, virtual / augmented reality applications, smart TV applications, etc.).

[0033] Application 112 is shown to include a library 114 (shown as libraries 114a and 114b) having interface circuits 116 (shown as interface circuits 116a and 116b). Library 114 may include a set of interface tools included in the package (e.g., application programming interfaces (APIs), web services, debuggers, pass-through network interfaces, etc.). For example, library 114 may include one or more application programming interfaces (APIs). In another example, library 114 may include web services. In yet another example, library 114 may be an interface kit including APIs, debuggers, and web services, etc. In some implementations, library 114 includes one or more libraries having reusable functions that interface with specific system software (e.g., iOS, Android, Linux®, etc.). Library 114 can facilitate the embedding of functionality into Application 112. For example, a merging participant can use application 112 to automatically send real-time location information (or near real-time location information, or final location information) of the client device 110 using library 114 at any time while the merging is in progress. In a further example, library 114 may include a function configured to collect and report device analysis values, and the user can insert this function into instructions in application 112 so that it is invoked during a specific action of application 112 (for example, during merging as detailed below). In some implementations, the functionality of interface circuit 116 is provided by library 114.

[0034] The interface circuit 116 can be configured to provide one or more interfaces. In various implementations, the interface may be presented on the application interface of the application 112 presented in the viewport of the client device 110. The interface provided by the interface circuit 116 (e.g., a user interface including a graphical user interface (GUI), a head-up display (HUD), and a text user interface (TUI)) may include various functions, such as enabling the user to create merge requests, accept merge requests, monitor participants in merge requests (invited and inviter), access a merge marketplace, set merge stop points and incentives, interact with others regarding merges, and configure settings (e.g., profile and privacy). The interface circuit 116 can further generate a navigation interface for real-time data (or delayed data from near real-time or periodic data reception) associated with the location of the client device 110 and other devices, the current geographical location, the proposed route or current route (e.g., the accepted proposed route), one or more stop points on the current route, changes to merging, etc.

[0035] In another implementation example, an application 112 running on a client device 110 may have the application display an interface on the client device 110. For example, a user can launch or access a mobile application stored on the client device 110 structured to host the interface (e.g., via a network 120). In various implementations, the interface may include, but is not limited to, a host device (e.g., a computing device) and infrastructure such as a set of files that define the interface and are stored on the host device (e.g., in a database 140). The mobile application operates by receiving a selection of the application (e.g., an icon) on the viewport of the client device 110. In response, the interface circuit 116 that runs the interface within the mobile application may request data such as content from the database 140 (e.g., merge information, settings, current merge, public merge, past merge, future merge, privacy settings, other interfaces, etc.). The mobile application may include other features such as navigation controls (e.g., back button, forward button, home button). In some implementations, the interface circuit 116 may include both a client-side interface and a server-side interface. For example, the client-side interface may be written in one or more general-purpose programming languages ​​and executed by the client device 110. The server-side interface may be written in one or more general-purpose programming languages ​​and executed by the cooperating system 130. Further details of the interface will be described in detail with reference to Figures 4 and 5.

[0036] The interface circuit 116 can detect events within the application 112. In various implementations, the interface circuit 116 may be configured to trigger other functions based on the detection of specific events (e.g., accepting a merge request, making an in-app purchase, configuring privacy settings, launching the application for the first time, spending a certain amount of time interacting with the application, selecting a public merge, etc.). For example, the interface circuit 116 may trigger a pop-up window (overlaid on the interface) when an actionable object (e.g., a button, dropdown, input field, etc.) is selected within the interface. In various implementations, the library 114 includes functions embedded in the application 112 to trigger the interface circuit 116. For example, a user may include the functionality of library 114 in the transaction confirmation function of application 112, causing the interface circuit 116 to track the location of the user device and send it to the interoperation system 130. It should be understood that events may include any user action within the application and are not limited to the examples explicitly assumed herein. In various implementations, the interface circuit 116 may be configured to distinguish between different types of events. For example, the interface circuit 116 may trigger a first set of actions based on a detected first type of event (e.g., selecting a merge icon) and a second set of actions based on a detected second type of event (e.g., completion of a merge). In various implementations, the interface circuit 116 is configured to collect event logs associated with the detected events and / or multiple events and to send the collected event logs to the merge circuit 135.

[0037] In various implementations, the interface circuit 116 can collect event logs based on a specified session. In one example, a specified session may be active from the time application 112 is started / selected until application 112 is closed / terminated. In another example, a specified session may become active based on a user requesting to start and terminate the session. For each session, the interface circuit 116 can collect event logs while the session is active. Once completed, the event logs may be provided to any system described herein. During a session, the event log traces each event within the session, thereby allowing events to be organized in ascending and / or descending order. In some implementations, events can be organized using various other techniques (e.g., by event type, by timestamp, by failure, etc.).

[0038] In various implementations, the interface circuit 116 of the client device 110 (or third-party device 150) begins collecting event logs when application 112 is launched (for example, when selected by the user via the input / output device 118 of the client device 110), thereby initiating a session. In some implementations, when the application is closed by the user, the interface circuit 116 stops collecting event logs, thereby terminating the session. In various implementations, the user can forcibly clear the event logs or forcibly reset application 112 to terminate a particular session and start a new one, thereby resetting the current session. Further details regarding the functionality of the interface circuit 116 and the interface presented in the viewport of the client device 110 are described in more detail with reference to Figures 4 and 5.

[0039] The input / output circuit 118 is structured to send and receive communications via the network 120 (for example, with the cooperative system 130 and / or other client devices 110). The input / output circuit 118 is structured to exchange data (e.g., environmental data, activity data, interface information, interactions), communications, commands, etc., with the input / output components of the cooperative system 130, other client devices, and / or data sources 160. In one implementation, the input / output circuit 118 includes a communication circuit to facilitate the exchange of data, values, messages, etc., between the input / output circuit 118 and the cooperative system 130. In yet another implementation, the input / output circuit 118 includes a machine-readable medium to facilitate the exchange of information between the client device 110 and the cooperative system 130. In yet another embodiment, the input / output circuit 118 includes any combination of hardware components, a communication circuit, and a machine-readable medium.

[0040] In some embodiments, the input / output circuit 118 includes appropriate input / output ports and / or uses an interconnection bus (not shown) for interconnection with a local display (e.g., a touchscreen display) and / or a keyboard / mouse device (if applicable), and functions as a local user interface for programming and / or data entry, retrieval, or other user interaction purposes. Thus, the input / output circuit 118 can provide an interface for the user to interact with various applications (e.g., application 112) stored in the client device 110. For example, the input / output circuit 118 includes keyboards, keypads, mice, joysticks, touchscreens, microphones, tactile sensors, automotive sensors, IoT sensors, biometric sensors, accelerometer sensors, virtual reality headsets, smart glasses, smart headsets, etc. Another example of the input / output circuit 118 includes, but is not limited to, television monitors, computer monitors, printers, facsimile machines, speakers, etc. As used herein, virtual reality, augmented reality, and mixed reality may be used interchangeably, but they refer to all types of extended reality, including virtual reality, augmented reality, and mixed reality.

[0041] In some implementations, the input / output circuit 118 of the client device 110 can receive user input from the user (e.g., via sensors or any other input / output devices / ports described herein). User input can be multiple inputs, including, but not limited to, gestures (e.g., flicking the client device 110, shaking the client device 110, user-defined custom gestures (e.g., using an API), biometric data (e.g., stress level, heart rate, hand shape, face shape, mental state, etc.) and / or behavioral data (e.g., haptic feedback, gestures, speech patterns, movement patterns (e.g., hands, feet, arms, face, iris, etc.) or combinations thereof). In some embodiments, one or more user inputs can be used to perform various actions on the client device 110. For example, a user performing a gesture can invoke a merge request or terminate a merge session (e.g., instruct complete or cancel).

[0042] The input / output circuit 118 can exchange and transmit data information with all devices described herein via the network 120. In various implementations, the input / output circuit 118 transmits data via the network 120. The input / output circuit 118 can confirm the transmission of data. For example, the input / output circuit 118 can transmit requests and / or information to the coordinating system 130 based on the selection of one or more selectable (or actionable) items within the interface described herein. In another example, the input / output circuit 118 can transmit requests and / or information to another client device operated by another user (e.g., another invitee, inviter). In various implementations, the input / output circuit 118 can transmit data periodically. For example, the input / output circuit 118 can transmit data at predefined times. In another example, the input / output circuit 118 can transmit data at certain intervals (e.g., every 10 seconds, every 10 minutes, every 10 hours, etc.).

[0043] The integration system 130 receives event logs from the library 114 and generates information by facilitating analysis of the received data. For example, the integration system 130 can receive a data bundle containing event logs from the library 114 and securely correlate the received data with data stored in the database 140 to generate information. In this example, the data bundle may contain one or more enrollment datasets and one or more data sharing levels for enrolled mobile devices in one or more enrollment datasets. Alternatively, or in combination, in this example, the data bundle may contain one or more invitees to a merge request and one or more data sharing levels for the invitees and / or inviters of the merge request. In another example, the integration system 130 can receive first data from the library 114 associated with the location and real-time (or near real-time) information of invitees and inviters of ongoing or pending merges, and second data associated with the metadata of the merge request, including the merge location and data sharing level, and correlate the first and second data.

[0044] In various embodiments, the integration system 130 generates aggregated information. For example, the integration system 130 can determine the number of users who have arrived at the merging location after interacting with the mobile application and accepting the merging request. The aggregated information may describe the number or grouping of merging requests (e.g., scheduled or pending merging requests). In addition, or alternatively, the aggregated information may describe the individual merging request interaction (e.g., the user's experience during merging, including but not limited to the traffic experienced by the user, the route taken by the user, whether the user created an intermediate stop, when the user arrived, the user's current location, etc.). The aggregated information may include a unique identifier. In some implementations, the identifier identifies the merging request. In some implementations, the aggregated information describes one or more interactions associated with the merging request. For example, the aggregated information may include the time, date, and / or merging location of the merging request. A merge request described by anonymous merge data (for example, if the invitee does not share information about the merge request with others) may include when the merge was accepted, the time it took for the user to receive the notification and accept the merge, whether the user selected an intermediate stop, and other navigation performed within the mobile application (e.g., selecting / clicking selectable elements, hovering over selectable elements, and / or other interactions with selectable elements).

[0045] The collaborative system 130 may be a server, a distributed processing cluster, a cloud processing system, or any other computing device. The collaborative system 130 may include or execute at least one computer program or at least one script. In some implementations, the collaborative system 130 may include a combination of software and hardware, such as one or more processors configured to execute one or more scripts.

[0046] The collaborative system 130 is shown to include a database 140 and a data processing circuit 132. The database 140 can store received data. For example, the database 140 can store merge request information including ongoing real-time information (e.g., the user's current location, or the user's near real-time location, or the user's previously recorded location), scheduled or pending merge information, metadata for one or more merge requests, sharing levels, specified merges and public merges, merge marketplace code bundles, software development kits (SDKs) and application programming interfaces (APIs), and graphical user interface code bundles (e.g., for mobile application implementations). In some implementations, the database 140 stores identifiers. For example, the database 140 can store logs (e.g., event logs of past, present, and future merges) and supplemental data that share intermediate identifiers. Identifiers may be used later for correlation of anonymous merge data. The database 140 may include one or more storage media. The storage medium may include, but is not limited to, magnetic storage, optical storage, flash storage, and / or RAM. The collaborative system 130 can implement or facilitate various APIs to perform database functions (i.e., management of data stored in the database 140). The APIs may include, but are not limited to, SQL, ODBC, JDBC, NoSQL, and / or any other data storage and manipulation APIs.

[0047] The data processing circuit 132 includes a processor 133 and a memory 134. The memory 134 may store instructions that, when executed by the processor 133, cause the data processing circuit 132 to perform various operations described herein. The operations described herein can be performed using software, hardware, or a combination thereof. The processor 133 may include a microprocessor, ASIC, FPGA, or a combination thereof. In many implementations, the processor 133 may be a multi-core processor or an array of processors. The memory 134 may include, but is not limited to, any electronic, optical, magnetic, or any other storage device that can provide program instructions to the processor 133. The memory 134 may include a floppy disk, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, EEPROM, EPROM, flash memory, optical media, or any other suitable memory from which the processor 133 can read instructions. Instructions may include, but are not limited to, code in any suitable computer programming language, such as C, C++, C#, Java®, JavaScript®, Perl, HTML, XML, Python, and Visual Basic.

[0048] Memory 134 may include a merge circuit 135. Broadly speaking, the merge circuit 135 can receive data and generate information about that data. In some implementations, the merge circuit 135 can receive a merge request (e.g., from an inviting device) and provide that merge request to each of several invited devices. For example, a user of library 114b can register a user account on a client device so that the client device can run library 114b and execute merge requests. Registering a client device may include, but is not limited to, providing various identification information (e.g., device name, geolocation, identifier, etc.), platform specification (e.g., iOS, Android, WebOS, BlackBerry OS, etc.), user actions (e.g., activation gestures, haptics, biometric authentication, etc.), and authentication information (e.g., username, password, two-factor authentication criteria, security questions, address information, etc.). When the merge circuit 135 approves or receives a registration request, it can store the information associated with the request in the database 140. In addition, a notification may be sent to the client device indicating that it is registered and that it can utilize the merge function associated with one or more applications.

[0049] In some implementations, the merge circuit 135 can facilitate and manage merge requests, including, but not limited to, communicating with the inviter and invitee of a merge, accessing the inviter's and invitee's client devices to request real-time (or near real-time) information, modifying one or more merges between the inviter and invitee (e.g., adding intermediate stops), controlling data sharing based on data sharing levels set by the inviter and invitee, determining unprotected and protected data and controlling access to protected data, scheduling merges, accessing social media data and other third-party data to schedule merges and update ongoing or pending merges, providing a graphical user interface for applications, and determining and generating routes and any other information used before, during, or after a merge.

[0050] In various implementations, the merging circuit 135 performs statistical calculations on the received data to produce statistical measurements that describe the received data. For example, the merging circuit 135 can determine the acceptance and responsiveness (e.g., whether the invitee and inviter associated with the merging request arrive at the correct location on time). In some implementations, the merging circuit 135 generates demographic information (e.g., user distribution), geographical results (e.g., location distribution), and / or audience (e.g., a target user group based on one or more parameters, e.g., users who have made purchases exceeding a threshold). For example, in a public merging (e.g., a football tailgate party, a concert, or any other event), the generated demographic information can be used to determine who should be invited to the public merging. In some implementations, the merging circuit 135 correlates the merging log with supplementary data. For example, the merging circuit 135 can use an intermediate identifier to correlate the merging log associated with the merging with supplemental data associated with social media data, and determine potential merging with invitees that may occur in the near future. In various implementations, the merging circuit 135 generates information. This information may include merging metadata, data describing the operation of application 112, and interactions between invitees and application 112.

[0051] In addition, the statistical calculations performed by the merge circuit 135 can generate usage metrics for client devices (e.g., client device 110) and library 114. Some usage metrics may include, but are not limited to, device registration metrics, feedback metrics (e.g., the percentage of users who submitted feedback), and content network testing metrics (e.g., the percentage of users who performed merges). The statistical calculations performed by the merge circuit 135 can also generate impact metrics for client devices (e.g., client device 110) and library 114. Some impact metrics may include, but are not limited to, the acceptance rate of merge requests specific to inviters or invitees, popular or common merge locations, popular or common intermediate stop points, acceptances and cancellations before completion, and the completion rate of merge requests specific to inviters or invitees.

[0052] In various implementations, usage metrics and impact metrics can be calculated based on various statistical operations and analyses. Usage metrics and impact metrics can further be prioritized based on various factors (e.g., region, inviter, language preference, new or existing user, etc.). In some implementations, machine learning models can be trained using incoming data and pre-collected data stored in database 140 (e.g., merge logs, past, current, pending, and scheduled merges). In other words, predictions regarding merge locations, intermediate stops, and merge invitees can be based on artificial intelligence (AI) or machine-learning models (MLM). For example, a first MLM can be trained to identify and predict specific merge locations within a specific region. In this example, a second MLM can be trained to identify invitees based on past merges. In various implementations, machine learning algorithms include, but are not limited to, neural networks, convolutional neural networks, regressive neural networks, linear regression models, and sparse vector machines. The various computing systems / devices described herein can input various data (e.g., event logs, debugging information, etc.) into a machine learning model and receive output from the model indicating specific actions to be taken.

[0053] The data source 160 can provide data to the integration system 130. In some deployment configurations, the data source 160 can be structured to collect data from other devices on the network 120 (e.g., client devices 110a and 110b) and relay the collected data to the integration system 130. In one example, a user and / or entity may have servers and databases (e.g., proxies, enterprise resource planning (ERP) systems) that store merge information associated with the user and / or entity (e.g., historical information, default information, social media information including the user's photos and location, public merge information). In this example, the integration system 130 can request data associated with specific data stored in the user or entity's data source (e.g., data source 160). For example, in some implementations, the data source 160 may host or otherwise support a discovery or exploration engine for Internet-connected devices. The discovery or exploration engine can provide data to the integration system 130 via the data ingestion engine 180. In some implementations, data source 160 can be scanned to provide additional data. This additional data may include news feed data (e.g., articles, breaking news, and television content), social media data (e.g., Facebook, Twitter, Snapchat, and TikTok), user geolocation data on the internet (e.g., GPS, triangulation, and IP addresses), government databases (e.g., FBI database, CIA database, COVID-19 database, No Fly List database, terrorist database, vulnerability database, cyber threat intelligence database, and certificate database), and / or any other data associated with the user and the merge request.

[0054] System 100 may include a data acquisition engine 180. In various implementations, the interoperability system 130 may be linked to the interoperability system 130 in a communicative and operational manner. The interoperability system 130 may include one or more processing circuits configured to execute various instructions. In various implementations, the interoperability system 130 may be configured to facilitate communication (e.g., via the network 120) between the interoperability system 130 and the systems described herein. Facilitating communication can be implemented as an application programming interface (API) (e.g., a REST API, a Web API, a customized API), a batch file, and / or a query. In various implementations, the data acquisition engine 180 may also be configured to control access to resources in the interoperability system 130 and the database 140.

[0055] The API can be used by the data ingestion engine 180 and / or computing system to exchange data in a structured format and to make function calls. The API can be configured to specify an appropriate communication protocol using an appropriate electronic data interchange (EDI) standard or technology. An EDI standard (e.g., messaging standards and / or assistive technologies) can include any of the following: SQL datasets, protocol buffer message streams, instantiated classes implemented in an appropriate object-oriented programming language (e.g., Java®, Ruby, C#), XML files, text files, Excel files, or web service messages in an appropriate web service message format (e.g., representational state transfer (REST), simple object access protocol (SOAP), web service definition language (WSDL), Java® Script object notation (JSON), XML remote procedure call (XML RPC)). Thus, an EDI message can be implemented using any of the above or other appropriate technologies.

[0056] In some implementations, data is exchanged using web services by components of the data ingestion engine 180. When data is exchanged using APIs configured to exchange web service messages, some or all components of the computing environment may include one or more web service nodes, or be associated with one or more web service nodes (e.g., as client devices). Web services are identifiable by unique network addresses such as IP addresses and / or URLs. Some or all components of the computing environment may include circuitry structured to access and exchange data using one or more remote procedure call protocols, such as Java® remote method invocation (RMI) or Windows® distributed component object model (DCOM). Web service nodes may include web service libraries containing callable code functions. A callable code function may be structured according to a predefined format, which may include a service name (interface name), operation name (e.g., read, write, class initialization), operation input parameters and data types, operation return values ​​and data types, service message format, etc. In some implementations, a callable code function may include an API structured to access a discovery or search engine for an Internet-connected device on demand and / or to receive a data feed from there. Further examples of callable code functions, embodied as various components of the data ingestion engine 180, are further provided herein.

[0057] The data source 160 can provide data to the interoperation system 130 based on the data ingestion engine 180 scanning the internet (e.g., various data sources and / or data feeds) for data associated with a user or merge request. In other words, the data ingestion engine 180 can maintain (e.g., in non-temporary memory, in cache memory, and / or in database 140) an executable for performing the scanning operation against the data source 160. Furthermore, the interoperation system 130 can initiate the scanning operation. For example, the interoperation system 130 can initiate the scanning operation by obtaining a domain identifier or other user / entity identifier from a computer-implemented DBMS or queue. In various implementations, the data source 160 can facilitate data communication between client devices 110 (e.g., 110a and 110b) so that the data source 160 receives data from client devices 110a and 110b (e.g., via network 120) before the data source 160 transmits the data to other systems described herein (e.g., interoperation system 130). In other implementations, and as described herein, the client device 110 and the data source 160 can transmit data directly to any system described herein via the network 120, and the data source 160 can provide information not provided by any client device 110.

[0058] Next, refer to Figure 2, which is a flowchart of Method 200 for linking devices to protect data, according to several embodiments. The linking system 130 can be configured to perform Method 200. Furthermore, any computing device described herein can be configured to perform Method 200.

[0059] In a general outline of Method 200, in block 210, one or more processing circuits (e.g., the collaborative system 130 in Figure 1) can receive merge requests. In block 220, one or more processing circuits can set up merge requests. In block 230, one or more processing circuits can monitor merge requests. Depending on the specific configuration, additional, fewer, or different operations may be performed. In some embodiments, some or all of the operations of Method 200 may be performed by one or more processors running on one or more computing devices, systems, or servers. In various embodiments, each operation may be reordered, added, deleted, or repeated.

[0060] In block 210, one or more processing circuits can receive a merge request from an inviting device associated with a merge location. The inviting device may facilitate the merge, and the merge request may include metadata of the merge request, including invited person information, potential intermediate stops, the merge location, and various other data of the merge. In some implementations, a merge request is associated with a predetermined merge with a given invited device. Furthermore, one or more processing circuits can determine a predetermined merge based on social media data, and the predetermined merge is determined based on identifying trends within the social media data. For example, a pre-configured merge can be established based on a group of individuals who meet at an arcade on the first Friday of every month (e.g., indicated by posts on a social media website). In another example, a merge request can be crafted using a social media platform to coordinate the time and place for an educational group planning a study session at a local library. In some implementations, one or more processing circuits can receive a list of items associated with the merge request (e.g., from an inviting device). In some implementations, a merge request is a public merge request configured to share merge requests on a merge marketplace. For example, a public merge within a community can be established by an event venue or location (e.g., a football game, a movie theater, a political rally, etc.) so that merge requests can be shared on a merge marketplace or online. In particular, a merge marketplace can be a separate application (online or mobile application) configured to offer public or private merges to user accounts or unregistered users, allowing users to select one or more merges. For example, a user might discover a merge for a local art exhibition through the marketplace, enabling them to engage in a more engaging cultural experience.

[0061] In some implementations, public merges can be created and shared through a merge marketplace, allowing users to discover and participate in a variety of events, such as football games, movie screenings, or political rallies. For example, a local community center might post a public invitation to a volunteer cleanup event at a nearby park. To enhance the user experience, the system intelligently identifies subgroups of merge participants within a public event, enabling users to connect and interact with people they know or who share their interests, such as friends or acquaintances. For example, a public merge for a tailgate party could analyze data such as participants' social connections, past merges, and interests to identify potential subgroups. In another example, a concert merge could use attendees' musical preferences to suggest meetups with fans of similar genres. This information can be used to create a more personalized experience by suggesting smaller gatherings within a large public event, where users can connect with people they know or who share similar tastes. The merge marketplace can be integrated into another online or mobile application that provides public and private merges to both registered users and unregistered guests. For example, a dedicated app for local community activities could incorporate a meet-up marketplace feature to encourage residents to participate in a variety of activities and events tailored to their interests and social circles. Users could browse and select from various meet-ups, further customizing the experience to suit their preferences and comfort level. This approach promotes more meaningful and enjoyable interactions at public events while maintaining user privacy and autonomy.

[0062] In block 220, one or more processing circuits can set up a merge request. Setting up a merge request may include establishing one or more data channels with the inviting device (block 221), providing the merge request (block 222), establishing one or more data channels with the invited device (block 223), and generating and providing a proposed route (block 224). In block 221, one or more processing circuits can establish one or more data channels with the inviting device. For example, one or more processing circuits may establish a secure wireless connection with the inviting device and ensure a reliable communication channel for transmitting merge details. Each data channel may include a network connection (e.g., wired, wireless, cloud) between one or more processing circuits and the cooperative system 130. Generally, each data channel of a plurality of data channels may be communicably connected to one or more processors via a data channel communication network so that each device or system connected to the data channel can become a computing device that stores, generates, and collects data.

[0063] In block 222, one or more processing circuits may provide a merge request to each of several invited devices, the merge request including a merge location. In some implementations, one or more processing circuits may determine one or more stop points within the region of the merge request, each containing one or more items from a list of items in stock. For example, merge circuit 135 may analyze data sources 160 (e.g., local grocery stores and online). In some implementations, each inviter and invited person may be associated with an application user account (also referred to as a “profile”). For example, the first invited device may be associated with an application profile, and the first suggested route is based on the profile’s default location. In another example, the suggested route may take into account historical traffic data and current road conditions to optimize the travel time for each invited person.

[0064] In block 223, one or more processing circuits may establish one or more data channels with a first invited device in response to receiving a first acceptance of a merge request from a first invited device among a plurality of invited devices. For example, the processing circuit may use Bluetooth or Wi-Fi Direct to establish a secure connection for sharing merge details and updates in real time. In some implementations, in response to receiving the first acceptance, one or more processing circuits may provide one or more stop points as selectable elements via a first GUI of the application, and determining the stop point and providing an intermediate location is in response to receiving a selection of one of the selectable elements. For example, a stop at a local cafe offering discounts to merge participants may be suggested to enhance the overall experience and provide a relaxed setting for participants to meet before the main event. Furthermore, one or more processing circuits may update the list of items to indicate that at least one item in the list of items belongs to the first inviting device. In addition, each of the one or more stop points offered may be presented with one of the selectable elements (for example, set by the inviter or set by one or more processing circuits) and may further include incentives (for example, providing the best seats at a match, offering the first choice of one or more food items, providing a better parking spot, or providing free food or beverages associated with the meeting point). For example, a special access code to a VIP area at a concert could be offered as an incentive to participants who choose to gather at a pre-determined promotional event venue.

[0065] In block 224, one or more processing circuits can generate and provide to a first invited device, via the application's first graphical user interface (GUI), a first proposed route to the meeting point and a first real-time location of one of the invited devices or at least one of the inviting devices, the first proposed route being based on the first geographic location of the first invited device. For example, the processing circuit dynamically updates the route in real time to avoid traffic congestion and ensure the fastest possible arrival time. In some implementations, one or more processing circuits can generate and present a second proposed route to the meeting point to a second invited device, via the application's second GUI, the second proposed route being based on the second geographic location of the second invited device. For example, the application could suggest to the second invited device a scenic route that allows for enjoyable travel if time permits.

[0066] In some implementations, the first proposed route is presented to the first invited device, and the presentation includes estimated time of arrival (ETA) for the inviting device, the first invited device, and the second invited device, respectively. For example, all or specific client devices that have accepted the merge request may be provided with each other's ETA. In another example, adjustments may be made for people arriving by different means of transport, such as public transport routes for people without cars. In some implementations, one or more processing circuits may update one or more stop points based on either the first proposed route or the second proposed route. In some implementations, in a public merge, one or more processing circuits may, via an application, generate a merge request and provide the merge request to multiple public invited devices, the merge request including a merge location, and the multiple public invited devices are determined based on an enrollment dataset. In particular, the enrollment dataset may be determined from data source 160 or may be provided by the inviter (e.g., a customer list). For example, a request to join a large-scale community cleanup event can be directed to local residents who have previously participated in similar events, thereby encouraging a large turnout and fostering community engagement.

[0067] In some implementations, the first acceptance includes privacy parameters for sharing data from the first invited device, and these privacy parameters include multiple data sharing levels associated with the type and amount of data being shared. For example, users may be allowed to set their own privacy settings. In some implementations, one or more processing circuits allow inviters or inviteds to set their own privacy settings based on multiple levels relating to who can see their data. For example, the first level of multiple data sharing levels configures one or more processors to share data from the first invited device with at most the inviting device, the second level of multiple data sharing levels configures one or more processors to share data from the first invited device with at most the inviting device and one of the multiple invited devices, and the third level of multiple data sharing levels configures one or more processors to share data from the first invited device with the inviting device and one of the multiple invited devices. Specifically, the third level allows sharing both location and contact information only with those directly involved in the gathering.

[0068] In another example, the first level of multiple data sharing levels configures one or more processors to share unprotected data from the first invited device with at most the inviting device; the second level of multiple data sharing levels configures one or more processors to share unprotected data from the first invited device with the inviting device and one of the invited devices; and the third level of multiple data sharing levels configures one or more processors to share both unprotected and protected data from the first invited device with the inviting device and one of the invited devices. In other words, the processing circuitry allows users to fine-tune their privacy preferences and combine the sharing of public and private data according to the user's level of comfort with each participant. For example, a user can choose to share their current location with close friends while only sharing their estimated arrival time with acquaintances.

[0069] In some implementations, the system allows invited guests to have greater control over their privacy by enabling them to opt in and choose from various privacy parameters for each meet-up session. For example, an invited guest could choose to share their exact location only with friends while attending a large music festival, increasing security without compromising privacy. In one embodiment, the system allows invited guests to customize the sharing of protected and unprotected data based on the nature of the meet-up session. In another example, a user attending a professional networking event could choose to share business contact information but keep their personal phone number private. This allows users to distinguish between trusted meet-ups, such as meeting with well-known attendees, and untrusted meet-ups, such as public events, where the user prefers to maintain a high level of privacy. For example, during a trusted meet-up, an invited guest might feel comfortable sharing both protected and unprotected data because they know the other attendees are people they have interacted with before. On the other hand, at untrusted or public events, invited guests can choose more restrictive settings, such as sharing only unprotected data or using a completely pseudonym. For example, someone attending a large convention might share their location with all attendees on the official app, but choose to remain invisible on broader social media feeds. The ability to customize privacy parameters on a per-session basis allows users to maintain control over their data and ensures that their privacy preferences are respected across different types of congregational events.

[0070] In block 230, one or more processing circuits can monitor merge requests. Monitoring merge requests may include collecting environmental data (block 231), providing real-time locations (block 232), and disconnecting one or more data channels (block 233). In block 231, one or more processing circuits may collect environmental data of the inviting device and multiple invited devices (e.g., continuously, at specified times, or over a period of time) via one or more data channels. Environmental data may include, but is not limited to, device data such as the device's current location, interactions with the device, merge location information, and merge cancellation or completion. In some implementations, one or more processing circuits may determine stop points along a first proposed route or a second proposed route and provide intermediate locations to at least one of the first invited device or a second invited device. For example, one or more processing circuits can establish stopping points for individuals requesting a merge, stopping before they arrive at the merge point (for example, if an invitee forgets to bring ketchup to a tailgate party).

[0071] In block 232, one or more processing circuits can provide the inviting device with the real-time location (or near real-time location, or delayed location based on delay data) of the first invited device and the second invited device based on environmental data, via the application's third GUI, where the real-time locations of the first invited device and the second invited device are presented on the application's third GUI. For example, the processing circuit highlights the route each participant takes as they converge to the meeting place, providing a visual representation of the participants arriving at the inviter. In another example, the processing circuit alerts the inviter when an invited person approaches within a certain distance of the meeting place, enabling better timing for the activity. In yet another example, the processing circuit can provide updates on the invited person's ETA adjustment due to traffic conditions, keeping the inviter informed in real time.

[0072] In block 233, one or more processing circuits may disconnect one or more data channels connecting one or more processors to at least one of the first or second invited devices in response to determining that at least one of the first or second invited devices has completed a merge request at the merge location. In some implementations, one or more processing circuits may share the geographic location of the inviting device with at least one of the first or second invited devices in response to determining that at least one of the first or second invited devices has arrived at the merge location. For example, the inviter (or invited person) may share a pinned location, such as a large parking lot, after arrival. In some implementations, once the arrival of the invited person is confirmed, the processing circuits may enable the inviter to send a welcome message or instructions on exactly where to meet within the location, further facilitating a smooth merge process. For example, this can be particularly useful at crowded events where it can be difficult to find each other, and sharing a specific meeting point can significantly improve the experience.

[0073] In some implementations, when the processing circuit determines that at least one invited device has arrived at the meeting place, it enables the user to privately message or notify other invited or invited participants of their presence. In various implementations, the private messaging function is enabled for the entire meeting. This is particularly useful in situations where participants gather in large or crowded areas, such as large parking lots, concerts, or festivals. Upon arriving at the meeting place, invited participants can choose to share their precise geographical location, such as a pinned location on a map, with the inviter and other attendees. This sharing of location data can be done through private messages or notifications, allowing participants to easily locate each other without broadcasting their location to the entire group or event. In addition, once the meeting request is complete, the system can automatically disconnect the data channel connecting the invited device and the processing circuit. This ensures that the user's location information is shared when necessary, while maintaining privacy and minimizing potential security risks.

[0074] In some implementations, the processing circuit can employ a "home safe" function, which can alert parents, guardians, or other important persons if the child (or other user) is not following the designated route home (or the destination from the designated route). For example, if a child deviates from the designated route after a school event, the system can send an alert to the parents' device. This allows parents, guardians, or other important persons to check on the user and gain peace of mind. In other words, this function can provide a real-time tracking option, so that guardians know the child's current location. For example, the processing circuit can send a notification if the child's device remains motionless for a certain period of time or if it detects an unusual movement pattern.

[0075] In some implementations, during the setup of a meet-up request in block 220, the processing circuit can determine and suggest a central meet-up location based on the geographical locations of all or some of the participants. For example, if participants are evenly distributed throughout the city, the system might suggest a popular central café equidistant (or nearly equidistant) from all attendees, maximizing convenience and reducing travel time. In another example, if the meet-up involves participants' preferences for outdoor activities, the system could suggest a highly-rated park centrally located from everyone's locations. In some implementations, the processing circuit determines and suggests a central location based on real-time traffic data and the participants' current locations to ensure the most efficient route for everyone. For example, a centrally located museum not only serves as a convenient meeting point but also offers engaging activities for the group. In some implementations, the central location can be based on specific characteristics or profiles of participants, such as a preference for vegan restaurants or an interest in art galleries, ensuring that the suggested location matches the group's interests.

[0076] In some implementations, the application presenting the GUI provided by the processing circuit can further include links to other applications. That is, during a meeting, the GUI could present audiobook applications, music applications, podcast applications, etc., allowing participants to receive similar audio or content (e.g., music by a specific band or artist if attending a music festival) or identical audio or content (e.g., the same podcast about wedding planning if participants are meeting for a wedding planning meeting). In other words, the GUI can facilitate seamless switching between different audio sources according to individual preferences or group agreement. For example, as a user approaches a book festival location (e.g., while collecting environmental data in block 231), the processing circuit could suggest starting the latest audiobook by a popular author. In another example, if the majority of the group starts playing a pre-meeting hype playlist, the GUI could display a notification to encourage others to join in. In some configurations, the processing circuit could provide a recommended playlist or audiobook chapter that finishes just as participants arrive at the meeting location (or around that time). For example, a playlist with a duration matching the estimated travel time may be automatically generated. In addition, one or more joining participants can share their favorite podcast episodes and begin simultaneous playback across devices. For example, when one participant presses the "Share and Play" button, all participants start listening to the same podcast from the same point. In another example, joining members may share curated playlists that dynamically update as the group progresses towards its destination. In addition, other individuals can receive real-time updates on the progress of other participants in the audio they are listening to, such as a live indicator showing which song in the shared playlist is currently playing. For example, the GUI could show that most participants are listening to chapter 3 of a shared audiobook, allowing other participants to synchronize their playback.

[0077] In some implementations, the processing circuitry allows the first and second GUIs to include look-and-feel (LF) themes based on the merge request or merge location. For example, the GUI theme could automatically adjust to create a festive user interface for a Halloween-themed merge, featuring pumpkin and ghost motifs. In some implementations, the merge request provided to multiple invited devices may include a customized invitation containing content corresponding to the merge request or merge location. For example, the customized invitation could feature a floral design and elegant cursive font suitable for a wedding-themed gathering.

[0078] In some implementations, if one of the invited devices or the inviting device is sharing its location, the first location of one of the invited devices or the inviting device can be used as a first visual indicator. If one of the invited devices or the inviting device is not sharing its location, the first location of one of the invited devices or the inviting device can be used as a second visual indicator. For example, the first visual indicator could be a bright pink color to show its presence when location sharing is active, and change to a light gray color to indicate privacy when location sharing is turned off.

[0079] In some implementations, the processing circuit, in response to receiving a first acceptance, activates one or more safety features on the first invited device, which include enabling a third-party device to track the first invited device and establishing a separate data channel between the third-party device and the first invited device for communication or message exchange. For example, a home safe feature allows a designated contact, such as a family member, to monitor the user's journey home after the event, thereby enhancing safety and peace of mind.

[0080] In some implementations, the received meeting point is a general location, and the processing circuit can, in response to receiving a first acceptance of the meeting request, determine the central location of the meeting point based on the first geographical location of the first invited device and the geographical location of the inviting device, and the first proposed route to the meeting point is to the central location. For example, a central meeting point based on the individual locations of the users may facilitate a convenient meeting place by calculating an intermediate point that minimizes the total travel time for all participants.

[0081] In some implementations, generating and providing a first suggested route to a meeting point via the application's first GUI includes at least one of the following: (1) a first optional element including requesting a rideshare or carpool for the meeting; (2) a second optional element including a suggestion for transportation by the inviting device or multiple invited devices; or (3) a third optional element including media recommendations that the first invited device can output as audio during the first suggested route to the meeting point. For example, the first optional element may include an option to select a rideshare service based on the option with the earliest arrival time or the option that is most cost-effective. For example, the second optional element may provide coordination of transportation schedules among inviteds to optimize routes for picking up each person based on their respective locations. For example, the third optional element may suggest playlists or podcasts that are popular or trending within the group's shared interests. In another example, a third optional element could be curating a playlist of music related to the meeting theme, or selecting a podcast episode that matches the estimated time to the destination, ensuring that the entertainment is perfectly timed to the duration of the journey.

[0082] Referring next to Figure 3, flowcharts of Method 300 for linking devices to protect data are shown in several embodiments. Client devices 110 (e.g., 110a and 110b) can be configured to perform Method 300. Furthermore, any computing device described herein can be configured to perform Method 300.

[0083] In a general overview of Method 300, Block 310 allows one or more processing circuits (e.g., client device 110 in Figure 1) to receive a merge request that includes a meeting place. For example, the request might come from a user planning to meet friends at a football game, specifying a particular entrance gate as the meeting place. In some deployment configurations, the merge request may include identifiers of invited devices expected to participate. For example, the request could specify the mobile device IDs of all attendees, facilitating a more secure and targeted connection.

[0084] In block 320, one or more processing circuits may provide the protection system with an acceptance of a merge request. For example, an attendee's device may return a confirmation message along with current location data. In some deployment configurations, the acceptance may include a verification token to authenticate the response. For example, each device may include a unique QR code® or digital signature in its acceptance to securely verify the identity of the attendee.

[0085] In block 330, one or more processing circuits can establish a data channel with the protection system in response to an acceptance. For example, a secure connection is set up to share location updates and notifications. In some deployment configurations, establishing a data channel may include setting up encrypted communications to protect the privacy of participants. The protection system facilitates merging, and user devices (e.g., processing circuits) can monitor the real-time location of all participants. For example, an app can display the current location of all attendees on a map and update their locations as they move.

[0086] In block 340, one or more processing circuits can receive and present, via the application's graphical user interface (GUI), a proposed route to the meeting point and the real-time location (or near real-time location, or past location) of one of the invited devices or at least one of the inviting devices, where the proposed route is based on the user device's first geographical location. For example, the app can propose the most efficient route for each attendee to reach a designated meeting point. In some configurations, the proposed route can be adjusted in real time based on changes in attendees' locations and traffic conditions. For example, if a road closure occurs, the app can immediately propose an alternative route to the meeting point.

[0087] In block 350, one or more processing circuits may collect and provide environmental data via data channels. For example, this may include up-to-date weather information, traffic information, or event-specific alerts. In some deployment configurations, collecting and providing environmental data may include integrating with external APIs for live updates. For example, an app could retrieve data from weather services and social media feeds to give attendees a comprehensive view of the conditions at the meeting place. In another example, a processing circuit could alert a user to leave early due to an expected storm.

[0088] In Block 360, one or more processing circuits can receive and display the real-time location of at least one of multiple invited devices or the inviting device via the application's GUI. For example, attendees can see how far their friends are from the meeting point. For example, the host can monitor when each guest is likely to arrive and adjust accordingly. Real-time locations can be displayed on an interactive map within the app. In some configurations, the display can include options for attendees to interact directly with each other through the app, allowing attendees to adjust or adjust meeting details as needed. For example, attendees can send messages directly through the app or share updates on their estimated arrival times.

[0089] In block 370, one or more processing circuits may disconnect the data channel connecting one or more processors to the protection system in response to one or more processors determining that they have completed the merge request at the merge location. For example, once all attendees have arrived, the app can automatically close the merge event, stop location tracking, and conserve battery life and privacy. In some deployment configurations, disconnecting the channel may include sending a final notification to all participants to confirm the success of the meet. For example, once the merge request is complete, the app may send a "Merge Successful" message and also offer the option of a group photo or event check-in to a social media platform.

[0090] Depending on the specific configuration, additional, fewer, or different operations may be performed. In some embodiments, some or all of the operations of Method 300 may be performed by one or more processors running on one or more computing devices, systems, or servers. In various embodiments, each operation may be reordered, added, deleted, or repeated.

[0091] In some embodiments, one or more processing circuits can present real-time location data of an invited or inviting device when one or more processing circuits are not moving geographically. In one embodiment, this location sharing is activated only when the processing circuit determines that the device is stationary. For example, if a user is at a designated meeting place and is not moving, real-time location data becomes available to other participants. Conversely, if a user is passing by or moving around, their real-time location data is not shared to protect their privacy. This dynamic location sharing feature allows users to connect with others during a meeting event while giving them a greater sense of control over their personal information.

[0092] Figures 4-5, which illustrate graphical user interfaces in several embodiments, are shown with general reference. Generally, Figures 4A-5K show graphical user interfaces that can be rendered on the client device 110 to perform and implement merging. A graphical user interface can include multiple interfaces, objects, and selectable elements. For example, the client device 110 can be configured to provide merging information (e.g., merging start, ongoing merging data, past merging data) to the graphical user interface based on events performed by application 112. A graphical user interface may include multiple interfaces, objects, and elements so that an individual (e.g., user or human operator) can provide biometric data (e.g., stress level, heart rate, hand shape, face shape, mental state, etc.) and / or behavioral data (e.g., haptic feedback, gestures, speech patterns, movement patterns (e.g., hands, feet, arms, face, iris, etc.)) and intangible feedback (e.g., selection of intangible content displayed on the client device 110, response to stimuli, etc.) and interact with multiple interfaces, objects, and / or elements. In various embodiments, the client device 110 can be of various sizes, such as mobile phones, IoT devices, smartwatches, smart gear, helmets, virtual reality headsets, augmented reality headsets, smart glasses, hats, headgear, and / or any type of portable electronic device. Thus, the display and / or client device 110 is not limited to any particular combination of hardware circuitry and software.

[0093] In some implementations, application 112 can change the appearance and look of its graphical user interface (GUI) (e.g., GUI400 and GUI500) based on the time of year (e.g., season), a specific day (e.g., July 4th), user religion, user age, user location, or type of gathering (e.g., going to a Halloween party). In other words, the theme and functionality of the GUI can be changed to match seasonal activities or holidays, thereby enhancing user engagement and festive mood. For example, during Halloween, the GUI could display a spooky theme with interactive elements such as pumpkins and ghosts, and tapping them could reveal gathering details or the location of the Halloween party. In another example, on Valentine's Day, the GUI could feature a romantic theme with hearts and roses, suggesting activities and events for couples. In yet another example, during the Christmas season, the GUI could be updated to reflect a winter wonderland, with snowflake touchpoints leading to a gathering of holiday markets. In yet another example, the GUI could feature vibrant festive colors for Hindu users during the Holi festival. Thus, the graphical user interface provided by application 112 can dynamically adjust its presentation and content in the context of the seasonal or festive theme of the merge to enhance the user experience. In additional implementation forms, application 112 can change the appearance and look of destination icons on the GUI. For example, when a destination is selected in the merge, a destination-specific icon may appear. This destination-specific icon may include, for example, a large trademark icon of the destination. For example, if Warner Bros. Studios is selected as the destination in the merge, the Warner Bros. Studios logo may appear floating above the destination location on the map. In another example, if the destination in the merge is a coffee shop, a large coffee cup may appear above the destination location. In this way, the GUI can help the user navigate to the destination by displaying relevant graphic information to the user.

[0094] In some implementations, application 112 can create, or allow the creation of, customized meet-up invitations for events, such as decorated digital invitation cards. That is, the GUI (e.g., GUI400 or GUI500) can provide inviters with a set of tools for designing personalized invitations with themed graphics, interactive elements, and meet-up information tailored to the nature of the event, such as a birthday party or wedding. For example, for a birthday celebration, the GUI could provide a template incorporating balloons and a cake, where tapping the balloons reveals the meet-up time and the cake displays the venue. In another example, for a wedding meet-up, the invitation could be decorated with a floral border, allowing guests to respond and meet at the destination by selecting flowers. In yet another example, for a corporate event, the GUI could provide a template with company branding, and interactive elements could outline the meet-up agenda. Thus, the graphical user interface provided by application 112 can be adapted to allow users to customize event-specific invitations. For example, in wedding preparations, application 112 can be used to send meet-up requests to all guests using a wedding-themed interface. These requests can also serve as digital invitations, and once accepted, the couple can track the progress of the invited guests on the wedding day. Application 112 on the GUI can also play wedding music chosen by the couple for guests as they travel to their locations. On the wedding day, everyone's location (or everyone who shared a location) is visible on the GUI, providing real-time updates on who has arrived.

[0095] Next, we refer to Figures 4A to 4K, which illustrate graphical user interfaces in several embodiments. Figures 4A to 4K disclose a method for setting up and carrying out a merge. The method includes setting a merge location (or destination), inviting friends or other individuals (by the inviter), adding arbitrary stops, and starting to proceed toward the merge. For example, in Figure 4A, the user can launch application 112 to present a graphical user interface (GUI) 400. The GUI 400 allows the user to interact with the GUI 400 and select an interactable element 402 to invite one or more individuals to merge. In Figure 4B, the user can interact with the GUI 400 and select an interactable element 404 to explore a merge location. In some configurations, the merge location should be added before inviting individuals to merge. In Figure 4C, after the user selects a meeting place, the user can interact with GUI 400 to select an interactive element 406 and invite one or more individuals to meet at a specific meeting place. In Figure 4D, a pop-up or another interactive element can be presented within GUI 400, allowing the user to interact with the pop-up to invite individuals to meet. In some configurations, the user can add 1 to n individuals to the meet. In addition, another pop-up or interactive element can be presented on the GUI, allowing application 112 to access the user's contacts through interaction with the user.

[0096] In Figure 4E, the user can interact with GUI 400 to select an interactive element 408 and invite one or more individuals. In addition, another popup or interactive element can be presented on GUI 400, which, through interaction with the user, allows application 112 to send messages (e.g., SMS messages, emails, phone calls). Furthermore, once someone is invited, that individual can appear in GUI 400 under the merge content. In Figure 4F, GUI 400 can indicate that a merge request has been sent and delivered, and the invited individual can receive a text message displayed on GUI 410 (e.g., a messaging application) on their computing device. In Figure 4G, after the invited individual downloads the application or accesses the web portal, GUI 400 can allow the invited individual to accept the merge request by interacting with GUI 400 and selecting an interactive element 412. In some deployment configurations, various details of the merge can be presented in GUI 400.

[0097] In Figure 4H, a user (invited or inviter) can initiate a merge trip on the GUI 400 by selecting the interactive element 414. In some configurations, once a merge request is accepted, the invited or inviter's GUI 400 in application 112 can automatically initiate the trip. After the trip has started, the GUI 400 can present the user's route to the merge location. In some configurations, the GUI 400 can be made to pause and resume the trip. In Figure 4I, other individuals in the group are notified that an individual has accepted a merge request by a check mark appearing next to the individual's avatar (e.g., John AndroidDev) next to their name. In some configurations, the GUI 400 can allow the individual who has accepted the trip to view the locations of all users by selecting the interactive element 416. In some configurations, various details of the merge can be presented in the GUI 400.

[0098] In Figure 4J, a user (invited or inviter) can view other users in a merge on the GUI 400 by selecting an interactive element 416 (also shown in Figure 4). In response, application 112 may present additional selectable elements, including selectable element 418, "View Merge Map." When selected, content item 420 is presented on the GUI 400, allowing one of the merge participants to view one or more locations of other individuals who have accepted the merge. In some configurations, content items can be identified by color, highlighting, or otherwise based on whether the user is actively sharing those locations. For example, pink may be presented on the GUI 400 to indicate that the user is actively sharing their location with other merge participants. In another example, gray may be presented on the GUI 400 to indicate that the user is not actively sharing their location with other merge participants. Thus, the GUI 400 uses color coding, highlighting, and visual indicators such as icons to show each participant's location sharing status and other relevant details, providing an appearance that enhances group coordination and interaction during the merge. In Figure 4K, GUI 400 allows individuals in a merged trip to complete (or end) the merge by selecting an interactive element 422. In some configurations, the location of an individual who has completed the merge may be shared with other individuals in the merge. For example, one location where a user has ended the merge may be shared with other individuals. In another example, a continuous location may be shared with other individuals so that other users in the merge can view it before completing their merge.

[0099] Next, we refer to Figures 5A to 5C, which illustrate graphical user interfaces in several embodiments. Figures 5A to 5C disclose a method for setting up and conducting a merge. The method includes setting a merge location (or destination), inviting friends or other individuals (by the inviter), adding arbitrary stops, and starting to proceed toward the merge. For example, in Figure 5A, the user can launch application 112 to present a graphical user interface (GUI) 500. GUI 500 may include similar features and functions to GUI 400 in Figures 4A to 4K. In some configurations, GUI 500 can allow individuals to create merges, invite individuals, and add one or more intermediate stops to the merge. In addition, after the merge creator enters the invited person information, a popup of GUI 510 of a messaging application can be displayed, allowing the creator to send invitations to one or more individuals to join the merge. In Figure 5B, invited individuals can also interact with GUI 500 to invite additional individuals to join the merge. In some configurations, individual names may be displayed on GUI 500 above the "Invited" indicator before a check mark appears on the avatar (e.g., indicating acceptance of the merge). In some configurations, one or more of the individuals in the merge can review the route and any optional stops. In Figure 5C, GUI 500 can allow users to select a mode of travel using one or more interactive elements (e.g., car, bicycle, walking / running, public transport). In some configurations, GUI 500 can offer rideshare or carpool, or application 112 can request rideshare or carpool, to pick up merge users and take them to the merge location. In addition, during the merge, users may be presented with pop-ups on GUI 500 that allow them to modify the merge or adjust settings (e.g., route settings, alternative routing, adding stops, editing or ending the route, closing, etc.). In some configurations, the next stop point and the final stop point may be presented to the GUI500.

[0100] In some configurations, a participant joining a ride can send a notification or request to another participant joining to pick them up (for example, because this person is on their way to the meeting point), or one participant joining a rideshare service can pick up the other participant joining the ride. For example, while on their way to the meeting point, one participant joining, Sarah, realizes she is running late due to unexpected traffic. Sarah notices she is passing by another participant joining, Tom, who is still at home, and uses GUI500 to send a notification to Tom suggesting he could pick her up along the way. GUI500 facilitates this interaction by allowing Sarah to send a request directly to Tom, streamlining their coordination and ensuring they both arrive at the meeting point together. In another example, Mike is using a rideshare service to get to the meeting point and realizes his route is passing by where Jenna is. Through the application GUI500, Mike sends a request to a rideshare driver via app integration to create an additional stop to pick up Jenna. This functionality within GUI500 enhances the user experience by ensuring efficient route planning and facilitating easy coordination among meeting participants. In some arrangement configurations, one meeting participant can send a request to pick up another individual who is walking. For example, Alex, who decided to walk to the meeting point, realizes the walk is longer than expected. Seeing this, Jordan, who is driving to the same location and nearby, sends a ride request to Alex via GUI500 and offers to ride the remaining distance. This gesture is facilitated by the functionality of application 112, which provides a real-time solution for communication between participants and improving the overall experience and convenience of the group.

[0101] Next, refer to Figures 6-1 to 6-4, which illustrate exemplary diagrams for protecting data associated with merge. As shown, when using merge, information can be protected from other third parties or other unknown parties. The data protection framework can protect personal data, thereby improving the security of mapping systems and collaborative applications. For example, a typical map application may include a user's name, gender, age, date of birth, relationship status, past behavior (e.g., pizza orders, pizza type, other orders), and music they have listened to in the past. However, the data protection framework described herein can anonymize the user and protect various other types of data.

[0102] Next, we refer to Figures 7A to 7B, which illustrate graphical user interfaces in several embodiments. Figures 7A to 7B disclose the wildcard functionality of the merge application described herein. The graphical user interface 700 shown in Figures 7A to 7B may include several interactive elements 702 related to various available wildcards. For example, the GUI 700 can be updated depending on the wildcard selected. For example, Figure 7B can display a COVID-19 testing center. The wildcard functionality allows individuals to set locations of interest. For example, instead of general locations of interest including grocery stores and coffee shops, an individual can set specific locations of interest in their user account, such as COVID-19 testing sites, specific gas stations, specific grocery stores (e.g., a brand of grocery store, or a grocery store that sells a specific product such as kombucha), specific coffee shops (e.g., a brand of coffee shop, or a coffee shop that sells a specific beverage such as cortado), specific restaurants, or specific types of beer (e.g., a brewery that sells sours). For each wildcard, users can further customize the results displayed based on their preferences. For example, they can specify the star rating of the location (e.g., only locations with a star rating of 4.5 or higher), the current wait time for that location (e.g., show locations with a wait time of less than one hour), and whether the location is available for booking.

[0103] In some implementations, the wildcard feature can be extended to include time-constrained events or availability, such as weekend farmers' markets or restaurant happy hours. This means users can specify their interest in events that only occur on specific days or times, and the application can provide targeted recommendations that fit the user's schedule. For example, a user could set Friday night outdoor concerts to be included in their preferences, ensuring they receive notifications or suggestions only for events that meet this criterion. Another example is when a user sets alerts for their favorite places when certain conditions are met, such as when there's no wait at a popular restaurant or when a specific item is in stock at a nearby store. The application can monitor these conditions in real time and notify the user immediately, making this feature extremely practical in time-constrained or high-demand scenarios. For instance, a user could be alerted when a newly released book becomes available at their local library, allowing them to reserve it before others.

[0104] Figure 8 shows a diagram of a computer system 800 that can be used to implement, for example, an exemplary client device 110, an exemplary cooperative system 130, and / or various other exemplary systems described herein. The computing system 800 includes a bus 805 or other communication component for transmitting information and a processor 810 coupled to the bus 805 for processing information. The computing system 800 also includes a main memory 815 coupled to the bus 805, such as random-access memory (RAM) or other dynamic storage devices for storing information and instructions executed by the processor 810. The main memory 815 may also be used to store location information, temporary variables, or other intermediate information while the processor 810 is executing instructions. The computing system 800 further includes a read-only memory (ROM) 820 or other static storage devices coupled to the bus 805 for storing static information and instructions for the processor 810. A storage device 825, such as a solid-state device, magnetic disk, or optical disk, is connected to the bus 805 for permanent storage of information and instructions.

[0105] The computing system 800 can be connected to a display 835, such as a liquid crystal display or an active-matrix display, via a bus 805 to display information to the user. An input device 830, such as a keyboard including alphanumeric keys and other keys, can be connected to the bus 805 to transmit information and command selections to the processor 810. In another implementation, the input device 830 has a touchscreen display 835. The input device 830 includes a cursor control device, such as a mouse, trackball, or cursor directional keys, for transmitting directional information and command selections to the processor 810 and for controlling cursor movement on the display 835.

[0106] In some implementations, the computing system 800 may include a communication adapter 840, such as a networking adapter. The communication adapter 840 may be connected to the bus 805 and may be configured to enable communication with the computing or communication network 120 and / or other computing systems. In various exemplary implementations, any type of networking configuration can be realized using the communication adapter 840, such as wired (e.g., via Ethernet®), wireless (e.g., via Wi-Fi, Bluetooth, etc.), pre-configured, ad-hoc, LAN, WAN, etc.

[0107] In various implementations, the process of performing the exemplary implementation described herein can be achieved by a computing system 800 in which a processor 810 executes a set of instructions contained in main memory 815. Such instructions can be read into main memory 815 from another computer-readable medium, such as a storage device 825. The execution of the set of instructions contained in main memory 815 causes the computing system 800 to perform the exemplary process described herein. One or more processors in a multiprocessing configuration may also be employed to execute the instructions contained in main memory 815. In alternative implementations, hardwired circuits may be used instead of or in combination with software instructions to implement the exemplary implementation. Thus, the implementation is not limited to any particular combination of hardware circuits and software.

[0108] While an exemplary processing system has been illustrated in Figure 8, the implementation of the subject matter and functional operations described herein can be carried out using, or in combination with, other types of digital electronic circuits, or hardware including computer software, firmware, or structures disclosed herein and their structural equivalents.

[0109] Next, referring to Figure 9, flowcharts of computer implementation methods 900 for recommending and / or playing media (e.g., audiovisual media) based on predicted movement duration are shown according to several embodiments. System 100 can be configured to perform method 900. Furthermore, any computing device described herein can be configured to perform method 900.

[0110] In the outline of Method 900, step 910 allows one or more processors to receive route parameters and playback parameters. Step 920 allows one or more processors to predict the travel duration. Step 930 allows one or more processors to access one or more media sources. Step 940 allows one or more processors to identify multiple media. Step 950 allows one or more processors to generate a subset of media. Step 960 allows one or more processors to present the subset of media for display. Step 970 allows one or more processors to receive the media selection. Step 980 allows one or more processors to activate the audio source that outputs the media. Depending on the particular configuration, additional, fewer, or different operations may be performed. In some embodiments, some or all of the operations of Method 900 may be performed by one or more processors running on one or more computing devices, systems, or servers. In various embodiments, each operation may be reordered, added, deleted, or repeated.

[0111] In step 910, one or more processors in the user device receive route parameters and playback parameters. Route parameters may include various data related to the navigation route. Such data may include location information for the navigation route and how to travel along the navigation route. Location data may include the starting location of the navigation route, the destination location of the navigation route, and real-time conditions of the navigation route (e.g., construction, toll booths, traffic conditions). Additional information included in the location data may include additional stops along the navigation route, such as restaurants, gas stations, intermediate stops at tourist attractions, or places to run errands. Location data may also include the time of day and / or the timing of the travel. For example, location data may include the departure time or the desired arrival time. In some embodiments, location data is received by one or more processors as user input to the user device. In some embodiments, location data is received from a standalone application running on the user device, such as a map application or a navigation application. Location data may be received over a network (e.g., network 120 in Figure 1). Returning to Figure 9, the mode of transportation can be one or more modes of transport. For example, the mode of transport may be, but is not limited to, a car, subway, walking, cycling, public transport, bus, airplane, rideshare, train, rail vehicle, animal (e.g., horse), skiing, skating, sled, off-road vehicle, motorcycle, helicopter, ferry, tram, cable car, hot air balloon, personal transporter, jet ski, gondola, rickshaw, or boat.

[0112] Playback parameters may include one or more media attribute preferences and a playback speed threshold. According to at least one embodiment, media attribute preferences may be associated with the user's media history or user input and may include preferred media types (e.g., podcasts, songs, music videos, movies, audiobooks, spoken language files, text-to-speech transcripts, voice recordings, voicemails, lectures, training videos, seminars, presentations, news broadcasts, sports commentary, talk shows, predictive phone calls, radio broadcasts), preferred media content (e.g., sports, entertainment, music, science, engineering, art, specific topics), and authors / speakers (e.g., book authors, podcast hosts, news anchors). Media attribute preferences can include: celebrities, athletes, media length (e.g., less than 10 minutes, less than 1 hour, longer than 30 minutes), media source (e.g., music application, news application, website, video player application, radio station), content depth (e.g., broad overview of a topic, in-depth exploration of a topic), media era (e.g., 1950s, 2000s, modern, classical), media genre (e.g., jazz, rock, classical), media language (e.g., English, Spanish, Latin, ASL), closed captions (e.g., subtitled media / unsubtitled media), etc. Media attribute preferences can be derived from user input or past user preferences, determined by past selections and adjustments received during media playback of different content. Past user preferences, selections, and / or adjustments can be stored in a user profile in a remote electronic storage location or locally on the user device.

[0113] In some embodiments, media attributes are associated with the time of day of navigation. For example, a user's past data stored in their user profile might include information such as listening to financial news while navigating from home to work in the morning and listening to classical music while navigating from work to home in the evening. This bifurcated media preference can then be used to recommend media based on the time of day and the location of the navigation.

[0114] In some embodiments, the playback speed threshold corresponds to the maximum media playback speed. For example, the playback speed threshold may be twice the playback speed. In such embodiments, the maximum media playback speed is twice the speed, in other words, it is played at twice the default (e.g., standard) speed. Various types of media content can have variable playback speed thresholds. For example, music may have a playback speed threshold of 1x (e.g., standard speed). Podcast media may have a playback speed threshold of 1.5x. Seminars or lectures may have a playback speed threshold of 2x. Various playback speed thresholds can be determined by past adjustments received during media playback of audiovisual media content and can be received by user input or past user preferences. In some embodiments, one or more processors receive and / or select default playback speeds for various types of media content.

[0115] It should be understood that in some implementations of the methods and systems described herein, step 910 does not necessarily have to include receiving a route parameter. For example, the systems and methods described in method 900 do not necessarily have to be applicable to the navigation embodiment, as will be described in more detail below. Rather, in some embodiments, the route parameter may be replaced with a “wait parameter.” For example, the wait parameter may include data associated with a wait time. For example, a user may input to an electronic device the length of time the user must wait before the next activity. In another example, one or more processors may query one or more calendars, messages, voicemails, etc., for event or activity information with associated location and / or time. In one example, a mother may be waiting to pick up her son from school. The activity “Pick up son” may be at 4:00 p.m. on the mother’s calendar. One or more processors may receive the current time (e.g., 3:39 p.m.) and the event time on the calendar (e.g., 4:00 p.m.). These two times may be included in the received wait parameter. Similarly, without the processor accessing event information such as a calendar, the mother can input into an electronic device (e.g., through a standalone application not associated with navigation) how much time remains for her until the activity (e.g., 21 minutes). This waiting time may be included in the waiting parameter. Therefore, the considerations relating to the movement parameter / movement duration in this specification may also apply to the waiting parameter / waiting duration.

[0116] In step 920, one or more processors predict the travel duration of a navigation route based on at least the mode of travel. In some embodiments, one or more processors estimate the travel time from the starting point to the destination point, passing through any additional intermediate points. One or more processors determine the length of the travel time considering the received mode of travel. In some embodiments, one or more processors predict the travel duration based on real-time traffic data or route information (heavily and lightly congested areas and corresponding delays), construction data (e.g., road closures, detours, etc.), and toll data (e.g., toll amounts and toll options).

[0117] It should be noted that in some embodiments, one or more processors predict travel duration, but one or more additional processors may also predict travel duration and transmit the predicted travel duration to one or more processors. For example, a remote server may run one or more prediction protocols to predict travel duration and transmit the predicted travel duration to one or more processors on a user device. In some embodiments, the predicted travel duration is a time range (e.g., 30-40 minutes). The predicted travel duration may be calculated based on real-time route information received from one or more traffic data sources. For example, real-time route information may include detours, traffic conditions, closures, congestion, etc.

[0118] In one embodiment, the mode of travel may be a commercial mode of travel (e.g., a civilian aircraft, bus, train, subway, etc.). In such an embodiment, the predicted duration of travel may be additionally, or alternatively, at least in part, based on scheduled departure and / or scheduled arrival times.

[0119] As discussed above, in some embodiments, Method 900 is not associated with travel time but with waiting time. In such embodiments, one or more processors determine the waiting time instead of the travel time. For example, in the given example above, where the current time is 3:39 p.m. and the mother will pick up her son at 4:00 p.m., a waiting time (e.g., 21 minutes) may be determined (as opposed to the travel time). This allows the user (e.g., the mother) to utilize the methods and systems described herein in situations other than travel (e.g., when waiting in line for school drop-off / pick-up).

[0120] In step 930, one or more processors may have access to one or more media sources. These media sources may be associated with one or more media content platforms, such as Netflix®, YouTube®, Hulu®, Amazon Prime Video®, Disney+®, Spotify®, Apple Music®, and SoundCloud®. Additional media content platforms may include a media database (e.g., data source 160 in Figure 1) hosted remotely or locally for one or more processors. The media database may host media files for access, retrieval, and / or playback by one or more processors.

[0121] In step 940, one or more processors can identify multiple media from one or more media sources that have one or more media attributes that match one or more media attribute preferences. According to one embodiment, one or more processors can run one or more computer comparison protocols to compare the media attributes of individual or batch media stored in one or more media sources with the received media attribute preferences. Similarly, various filtering techniques may be used to filter media in one or more media sources based on one or more media attributes. If media has one or more media attributes that satisfy the received media attribute preferences, one or more processors identify the satisfying media as having one or more media attributes that match one or more received media attribute preferences.

[0122] In step 950, one or more processors generate a subset of media from multiple media. In one embodiment, each media in the subset of media may share one or more common attributes. In the exemplary embodiment, each media in the generated subset of media has a minimum playback duration within the playback range.

[0123] In some embodiments, each media has multiple playback durations. For example, the media may have a standard playback duration, a minimum playback duration, a maximum playback duration, and / or a regulated playback duration.

[0124] The standard playback duration may correspond to the playback length of the media at the standard (e.g., default) playback speed. In the example given, the standard playback speed is 1x. This can be considered the default speed at which the media is output, either through the playback settings or the media file attributes.

[0125] The media may also have a minimum playback duration. The minimum playback duration may correspond to the shortest playback length of the media, based on the media being output at the maximum playback speed (e.g., maximum playback speed). In the exemplary embodiment, the maximum playback speed is 2x speed. In some embodiments, as discussed above, different media types and / or content may have different maximum playback speeds. In at least one embodiment, the maximum playback speed corresponds to the playback speed threshold received in step 910.

[0126] The maximum playback duration may correspond to the longest playback length of the media, based on the media being output at the minimum playback speed (e.g., minimum playback rate). In the exemplary embodiment, the minimum playback speed is 0.75x. In some embodiments, different media types and / or content may have different minimum playback speeds. The minimum playback speed may correspond to the playback speed threshold received in step 910.

[0127] The adjusted playback duration may correspond to the adjusted playback length, based on the media being output at an adjusted playback speed (e.g., adjusted playback speed). The adjusted playback speed can be any playback speed multiplier that increases or decreases the playback speed of the media, but in the exemplary embodiment, the adjusted playback speed is within the range of the minimum and maximum playback speeds.

[0128] It should be understood that media can have one or more playback durations of the same length. For example, in some embodiments, the maximum playback speed of music may be the same as the standard playback speed of music (e.g., 1x speed), as it may be preferable not to increase the playback speed of the music. In such embodiments, the standard playback duration and the minimum playback duration may be the same. Similarly, the minimum playback speed may be the same as the standard playback speed and the maximum playback speed. In such embodiments, the maximum playback speed, standard playback duration, and minimum playback duration may be the same length.

[0129] In some embodiments, the playback range extends from a lower limit to an upper limit. In various embodiments, the lower limit is 0 minutes and the upper limit is the predicted movement duration (or an upper / lower predicted movement duration within a range of values). In some embodiments, the lower limit may be longer than 0 minutes and may be received by one or more processors as user input / preference (e.g., at least half of the predicted movement duration).

[0130] In some embodiments, one or more processors generate a subset of media without first identifying multiple media having one or more media attributes. In such embodiments, one or more processors do not receive media attribute preferences, and one or more processors generate a subset of media, but each individual media within the subset of media satisfies the minimum playback duration regardless of its media attributes.

[0131] When determining the minimum playback duration, one or more processors may consider a given segment of the individual media. For example, when determining whether the minimum playback duration of an audiobook will fit within the estimated or predicted travel duration, one or more processors may refer to the length of individual chapters. Individual chapters can be considered a given segment of the media, and similarly, chapters in podcasts, videos, performances, lectures, etc., created by the author or publisher can also be considered a given segment of the media. One or more processors may consider the length of individual chapters as the "minimum playback duration" when determining whether the media can be played within the estimated travel duration.

[0132] In step 960, one or more processors present a subset of media for display on the user device via a GUI or auditory user interface (AUI) of an application run by one or more processors. In one embodiment, the subset of media is presented as selectable graphical components on the GUI. The subset of media may be presented for display along with various media attributes associated with the media. For example, media attributes may include various playback durations (with corresponding playback speeds), genre, title, author, host, description, etc. In step 970, one or more processors receive a selection of media from the subset. The selection is made and received as user input by one or more processors.

[0133] In step 980, in response to receiving a selection of media from a subset of media, one or more processors activate an audio source on a user device or an external device and output media from the subset of media. The user device may be the client device 110a in Figure 1. The external device may be a vehicle or other audio playback device, such as an audio converter (e.g., speakers, headphones, etc.). In various embodiments, one or more processors activate the audio source to output media at a playback speed below a playback speed threshold, thereby reproducing the entire media file at a speed within the playback speed threshold within the predicted travel duration.

[0134] As a non-limiting example, one or more processors may receive user input at 1.5x speed as a playback speed threshold for playing a podcast episode (a preferred media attribute of the user associated with one or more processors). After receiving the mode of travel (e.g., travel by car) and the starting and destination locations, one or more processors determine a navigation route between the starting and destination locations. One or more processors predict a travel duration of one hour based on real-time traffic conditions, the length of the navigation route, and the average speed of the car (or the user's past speed). One or more processors access various media sources associated with the user profile associated with one or more processors. By accessing various media sources, one or more processors identify various media files that satisfy the preferred media attribute (e.g., podcast episodes). Upon identifying various media files that satisfy the desired media attributes, one or more processors determine the minimum playback duration for each of the media files that satisfy the preferred media attributes by adjusting the standard playback duration of each media file to a 1.5x playback speed threshold and determining the resulting playback duration. The one or more processors then generate and present a list of media files with a minimum playback duration shorter than the predicted travel duration. When presenting media files with a minimum playback duration shorter than the predicted travel duration, one of the presented media files may be selected and fully reproduced within the predicted travel duration. Once one or more selections of the presented media files are received by one or more processors, the one or more processors cause the media file to be output acoustically and / or visually at the playback speed. In some embodiments, one or more processors reproduce the media file at the standard (or other default) playback speed if the standard (or other default) playback duration is within the range of the predicted travel duration.If the standard playback duration is longer than the predicted travel duration, one or more processors may play the media file at an adjusted playback speed, where the adjusted playback speed is the minimum increase so that the adjusted playback duration is shorter than the predicted travel duration. In some embodiments, the predicted travel duration is continuously updated (e.g., at regular intervals) during the user's navigation along a navigation route (determined by one or more processors), and one or more processors continuously adjust the adjusted playback speed of the media file (up to a playback speed threshold) so that the adjusted playback duration remains below the maximum media playback speed while staying within the updated predicted travel duration. In some embodiments, filtering of the predicted travel duration is used to avoid jumps in playback speed adjustment. Similarly, there may be one or more attributes of playback adjustment that prevent one or more processors from adjusting the playback speed beyond a certain rate of change (i.e., too rapid increases or decreases in playback speed).

[0135] In addition, the systems and methods described herein enable improved sharing of audiovisual content among stakeholders within a group by providing a single audiovisual medium for multiple users within the group to consume while traveling to a common destination, while ensuring that each user can fully consume the audiovisual medium during their respective navigation toward the common destination.

[0136] In such embodiments, one or more processors are configured to receive multiple route parameters and multiple playback parameters associated with users in a group. One or more processors determine the estimated travel duration for each user in the group to travel to a common destination. The estimated travel duration for each user is based on the received route parameters and multiple playback parameters associated with each individual user in the group. Once the estimated travel durations for all users in the group are determined, one or more processors determine the minimum estimated travel duration corresponding to the user with the shortest estimated travel duration. One or more processors then generate a subset of media with the associated minimum playback duration within a second playback range. The second playback range may correspond to the minimum estimated travel duration, as described above. This subset of media is transmitted to each user's electronic device in the group, so that each person in the group can fully listen to the same media before arriving at the common destination. In some embodiments, one user in the group selects media to share with all users in the group. In some embodiments, one or more processors may, based on the systems and methods described herein, access a calendar or schedule to determine a meeting and suggest media to play to all participants in the meeting.

[0137] In additional embodiments, the methods and systems discussed herein may include corporate-sponsored media content for recommendation and presentation to the user via one or more electronic devices configured for audio / media playback. In non-limiting examples, the user selects a destination location to travel to. The user may select the location on a standalone navigation application, a standalone media playback application, or an integrated navigation / media playback application. The user may select the destination location using gestures, voice commands, hardware input, etc. In addition to the destination location, the user may select a starting location (e.g., where to begin the journey), intermediate locations (e.g., locations to pass through from the starting location to the destination location), and a mode of travel. As described above, the system can receive these selections and determine a navigation route (and corresponding estimated travel duration) from the starting location to the destination location, passing through any intermediate locations. The navigation route may be associated with minimum travel duration, minimum travel distance, minimum carbon emissions, minimum elevation change, and / or may include several sponsored locations between the starting point and the destination location (for example, the system may modify the navigation route to pass through sponsored locations or locations with sponsored content / media).

[0138] Once a navigation route is determined, the system determines whether that navigation route is associated with sponsored media. In other words, the system determines whether the route passes through locations associated with sponsored media. Locations can include a starting location, a destination location, intermediate locations, and / or any locations (or their vicinity) along the route. In one example, a user might select a theater as the destination location. Entities associated with the selected theater (e.g., the theater owner, the owner of a show being performed at the theater, the director of a show being performed at the theater) can create and post content associated with the theater or the show being performed. The system can send a request for indications of a list of events occurring at the theater (with corresponding times and locations), receive a response from a server or electronic storage location, and identify sponsored media corresponding to events occurring around the estimated arrival or departure time. Alternatively, the system may automatically receive sponsored media when the navigation route is sent to a second server.

[0139] Sponsored media can be any media, but in exemplary embodiments, it may include historical or informational data related to the location. In an embodiment where the user navigates to a theater, the sponsored media may include information about a show currently playing at the theater. This data may include audio or audiovisual information about the show's director, author, cast, history, schedule, and / or sponsors. This allows the user to hear and / or see relevant background information before arriving at their destination. While a theater is used in the exemplary embodiments, it should be understood that sponsored media can be related to any location or event, including cinemas, sporting events, seminars, conferences, symposiums, restaurants, banquets, award ceremonies, businesses, etc.

[0140] In some embodiments, the system can access the user's calendar or schedule and determine the event to which the user is to navigate. The system can search for sponsored media associated with the event and present any identified sponsored media on the user's device for selection.

[0141] Upon receiving sponsored media, the system determines whether the minimum playback duration of the sponsored media falls within the playback range. The minimum playback duration may relate to the playback duration at the maximum playback speed, as determined by the user's playback parameters and / or preferences, as described in this document. In response to the sponsored media having a minimum playback duration within a playback threshold (a playback threshold corresponding to the estimated travel duration along a navigation route), the system presents the sponsored media for selection. The system may present the sponsored media (with or without indication of its sponsored status) as an interactive graphic element on a display on the user device configured for user selection. In addition, or alternatively, the system accesses one or more user attributes within the user profile associated with the user to determine whether to automatically select and play sponsored media. For example, a user may select a particular subscription service to avoid receiving sponsored content / media; in this case, the user would have subscription attributes associated with the selected subscription service. In embodiments where the user selects a subscription service (and has corresponding subscription attributes), the system receives indications of the subscription attributes but does not automatically select sponsored content for playback. In such embodiments, the system may still present sponsored media for the user to choose from. In other embodiments, if the user has a subscription attribute, sponsored media is not presented to the user. If the user profile does not have a subscription attribute, the system may automatically select sponsored media for playback.

[0142] Upon receiving a selection (either automatically by the system or from the user device), the system activates the sponsored media audio source on the user device or an external device (e.g., a speaker or automotive sound system) and outputs the sponsored media. In some embodiments, the system activates the audio source when it receives an indication that the user has begun moving along a navigation route. This indication may arise from a user selection of a “Navigation Start” graphic element on the user device, a vehicle beginning to travel along a navigation trajectory, or the user device determining that it is moving along a navigation route. The sponsored media is played at the adjusted playback speed as described herein, while ensuring that the playback speed does not exceed the maximum playback speed (e.g., the user’s preference associated with the fastest possible playback speed).

[0143] In various embodiments, sponsored media refers to content or media sponsored by a company. Further embodiments may include restaurants sponsoring sponsored media related to their menu and / or specials, the Emmy Awards sponsoring sponsored media related to nominations, companies sponsoring sponsored media related to their offerings, universities sponsoring sponsored media related to various programs at their institution, sports teams sponsoring sponsored media related to their performance during the season, and developers sponsoring sponsored media related to new developments in their neighborhood.

[0144] While destination locations may be associated with sponsored media, it will be understood that locations along the navigation route may also be associated with sponsored media. For example, when driving near a new development, the system may automatically play sponsored media about what will soon be available at that development (e.g., prices and square feet of new homes for sale). In some embodiments, the systems and methods described herein may also include directional information. For example, a processor determines the direction of travel based on route parameters, current and / or historical location data, or sensor data (e.g., image data from one or more cameras). In such embodiments, the system may automatically play sponsored media about what will soon be available at the new development, but including directional information (e.g., "Looking to the right, you will see the new development Shady Acres with new homes for sale starting at $300,000.").

[0145] Implementations of the subjects and operations described herein can be carried out using or in combination with one or more of the following: digital electronic circuits, or computer software, firmware, or structures disclosed herein and their structural equivalents embodied in tangible media. Implementations of the subjects described herein may be implemented as one or more modules of one or more computer programs, i.e., computer program instructions encoded in one or more computer storage media for execution by or control of a data processing device. Alternatively, or in addition, program instructions may be encoded in artificially generated propagating signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device for execution by a data processing device. Computer-readable storage media may be or include computer-readable storage devices, computer-readable storage boards, random-access or serial-access memory arrays or devices, or one or more of the following. Furthermore, although computer storage media are not propagating signals themselves, they can be the source or destination of computer program instructions encoded as artificially generated propagating signals. Computer storage media can be one or more separate components or media (e.g., multiple CDs, disks, or other storage devices), or they can be contained within them. Therefore, computer storage media are tangible and non-temporary.

[0146] The operations described herein can be implemented as operations performed by a data processing device on data stored in one or more computer-readable storage devices or on data received from other sources.

[0147] The terms “data processing device” or “computing device” encompass all types of devices, machines, and equipment for processing data, including, in practice, programmable processors, computers, systems on a chip, or combinations thereof. A device may include special-purpose logic circuits, such as field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs). In addition to hardware, a device may also include code that creates the execution environment for a target computer program, such as processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or code comprising one or more of these. This device and execution environment can realize the infrastructure of various different computing models, such as web services, distributed computing, and grid computing infrastructure.

[0148] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. A computer program may, though not required, correspond to a file in a file system. A program may be stored in part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in a group of coordinated files (e.g., a file that stores one or more modules, subprograms, or parts of code). A computer program may be deployed to run on one computer, or on multiple computers located in one site, or distributed across multiple sites and interconnected by a communication network.

[0149] The processes and logic flows described herein may be executed by one or more programmable processors that execute one or more computer programs to perform actions by acting on input data and producing outputs. The processes and logic flows may also be executed by special-purpose logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and devices may be implemented as such.

[0150] Processors suitable for executing computer programs include, as an example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor receives instructions and data from read-only memory (ROM) or random-access memory (RAM), or both. Essential elements of a computer are a processor for performing actions according to instructions, and one or more memory devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or is operably coupled to such mass storage devices for receiving data from them, transmitting data to them, or both. However, a computer does not need to have such a device. Moreover, a computer can be incorporated into other devices, such as a mobile phone, a personal digital assistant (PDA), a portable audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a Universal Serial Bus (USB) flash drive). Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, examples of which include semiconductor memory devices such as EPROM, EEPROM, and flash memory devices, magnetic disks such as internal hard disks or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory can be complemented by or incorporated into special-purpose logic circuits.

[0151] To provide user interaction, the implementations of the subject matter described herein may be performed using a computer having a display device for displaying information to the user, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices may also be used to provide user interaction; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic input, speech input, or tactile input. In addition, the computer may interact with the user by sending and receiving documents to and from devices used by the user, for example, by sending a web page to a web browser on the user's client device in response to a request received from a web browser.

[0152] Implementations of the subject matter described herein may be performed using a computing system that includes back-end components, such as data servers, or middleware components, such as application servers, or front-end components, such as a client computer having a graphical user interface or web browser through which a user can interact with the implementation of the subject matter described herein, or any combination of one or more such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, such as a communication network. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad-hoc peer-to-peer networks, distributed ledger networks).

[0153] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact through a communication network. The relationship between a client and a server arises from computer programs running on each computer that have a client-server relationship with each other. In some implementations, the server sends data (e.g., an HTML page) to the client device (for example, to display data to a user interacting with the client device and to receive user input from that user). Data generated on the client device (e.g., the results of user interaction) may be received by the server from the client device.

[0154] In some exemplary implementations, the features disclosed herein can be implemented in a smart television module (or connected television module, hybrid television module, etc.), which may include an internet connection and processing circuitry configured to integrate more traditional television programming sources (e.g., those received via cable, satellite, terrestrial, or other signals). The smart television module may be physically integrated into a television set or may include separate devices such as a set-top box, Blu-ray® or other digital media player, game console, hotel television system, and other related devices. The smart television module may be configured to enable viewers to explore and find videos, movies, photographs, and other content stored on the web, on local cable television channels, on satellite television channels, or on a local hard drive. A set-top box (STB) or set-top unit (STU) may include an information appliance device that includes a tuner and connects to a television set and an external signal source to convert signals into content, which is then displayed on a television screen or other display device. A smart television module may be configured to provide a home screen or top-level screen, which may include icons for several different applications, such as a web browser and several streaming media services (e.g., Netflix, Vudu, Hulu, Disney+, etc.), connected cable or satellite media sources, and other web "channels." A smart television module may be further configured to provide the user with an electronic program guide. An accompanying application for the smart television module may run on a mobile computing device and provide the user with additional information about available programming, enabling the user to control the smart television module.In alternative implementations, the features may be implemented in laptop computers or other personal computers, smartphones, other mobile phones, handheld computers, smartwatches, tablet PCs, or other computing devices.

[0155] This specification includes details of many specific implementations, but these should not be interpreted as limitations on the scope of the invention or the scope of claims, but rather as descriptions of features specific to a particular implementation of a particular invention. In the context of separate implementations, some features described herein can also be performed in combination or in a single implementation. Conversely, various features described in the context of a single implementation can also be performed separately or in any preferred partial combination in multiple implementations. Furthermore, features may be described above as working in combination, but even if initially claimed as such, one or more features from a claimed combination may be removed from the combination in some cases, and the claimed combination may cover any partial combination or a variation of a partial combination. In addition, features described under a particular heading can be used in relation to and / or in combination with exemplary implementations described under other headings. Headings, where provided, are included solely for readability and should not be interpreted as limiting any features provided under such headings.

[0156] Similarly, while the diagrams show operations in a specific order, this should not be interpreted as requiring such operations to be performed in a specific or sequential order to achieve the desired result, or requiring all illustrated operations to be performed. Under certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the fact that various system components are separate in the aforementioned implementations should not be interpreted as requiring them to be so separate in all implementations. It should be understood that the described program components and systems can generally be integrated into a single software product or packaged into multiple software products embodied in tangible media.

[0157] Thus, specific implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions described in the claims may be performed in a different order, but the desired results can still be achieved. In addition, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous.

Claims

1. A computer implementation method for protecting data by linking devices, wherein the computer implementation method is One or more processors receive a merge request associated with the merge location from the inviting device, The one or more processors establish one or more data channels with the inviting device, The one or more processors provide the merge request to each of the multiple invited devices, wherein the merge request includes the merge location. In response to receiving a first acceptance of the merge request from the first invited device among the plurality of invited devices, one or more processors establish one or more data channels with the first invited device, The one or more processors generate and provide to the first invited device, via the first graphical user interface (GUI) of the application, a first proposed route to the meeting place and a first location of one of the plurality of invited devices or at least one of the inviting devices, wherein the first proposed route is generated and provided based on the first geographic location of the first invited device. In response to receiving a second acceptance of the merge request from the second invited device among the plurality of invited devices, one or more processors establish one or more data channels with the second invited device, The one or more processors generate and present a second proposed route to the meeting point via a second GUI of the application, the second proposed route being generated and presented based on the second geographic location of the second invited device. The one or more processors collect environmental data of the inviting device and the multiple invited devices via the one or more data channels, The one or more processors provide the inviting device with the locations of the first invited device and the second invited device based on the environment data, via the third GUI of the application, wherein the locations of the first invited device and the second invited device are presented on the third GUI of the application. In response to the determination that at least one of the first invited device or the second invited device has completed the merge request at the merge location, one or more processors disconnect one or more data channels connecting the one or more processors to at least one of the first invited device or the second invited device. Computer implementation methods, including those mentioned above.

2. The merge request is associated with a predetermined merge with a predetermined invited device, and the computer implementation method is The one or more processors determine the predetermined merge based on social media data. The further includes the fact that the predetermined merger is determined based on identifying trends within the social media data, The computer implementation method according to claim 1, wherein the first proposed route is presented on the first invited device, and the presentation includes estimated arrival times (ETA) for the inviting device, the first invited device, and the second invited device, respectively.

3. The one or more processors determine the stopping points along the first proposed route or the second proposed route, The one or more processors provide an intermediate location to at least one of the first invited device or the second invited device. The computer implementation method according to claim 1, further comprising:

4. The one or more processors receive a list of items associated with the merge request, The one or more processors determine one or more stopping points within the region of the merge request, including one or more of the list of items in stock. In response to receiving the first acceptance, the one or more processors provide the one or more stop points as selectable elements via the first GUI of the application, wherein determining the stop points and providing the intermediate locations is in response to receiving a selection of one of the selectable elements, and providing the one or more stop points, The one or more processors update the list of items to indicate that at least one item in the list of items belongs to the first inviting device. The computer implementation method according to claim 3, further comprising:

5. Updating the one or more stop points based on either the first proposed route or the second proposed route, wherein each of the provided stop points further includes an incentive presented together with one of the selectable elements. The computer implementation method according to claim 4, further comprising:

6. In response to determining that at least one of the first invited device or the second invited device has arrived at the meeting place, one or more processors share the geographic location of the inviting device with at least one of the first invited device or the second invited device. The computer implementation method according to claim 1, further comprising:

7. The merge request is a public merge request configured to share the merge request with a merge marketplace, and the computer implementation method is One or more processors generate the merge request via the application and provide it to multiple publicly invited devices. The computer implementation method according to claim 1, further comprising the following: the merge request includes the merge location, and the plurality of publicly invited devices are determined based on the membership dataset.

8. The computer implementation method according to claim 1, wherein the first acceptance includes a privacy parameter for sharing data from the first invited device, and the privacy parameter includes a plurality of data sharing levels associated with the type and amount of data to be shared.

9. The computer implementation method according to claim 8, wherein the first level of the plurality of data sharing levels configures the one or more processors to share the data of the first invited device with at most the inviting device, the second level of the plurality of data sharing levels configures the one or more processors to share the data of the first invited device with at most the inviting device and one of the plurality of invited devices, and the third level of the plurality of data sharing levels configures the one or more processors to share the data of the first invited device with the inviting device and one of the plurality of invited devices.

10. The computer implementation method according to claim 8, wherein the first of the plurality of data sharing levels configures the one or more processors to share at most the unprotected data of the first invited device with the inviting device, the second of the plurality of data sharing levels configures the one or more processors to share the unprotected data of the first invited device with the inviting device and one of the plurality of invited devices, and the third of the plurality of data sharing levels configures the one or more processors to share the unprotected and protected data of the first invited device with the inviting device and one of the plurality of invited devices.

11. The computer implementation method according to claim 8, wherein the first invited device is associated with the application profile, and the first proposed route is based on the default location of the profile.

12. The first GUI and the second GUI include a look and feel (LF) theme based on the merge request, user attributes, or merge location. The merge request provided to the multiple invited devices includes a customized invitation containing content corresponding to the merge request or merge location. If one of the multiple invited devices or the inviting device is sharing a location, the first location of the one of the multiple invited devices or the inviting device becomes the first visual indicator. The computer implementation method according to claim 1, wherein if one of the plurality of invited devices or the inviting device is not sharing a location, the first location of one of the plurality of invited devices or the inviting device becomes a second visual indicator.

13. In response to receiving the first acceptance, the computer implementation method The computer implementation method according to claim 1, further comprising activating one or more security features on the first invited device, the one or more security features comprising enabling a third-party device to track the first invited device and establishing another data channel between the third-party device and the first invited device for communication or exchange of messages.

14. The received merging location is a common location, and the computer implementation method is The computer implementation method according to claim 1, further comprising, in response to receiving the first acceptance of the merge request, one or more processing circuits determining the central location of the merge location based on the first geographic location of the first invited device and the geographic location of the inviting device, wherein the first proposed route to the merge location is to the central location.

15. At a minimum, generating and providing the first proposed route to the merging location via the first GUI of the application is: A first optional element including a request for ride-sharing or carpooling for the aforementioned merging, A second optional element, including a proposal for transportation by the inviting device or the multiple invited devices, or A third optional element including media recommendations that the first invited device can output as audio during the first proposed route to the meeting point. A computer implementation method according to claim 1, comprising one of the following.

16. A data protection system for protecting data by linking devices, wherein the data protection system is A data processing system, Memory and The inviting device receives a merge request associated with the merge location, Establishing one or more data channels with the inviting device Providing the merge request to each of the multiple invited devices, wherein the merge request includes the merge location, In response to receiving a first acceptance of the merge request from the first invited device among the plurality of invited devices, one or more data channels are established with the first invited device. The application generates and provides to the first invited device a first proposed route to the meeting place and a first location of one of the plurality of invited devices or at least one of the inviting devices, wherein the first proposed route is generated and provided based on the first geographic location of the first invited device. In response to receiving a second acceptance of the merge request from a second invited device among the plurality of invited devices, one or more data channels are established with the second invited device. The application generates and presents a second proposed route to the meeting point via a second GUI, wherein the second proposed route is generated and presented based on the second geographic location of the second invited device. Collecting environmental data of the inviting device and the multiple invited devices via the aforementioned one or more data channels, Providing the location of the first invited device and the second invited device to the inviting device via the third GUI of the application, based on the environmental data, wherein the location of the first invited device and the second invited device is presented on the third GUI of the application. In response to determining that at least one of the first invited device or the second invited device has completed the merge request at the merge location, disconnect the one or more data channels connecting the data processing system and at least one of the first invited device or the second invited device. One or more processors configured to perform the following: Data processing systems including A data protection system equipped with these features.

17. The merge request is associated with a predetermined merge with a predetermined invited device, and the one or more processors, To determine the predetermined merger based on social media data Furthermore, the predetermined merger is determined based on identifying trends within the social media data, The data protection system according to claim 16, wherein the first proposed route is presented on the first invited device, and the presentation includes estimated time of arrival (ETA) for the inviting device, the first invited device, and the second invited device, respectively.

18. The aforementioned one or more processors Determining a stopping point along the first proposed route or the second proposed route, Providing an intermediate location for at least one of the first invited device or the second invited device The data protection system according to claim 16, further configured to perform the following:

19. The aforementioned one or more processors Receiving a list of items associated with the merge request, Within the area of ​​the merge request, determine one or more stopping points that include one or more of the items in stock from the list of items, Providing the one or more stop points as selectable elements via the first GUI of the application in response to receiving the first acceptance, wherein determining the stop points and providing the intermediate locations is in response to receiving the selection of one of the selectable elements, The list of items is updated to indicate that at least one item in the list of items belongs to the first inviting device, Updating one or more of the stop points based on either the first proposed route or the second proposed route, wherein each of the provided stop points further includes an incentive presented together with one of the selectable elements. The data protection system according to claim 18, further configured to perform the following:

20. A computer implementation method for protecting data by linking devices, wherein the computer implementation method is One or more processors receive a merge request including the merge location, The one or more processors provide the protection system with the acceptance of the merge request. In response to the aforementioned acceptance, one or more processors establish a data channel with the protection system, The one or more processors receive and present, via the graphical user interface (GUI) of the application, a proposed route to the meeting place and the location of one of the invited devices or at least one of the inviting devices, wherein the proposed route is received and presented based on a first geographic location of the one or more processors. The aforementioned one or more processors collect and provide environmental data via the data channel, The one or more processors receive and present the location of at least one of the multiple invited devices or the inviting device via the GUI of the application. In response to one or more processors determining that they have completed the merge request at the merge location, one or more processors disconnect the data channel connecting one or more processors and the protection system. Computer implementation methods, including those mentioned above.

Images