Playback control of media content across devices in a maas transportation network

Abstract

A system and method for playback control of media content across devices in a MaaS transportation network is provided. The system receives, from the MaaS network, trip details of an ongoing trip and determines a first vehicle through which a user is set to complete a first segment of an activity of the ongoing trip. The system generates a media content recommendation based on the trip details and controls a first display device used within the first vehicle to display such recommendation. The system receives a selection of the first content recommendation and controls playback of a first media content associated with the selection on the first display device. The system detects an event requiring a pause in playback and controls the playback to resume on a second display device used within a second vehicle for a second segment of the ongoing trip or a duration of a different trip.

Description

[0001] Cross-references to related applications / incorporation via reference

[0002] This application is an international patent application claiming priority to U.S. Patent Application No. 17 / 092597, filed November 9, 2020, with the U.S. Patent and Trademark Office. Each of the above-cited applications is incorporated herein by reference in its entirety. Technical Field

[0003] Various embodiments of this disclosure relate to Mobile-as-a-Service (MaaS) technology. More specifically, various embodiments of this disclosure relate to systems and methods for playback control of media content for devices across a MaaS transportation network. Background Technology

[0004] In the mobile space, there are different transportation service providers offering rides via one or more public or private modes of transportation. Each of these providers can offer its services through infrastructure that may be based on a closed platform. For example, each such mobile provider may have separate ticketing infrastructure (e.g., ticket gates and point-of-sale (PoS) devices) or separate applications (e.g., ticket booking apps, ticket processing apps, and ridehailing apps) to create, pay for, or manage trips. In some scenarios, users may plan trips involving services from different transportation providers. For example, a trip might include a taxi service covering the first segment of the trip and a subway service covering the remainder. Traditionally, these two transportation providers may keep their information technology (IT) infrastructure and IT operations closed and independent of each other. As a result, no shared services are available for the user to benefit and enjoy throughout the trip.

[0005] By comparing the described system with some aspects of this disclosure, as illustrated in the remainder of this application and with reference to the accompanying drawings, the limitations and disadvantages of conventional and traditional methods will become apparent to those skilled in the art. Summary of the Invention

[0006] A system and method are provided for playback control of media content of devices across a Mobility as a Service (MaaS) transportation network, described substantially as shown in and / or in conjunction with at least one figure, and set forth more fully in the claims.

[0007] By together with Figure 1 These and other features and advantages of this disclosure will be understood by reviewing the following detailed description of the disclosure, in which the same reference numerals always denote the same parts in the accompanying drawings. Attached Figure Description

[0008] Figure 1 This is a block diagram illustrating an exemplary network environment for implementing playback control of media content of devices across a Mobility as a Service (MaaS) transportation network according to embodiments of the present disclosure.

[0009] Figure 2 This is a block diagram of an exemplary system for playback control of media content of devices across a MaaS transportation network, according to embodiments of this disclosure.

[0010] Figure 3 This is a block diagram illustrating exemplary operation of playback control of media content for devices across a MaaS transportation network according to embodiments of the present disclosure.

[0011] Figure 4 This is a block diagram illustrating an exemplary network environment for sending media content blocks to a display device for playback of media content according to embodiments of the present disclosure.

[0012] Figure 5 This is a sequence diagram illustrating exemplary operations for sending blocks of a transport stream of media content to a display device for playback of the media content, according to embodiments of the present disclosure.

[0013] Figure 6 This is a diagram illustrating an exemplary scenario for playback control of media content for devices across a MaaS transportation network according to embodiments of this disclosure.

[0014] Figure 7 This is a sequence diagram illustrating exemplary operations of a MaaS transportation network for payment settlement associated with media use according to embodiments of the present disclosure.

[0015] Figure 8 This is a flowchart illustrating an exemplary method for controlling the playback of media content for devices across a MaaS transportation network according to an embodiment of this disclosure. Detailed Implementation

[0016] The implementations described below can be found in the disclosed systems and methods for controlling playback of media content across multiple devices. Such devices can be associated with transportation service providers registered on a Mobility-as-a-Service (MaaS) transportation network. The disclosed system can be part of a joint transportation management system that facilitates the operation of multiple similar or dissimilar mobile providers and their infrastructure (e.g., ticket gates, applications, and / or point-of-sale (PoS) devices) on the MaaS network to provide various mobile services. Each mobile provider can have secure data ownership and can control the shared use of relevant transaction data through a distributed ledger. This can enhance connectivity between various mobile providers.

[0017] An exemplary aspect of this disclosure provides a system that can control the playback of first media content (such as audio or video content) across devices used within a vehicle associated with a user's ongoing trip. The system can receive trip details associated with the user's ongoing trip from a MaaS network. For example, the ongoing trip can be divided into segments that can be covered by multiple vehicles (e.g., a first vehicle and a second vehicle) from at least one transportation service provider associated with the MaaS network. The system can identify the first vehicle as the vehicle for which the user can be set to complete the first segment of the ongoing trip. The system can generate a group of recommended media content based on the received trip details and the user's associated media consumption history. Therefore, the system can provide the user with customized media content, thereby enhancing the user experience. The system can then receive a user selection of the first media content recommendation via a first display device that can be used within the identified first vehicle. Based on the user selection, the system can control the playback of the media content associated with the first media content recommendation on the first display device. During the duration of the ongoing trip, the system can detect events that may require pausing the playback of the media content. Examples of events may include, but are not limited to, the end of the first segment of an ongoing trip, and user input that pauses the playback of media content. The system can control the playback of the first media content to resume on a second display device used inside the second vehicle and during the duration of a second segment of the ongoing trip or during the duration of a different segment of the user's trip. For example, the system can record a timestamp at which playback of the first media content can be paused based on a detected event. The system can control the playback of the first media content to resume from the recorded timestamp on a second display device used inside the second vehicle and during the duration of a second segment of the ongoing trip or during the duration of a different segment of the user's trip.

[0018] Because the system enables seamless streaming and playback of media content across different display devices (monitors in vehicles or personal mobile devices) during the duration of one or more trips, users can watch, pause, and then resume playback of media content at any point during the trip. This seamless streaming and playback of media content is achieved even when the trip is covered by various vehicles managed by different transportation service providers. The system disclosed herein ensures the effective monetization of media content through the real-time allocation, distribution, and / or settlement of payments using smart contracts. Therefore, the system disclosed herein can ensure seamless and cost-effective consumption of media content on display devices used during one or more trips in a MaaS transportation space.

[0019] Figure 1This is a block diagram illustrating an exemplary network environment for implementing playback control of media content across a Mobility-as-a-Service (MaaS) transportation network according to embodiments of this disclosure. Reference Figure 1 The diagram illustrates a network environment 100. Network environment 100 may include system 102, MaaS network 104, and multiple Mobile Provider (MP) servers 106. The multiple MP servers 106 may include a first MP server 106A, a second MP server 106B, ..., and an Nth MP server 106N. Network environment 100 may also include a communication network 108. Further, a plurality of display devices are shown, which may include a first display device 110A, a second display device 110B, ..., and an Nth display device 110N. As shown, for example, the first display device 110A, the second display device 110B, ..., and the Nth display device 110N may be accessed within a first vehicle 112A, a second vehicle 112B, ..., and an Nth vehicle 112N, respectively. The first vehicle 112A, the second vehicle 112B, ..., and the Nth vehicle 112N may be collectively referred to as multiple vehicles 112A, 112B...112N. In at least one embodiment, one or more of the plurality of vehicles 112A, 112B...112N may not have any display device within the vehicle. A user 114 that may be associated with display device 116 is also shown.

[0020] MaaS network 104 can be associated with a publish-subscribe model. MaaS network 104 may include multiple publisher nodes 118A, 118B, ... 118N, agent node device 120, and multiple subscriber nodes 122A, 122B, ... 122N. MaaS network 104 may also include multiple mobile provider (MP) nodes 124A, 124B, ... 124N of a first distributed ledger 124 and multiple MaaS nodes 126A, 126B, ... 126N of a second distributed ledger 126. Furthermore, MaaS network 104 may include distributed ledger child nodes 128, which may include driver child nodes 128A, user child nodes 128B, and document child nodes 128C. Additionally, a system 102 is shown that can be communicatively coupled to MaaS network 104 or to a second distributed ledger 126 of MaaS network 104.

[0021] exist Figure 1In this document, the number of nodes in the MaaS network 104, the number of MP servers in the multiple MP servers 106, the number of display devices 110A, 110B…110N, and the number of vehicles 112A, 112B…112N are given as examples only and should not be construed as limiting this disclosure. This disclosure can also be applied to more or fewer numbers of nodes, MP servers, display devices, and vehicles for playback control of media content across devices in a MaaS transportation network, without departing from the scope of this disclosure. For the sake of brevity, in Figure 1 The document only shows N nodes of the MaaS network 104, N servers of the multiple MP servers 106, N display devices 110A, 110B...110N, and N vehicles 112A, 112B...112N. However, in some embodiments, there may be more or fewer than N nodes of the MaaS network 104, the number of servers of the multiple MP servers 106, the number of display devices 110A, 110B...110N, and the number of vehicles 112A, 112B...112N, without limiting the scope of this disclosure. Furthermore, a vehicle (e.g., a first vehicle 112A) may be associated with a mobile provider server (e.g., a first MP server 106A). A mobile provider server may be associated with multiple vehicles without limiting the scope of this disclosure.

[0022] System 102 may include appropriate logic, circuitry, code, and / or interfaces that can be configured to control the delivery of media content to various display devices accessible within multiple vehicles 112A, 112B…112N in different segments of a trip. For example, if user 114 begins playback of a program in the first segment of an ongoing trip, user 114 can pause and resume playback on any subsequent segment of the same ongoing trip or a different trip. Trips can be booked via MaaS transportation services, and trip fulfillment can be tracked and managed via the MaaS network 104.

[0023] In an embodiment, system 102 may include a trained artificial intelligence (AI) model (e.g., such as...). Figure 2 The AI ​​system (shown) can be configured to recommend a set of media content for playback on various display devices and / or display devices 116 across multiple vehicles 112A, 112B…112N, based on user 114’s travel details, user 114’s media consumption history, user 114’s user profile, and / or the device specifications of various display devices.

[0024] Example implementations of system 102 may include, but are not limited to, virtual machines (VMs) on a host, containers or virtual runtime environments of an operating system (OS) on a host or server, containerized applications on a server, BareMetal servers, cloud servers (such as private, public, or hybrid clouds), workstations, media servers, or any device capable of generating media content and streaming media content to a cluster of devices. In one embodiment, system 102 may be implemented as a server or a VM or container on a server node among a plurality of MP servers 106.

[0025] MaaS network 104 can support standard specifications for communication. MaaS network 104 may include publisher nodes (e.g., ticket readers or ride booking applications), subscriber nodes, and at least one agent node device to transmit transaction messages from publisher nodes to subscriber nodes according to a publish-reservation network protocol, which is, for example, but not limited to, a message delivery protocol based on Message Queuing Telemetry Delivery (MQTT), a message delivery protocol based on Advanced Message Queuing Protocol (AMQP), or a message delivery framework based on Message-Oriented Middleware (MOM). In at least one embodiment, MaaS network 104 may include a distributed ledger, which may include ledger nodes to record transactions associated with various mobility services, such as ticket transactions for MaaS transportation services, media usage or consumption statistics, or payment settlements between various stakeholders such as content owners, transportation providers, or operators of MaaS network 104.

[0026] The publisher nodes of all transportation service providers associated with MaaS network 104 can follow standard or public communication protocols for data exchange. MaaS network 104 can include similar publisher nodes that can follow MaaS standard communication specifications. In an embodiment, MaaS network 104 can also include heterogeneous publisher nodes that can follow proprietary communication protocols. MaaS network 104 can provide plug-in-based support to publisher nodes, enabling support for such heterogeneous publisher nodes until the individual transportation service providers comply with and support the MaaS standard specifications for communication.

[0027] MaaS Network 104 enables publisher nodes associated with different transportation providers to join MaaS Network 104. Through node management devices, MaaS Network 104 provides batch cluster management of publisher nodes. All publisher nodes can operate on MaaS Network 104 by following a setup protocol. The setup protocol enforces a common security architecture (for publisher node authentication and authorization), network protocols (e.g., HTTP, MQTT, AMQP, etc.), a uniform data request or response format (e.g., JSON, CSV, or XML), and an API / data scheme. This ensures that each publisher node adheres to cluster-level configuration (e.g., device profiles including company name, company ID, door ID, door number, etc.) and device-level certificates (i.e., authentication credentials). The cluster-level configuration pattern and setup protocol facilitate transportation providers deploying new publisher nodes or replacing existing publisher nodes with plug-and-play methods. This facilitates MaaS Network 104 as a homogeneous transportation network with interoperability between resources (e.g., publisher node devices) from various transportation providers.

[0028] Each of the multiple publisher nodes 118A, 118B...118N may include suitable logic, circuitry, code, and / or interfaces that can be configured to operate as a ticket processing client for the transportation services of various transportation service providers. For example, as a ticket processing client, each of the multiple publisher nodes 118A, 118B...118N can read, issue, recharge, or cancel tickets to create events associated with the corresponding transportation service. Based on such events, transaction messages can be transmitted via proxy node device 120 to one or more subscriber nodes (e.g., multiple subscriber nodes 122A, 122B...122N) of the MaaS network 104. Examples of the multiple publisher nodes 118A, 118B...118N may include, but are not limited to, consumer electronics devices with trip planning or booking applications, ticket readers on ticket gates, ticket kiosks, point-of-sale (PoS) devices, mobile POS, ticket machines, and smart gates that can read tickets to start or end a ride on a transportation vehicle.

[0029] Each of the multiple subscriber nodes 122A, 122B…122N may include suitable logic, circuitry, code, and / or interfaces, which may be configured to receive transaction messages from one or more of the multiple publisher nodes 118A, 118B…118N via proxy node device 120. Each transaction message may include a topic that can be subscribed to by one or more of the multiple subscriber nodes 122A, 122B…122N. Example implementations of subscriber nodes may include, but are not limited to, web servers, edge devices, edge nodes, cloud servers, cluster nodes of cloud-based servers, workstations, or any computing device with fog computing capabilities.

[0030] The first publisher node 118A among multiple publisher nodes 118A, 118B...118N and the first subscriber node 122A among multiple subscriber nodes 122A, 122B...122N may be associated with a first transportation provider. Other nodes, such as the second publisher node 118B and the second subscriber node 122B, may be associated with the first transportation provider or a second transportation provider that may be different from the first transportation provider. Furthermore, the first publisher node 118A may be associated with a first MP server 106A, the second publisher node 118B may be associated with a second MP server 106B, and so on.

[0031] The proxy node device 120 may include appropriate logic, circuitry, code, and / or interfaces that can be configured to route transaction messages from publisher nodes (e.g., the first publisher node 118A) to subscriber nodes (e.g., the first subscriber node 122A). The decision to authorize the proxy node device 120 to route such transaction messages to subscriber nodes may be made by a server associated with the MaaS network 104. Figure 1 (Not shown in the image) to determine. Example implementations of the agent node device 120 may include, but are not limited to, application servers, cloud servers, host servers, database servers, web servers, or other types of servers.

[0032] The agent node device 120 can be configured to communicate with each of the multiple publisher nodes 118A, 118B...118N and the multiple subscriber nodes 122A, 122B...122N via an appropriate publish-subscribe network protocol (e.g., but not limited to MQTT-based messaging protocol, AMQP-based messaging protocol, or message-oriented middleware (MOM)-based messaging framework).

[0033] Multiple MP nodes 124A, 124B…124N may include appropriate logic, circuitry, code, and / or interfaces that can be configured to store transaction data associated with corresponding mobile providers. For example, a first MP node 124A may store transaction data associated with a first mobile provider. The transaction data may include records of user trips. Each trip may correspond to a MaaS transportation service, which may be provided by a first transportation provider (e.g., associated with a first MP server 106A) for at least a segment of the trip. Each of the multiple MP nodes may be referred to as a node of a first distributed ledger 124, which may store transaction data for various mobile providers in the MaaS network 104.

[0034] Multiple MaaS nodes 126A, 126B…126N may include appropriate logic, circuitry, code, and / or interfaces, which can be configured to store transaction data associated with all mobile providers of the MaaS network 104. The storage of transaction data associated with each transportation service provider can be used for settlement payments for transportation services provided to users between transportation service providers. Each of the multiple MaaS nodes 126A, 126B…126N may correspond to a node of the second distributed ledger 126, which can store transaction data associated with the MaaS network 104.

[0035] Each of the multiple MP nodes 124A-124N and each of the multiple MaaS nodes 126A, 126B...126N can be associated with the distributed ledger child node 128. For example, each of the first MP node 124A and the first MaaS node 126A can be associated with the driver child node 128A, user child node 128B, and document child node 128C of the distributed ledger child node 128. Similarly, each of the second MP node 124B and the second MaaS node 126B can be associated with the driver child node 128A, user child node 128B, and document child node 128C of the distributed ledger child node 128. The driver sub-node 128A of the distributed ledger sub-node 128 can store driver profile information associated with the mobile provider of the MaaS network 104. In one embodiment, the driver sub-node 128A can store an event timeline (or event tracking information) associated with the driver. Exemplary information that may be included in the event timeline associated with the driver may include, but is not limited to, a driver-associated points card, a driver-associated profile, driver-associated behavioral information, and event context, such as traffic information, driver actions, and driver speech. The user sub-node 128B of the distributed ledger sub-node 128 can store user (or passenger) information associated with the mobile provider of the MaaS network 104. In one embodiment, the user sub-node 128B can store an event timeline (or event tracking information) associated with the user. Exemplary information that may be included in the event timeline associated with the user may include, but is not limited to, user-specific settings and preferences (such as privacy settings). User-specific settings and preferences can help mobile providers and MaaS providers ensure that the storage of user data in distributed ledger nodes / sub-nodes complies with data privacy standards, legal obligations, and rules (such as the General Data Protection Regulation (GDPR)). The document sub-node 128C of distributed ledger sub-node 128 can store log information associated with vehicles 112A, 112B…112N of the mobile provider in MaaS network 104. Furthermore, document sub-node 128C can store notification information and messages generated based on one or more events determined to be associated with MaaS network 104. In this embodiment, document sub-node 128C can store track IDs (e.g., media content IDs) associated with media content that can be played back or recommended to users.Document sub-node 128C can also store the playback or resume ID associated with the last playback timestamp of the media content or the last pause timestamp of the media content playback, as well as the user ID associated with the media content.

[0036] Multiple subscriber nodes 122A, 122B...122N can be associated with corresponding nodes of the first distributed ledger 124. For example, the first subscriber node 122A can be associated with the first MP node 124A of the first distributed ledger 124, the second subscriber node 122B can be associated with the second MP node 124B of the first distributed ledger 124, and so on.

[0037] In this embodiment, at least two ledger nodes of each of the first distributed ledger 124 and the second distributed ledger 126 may store transaction data associated with the MaaS transportation service. The MaaS transportation service may be associated with one or more of the following: multiple transportation providers and / or users 114 (e.g., passengers) who can utilize the MaaS transportation service through a unified MaaS interface or through multiple publisher nodes 118A, 118B…118N. The transaction data associated with the MaaS transportation service may be contained in a set of state objects, such as an initial state object and updated versions of the initial state object. Each state object may include a smart contract, contract code (or transaction rules agreed upon by the parties to the transaction), and state attributes (which may be updated when transaction data is updated based on transaction requests from multiple publisher nodes 118A, 118B…118N).

[0038] In at least one embodiment, each of the first distributed ledger 124 and the second distributed ledger 126 may be a decentralized and distributed database system capable of maintaining immutable records of data operations or transactions. A set of data operations may be grouped together as blocks and may be further linked to previous data operation blocks to form a chain of multiple blocks. All data operation blocks may be stored in a decentralized manner, wherein at least two participants or nodes of each of the first distributed ledger 124 and the second distributed ledger 126 may store a subset of multiple blocks associated with one or more transactions in which at least two participants or nodes may participate. Furthermore, each of the first distributed ledger 124 and the second distributed ledger 126 may include an operating system (e.g., a Java Virtual Machine (JVM)) that may allow the deployment of smart contracts between multiple parties (e.g., multiple mobile provider nodes of a first transportation provider) and counterparty nodes (i.e., MaaS provider nodes).

[0039] As an example and not a limitation, each of the first distributed ledger 124 and the second distributed ledger 126 can be a distributed ledger technology (DLT) system, such as a blockchain-based system (e.g., the Corda blockchain, the Ethereum blockchain, or the Hyperledger blockchain). Each of the first distributed ledger 124 and the second distributed ledger 126 can store a set of immutable state objects that can be tracked by the first distributed ledger 124 and the second distributed ledger 126, respectively. State objects can include a set of distributed ledger-compatible rules for different types of distributed ledger technologies. For example, state objects can include transaction data, such as smart contracts between parties, contract codes (transaction rules), and content including state attributes with certain state values. Smart contracts can include a set of conditions under which the parties to the smart contract can agree to interact with each other. Smart contracts can run on one or more nodes of each of the first distributed ledger 124 and the second distributed ledger 126 and can govern the transitions between state objects to generate transactions. Smart contracts can be written once, reused on a large number of state objects, and can refer to governing legal prose using cryptographic hashes.

[0040] Each of the first distributed ledger 124 and the second distributed ledger 126 can use a secure cryptographic hash to identify the parties and data, and also links state objects to previous versions of state objects to provide a chain of origin. Transactions between groups of parties can be stored on the first distributed ledger 124 and the second distributed ledger 126, allowing only groups of parties associated with a transaction to view the transaction. A party associated with a transaction can store the current state object of the transaction in a repository (a database associated with a corresponding distributed ledger such as the first distributed ledger 124 and the second distributed ledger 126). Another party eligible to view or process the transaction (e.g., verify the transaction) can retrieve the current state object of the transaction from the repository. Additionally, each state object in each of the first distributed ledger 124 and the second distributed ledger 126 can include a smart contract between parties or nodes that can participate in the associated transaction.

[0041] On each of the first distributed ledger 124 and the second distributed ledger 126, a participant or node (e.g., the first MP node 124A) can update a transaction by updating the state attributes of an input state object (e.g., a first state object) to produce an output state object (e.g., a second state object). The updated transaction can thereby create a source chain (which can be associated with the transaction data). Each of the first distributed ledger 124 and the second distributed ledger 126 can provide consensus on the updated transaction based on the determination of its validity and uniqueness. In an embodiment, participants of the node associated with the updated transaction can determine its validity by independently executing the smart contract and verification logic associated with the transaction. Furthermore, the consensus node associated with each of the first distributed ledger 124 and the second distributed ledger 126 can determine the uniqueness of the updated transaction based on a check that no other transactions have reached consensus using the same input state object as the current transaction.

[0042] According to an embodiment, each of the first distributed ledger 124 and the second distributed ledger 126 can be associated with a decentralized application that may include a client-side interface (front-end) and a server-side interface (back-end). The decentralized application can be configured to implement a workflow associated with the blockchain (e.g., a Corda stream) to record transactions on nodes of the distributed ledger (such as the first MP node 124A of the first distributed ledger 124 and / or the first MaaS node 126A of the second distributed ledger 126). The client-side interface can be hosted on each of a plurality of subscriber nodes 122A, 122B…122N, and the client-side interface can be configured to be loaded onto a client associated with a subscriber node. For example, the client-side interface of the decentralized application can be a remote procedure call (RPC) client, which can be configured on each subscriber node and peer node (i.e., MaaS provider node). The server-side interface of the decentralized application can run on each node of the first distributed ledger 124 and the second distributed ledger 126 associated with the corresponding subscriber node and peer node.

[0043] In one embodiment, a transaction request from the publisher node can initiate a MaaS transaction between a mobile provider node (e.g., the first MP node 124A of the first distributed ledger 124) and a MaaS provider node (i.e., the counterpart node). The first distributed ledger 124 can store records of MaaS transactions between two parties, namely the mobile provider node (e.g., the first MP node 124A of the first mobile provider), the MaaS provider node (i.e., the counterpart node), and / or one or more users (e.g., user 114). The second distributed ledger 126 can store records of MaaS transactions between any mobile provider node (e.g., the first MP node 124A, the second MP node 124B, ... and the Nth MP node 124N), the MaaS provider node (i.e., the counterpart node), and / or one or more users (e.g., user 114).

[0044] In the case of multiple MaaS providers, exemplary implementations may include multiple MaaS provider nodes, each of which may be associated with a specific MaaS provider and may be included in a separate distributed ledger for that particular MaaS provider. In some cases, multiple MaaS provider nodes may be included in a common distributed ledger, such as a second distributed ledger 126.

[0045] In one embodiment, the first MP node 124A and the first MaaS node 126A may be one of a plurality of database nodes of the first distributed ledger 124 and the second distributed ledger 126, respectively, and may be configured to receive transaction messages via the first subscriber node 122A. Each of the first MP node 124A and the first MaaS node 126A may be configured to update the initial state object associated with the first distributed ledger 124 and the second distributed ledger 126, respectively, based on the transaction message, to output an updated state object. The first MP node 124A and the first MaaS node 126A may establish a transaction that may include an initial state object with initial transaction data and an updated state object with updated transaction data.

[0046] In an embodiment, the second distributed ledger 126 may also store trip details for one or more users (e.g., user 114) based on transaction messages received from one or more publisher nodes of the MaaS network 104. In the example, the transaction message may include information related to the source and destination of a user's (e.g., user 114) ongoing trip, trip route information, the duration of the ongoing trip, one or more segments of the ongoing trip, the duration of each segment of the ongoing trip, at least one transportation service provider, and details of multiple vehicles (e.g., multiple vehicles 112A, 112B…112N) of the at least one transportation service provider. The first distributed ledger node of the second distributed ledger 126 (e.g., first MaaS node 126A) may send the trip details of the user (e.g., user 114) to system 102.

[0047] In an embodiment, the second distributed ledger 126 (including, for example, a first distributed ledger node, such as a first MaaS node 126A) may also store trip status associated with an ongoing trip of one or more users (e.g., user 114). Trip status may include, but is not limited to, information about active or in-progress segments of user 114's trip, the vehicles on which user 114 may travel covering the active segments, and source and destination locations associated with the active segments. The first distributed ledger node (such as the first MaaS node 126A) may be configured to send the stored trip status associated with user 114's ongoing trip to system 102.

[0048] Multiple MP servers 106 may include appropriate logic, circuitry, code, and / or interfaces, which can be configured to collectively manage trips and trip details associated with a transportation service provider. For example, a first MP server 106A may be configured to manage trip details associated with a first transportation service provider. A second MP server 106B may be configured to manage trip details associated with a second transportation service provider. An Nth MP server 106N may be configured to manage trip details associated with an Nth transportation service provider. Each of the multiple MP servers 106 can be implemented as a cloud server and can perform operations via web applications, cloud applications, HTTP requests, repository operations, file transfers, etc. Other example implementations of each of the multiple MP servers 106 may include, but are not limited to, database servers, file servers, web servers, media servers, application servers, host servers, or cloud computing servers. In at least one embodiment, each of the multiple MP servers 106 can be implemented as multiple distributed cloud-based resources using several techniques known to those skilled in the art. In some embodiments, one or more of the plurality of MP servers 106 may be implemented within a corresponding vehicle, such as a first vehicle 112A, a second vehicle 112B, ... and an Nth vehicle 112N.

[0049] The communication network 108 may include a communication medium through which each node of the MaaS network 104 can communicate with multiple MP servers 106 and system 102. Furthermore, the communication network 108 may include a communication medium through which system 102 can communicate with multiple display devices, such as a first display device 110A, a second display device 110B, an Nth display device 110N, and a display device 116.

[0050] In an exemplary embodiment, the communication network 108 may include a mobile wireless network (such as... Figure 4 As shown in the diagram, system 102 can communicate with multiple display devices via the mobile wireless network. In this case, when different display devices (e.g., first display device 110A and second display device 110B) are used within several segments of a user 114's ongoing or different journeys in vehicles (e.g., first vehicle 112A and second vehicle 112B), the mobile wireless network is suitable for seamlessly sending media content and other information to such devices.

[0051] Examples of communication network 108 may include, but are not limited to, the Internet, cloud networks, Wi-Fi networks, personal area networks (PANs), local area networks (LANs) or metropolitan area networks (MANs), and mobile wireless networks such as Long Term Evolution (LTE) networks (e.g., 4th or 5th generation (5G) mobile networks). Various nodes of MaaS network 104 may be configured to connect to communication network 108 according to various wired or wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, at least one of Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Zigbee, EDGE, IEEE 802.11, Li-Fi, 802.16, IEEE 802.11s, IEEE 802.11g, multi-hop communication, wireless access points (APs), device-to-device communication, cellular communication protocols, and Bluetooth (BT) communication protocols.

[0052] Multiple display devices may include a first display device 110A, a second display device 110B, ... and an Nth display device 110N. Each of these devices may include appropriate logic, circuitry, and / or interfaces that can be configured to display or present media content. In one embodiment, at least one such display device may be an in-vehicle display of a vehicle (such as one of multiple vehicles 112A, 112B...112N). In another embodiment, at least one of these display devices may be a personal mobile device that can be carried by user 114 throughout the duration of the journey. Examples of such display devices may include, but are not limited to, an in-vehicle dashboard display, an in-vehicle rear-seat entertainment system, an in-vehicle headrest display, or user 114's personal mobile device.

[0053] Each of the first display device 110A, the second display device 110B, ... and the Nth display device 110N may include a display unit that can be implemented using several known technologies, such as, but not limited to, at least one of liquid crystal display (LCD), light-emitting diode (LED) display, plasma display, or organic LED (OLED) display technologies, or other display devices. According to embodiments, the display unit of the display device may refer to a display screen of a head-mounted device (HMD), a smart glasses device, a see-through display, a projection-based display, an electrochromic display, or a transparent display. In one embodiment, each of the first display device 110A, the second display device 110B, ... and the Nth display device 110N may be a touch-enabled device, allowing the user 114 to provide user input via the display device.

[0054] Each of the multiple modes of transport 112A, 112B…112N (e.g., first mode of transport 112A, second mode of transport 112B,… and Nth mode of transport 112N) can be owned, leased, or managed by a transport service provider associated with MaaS network 104. Each of these modes of transport can be provided as part of a public transport service or a private transport service. When user 114 books a trip on MaaS network 104, the trip can be divided into multiple segments, which can be covered by the multiple modes of transport 112A, 112B…112N (as one or more modes of transport). Examples of such modes of transport can include, but are not limited to, rail, bus, car, airplane, taxi or trolley, tram, light rail, ferry, express transport, truck, or bicycle. Each of the multiple modes of transport 112A, 112B…112N can be associated with one of these modes of transport. Figure 1 In this disclosure, multiple vehicles 112A, 112B…112N (e.g., first vehicle 112A, second vehicle 112B, and Nth vehicle 112N) are shown as cars, taxis, and trucks, provided only as examples and should not be construed as limiting this disclosure. This disclosure can be applied to vehicles that can be associated with other available public or private modes of transportation.

[0055] Display device 116 may be a personal mobile device of user 114. Display device 116 may include appropriate logic, circuitry, and / or interfaces that can be configured to display or present media content. Example implementations of display device 116 may include, but are not limited to, smartphones or mobile phones, audio players, wearable audio devices (such as headphones), smart wearable displays, tablets, laptops, or head-mounted displays. For brevity, further description of display device 116 is omitted from this disclosure. In one embodiment, display device 116 may be a shared device in a transportation vehicle (such as a bus or railway).

[0056] In operation, system 102 can be configured to receive, from MaaS network 104, trip details associated with user 114's ongoing trip (e.g., such as...). Figure 3 (As described in the document). Each of the first vehicle 112A, the second vehicle 112B, ... and the Nth vehicle 112N can be registered with a transportation service provider. System 102 can identify the first vehicle 112A as the vehicle that user 114 can use to complete the first segment of an ongoing trip.

[0057] System 102 can generate a set of media content recommendations based on the received trip details and the media consumption history associated with user 114. In some embodiments, the set of media content recommendations can be further generated based on the user profile associated with user 114 and the device specifications associated with the display device (such as the first display device 110A).

[0058] At any point during the duration of the ongoing trip, system 102 can control the first display device 110A to display the generated group of recommended media content. The first display device 110A can be used within the defined first vehicle 112A during the duration of the first segment of the activity of the ongoing trip. System 102 can receive user selections for first media content recommendations in the displayed group of recommended media content. For example, in Figure 3 The document provides details related to the generation of media content recommendation groups, the display of media content recommendation groups, and user selection of media content recommendations.

[0059] System 102 can control the playback of the first media content associated with the first media content recommendation on the first display device 110A. At any point during the duration of an ongoing activity (such as the duration of the first segment of an activity), system 102 can detect a first event that may require pausing the playback of the first media content. For example, the first event can be detected based on the end of the first segment of an ongoing activity or user input from user 114 to pause the playback of the first media content. During the duration of a second segment of an ongoing activity or during the duration of a different activity of user 114, system 102 can control the playback of the first media content to resume on the second display device 110B. When playback resumes, the second display device 110B can be used within the second vehicle 112B.

[0060] In some scenarios, the first media content or a portion thereof (e.g., a set of cached blocks of a media stream) may be stored on the second vehicle 112B or a display device (e.g., the second display device 110B) within the second vehicle 112B, and furthermore, the second vehicle 112B may be physically near the first vehicle 112A. In such a case, the first display device 110A and the second display device 110B may establish a communication link with each other based on the physical proximity of the first vehicle 112A and the second vehicle 112B, for example, through an Internet of Things (IoT) network (such as a vehicle-to-vehicle (V2V) network or a vehicle-to-all (V2X) network). Therefore, the first display device 110A may receive the first media content or a set of cached blocks of a media stream from the second vehicle 112B or the second display device 110B. This may be useful in situations such as handover (e.g., in a 5G cellular network) or insufficient network bandwidth in the communication network 108. The first display device 110A can receive cached blocks of first media content or media streams from the second display device 110B associated with the second vehicle 112B. Similarly, via an IoT network (such as a V2V network or a V2X network), the first display device 110A can receive other media content that may have previously been streamed or cached on the second display device 110B within the second vehicle 112B.

[0061] Because system 102 enables seamless streaming and playback of media content across different display devices (in-vehicle displays or personal mobile devices) during the duration of one or more trips, user 114 can watch, pause, and then resume playback of the media content at any point during the duration of such a trip. This seamless streaming and playback of media content is possible for user 114 even when the trip is covered by vehicles managed by different transportation service providers. For example, system 102 can control the playback of first media content to pause on first display device 110A at the end of the first segment of the activity and resume on second display device 110B at the start of the ongoing trip or the second segment of a different trip. This control can be based on user input via first display device 110A to pause playback and another user input via second display device 110B to resume the paused playback.

[0062] Figure 2 This is a block diagram of an exemplary system for playback control of media content across devices in a MaaS transportation network, according to embodiments of this disclosure. (In conjunction with...) Figure 1 Explanation of elements Figure 2 .refer to Figure 2The diagram shows a block diagram 200 of system 102. System 102 may include circuitry 202, memory 204, and a network interface 206. System 102 may also include input / output (I / O) devices 208. Memory 204 may include an AI model 204A.

[0063] Circuit 202 may include appropriate logic, circuitry, and interfaces that can be configured to execute program instructions associated with different operations to be performed by system 102. Circuit 202 may be implemented based on a variety of processor technologies known in the art. Examples of processor technologies may include, but are not limited to, a central processing unit (CPU), x86-based processors, reduced instruction set computing (RISC) processors, application-specific integrated circuit (ASIC) processors, complex instruction set computing (CISC) processors, graphics processing units (GPUs), and other processors.

[0064] Memory 204 may include appropriate logic, circuitry, and interfaces, and may be configured to store program instructions to be executed by circuitry 202. Memory 204 may be configured to store trip details, user profiles, device specifications, and media consumption history. Memory 204 may also be configured to store timestamps associated with pauses in playback of the first media content. Memory 204 may be further configured to store an AI model 204A. Examples of implementations of memory 204 may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), hard disk drive (HDD), solid-state drive (SSD), CPU cache, and / or secure digital card (SD).

[0065] AI Model 204A can be a classifier or regression model that can be trained to recognize relationships between inputs (such as features in the training dataset, which may include trip details, media consumption history, user profile data, device specifications, or datasets of media content groups) and output labels for a dataset that may include categorized recommended media content from the media content groups. AI Model 204A can be defined by its hyperparameters, such as the number of weights, cost function, input size, number of layers, etc. The hyperparameters of AI Model 204A can be tuned, and the weights can be updated to move towards the global minimum of the cost function of AI Model 204A. After several training epochs on the feature information in the training dataset, AI Model 204A can be trained to output a prediction / classification result for a set of inputs. The prediction result can indicate the class label for each input in the input set (e.g., input features extracted from new / unseen instances).

[0066] AI model 204A may include electronic data, such as software programs, software program code, libraries, applications, scripts, or other logic or instructions executed by a processing device such as circuit 202. AI model 204A may include code and routines configured to enable a computing device such as circuit 202 to perform one or more operations for classifying one or more inputs (e.g., trip details, media consumption history, user profile data, device specifications, media content groups) into recommended media content from the media content groups. Additionally or alternatively, AI model 204A may be implemented using hardware including a processor, a microprocessor (e.g., performing or controlling the execution of one or more operations), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC). Alternatively, in some embodiments, AI model 204A may be implemented using a combination of hardware and software.

[0067] Examples of AI Model 204A (such as one or more trained neural network models) may include, but are not limited to, deep neural networks (DNNs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), linear regression models, logistic regression models, decision tree models, K-means-based models, or random forest models.

[0068] I / O device 208 may include appropriate logic, circuitry, and interfaces that can be configured to receive input from a user and provide output based on the received input. I / O device 208, which may include various input and output devices, can be configured to communicate with circuitry 202. Examples of I / O device 208 may include, but are not limited to, touchscreens, keyboards, mice, joysticks, microphones, display devices, and speakers.

[0069] Network interface 206 may include appropriate logic, circuitry, code, and / or interfaces that can be configured to facilitate communication between circuitry 202, MaaS network 104, multiple MP servers 106, and multiple display devices via communication network 108. Network interface 206 can be implemented using various known technologies to support wired or wireless communication between system 102 and communication network 108. Network interface 206 may include, but is not limited to, antennas, radio frequency (RF) transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, encoder-decoder (CODEC) chipsets, user identity module (SIM) cards, or local buffer circuitry.

[0070] Network interface 206 can be configured to communicate wirelessly with networks such as the Internet, intranets, or wireless networks such as cellular telephone networks, wireless local area networks (LANs), and metropolitan area networks (MANs). Wireless communication can be configured to use one or more of several communication standards, protocols, and technologies, such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Long Term Evolution (LTE), Code Division Multiple Access (CDMA), 5G networks (e.g., 5G New Radio (NR) networks), 5G smart antennas, Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, or IEEE 802.11n), Voice over Internet Protocol (VoIP), Li-Fi, Wi-MAX, email protocols, instant messaging, and short message service (SMS). Network interface 206 is capable of communicating with 5G communication networks and will include appropriate 5G support functions, such as, but not limited to, 5G NR, V2X infrastructure and 5G smart antennas.

[0071] Figure 3 This is a block diagram illustrating exemplary operation of playback control of media content for devices across a MaaS transportation network according to embodiments of this disclosure. (In conjunction with...) Figure 1 and 2 Element description Figure 3 . refer to Figure 3 A block diagram 300 is shown illustrating exemplary operations from 302 to 338 as described herein. The exemplary operations shown in block diagram 300 may begin at 302 and may be performed by any computing system, apparatus, or device, such as by... Figure 1 or Figure 2 System 102 executes. Although shown in separate boxes, exemplary operations associated with one or more boxes of block diagram 300 may be divided into additional boxes, combined into fewer boxes, or eliminated, depending on the implementation of the exemplary operations.

[0072] At 302, trip details can be received. In one embodiment, circuitry 202 can be configured to receive trip details associated with an ongoing trip for user 114 from MaaS network 104. In this embodiment, the received trip details may include contextual factors associated with user 114's ongoing trip. Examples of trip details associated with user 114's ongoing trip may include, but are not limited to, information corresponding to the source and destination of the ongoing trip, the duration of the ongoing trip, information associated with one or more segments of the ongoing trip, the duration of each segment of the ongoing trip, at least one transportation service provider associated with the ongoing trip, and details of multiple modes of transportation to be used in the ongoing trip. For example, such details may include the type of transportation or mode of transportation associated with each mode of transportation and the type of transportation service (private or public) associated with each mode of transportation. In some cases, such details may also specify whether the mode of transportation includes a built-in display for entertainment.

[0073] At 304, media consumption history can be received. In an embodiment, circuit 202 can be configured to receive media consumption history associated with user 114 from MaaS network 104. Examples of media consumption history may include, but are not limited to, logs listing the user's viewing history of programs or shows, games or other interactive content, past viewing history of media content styles, types of media content consumed during past trips, and specific times or media content consumption in the past (such as time at home during the day) or at a specific destination (such as on a vehicle or at home). Media types may include, for example, audio content, video content, audio viewing content associated with a particular style of media content, audio viewing content associated with a preferred content length, game content, virtual reality (VR) or augmented reality (AR) content, immersive 3D video, etc.

[0074] At 306, a user profile can be received. In one embodiment, circuitry 202 can be configured to receive a user profile of user 114 from MaaS network 104. The user profile may include, for example, user 114's content preferences and other details, such as the user's name, age group, or other demographic factors, such as the income group to which user 114 belongs. In an embodiment, the user profile may include details of travel destinations typically covered in user 114's itinerary, the types of media content preferred by user 114, the types of transportation preferred by user 114, the type of account (such as a paid subscription account) of user 114, and behavioral data points on user 114.

[0075] At 308, device specifications can be received. In one embodiment, circuitry 202 may be configured to receive device specifications associated with the first display device 110A from MaaS network 104. Device specifications may include, for example, the model name of the first display device 110A, the screen size of the first display device 110A, and one or more compatible media formats associated with the first display device 110A.

[0076] At 310, a context-aware recommendation model can be loaded into memory 204. This context-aware recommendation model can be trained on a media content recommendation task. For example, the context-aware recommendation model can be a classifier model that can be trained to generate groups of media content recommendations that can be matched with features extracted from one or more of trip details, user profiles, media consumption history, and device specifications. In one embodiment, AI model 204A can be used as the context-aware recommendation model.

[0077] In one embodiment, the context-aware recommendation model can be implemented as a machine learning model. Examples of machine learning models may include, but are not limited to, regression models (such as multivariate logistic or linear regression models), decision tree models, random forests, gradient boosting trees, or Naive Bayes.

[0078] In another embodiment, the context-aware recommendation model can be implemented as a neural network (NN) model. The NN model can be defined by its hyperparameters, such as the number of weights, cost function, input size, number of layers, number of neurons per layer, etc. During the training phase, the hyperparameters of the context-aware recommendation model can be tuned, and the weights can be updated to move towards the global minimum of the cost function. After several epochs of training on the training dataset, the context-aware recommendation model can be trained to output predictions / classifications for a set of inputs. The predictions can indicate a category label (media content recommendation) for each input in the input set (e.g., input features extracted from new / unseen instances).

[0079] Context-aware recommendation models can include electronic data, such as software programs, software program code, libraries, applications, scripts, or other logic or instructions for execution by a processing device such as circuit 202. Context-aware recommendation models can include code and routines configured to enable computing devices such as circuit 202 to execute one or more operations for classifying one or more inputs into recommendation groups. Additionally or alternatively, trained context-aware recommendation models can be implemented using hardware, including processors, microprocessors (e.g., for performing one or more operations or controlling the execution of one or more operations), field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs). Alternatively, in some embodiments, trained context-aware recommendation models can be implemented using a combination of hardware and software. In some embodiments, context-aware recommendation models can be based on a hybrid architecture of multiple deep neural networks (DNNs).

[0080] At 312, recommendation groups can be generated. In an embodiment, circuit 202 can be configured to generate media content recommendation groups based on received trip details and media consumption history associated with user 114. The generated recommendation groups may include, but are not limited to, recommendations associated with the type of media content preferred by user 114, the style of media content based on previously played media content, or media content to be restored. In an embodiment, circuit 202 may be further configured to generate media content recommendation groups based on received user profiles and device specifications. As an example, the generated media content recommendation groups may be associated with media content such as, but not limited to, thriller and horror shows. Such shows may be associated with styles or programs mentioned in the media consumption history or user profile.

[0081] In one embodiment, at least one media content recommendation in the generated media content recommendation group can be generated based on styles or media programs that may be popular among users in a specific user group, such as users in a specific age group. In another embodiment, at least one media content recommendation in the media content recommendation group can be generated based on the preferences of other users who have similar interests or similar user profiles compared to user 114.

[0082] In one embodiment, circuit 202 can construct input features for a context-aware recommendation model. The input features can be constructed based on one or more of the following: received trip details, received media consumption history, received user profile, or received device specifications. Circuit 202 can then input the constructed input features into the (trained) context-aware recommendation model and can generate a set of recommendations as the output of the context-aware recommendation model for the input features.

[0083] For example, trip details may include information associated with the duration of user 114's ongoing trip and one or more modes of transportation that user 114 can use. Trip details may also include trip status associated with the ongoing trip (such as an identifier indicating the activity segment of the ongoing trip). User 114's media consumption history may indicate the user's preferences for various content styles (such as thrillers or horror movies) and preferred content formats (such as audio podcasts, video-on-demand (VOD) programs, or broadcast media content). Furthermore, user 114's media consumption history may list a set of shows that user 114 may have previously watched in past trips.

[0084] The device specifications of a display device (e.g., first display device 110A or personal mobile device (e.g., display device 116 of user 114)) may include, for example, screen size information, a set of supported display resolutions, and media format compatibility (such as in terms of supported codecs). Media content related to media content recommendation may conform to device specifications (e.g., compatible screen resolutions and media formats).

[0085] At 314, a model validation metric can be generated. In an embodiment, circuit 202 can be configured to generate a model validation metric. The model validation metric provides a quantitative measure of the accuracy with which a context-aware recommendation model can output media content recommendations for a given input. As an example, circuit 202 can be configured to receive user input indicating the selection of a context-aware recommendation model. Based on the user input, circuit 202 can be configured to validate the context-aware recommendation model. The model validation metric enables the selection of a context-aware recommendation model from a variety of recommendation models that can be pre-trained for the media content recommendation task. For example, such a metric may include a confusion matrix to describe the performance of the recommendation model on test data.

[0086] At 316, the first segment of the activity can be determined. In an embodiment, circuit 202 can be configured to determine the first segment of the activity of an ongoing trip. The ongoing trip can be divided into multiple segments, which may need to be covered by multiple vehicles (e.g., multiple vehicles 112A, 112B...112N) of at least one transportation service provider associated with MaaS network 104. The multiple vehicles may include a first vehicle (e.g., first vehicle 112A) and a second vehicle (e.g., second vehicle 112B).

[0087] At 318, a first means of transportation can be determined. In an embodiment, circuit 202 can be configured to determine the first means of transportation through which user 114 can be set to complete the first segment of an ongoing journey.

[0088] At 320, a first display device (e.g., first display device 110A) can be controlled. In an embodiment, circuitry 202 can be configured to control the first display device 110A to display a generated group of recommended media content. The first display device 110A can be used within a defined first vehicle 112A for the duration of a first segment of the activity. Examples of the first display device 110A may include, but are not limited to, a dashboard display of the first vehicle 112A, a rear-seat entertainment system of the first vehicle 112A, a headrest display of the first vehicle 112A, or a personal mobile device of user 114 (e.g., display device 116). As an example, where the first display device 110A can be connected to a personal mobile device, the first display device 110A can be controlled via the user interface (UI) of the personal mobile device (e.g., display device 116).

[0089] At 322, recommendations can be selected. In an embodiment, circuit 202 can be configured to receive a user selection of a first media content recommendation from the displayed group of media content recommendations. In one embodiment, the context-aware recommendation model can be retrained based on the selection of the first media content.

[0090] At 324, a transport stream can be generated. In an embodiment, circuit 202 can be configured to generate a transport stream to include first media content associated with a first media content recommendation. In an embodiment, circuit 202 can be configured to generate a transport stream (including the first media content) based on the device specifications of the first display device 110A.

[0091] At 326, data stream packetization can be performed. In one embodiment, circuitry 202 can be configured to perform data stream packetization to generate a series of blocks of the generated transport stream. Each block in the generated series of blocks may not overlap with other blocks in the generated series of blocks. The series of blocks can be generated in such a way that the generated transport stream can be cached on a predicted edge network (e.g., an edge device associated with a base station of a mobile wireless network), to which the first display device 110A may be connected for the duration of an ongoing trip.

[0092] In one embodiment, circuit 202 may be configured to store the generated series of blocks on media server 328. Media server 328 may control the playback of the first media content associated with the first media content recommendation on the first display device 110A.

[0093] At 330, event-based playback can be controlled. In an embodiment, circuit 202 can be configured to detect a first event during the duration of an ongoing segment that may require pause of playback of the first media content on the first display device 110A. Examples of the detected first event may include, but are not limited to, the end of a segment, the end of a segment, pause of media content based on user input, or the user turning his / her head or eyes away from the first display device 110A. In an embodiment, circuit 202 can be further configured to control the playback of the first media content to pause on the first display device 110A based on the detection of the first event.

[0094] At 332, a media content identifier (ID) and a playback / restore ID can be stored. In an embodiment, circuit 202 can be configured to determine, based on detected events, a timestamp at which playback of the first media content can be paused throughout its entire duration. Circuit 202 can be further configured to store the media content ID (e.g., a track ID that identifies the first media content and also provides a location such as a Uniform Resource Locator (URL) for the first media content) in distributed ledger child nodes 128 (e.g., document child nodes 128C and user child nodes 128B). Furthermore, circuit 202 can record the timestamp as a playback / restore ID in a database such as distributed ledger child node 128 (e.g., document child node 128C). Circuit 202 can also store the user ID associated with user 114 along with the media content ID and the playback / restore ID in distributed ledger child node 128 (e.g., document child node 128C).

[0095] At point 334, the (active) second segment can be determined. In an embodiment, circuit 202 can be configured to determine the second segment of the ongoing process. In one case, the second segment may belong to the same process as the first active segment. In another scenario, the second segment may belong to a different process than the ongoing process. It should be noted that the second segment may or may not immediately follow the first active segment.

[0096] At 336, a second means of transport (e.g., second means of transport 112B) can be determined. In an embodiment, circuit 202 can be configured to determine the second means of transport 112B, through which user 114 can be set to complete a second segment of an ongoing trip or a different trip.

[0097] At point 338, a second display device (e.g., second display device 110B) can be controlled. In an embodiment, circuitry 202 can be configured to control the second display device 110B to display the generated media content recommendation set. The second display device 110B can be used within the defined second vehicle 112B for the duration of the second segment. Examples of the second display device 110B may include, but are not limited to, a dashboard display of the second vehicle 112B, a rear-seat entertainment system of the second vehicle 112B, a headrest display of the second vehicle 112B, and a personal mobile device of user 114 (e.g., display device 116).

[0098] In one embodiment, circuit 202 can be configured to control a first display device 110A to display a first option based on a detected first event, to pause playback of the first media content on the first display device 110A, and to resume playback on the second display device 110B in a second segment. In another embodiment, circuit 202 can be configured to receive first user input, which includes a selection of the displayed first option. In this case, playback of the first media content can be further controlled to resume on the second display device 110B based on the received first input. Additionally, playback of the first media content can be controlled to resume on the second display device 110B from a timestamp recorded on the distributed ledger child node 128 (e.g., document child node 128C).

[0099] In one embodiment, circuit 202 may be configured to control a second display device (e.g., display device 116) to display a second option to resume playback of the first media content based on the determination that the second vehicle 112B lacks an in-vehicle display. In this case, the second display device may be a personal mobile device of user 114 (e.g., display device 116). Circuit 202 may be configured to receive second user input including a selection of the second option. Playback of the first media content may be further controlled based on the received second input to resume on the second display device (e.g., display device 116) from a recorded timestamp.

[0100] Figure 4 This is a block diagram illustrating an exemplary network environment for sending media content blocks to a display device for seamless playback of media content according to embodiments of the present disclosure. (In conjunction with...) Figure 1 , 2 Element description of 3 Figure 4 . refer to Figure 4The diagram illustrates a network environment 400. Network environment 400 includes system 102, virtual network operator 402, and infrastructure provider 404. Network environment 400 may further include a virtual network 406, which includes a first base station 408A and a second base station 408B, an edge computing device 410, and a first display device 110A. Infrastructure provider 404 can manage the infrastructure of mobile wireless network 412, such as a 4th or 5th generation mobile network.

[0101] Virtual Network Operator 402 may be a network operator that can resell network services and may not own or operate telecommunications infrastructure. Virtual Network Operator 402 may provide network services based on bandwidth licenses from a telecommunications provider at wholesale rates. Virtual Network Operator 402 may have one or more associated network devices, which may include appropriate logic, circuitry, code, and / or interfaces to perform the operation of Virtual Network Operator 402. Virtual Network Operator 402 may be configured to receive service requests that can be sent by System 102. The received service requests may include Quality of Service (QoS) requirements and a set of mobility network management functions. QoS requirements may include, but are not limited to, 100 megabits per second (Mbps) bandwidth, a maximum latency of 10 milliseconds, a maximum jitter of 1 millisecond, and a recovery time of less than 1 second. The set of mobility network management functions may include, but is not limited to, information related to mobility context management, location tracking, paging, reachability management, handover control, mobility anchoring, and path optimization.

[0102] Virtual network operator 402 can send network resource requests to infrastructure provider 404 associated with mobile wireless network 412 (e.g., a 5G telecommunications network) based on received service requests. Virtual network operator 402 can use the received service requests to perform analysis and send the network resource requests to infrastructure provider 404. For example, virtual network operator 402 can perform analysis to determine the amount of network resources (e.g., bandwidth, network channels, and network slices) that can be used to transmit media content from system 102 to any display device (such as the first display device 110A).

[0103] Infrastructure provider 404 can manage network resources of mobile wireless network 412 (e.g., a 5G telecommunications network). Infrastructure provider 404 may include one or more associated network devices, which may include appropriate logic, circuitry, code, and / or interfaces configured to perform the operations of infrastructure provider 404. Infrastructure provider 404 is configured to receive network resource requests from virtual network operator 402. The resource controller of infrastructure provider 404 can be configured to serve the received network resource requests and create virtual network 406 to allocate network resources of mobile wireless network 412 (e.g., a 5G telecommunications network) according to the service requirements in the received network resource requests. Infrastructure provider 404 can allocate new resources for service requirements or adjust existing resources for service requirements. Therefore, the created virtual network 406 can meet resource allocation needs.

[0104] As part of the network slicing features of the mobile wireless network 412, the virtual network 406 of the mobile wireless network 412 (e.g., a 5G telecommunications network) can provide end-to-end customization capabilities to support different application requirements, such as big data management on the MaaS network 104 associated with multiple transportation service providers. Furthermore, the mobility-driven network slices of the mobile wireless network 412 (e.g., a 5G telecommunications network) can support multiple network slices with different mobility management schemes. The mobility management scheme can be determined by the actual required level of mobility support from the mobile wireless network 412 (e.g., the 5G telecommunications network). The mobility management scheme can be obtained by orchestrating the selected basic mobility management functions. The virtual network 406 can be configured to ensure the delivery of infotainment application services to display devices (such as a first display device 110A) that can be used while moving within a vehicle (such as a first vehicle 112A) on a predicted route of a trip (booked and managed via the MaaS network 104).

[0105] Each of the first base station 408A and the second base station 408B may include appropriate logic, circuitry, code, and / or interfaces for transmitting and receiving radio signals. Each of the first base station 408A and the second base station 408B may be a hub for a local wireless network and / or a gateway between a wired network and a wireless network (e.g., a cellular network). Each of the first base station 408A and the second base station 408B may be configured to transmit media content (e.g., first media content) to a connected display device (such as the first display device 110A) via a virtual network 406.

[0106] Edge computing device 410 may include suitable logic, circuitry, and / or interfaces configured to cache blocks of the first media content transport stream before they are sent to first display device 110A for playback of a portion of the first media content on first display device 110A. Such blocks may be pre-cached before the network of first display device 110A switches from first base station 408A to second base station 408B. Edge computing device 410 may receive such blocks of the first media content from system 102 via virtual network 406.

[0107] Edge computing device 410 may include computing devices that can have storage capabilities and can be connected to a network (e.g., an edge network). The edge network may include multiple switches or gateway devices, which may be located at ingress or egress points between networks, and may have computing capabilities to process or store information from connected devices such as edge computing device 410. For example, in Figure 5 The details described are related to cache blocks and sending cached blocks to the first display device 110A.

[0108] Mobile wireless network 412 (e.g., a 5G telecommunications network) can be an ultra-dense wireless telecommunications network that may include a large number of base stations. This can lead to frequent handovers, higher handover latency, and consequently, communication failures that may affect the overall quality of service of mobile wireless network 412. In one embodiment, the Mobility Management as a Service (MMaaS) of MaaS network 104 can reduce communication failures by configuring handover policies using trip route information of an ongoing trip associated with MaaS network 104 and application requirements of system 102. For example, virtual network 406 can configure handover policies by dynamically adjusting one or more handover control parameters (HCPs) based on trip route information of the first active segment of an ongoing trip of user 114.

[0109] In one embodiment, agent node device 120 (which may be associated with a smart agent of MaaS network 104) can be configured to determine a specific message routing strategy for transaction messages of MaaS network 104 by calculating probability-based scores associated with various factors that may affect transaction processing of MaaS network 104. Therefore, the selection of the message routing strategy can be based on the calculated probability-based scores, which may be trade-offs among various factors associated with transaction processing of MaaS network 104. Examples of these factors may include, but are not limited to: system risk mitigation of MaaS network 104, remedies for operational and system failures associated with nodes of MaaS network 104, cost-benefit analysis for users of MaaS network 104 (e.g., price- and / or user preference-based benefits), and cost-benefit analysis for mobile providers and / or organizations operating MaaS network 104. Examples of these factors may further include, but are not limited to, traffic optimization associated with the mobile provider of MaaS network 104, energy consumption and carbon emissions associated with vehicles 112A, 112B…112N of the mobile provider of MaaS network 104, and user time consumption associated with transactions on MaaS network 104. In an embodiment, virtual network 406 may further configure a handover strategy based on the selected message routing strategy of proxy node device 120. As discussed, the selected message routing strategy may be based on a calculated probability-based score, which may be a trade-off between various of the foregoing factors.

[0110] Figure 5 This is a sequence diagram illustrating exemplary operations for sending blocks of a transport stream of media content to a display device for playback of the media content, according to embodiments of the present disclosure. (In conjunction with...) Figure 1 , 2 Element descriptions of 3 and 4 Figure 5 . refer to Figure 5 Sequence diagram 500 is shown to depict exemplary operations from 502 to 520. The exemplary operations shown in sequence diagram 500 may begin at 502 and may be performed by any computing system, device, or apparatus, such as by [unclear text - likely a typo]. Figure 1 or Figure 2 The system 102, virtual network operator 402, infrastructure provider 404, virtual network 406, and edge computing device 410 are used to perform this.

[0111] At point 502, a service request can be sent. In one embodiment, circuit 202 can be configured to send the service request to virtual network operator 402. In one embodiment, virtual network operator 402 can be configured to receive the sent service request. The service request may include a Quality of Service (QoS) requirement and a set of mobility network management functions. The QoS requirement may include, but is not limited to, 100 megabits per second (Mbps) bandwidth, a maximum latency of 10 milliseconds, a maximum jitter of 1 millisecond, and a recovery time of less than 1 second. The set of mobility network management functions may include, but is not limited to, information related to mobility context management, location tracking, paging, reachability management, handover control, mobility anchoring, and path optimization. In one embodiment, the service request may be for sending first media content from system 102 via a 5G telecommunications network to a display device such as a first display device 110A.

[0112] At step 504, a network resource request can be sent. In one embodiment, based on the received service request, the virtual network operator 402 can be configured to send a network resource request to the infrastructure provider 404 associated with the mobile wireless network 412 (e.g., a 5G telecommunications network). In another embodiment, the virtual network operator 402 can perform analysis on the received service request and can generate a network resource request based on that analysis.

[0113] At 506, network resources can be allocated. In one embodiment, infrastructure provider 404 can be configured to create virtual network 406 to allocate network resources of mobile wireless network 412 (such as 5G telecommunications networks, e.g., communication network 108) according to service requirements. For example, in Figure 4 The text further describes the allocation of network resources.

[0114] At 508, a first base station 408A can be identified. In an embodiment, the created virtual network 406 can be configured to identify, during the duration of an ongoing process, a first base station 408A of a mobile wireless network 412 to which the first display device 110A can connect, to stream a first set of blocks from a stored series of blocks from a media server 328 for playback on the first display device 110A. As an example, the virtual network 406 can store location information of multiple base stations associated with the virtual network 406. The virtual network 406 can receive the current location of a first vehicle 112A to which the first display device 110A can use. In one embodiment, the current location of the first vehicle 112A can be received from a first MP server 106A. Based on the stored location information of multiple base stations and the received current location of the first vehicle 112A, the virtual network 406 can be configured to determine a first base station 408A to which the first display device 110A can currently connect to stream the first set of blocks.

[0115] At 510, a second base station 408B can be determined. In an embodiment, based on trip route information associated with an ongoing trip, the created virtual network 406 can be configured to determine a second base station 408B of a mobile wireless network 412 (such as a 5G telecommunications network) that the first display device 110A may connect to after a handover from the first base station 408A. In an embodiment, the virtual network 406 may receive trip route information associated with an ongoing trip from system 102. Based on stored location information of multiple base stations and the received trip route information, the virtual network 406 can be configured to determine the second base station 408B.

[0116] At 512, a second block can be sent. In an embodiment, prior to the handover, the created virtual network 406 can be configured to send the second block from a stored series of blocks to the edge computing device 410 associated with the second base station 408B.

[0117] At 514, the second block can be cached. In an embodiment, before the switch, the edge computing device 410 can be configured to receive the sent second block and cache the received second block.

[0118] At 516, a second cached block can be sent. In one embodiment, after a switchover, the edge computing device 410 can be configured to send the second cached block to the first display device 110A for playback of a portion of the first media content on the first display device 110A.

[0119] As described, edge computing device 410 can predictively cache a portion of first media content (such as a second chunk of a media stream) before handover to the next base station. After handover to the next base station, edge computing device 410 can send the cached portion of the first media content to a display device (e.g., first display device 110A). Therefore, potential communication failures during handover between base stations can be reduced, and media content delivery can be optimized by predictively caching a portion of the first media content at edge computing device 410. The above process can be repeated to pre-cache other portions of the first media content to other base stations that the first display device 110A may connect to during the duration of the first segment of the ongoing trip. By using the configured handover strategy and edge computing device 410, the first media content can be seamlessly streamed to any display device used during the duration of the ongoing trip.

[0120] In some scenarios, the first media content or a portion thereof (e.g., a set of cached blocks of a media stream) may be stored on the second vehicle 112B or a display device (e.g., the second display device 110B) within the second vehicle 112B, and furthermore, the second vehicle 112B may be physically near the first vehicle 112A. In this case, the first display device 110A and the second display device 110B can establish a communication link with each other via, for example, an Internet of Things (IoT) network (e.g., a vehicle-to-vehicle (V2V) network or a vehicle-to-everything (V2X) network). Therefore, the first display device 110A can receive the first media content or a set of cached blocks of a media stream from the second vehicle 112B or the second display device 110B. This can be useful in situations involving handover (e.g., in a 5G cellular network) or a lack of network bandwidth. Similarly, via an IoT network (such as a V2V network or a V2X network), the first display device 110A may also receive other media content that may have been cached or previously streamed on the second display device 110B within the second vehicle 112B.

[0121] Figure 6 This is a diagram illustrating an exemplary scenario of playback control of media content for devices across a MaaS transportation network according to embodiments of this disclosure. Combined with... Figure 1 , 2 Explanation of elements 3, 4, and 5 Figure 6 . refer to Figure 6 The following diagram illustrates scenario 600. Scenario 600 may include a representation 602 of user 114's ongoing trip and a timeline 604 of the ongoing trip.

[0122] An ongoing trip can begin at source location A and end at destination location D. The ongoing trip can be divided into three segments, such as segment 612 (between source location A and first intermediate location B), segment 614 (between first intermediate location B and second intermediate location C), and segment 616 (between second intermediate location C and destination location D). These three segments can be covered by multiple modes of transportation from at least one transportation service provider associated with MaaS network 104. The multiple modes of transportation may include taxis 606, trains 608, and bicycles 610.

[0123] During the duration of the first segment 612 of the activity, when the first display device 110A is used inside the taxi 606, circuit 202 can display a set of media content recommendations on the first display device 110A. At any point during the duration of the first segment 612 of the activity, circuit 202 can receive a user selection for a first media content recommendation in the displayed set of media content recommendations. Thereafter, circuit 202 can control the playback of the first media content associated with the first media content recommendation on the first display device 110A.

[0124] In some scenarios, the media content recommendation group may include media content that can be stored on or streamed to user 114's display device 116 before the start of the first segment 612 of the activity. If the media content has already been played back on user 114's display device 116 for a certain timestamp before the start of the first segment 612 of the activity, circuit 202 may control the first display device 110A to prompt user 114 to resume playback of the media content from the same timestamp on the first display device 110A. In another scenario, circuit 202 may control the display device 116 to display the media content recommendation group even before the start of the first activity segment 612 (e.g., while user 114 is waiting for a taxi 606) or during the duration between two segments of the trip (e.g., when user 114 is waiting to start the second segment of the trip after the end of the first activity segment 612). Based on the selection of the first media content received from user 114, circuit 202 may control the playback of the first media content on display device 116. Playback of the first media content on display device 116 can be paused at a specific timestamp at the beginning of the first segment 612, and circuit 202 can control the playback of the first media content to resume on the first display device 110A from the paused timestamp.

[0125] During the duration of the ongoing process, circuit 202 can detect a first event that may require pausing playback of the first media content. The first event may include user input to pause playback of the first media content (e.g., selecting a first option 624 on the first display device 110A). Circuit 202 can determine a first timestamp 618 on which playback of the first media content can be paused based on the detected first event throughout the entire duration of the first media content. The first media content can be paused, and circuit 202 can record the first timestamp 618 on the distributed ledger child node 128 (e.g., document child node 128C).

[0126] In one embodiment, the first display device 110A may include an image capturing device. By using the image capturing device, the first display device 110A can capture multiple images of user 114 while user 114 may be viewing first media content on the first display device 110A. The first display device 110A may apply gaze estimation techniques to track the movement of the user 114's line of sight (LoS) in each of the multiple images. The LoS may include the posture of the user 114's head and the orientation of the eyes relative to a reference position. Based on the tracking of the LoS, the first display device 110A can determine whether user 114 is facing the first display device 110A at any given time. In some scenarios, based on the posture of user 114's head and the orientation of the eyes relative to a reference position, and the detection of a mobile phone near user 114's ear or mouth in the multiple images, the first display device 110A may detect that user 114 is making a call. If the first display device 110A determines that the Loss of User 114 has left the first display device 110A, or if the first display device 110A detects that the user 114 is on a call, the first display device 110A may automatically pause the playback of the first media content on the first display device 110A. In some scenarios, when the first display device 110A detects that the Loss of User 114 has left the first display device 110A, or when the first display device 110A detects that the user 114 is on a call, the first display device 110A may display a first option 624 to allow the user 114 to manually pause the playback of the first media content. The first media content can be paused, and the circuit 202 may record a first timestamp 618 on the distributed ledger child node 128 (e.g., document child node 128C).

[0127] In other scenarios, the first display device 110A may receive user input from user 114 to locate the first media content. For example, the user input may indicate a need to rewind, advance, or skip certain segments of the first media content, or an instruction to navigate to a specific timestamp within the first media content. Based on the received user input, the first display device 110A can locate the first media content to a new content playback timestamp. Circuit 202 can accordingly record a timestamp corresponding to the new content playback timestamp (after the search) as a first timestamp 618 on the distributed ledger child node 128 (e.g., document child node 128C). Therefore, the type of interruption during media content playback can be appropriately monitored. Examples of interruption types during media content playback may include, but are not limited to, automatic or manual pauses of media content playback due to user inattention (e.g., when the user looks away from the first display device 110A or while the user is on a call), or manual searching for media content playback.

[0128] In another embodiment, proxy node device 120 can determine the failure of one or more transactions in MaaS network 104 and predict the cause of the failure. The failure of one or more transactions can indicate a failure corresponding to a route associated with the one or more transactions. Examples of such predicted causes of failure can include, for example, natural disasters (e.g., earthquakes, tsunamis, cyclones, storms, floods, or volcanic eruptions), calamities (e.g., accidents at major intersections, or epidemics / contagious diseases), or traffic disruptions (e.g., protests / convoys, traffic diversions due to events / festivals, or peak-hour traffic congestion). Proxy node device 120 can also determine alternative routes associated with one or more transactions based on the determined failure and the predicted cause of failure. Based on the predicted cause of failure and the determined alternative routes, circuitry 202 can control a first display device 110A to display a prompt to user 114. The prompt can indicate that the current segment of the journey may be interrupted for a specific time (e.g., a few minutes) due to the predicted cause of failure. The prompt can also indicate that the journey can continue on a new segment of the alternative route. In this configuration, the first display device 110A can be configured to automatically pause playback of the first media content or allow user 114 to manually pause playback of the first media content. Again, the first media content can be paused, and circuit 202 can record a first timestamp 618 on the distributed ledger child node 128 (e.g., document child node 128C).

[0129] In an embodiment, playback of the first media content can be resumed on user 114's display device 116 after the end of the first segment 612 of the trip and before the start of the second segment 614 (e.g., when user 114 gets off taxi 606 and waits for train 608). Circuit 202 can extract a first timestamp 618 from distributed ledger child node 128 (e.g., document child node 128C) and can control display device 116 to resume playback of the first media content from the extracted first timestamp 618. Furthermore, display device 116 can automatically pause playback of the first media content before the start of the second segment 614 (e.g., at a predetermined time before the start of the second segment 614) or allow user 114 to manually pause playback of the first media content. Circuit 202 can store the current timestamp associated with the playback of the first media content as the first timestamp 618 on distributed ledger child node 128 (e.g., document child node 128C).

[0130] During the duration of the second segment 614 of the journey, circuit 202 may control the playback of the first media content to resume on the second display device 110B used within train 608. At any time during the duration of the second segment 614, circuit 202 may detect a second event that may require the resumption of playback of the first media content. The second event may include user input for resuming playback of the first media content (e.g., by selecting a second option 626 on the second display device 110B). Circuit 202 may retrieve a first timestamp 618 of a record from a distributed ledger child node 128 (e.g., a document child node 128C). Playback of the first media content may resume on the second display device 110B from the retrieved first timestamp 618. Alternatively, circuit 202 may control the second display device 110B to prompt user 114 to provide user input indicating a location in the first media content from which user 114 may wish to resume playback of the media content. Based on the user input indicating the location, playback of the first media content may resume on the second display device 110B.

[0131] In another embodiment, circuit 202 may be configured to receive data from a first distributed ledger node of the MaaS network 104 (e.g., a first MaaS node, such as...). Figure 7 (As shown) Receives the trip status associated with the ongoing trip. Circuit 202 can detect a second event based on the received trip status, which may indicate that user 114 may be on a second means of transportation 112B (such as train 608) to complete a second segment 614 of the ongoing trip. Circuit 202 can retrieve a first timestamp 618 of the record from a distributed ledger child node 128 (e.g., document child node 128C) based on the detected second event. Playback of the first media content can be controlled to resume on a second display device 110B from the retrieved first timestamp 618.

[0132] Circuit 202 can control the playback of the first media content to pause on the second display device 110B based on the determination of a third event, which can indicate the end of the second segment 614 of the ongoing process. Circuit 202 can determine a second timestamp 620 on which the playback of the first media content can be paused based on the detected third event throughout the entire duration of the first media content. The playback of the first media content can be paused, and circuit 202 can record the second timestamp 620 on the distributed ledger child node 128 (e.g., document child node 128C).

[0133] In one embodiment, circuit 202 can control a second display device 110B to display a notification that the second segment 614 of the ongoing journey's activity may be nearing its end. This could warn user 114 to disembark from train 608.

[0134] During the duration of the third segment 616 of the journey, circuit 202 can control the playback of the first media content on a display device (e.g., the Nth display device 110N) associated with bicycle 610. As shown, the third segment 616 can be covered by bicycle 610. In this case, the first media content may not be viewable. Circuit 202 can detect a fourth event during the duration of the ongoing journey that may require the resumption of playback of the first media content on the Nth display device 110N. The fourth event may include, for example, user input to resume playback of audio content associated with the first media content.

[0135] Circuit 202 can retrieve a second timestamp 620 of a record from distributed ledger child node 128 (e.g., document child node 128C). Playback of the first media content (i.e., the audio content of the first media content) can be resumed on the Nth display device 110N from the retrieved second timestamp 620. The audio content can be played during the third segment 616 of the entire activity of the ongoing process. At any time, circuit 202 can control the playback of the first media content (i.e., the audio content associated with the first media content) to pause on the Nth display device 110N based on the determination of a fifth event indicating the end of the third segment 616 of the activity of the ongoing process or the end of the process. In another scenario, the fifth event can indicate the completion of the playback of the first media content (i.e., the audio content associated with the first media content). In an embodiment, the audio content may not be associated with the first media content. In this case, the audio content may be, for example, a podcast, an audiobook, music or a song, or the audio portion of another video content.

[0136] In one embodiment, based on the determination that the Nth display device 110N associated with bicycle 610 can play only audio content, circuitry 202 can receive user input from user 114 to resume playback of the first media content on user 114's personal computing device (e.g., display device 116). For example, display device 116 may have the capability to play both audio and video content of the first media content. Based on the received user input to resume playback on display device 116, circuitry 202 can control display device 116 to resume playback of the first media content from a recorded second timestamp 620. Therefore, system 102 can allow seamless playback of the first media content across devices in MaaS network 104.

[0137] In an embodiment, circuit 202 may receive media content playback settings associated with playback of first media content on the first display device 110A during the duration of the first segment 612 of an ongoing activity. The media content playback settings may be received from the first display device 110A via user input. Examples of media content playback settings may include, but are not limited to, volume settings, display settings, and playback speed. Circuit 202 may store the received media content playback settings in distributed ledger child nodes 128 (e.g., document child nodes 128C and / or user child nodes 128B). Circuit 202 may retrieve the media content playback settings from distributed ledger child nodes 128 (e.g., document child nodes 128C and / or user child nodes 128B) at the beginning of another segment (e.g., the second segment 614) or during its duration. When the first media content is played back on the second display device 110B, the retrieved media content playback settings may be configured on the second display device 110B. Circuit 202 can control the playback of the first media content according to the configured media content playback settings.

[0138] In an embodiment, the vehicle that user 114 may be using during a segment of an ongoing trip may have a display device that may be part of the vehicle's public infotainment system. For example, the first display device 110A may be part of the infotainment system of taxi 606. Taxi 606 may also include one or more display devices in addition to the first display device 110A. In some cases, the one or more display devices may also be part of the same infotainment system of taxi 606. If user 114 has a subscription to watch the first media content through a priority subscription model (e.g., a premium membership with a content provider that can provide the first media content), circuitry 202 may enable user 114 to have priority access to the infotainment system among other users (if any) in taxi 606. In this case, circuitry 202 may control the playback of the first media content on the first display device 110A and may control one or more functions of the infotainment system.

[0139] In this embodiment, the ticket associated with the trip or a segment of the trip may include offers, promotions, or holiday discounts that authorize user 114 to access audio / video services associated with the trip or a segment of the trip. In this case, user 114 may or may not be a subscriber to the audio / video service. The audio / video service may be pre-bundled with the ticket associated with the trip or a segment of the trip. Circuit 202 may accordingly provide the audio / video service (e.g., a movie, a TV series, or an online / web series) as one or more media contents from a recommended group of media contents that can be played back during the duration of the trip or a segment of the trip.

[0140] In one embodiment, circuitry 202 can monitor the status of each of a plurality of display devices (e.g., first display device 110A, second display device 110B, and Nth display device 110N, and display device 116) that can be used during the duration of an ongoing process. Based on the monitored status of each display device, circuitry 202 can determine first monitoring information indicating whether a display device among the plurality of display devices is not functioning. The first monitoring information can also indicate the duration for which a display device is not used. In some cases, circuitry 202 can process a refund or offer a quote through display device 116 based on the first monitoring information. This can lead to optimal display device usage and reduced user churn.

[0141] Although the second paragraph 614 and the third paragraph 616 are in Figure 6 The segments are shown as single trip segments, but the scope of this disclosure is not limited thereto. In one embodiment, without departing from the scope of this disclosure, the second segment 614 and / or the third segment 616 may be segments of a trip that may be different from the trip associated with the first segment 612. Figure 6 In the diagram, the first segment 612, the second segment 614, and the third segment 616 are shown as consecutive segments of a single stroke. However, this disclosure is not limited thereto, and in some embodiments, the second segment 614 may be any segment following the first segment 612, and the third segment 616 may be any segment following the second segment 614, without departing from the scope of this disclosure.

[0142] Figure 7 This is a sequence diagram illustrating exemplary operations for payment settlement associated with media usage in a MaaS transportation network according to embodiments of this disclosure. (Combined with...) Figure 1 , 2 Explanation of elements 3, 4, 5, and 6 Figure 7 . refer to Figure 7 Sequence diagram 700 is shown to depict exemplary operations from 702 to 718. The exemplary operations shown in sequence diagram 700 may begin at 702 and may be performed by any computing system, device, or apparatus, such as by [unclear text - likely a typo]. Figure 2 The system 102 is implemented by circuit 202, MaaS network 104, first transportation service provider 720A, second transportation service provider 720B and content owner 722.

[0143] At 702, first media consumption information can be collected. In an embodiment, circuit 202 can collect first media consumption information associated with first media content on a first display device (e.g., first display device 110A) and a second display device (e.g., second display device 110B) during the duration of an ongoing process. The first media consumption information may include, but is not limited to, an identifier (such as a title) of the first media content selected for playback by user 114, the playback duration of the first media content, and the number of times user 114 views the first media content. The first media consumption information may also include, but is not limited to, the type and device specifications of each display device on which the first media content can be played, and the number of times the playback of the first media content can be paused and resumed.

[0144] At 704, a transaction message can be sent. In one embodiment, circuit 202 can send a transaction message, which may include the collected first media usage information, to MaaS network 104.

[0145] At point 706, the first distributed ledger node can be updated. In one embodiment, MaaS network 104 can be configured to receive sent transaction messages and can update records on the first distributed ledger node of MaaS network 104 (e.g., the first MaaS node 126A of the second distributed ledger 126). These records can be updated based on the received transaction messages by executing transactions on the first distributed ledger node (e.g., the first MaaS node 126A). The updated records can incorporate media usage statistics associated with the first media content from all users who may have viewed the first media content within a given time period.

[0146] At 708, a first smart contract may be stored. In one embodiment, the MaaS network 104 may store the first smart contract on a first distributed ledger node (e.g., a first MaaS node 126A). The first smart contract may store payment settlement rules that can be agreed upon by the provider of the MaaS network 104 and at least one transportation service provider associated with the MaaS network 104 (e.g., a first transportation service provider 720A and a second transportation service provider 720B).

[0147] For example, payment settlement rules may include scheduled automatic payment rules based on media usage statistics. Scheduled automatic payment rules may be associated with a configurable settlement model that includes payment settlement schedules at different intervals, such as, but not limited to, daily, weekly, bi-weekly, monthly, quarterly, or annual payments. In some cases, such rules may include a percentage share of revenue for each of the MaaS network 104 provider and at least one transportation service provider (e.g., first transportation service provider 720A and second transportation service provider 720B). This share may be determined based, for example, the duration or amount of media viewing within each transportation service provider's vehicles.

[0148] Media usage statistics can be used to settle fees for media content usage during one or more trips managed by MaaS Network 104. This payment can be settled between the transportation service provider and the provider of MaaS Network 104. The provider of MaaS Network 104 may have predetermined revenue-sharing agreements with different transportation service providers associated with MaaS Network 104. MaaS Network 104 can settle payments based on these predetermined revenue-sharing agreements. For example, MaaS Network 104 may allocate 20% of the media usage revenue (determined based on the number of views and the duration of each view) to its providers. MaaS Network 104 may then distribute the remaining media usage revenue equally among the different transportation service providers. Alternatively, MaaS Network 104 may distribute the remaining media usage revenue among transportation service providers at a rate proportional to the distance traveled by the user or the duration of the trip recorded by each transportation service provider. Alternatively, the MaaS network 104 may allocate a percentage of the remaining media usage revenue to the transportation service providers, which may be proportional to the total duration of playbacks recorded for a particular transportation service provider, the number of views recorded for a particular transportation service provider, and / or the cost associated with the media content on each transportation service provider.

[0149] At 710, the stored first smart contract can be executed. In one embodiment, the MaaS network 104 can execute the stored first smart contract on a first distributed ledger node (e.g., first MaaS node 126A). By executing the stored first smart contract, the provider of the MaaS network 104 can initiate payment settlement to at least one transportation service provider (e.g., first transportation service provider 720A and second transportation service provider 720B).

[0150] Payment can be settled at 712A and 712B. In an embodiment, MaaS network 104 can be configured to settle payments for playback of first media content with at least one transportation service provider (e.g., a first transportation service provider 720A and a second transportation service provider). MaaS network 104 can settle payments by executing a stored first smart contract based on update records associated with the first media content (at 706) and payment settlement rules that can be agreed upon by the provider of MaaS network 104 and at least one transportation service provider.

[0151] At 714, a second smart contract can be stored. In one embodiment, MaaS network 104 can store the second smart contract on a first distributed ledger node (e.g., the first MaaS node 126A of the second distributed ledger 126). The second smart contract can store a usage fee payment rule agreed upon by the provider of MaaS network 104 and the content owner of the first media content (e.g., content owner 722). In one embodiment, the usage fee payment rule can determine the usage fee amount for content owner 722 based on media usage statistics. For example, the usage fee amount can be determined as the price per view of the first media content (in US dollars) multiplied by the total number of views, which can be recorded on MaaS network 104 over a period of time. In embodiments, the usage fee amount can also be determined based on engagement metrics such as total playback time or number of interactions (e.g., the number of times the first media content is mentioned on social media platforms).

[0152] At 716, the stored second smart contract can be executed. In one embodiment, MaaS network 104 can be configured to execute the stored second smart contract on a first distributed ledger node (e.g., first MaaS node 126A). By executing the stored second smart contract, the provider of MaaS network 104 can initiate payment settlement to the content owner 722 of the first media content.

[0153] At 714, usage fee payments can be settled. In one embodiment, MaaS network 104 can settle usage fee payments for playing back the first media content with the content owner 722. MaaS network 104 can settle payments by executing a stored second smart contract based on update records associated with the first media content and usage fee payment rules that MaaS network 104 and content owner 722 can agree upon.

[0154] The system 102 of this disclosure can ensure the effective monetization of media content through real-time allocation, distribution, and / or payment settlement using smart contracts. Payments may include consumption-based payments to transportation service providers and providers of the MaaS network 104, or usage fees to content owners of the media content.

[0155] Figure 8 This is a flowchart illustrating an exemplary method for playback control of media content for devices across a MaaS transportation network according to embodiments of this disclosure. (Combined with...) Figure 1 , 2 Explanation of elements 1, 2, 3, 4, 5, 6, and 7 Figure 8 . refer to Figure 8 A flowchart 800 is shown. The method shown in flowchart 800 can be executed by any computing system, such as system 102 or circuit 202. The method can begin at 802 and proceed to 804.

[0156] At 804, trip details can be received. In one or more embodiments, circuit 202 can be configured to receive trip details associated with an ongoing trip for a user (e.g., user 114) from MaaS network 104. For example, circuit 202 can receive trip details for user 114 from a first distributed ledger node (e.g., first MaaS node 126A) of MaaS network 104. Figure 3 and 7 The document further describes the receipt of the itinerary details.

[0157] At 806, a first means of transportation can be determined. In one or more embodiments, circuit 202 can be configured to determine the first means of transportation (e.g., first means of transportation 112A), by which user 114 can be set to complete the first segment of an ongoing journey, such as, for example, in Figure 3 As described in [the text].

[0158] At 808, a media content recommendation group can be generated. In one or more embodiments, circuit 202 can be configured to generate the media content recommendation group based on the received trip details and the media consumption history associated with user 114, such as, for example... Figure 3 As described in [the text].

[0159] At point 810, the first display device can be controlled. In one or more embodiments, circuitry 202 can be configured to control the first display device (e.g., first display device 110A) to display the generated media content recommendation set. The first display device 110A can be used within a first vehicle 112A. For example, in... Figure 3 The document further describes the media content recommendation group generated by controlling the first display device 110A.

[0160] At 812, user selection can be received. In one or more embodiments, circuit 202 can be configured to receive user selection for a first media content recommendation in a group of displayed media content recommendations. The first media content recommendation may be associated with first media content selected for playback on the first display device 110A.

[0161] At point 814, playback of the first media content can be controlled. In one or more embodiments, circuit 202 can be configured to control playback of the first media content associated with the first media content recommendation on the first display device 110A.

[0162] At point 816, a first event can be detected. In one or more embodiments, circuitry 202 can be configured to detect a first event that may require pausing playback of the first media content during the duration of an ongoing process. Examples of the first event may include, but are not limited to, the completion of the first segment of activity in the process or receiving user input from user 114 that may instruct the pause of playback of the first media content.

[0163] At 818, playback of the first media content can be controlled to resume on a second display device used within the second vehicle (e.g., second vehicle 112B) and during the duration of a second segment of an ongoing trip or during the duration of a different trip for user 114. In one or more embodiments, circuitry 202 can be configured to control playback of the first media content on a second display device 110B used within the second vehicle 112B and during the duration of a second segment of an ongoing trip or during the duration of a different trip for user 114. For example, in Figure 6 The text further explains the control over the playback of the first media content on the second display device 110B.

[0164] Although flowchart 800 is illustrated as separate operations, such as 802, 804, 806, 808, 810, 812, 814, 816, and 818, this disclosure is not limited thereto. Therefore, in some embodiments, depending on the particular implementation, such separate operations may be further divided into additional operations, combined into fewer operations, or eliminated without departing from the essence of the disclosed embodiments.

[0165] Various embodiments of this disclosure may provide a non-transitory computer-readable medium and / or storage medium having instructions stored thereon that are executable by a machine and / or computer to operate an operating system (e.g., system 102). These instructions may cause the machine and / or computer to perform operations including receiving trip details associated with an ongoing trip of a user (e.g., user 114) from a Mobile-as-a-Service (MaaS) network (e.g., MaaS network 104). The operations may also include determining a first mode of transportation (e.g., first mode of transportation 112A) by which user 114 may be configured to complete a first segment of the ongoing trip. The operations may also include generating a group of recommended media content based on the received trip details and media consumption history associated with user 114. The operations may also include controlling a first display device (e.g., first display device 110A) to display the generated group of recommended media content. The first display device 110A may be used within the determined first mode of transportation 112A for the duration of the first segment of the activity. The operations may also include receiving a user selection of a first media content recommendation from the displayed group of recommended media content. The operation may also include controlling the playback of the first media content associated with the first media content recommendation on the first display device 110A. The operation may also include detecting a first event during the duration of an ongoing trip that may require pausing the playback of the first media content. The operation may also include controlling the playback of the first media content to resume on a second display device (e.g., second display device 110B) used within a second vehicle (e.g., second vehicle 112B) and during the duration of a second segment of an ongoing trip or during the duration of a different trip for user 114.

[0166] Exemplary aspects of this disclosure may provide a system including circuitry (e.g., circuitry 202) (e.g.) Figure 1System 102). The circuitry can be configured to receive trip details associated with an ongoing trip for a user (e.g., user 114) from a Mobile-as-a-Service (MaaS) network (e.g., MaaS network 104). Circuitry 202 can be configured to determine a first mode of transportation (e.g., first mode of transportation 112A) through which user 114 can be set to complete the first segment of the ongoing trip. Circuitry 202 can be configured to generate a group of recommended media content based on the received trip details and the media consumption history associated with user 114. Circuitry 202 can be configured to control a first display device (e.g., first display device 110A) to display the generated group of recommended media content. First display device 110A can be used within the determined first mode of transportation 112A for the duration of the first segment of the activity. Circuitry 202 can be configured to receive a user selection of a first media content recommendation in the displayed group of recommended media content. Circuitry 202 can be configured to control the playback of the first media content associated with the first media content recommendation on the first display device 110A. Circuit 202 can be configured to detect a first event that may require pausing playback of the first media content during the duration of an ongoing trip. Circuit 202 can be configured to control the playback of the first media content to resume on a second display device (such as second display device 110B) used within a second vehicle (such as second vehicle 112B) and during the duration of a second segment of an ongoing trip or during the duration of a different trip for user 114.

[0167] According to an embodiment, an ongoing trip can be divided into multiple segments, which will be covered by multiple vehicles (e.g., multiple vehicles 112A, 112B...112N) of at least one transportation service provider associated with MaaS network 104. The multiple vehicles 112A, 112B...112N may include a first vehicle 112A and a second vehicle 112B.

[0168] According to an embodiment, circuit 202 can be configured to receive a user profile and device specifications associated with the first display device 110A, the user profile including content preferences associated with user 114. According to an embodiment, a group of media content recommendations can be further generated based on the received user profile and device specifications.

[0169] According to an embodiment, circuit 202 can be configured to construct input features for a context-aware recommendation model trained on a media content recommendation task. The input features can be constructed based on one or more of received trip details, media consumption history, received user profiles, and device specifications. Circuit 202 can be further configured to input the constructed input features into the context-aware recommendation model and generate a set of recommendations as the output of the context-aware recommendation model for the input features.

[0170] According to an embodiment, circuit 202 can be configured to control first display device 110A based on a detected first event to display a first option to pause playback of first media content on first display device 110A and resume playback on second display device 110B during a second segment of the ongoing process. Circuit 202 can be configured to receive first user input including a selection of the displayed first option. Playback of the first media content can be further controlled to resume on second display device 110B based on the received first input.

[0171] According to an embodiment, each of the first display device 110A and the second display device 110B may be one of the following: the dashboard display of the first vehicle 112A and the second vehicle 112B respectively, the rear seat entertainment system of the first vehicle 112A and the second vehicle 112B respectively, the headrest display of the first vehicle 112A and the second vehicle 112B respectively, or the personal mobile device of the user 114 (e.g., display device 116).

[0172] According to an embodiment, circuit 202 can be configured to control second display device 110B to display a second option to resume playback of the first media content based on a determination that the second vehicle 112B may lack an in-vehicle display. The second display device 110B may be a personal mobile device of user 114 (e.g., display device 116). Circuit 202 can also be configured to receive second user input including a selection of the second option. Playback of the first media content can be further controlled to resume on the second display device 110B based on the received second input.

[0173] According to an embodiment, circuit 202 may be configured to control the playback of first media content to pause on the first display device 110A based on determining that the detected first event can indicate the end of the first active segment of the ongoing process.

[0174] According to an embodiment, circuit 202 can be configured to determine a timestamp for pausing playback of the first media content based on detected events throughout the entire duration of the first media content. Circuit 202 can be further configured to record the timestamp on a database (e.g., a distributed ledger child node 128 (e.g., a document child node 128C)).

[0175] According to an embodiment, playback of the first media content can be controlled to resume on the second display device 110B from a recorded timestamp.

[0176] According to an embodiment, circuit 202 can be configured to receive trip status associated with an ongoing trip from a first distributed ledger node (e.g., first MaaS node 126A) of MaaS network 104. Circuit 202 can be configured to detect a second event based on the received trip status, which may indicate that user 114 may be on second vehicle 112B to complete a second segment of the ongoing trip. Circuit 202 can be further configured to retrieve a timestamp of a record from a distributed ledger child node 128 (e.g., document child node 128C) based on the detected second event. Playback of the first media content can be controlled to resume on the second display device 110B from the retrieved timestamp.

[0177] According to an embodiment, circuit 202 can be configured to generate a transport stream including first media content based on the device specifications of the first display device 110A. Circuit 202 can also be configured to generate a series of blocks of the generated transport stream. Each block in the generated series of blocks may not overlap with other blocks in the generated series of blocks. Circuit 202 can be configured to store the generated series of blocks on a media server.

[0178] According to an embodiment, circuit 202 can be configured to send a service request, including a Quality of Service (QoS) requirement and a set of mobility network management functions, to a virtual network operator (e.g., virtual network operator 402). Virtual network operator 402 can receive the sent service request and, based on the received service request, send a network resource request to an infrastructure provider (e.g., infrastructure provider 404) associated with the mobile wireless network (e.g., communication network 108).

[0179] According to an embodiment, infrastructure provider 404 may create a virtual network (e.g., virtual network 406) to allocate network resources of a mobile wireless network (e.g., communication network 108) based on service requirements.

[0180] According to an embodiment, the created virtual network 406 can determine, during the duration of an ongoing trip, a first base station (e.g., first base station 408A) of a mobile wireless network (e.g., communication network 108) to which the first display device 110A can connect, to stream a first set of blocks from a series of blocks stored on a media server for playback on the first display device 110A. The created virtual network 406 can determine, based on trip route information associated with the ongoing trip, a second base station (e.g., second base station 408B) of a mobile wireless network (e.g., communication network 108) that the first display device 110A may connect to after switching from the first base station 408A. The created virtual network 406 can send a second set of blocks from the stored series of blocks to an edge computing device (e.g., edge computing device 410) associated with the second base station 408B before switching.

[0181] According to an embodiment, the edge computing device 410 can receive and cache the transmitted second block before the switch. After the switch, the edge computing device 410 can send the cached second block to the first display device 110A for playback of a portion of the first media content.

[0182] According to an embodiment, circuit 202 can be configured to collect first media consumption information associated with first media content on the first display device 110A and the second display device 110B during the duration of an ongoing process. Circuit 202 can also be configured to send a transaction message including the collected first media usage information to MaaS network 104. MaaS network 104 can be configured to receive the sent transaction message and update a record on a first distributed ledger node (e.g., first MaaS node 126A) of MaaS network 104. This record can be updated based on the received transaction message by executing a transaction on the first distributed ledger node (e.g., first MaaS node 126A). The updated record may include media usage statistics associated with the first media content from all users who may have viewed the first media content.

[0183] According to an embodiment, MaaS network 104 may store a first smart contract, which may store payment settlement rules agreed upon by the provider of MaaS network 104 and at least one transportation service provider associated with MaaS network 104 (e.g., first transportation service provider 720A and second transportation service provider 720B). MaaS network 104 may execute the stored first smart contract based on updated records associated with first media content to settle payments with the provider of MaaS network 104 and at least one transportation service provider (e.g., first transportation service provider 720A and second transportation service provider 720B).

[0184] According to one embodiment, MaaS network 104 may store a second smart contract, which may store royalty payment rules agreed upon by the provider of MaaS network 104 and the content owner of the first media content (e.g., content owner 722). MaaS network 104 may execute the stored second smart contract based on updated records associated with the first media content to settle royalty payments with content owner 722.

[0185] This disclosure can be implemented in hardware or a combination of hardware and software. It can be implemented centrally in at least one computer system or distributedly, wherein different components can be distributed across several interconnected computer systems. A computer system or other apparatus suitable for performing the methods described herein may be appropriate. The combination of hardware and software can be a general-purpose computer system having a computer program that, when loaded and executed, can control the computer system to perform the methods described herein. This disclosure can be implemented in hardware that includes a portion of an integrated circuit that also performs other functions.

[0186] This disclosure can also be embedded in a computer program product that includes all features enabling the implementation of the methods described herein and, when loaded into a computer system, the execution of those methods. In this context, a computer program represents any expression of a set of instructions in any language, code, or notation, which is intended to cause a system with information processing capabilities to directly perform a particular function, or to perform a particular function after one or both of: a) being translated into another language, code, or notation; or b) being reproduced in a different material form.

[0187] Although this disclosure has been described with reference to certain embodiments, those skilled in the art will understand that various changes can be made and equivalents can be substituted without departing from the scope of this disclosure. Furthermore, many modifications can be made to adapt a particular situation or material to the teachings of this disclosure without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the specific embodiments disclosed, but will include all embodiments falling within the scope of the appended claims.

Claims

1. A system comprising: The circuit is configured as follows: Receive trip details associated with the user's ongoing trip from the Mobile as a Service (MaaS) network; The first mode of transportation is determined, and through this first mode of transportation, the user is set to complete the first segment of the activity of the ongoing journey; Media content recommendation groups are generated based on the received trip details and the user's associated media consumption history; Control the first display device to display the generated media content recommendation group, wherein the first display device is used within the determined first vehicle during the duration of the first segment of the activity; Receive the user's selection of the first media content recommendation in the displayed media content recommendation group; Control the playback of first media content associated with the first media content recommendation on the first display device; Detect the first event requiring a pause in the playback of primary media content during the duration of the ongoing event; as well as Control the playback of the first media content to be resumed on a second display device used within the second vehicle and during the duration of a second segment of an ongoing journey or during the duration of a different journey for the user. The circuit is also configured to: When the second vehicle is near the first vehicle, the first vehicle is controlled to establish a communication link with the second vehicle via the Internet of Things, and the first display device is controlled to receive a set of cached blocks of first media content from the second vehicle or a second display device within the second vehicle.

2. The system according to claim 1, wherein The ongoing trip is divided into segments that will be covered by multiple modes of transportation through at least one transportation service provider associated with the MaaS network, and The multiple means of transportation include a first means of transportation and a second means of transportation.

3. The system according to claim 1, wherein, The circuit is also configured to receive a user profile and device specifications associated with a first display device, the user profile including content preferences associated with the user.

4. The system according to claim 3, wherein, The media content recommendation group is also generated based on the received user profile and device specifications.

5. The system of claim 3, wherein the circuit is further configured to: Construct input features for a context-aware recommendation model trained on a media content recommendation task. in, The input features are constructed based on one or more of the received trip details, media consumption history, received user profile, and device specifications. The constructed input features are then fed into the context-aware recommendation model; and The generated recommendation groups serve as the output of the context-aware recommendation model in response to the input.

6. The system of claim 1, wherein the circuit is further configured to: Based on the detected first event, control the first display device to display a first option to pause the playback of the first media content on the first display device and resume playback on the second display device during the second segment of the ongoing process; and Receive first user input, including selection of the first displayed option. It also controls the playback of the first media content based on the received first input to restore it on the second display device.

7. The system of claim 1, wherein each of the first display device and the second display device is one of the following: an instrument panel display of the first vehicle, a rear-seat entertainment system of the first vehicle, a headrest display of the first vehicle, and a user's personal mobile device.

8. The system of claim 1, wherein the circuit is further configured to: Based on the determination that the second vehicle lacks an in-vehicle display, the system controls the second display device to display a second option to restore playback of the first media content. The second display device is the user's personal mobile device; and Receive second user input, including the selection of a second option. It also controls the playback of the first media content based on the received second input to restore it on the second display device.

9. The system according to claim 1, wherein, The circuit is also configured to control the playback of the first media content to pause on the first display device based on determining that the detected first event indicates the end of the first active segment of the ongoing process.

10. The system of claim 1, wherein the circuit is further configured to: Determine the timestamp for pausing playback of the first media content based on detected events throughout its entire duration; and The timestamp is recorded in the database.

11. The system according to claim 10, wherein, Control the playback of the first media content to resume from the recorded timestamp on the second display device.

12. The system of claim 10, wherein the circuit is further configured to: Receive the process status associated with the ongoing process from the first distributed ledger node of the MaaS network; The second event is detected based on the received trip status, and the second event instructs the user to complete the second segment of the ongoing trip on a second vehicle; as well as The timestamp of the record is retrieved from the database based on the detected second event. The playback of the first media content is controlled to resume on the second display device from the retrieved timestamp.

13. The system of claim 1, wherein the circuit is further configured to: A delivery stream including first media content is generated based on the device specifications of the first display device; Generate a series of blocks from the generated transport stream. Each block in the generated series of blocks does not overlap with any other block in the same series; and The generated series of blocks are stored on the media server.

14. The system of claim 13, wherein the circuitry is further configured to send a service request to the virtual network operator including a Quality of Service (QoS) requirement and a set of mobility network management functions, wherein the virtual network operator: Receive the sent service request; and Based on the received service requests, a network resource request is sent to the infrastructure provider associated with the mobile wireless network.

15. The system according to claim 14, wherein, Infrastructure providers create virtual networks to allocate network resources for mobile wireless networks based on service requirements.

16. The system of claim 15, wherein the created virtual network: During the duration of the ongoing process, a first base station of a mobile wireless network to which the first display device is connected is determined to stream a first set of blocks from a series of blocks stored on a media server for playback on the first display device. The second base station to which the first display device may connect after switching from the first base station to the second base station is determined based on the trip route information associated with the ongoing trip. and Before the handover, the second set of blocks from the stored series of blocks is sent to the edge computing device associated with the second base station.

17. The system according to claim 16, wherein, The edge computing device: Receive the second block before the switch; The second block sent to the cache; and After the switch, the second cached block is sent to the first display device for playback of a portion of the first media content on the first display device.

18. The system of claim 1, wherein the circuit is further configured to: During the duration of the ongoing process, first media consumption information associated with first media content on the first and second display devices is collected; and Send a transaction message to the MaaS network including the collected first media usage information, wherein the MaaS network is configured as follows: Receive the sent transaction messages; and Update the records on the first distributed ledger node of the MaaS network. The record is updated by executing a transaction on the first distributed ledger node based on the received transaction message, and The updated records merge media usage statistics associated with the primary media content from all users who may have viewed it.

19. The system of claim 18, wherein the MaaS network: The system stores a first smart contract, which contains payment settlement rules agreed upon by the MaaS network provider and at least one transportation service provider associated with the MaaS network; and Based on the updated records associated with the first media content, the stored first smart contract is executed to settle payments with the MaaS network provider and the at least one transportation service provider.

20. The system of claim 18, wherein the MaaS network: The system stores a second smart contract, which contains the royalty payment rules agreed upon by the MaaS network provider and the content owner of the first media content; and Based on the updated records associated with the first media content, a stored second smart contract is executed to settle usage fee payments with the content owner.

21. A method comprising: In the system: Receive trip details associated with the user's ongoing trip from the Mobile as a Service (MaaS) network; The first mode of transportation is determined, and through this first mode of transportation, the user is set to complete the first segment of the activity of the ongoing journey; Media content recommendation groups are generated based on the received trip details and the user's associated media consumption history; Control the first display device to display the generated media content recommendation group, wherein the first display device is used within the determined first vehicle during the duration of the first segment of the activity; Receive the user's selection of the first media content recommendation in the displayed media content recommendation group; Control the playback of first media content associated with the first media content recommendation on the first display device; Detect the first event requiring a pause in the playback of primary media content during the duration of the ongoing event; as well as Control the playback of the first media content to be resumed on a second display device used within the second vehicle and during the duration of a second segment of an ongoing journey or during the duration of a different journey for the user. The method further includes: When the second vehicle is near the first vehicle, the first vehicle is controlled to establish a communication link with the second vehicle via the Internet of Things, and the first display device is controlled to receive a set of cached blocks of first media content from the second vehicle or a second display device within the second vehicle.

22. A non-transitory computer-readable medium storing computer-executable instructions thereon, the computer-executable instructions causing the system to perform operations when executed by a system, the operations including: Receive trip details associated with the user's ongoing trip from the Mobile as a Service (MaaS) network; The first mode of transportation is determined, and through this first mode of transportation, the user is set to complete the first segment of the activity of the ongoing journey; Media content recommendation groups are generated based on the received trip details and the user's associated media consumption history; Control the first display device to display the generated media content recommendation group, wherein the first display device is used within the determined first vehicle during the duration of the first segment of the activity; Receive the user's selection of the first media content recommendation in the displayed media content recommendation group; Control the playback of first media content associated with the first media content recommendation on the first display device; Detect the first event requiring a pause in the playback of primary media content during the duration of the ongoing event; as well as Control the playback of the first media content to be resumed on a second display device used within the second vehicle and during the duration of a second segment of an ongoing journey or during the duration of a different journey for the user. The operation also includes: When the second vehicle is near the first vehicle, the first vehicle is controlled to establish a communication link with the second vehicle via the Internet of Things, and the first display device is controlled to receive a set of cached blocks of first media content from the second vehicle or a second display device within the second vehicle.

Images