Playback control of media content across devices in a MAAS transport network

Abstract

A system and method for controlling playback of media content across devices in a MaaS transportation network is provided. The system receives details of a current ongoing trip from the MaaS network and determines a first vehicle in which to configure a user to complete an active first leg of the current ongoing trip. The system generates media content recommendations based on the trip details and controls a first display device used in the first vehicle to display such recommendations. The system receives a selection of the first content recommendation and controls playback of first media content associated with the selection on the first display device. The system detects an event requiring playback to be paused and controls playback to resume on a second display device used in a second vehicle during a second leg of the current ongoing trip or another trip.

Description

Technical Field

[0001] [Cross - Reference to Related Applications / Incorporation by Reference] None

[0002] Various embodiments of the present disclosure are related to Mobility - as - a - Service (MaaS) technology. Specifically, various embodiments of the present disclosure relate to systems and methods for controlling the playback of media content across devices in a MaaS transportation network.

Background Art

[0003] In the mobility space, there are various transportation service providers that offer ride - hailing services through one or more public or private means of transportation. Such providers can each offer services through an infrastructure that can be based on a closed - platform. For example, each of such mobility providers can have an individual ticketing infrastructure (e.g., ticketing gates and point - of - sale (PoS) devices) or individual applications (e.g., ticket reservation applications, ticketing applications, and ride - hailing applications) for trip creation, payment, or management. In some scenarios, a user may plan a trip involving services of different transportation providers. For example, a trip can include a taxi service covering the first leg of the journey and a subway service covering the remaining part of the journey. Conventionally, these two transportation providers can have closed and independent information technology (IT) infrastructures and IT operations from each other. As a result, shared services that provide benefits and hospitality to users throughout the trip period may not be available.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Those skilled in the art will appreciate the limitations and disadvantages of conventional and customary approaches by comparing the described system with some aspects of the present disclosure, which will be shown hereinafter with reference to the drawings in the remainder of this application. **Means for Solving the Problem**

[0005] Provide a system and method for playback control of media content across devices in a Mobility as a Service (MaaS) transportation network, substantially shown in at least one figure and / or described in relation to these figures, and further fully shown in the claims.

[0006] These and other features and advantages of the present disclosure can be understood by considering the following detailed description of the present disclosure with reference to the accompanying drawings, in which like elements are referred to by like reference numerals throughout. **Brief Description of the Drawings**

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

[0008] In a system and method for playback control of media content across a plurality of disclosed devices, implementations described below can be found. Such devices can be associated with a transportation service provider registered in a Mobility as a Service (MaaS) transport network. The disclosed system can be part of a federated transportation management system that enables multiple homogeneous or heterogeneous mobility providers and their infrastructure such as turnstiles, applications, and / or point-of-sale (PoS) devices to operate on the MaaS network to provide various mobility services. Each mobility provider enjoys secure data ownership and can control the joint use of related transaction data through a distributed ledger. This can enhance connectivity between various mobility providers.

[0009] Exemplary aspects of the present disclosure provide a system that can control the playback of first media content (such as audio content or video content) across devices used within a vehicle related to a user's current ongoing trip. The system can receive trip details related to the user's current ongoing trip from a MaaS network. For example, the current ongoing trip can be divided into segments that can be covered through a plurality of vehicles (such as a first vehicle and a second vehicle) of at least one transportation service provider associated with the MaaS network. The system can determine the first vehicle as the vehicle in which the user can be set to complete the active first segment of the current ongoing trip. The system can generate a series of media content recommendations based on the received trip details and the user's related media consumption history. Thus, the system can improve the user experience by providing customized media content to the user. Subsequently, the system can receive a user selection of the first media content recommendation via a first display device that can be used within the determined first vehicle. The system can control the playback of the media content related to the first media content recommendation on the first display device based on the user selection. The system can detect an event that may require pausing the playback of the media content during the period of the current ongoing trip. Examples of events can include, but are not limited to, the end of the active first segment of the current ongoing trip and user input to pause the playback of the media content. The system can control to resume the playback of the first media content on a second display device used within a second vehicle during the period of the second segment of the current ongoing trip or during the period of a different trip of the user. For example, the system can record a timestamp at which the playback of the first media content can be paused based on the detected event.The system can be controlled to resume playing the first media content from the recorded timestamp on a second display device used within a second leg of a current ongoing trip or within a different trip of the user, within a second vehicle.

[0010] The system enables seamless streaming and playback of media content on different display devices (in-vehicle displays or personal mobile devices) throughout the duration of one or more trips, so that the user can watch, pause, and resume playback of media content at any point during such trips. Such seamless streaming and playback of media content can be made available to the user even if the trip is covered through vehicles managed by different transportation service providers. The system of the present disclosure can ensure effective monetization of media content through real-time payment allocation, distribution, and / or settlement using smart contracts. Thus, the system of the present disclosure can ensure seamless and cost-efficient consumption of media content on display devices used throughout one or more trips in the MaaS transportation space.

[0011] FIG. 1 is a block diagram showing an exemplary network environment that enables playback control of media content across devices in a Mobility as a Service (MaaS) transportation network according to an embodiment of the present disclosure. FIG. 1 shows a network environment 100. The network environment 100 can include a system 102, a MaaS network 104, and a plurality of Mobility Provider (MP) servers 106. The plurality of MP servers 106 can include a first MP server 106A, a second MP server 106B, ..., and an Nth MP server 106N. The network environment 100 can further include a communication network 108. Further shown are a plurality of display devices that can include a first display device 110A, a second display device 110B, ..., and an Nth display device 110N. For example, as shown, the first display device 110A, the second display device 110B, ..., and the Nth display device 110N can 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 can collectively be referred to as a plurality of vehicles 112A, 112B... 112N. In at least one embodiment, one or more of the plurality of vehicles 112A, 112B... 112N may not have an in-vehicle display device. Further shown is a user 114 who can be associated with the display device 116.

[0012] The MaaS network 104 can be related to a publish-subscribe pattern. The MaaS network 104 can include a plurality of issuer nodes 118A, 118B,... 118N, a broker node device 120, and a plurality of subscriber nodes 122A, 122B... 122N. The MaaS network 104 can further include a plurality of Mobility Provider (MP) nodes 124A, 124B,... 124N of a first distributed ledger 124, and a plurality of MaaS nodes 126A, 126B... 126N of a second distributed ledger 126. Further, the MaaS network 104 can include a distributed ledger sub-node 128 including a driver sub-node 128A, a user sub-node 128B, and a document sub-node 128C. Further shown is a system 102 communicably coupled to the MaaS network 104 or the second distributed ledger 126 of the MaaS network 104.

[0013] In FIG. 1, the number of nodes in the MaaS network 104, the number of MP servers in the plurality of MP servers 106, the number of display devices 110A, 110B... 110N, and the number of vehicles 112A, 112B... 112N are shown only as an example and should not be construed as limiting the present disclosure. The present disclosure is applicable to a greater or fewer number of nodes, MP servers, display devices, and vehicles for the reproduction control of media content across devices in the MaaS transportation network without departing from its scope. For simplicity, FIG. 1 shows only N nodes of the MaaS network 104, N servers of the plurality of MP servers 106, N display devices 110A, 110B... 110N, and N vehicles 112A, 112B... 112N. However, in some embodiments, without limiting the scope of the present disclosure, there can be a greater or fewer number of nodes in the MaaS network 104, the number of servers of the plurality of MP servers 106, display devices 110A, 110B... 110N, and vehicles 112A, 112B... 112N. Further, one vehicle (such as the first vehicle 112A) can be associated with one mobility provider server (such as the first MP server 106A). Without limiting the scope of the present disclosure, one mobility provider server can be associated with a plurality of vehicles.

[0014] The system 102 can include suitable logic, circuitry, code, and / or interfaces configured to control the delivery of media content to various display devices accessible within the plurality of vehicles 112A, 112B... 112N during various legs of a trip. For example, if the user 114 starts playing a program during the first leg of a current trip, the playback can be paused and resumed during a subsequent leg of the same current trip or a different trip. Trips can be reserved through the MaaS transportation service and its fulfillment can be tracked and managed through the MaaS network 104.

[0015] In one embodiment, the system 102 can be an artificial intelligence (AI) system that includes a trained AI model (e.g., as shown in FIG. 2). The trained AI model can include one or more machine learning models, or one or more trained neural network models. The trained AI model of the system 102 can recommend a series of media contents for playback on various display devices of a plurality of vehicles 112A, 112B... 112N based on the travel details of the user 114, the media consumption history of the user 114, the user profile of the user 114, and / or the device specifications of various display devices.

[0016] Exemplary implementations of the system 102 include, but are not limited to, virtual machines (VMs) on a host machine, virtual runtime environments of containers or operating systems (OSs) on a host machine or server, containerized applications on a server, bare metal servers, cloud servers (such as private, public, or hybrid clouds), workstations, media servers, or any device having the ability to generate media content and stream it to a group of devices. In one embodiment, the system 102 can be implemented as a VM or a container on a server or a server node of a plurality of MP servers 106.

[0017] The MaaS network 104 can support standard communication specifications. The MaaS network 104 can include an issuer node (e.g., a ticket reader or a ride reservation application), a subscriber node, and at least one broker node device that conveys transaction messages from the issuer node to the subscriber node according to a publish-subscribe network protocol such as, but not limited to, a message queuing telemetry transport (MQTT)-based messaging protocol, an advanced message queuing protocol (AMQP)-based messaging protocol, or a message-oriented middleware (MOM)-based messaging framework. In at least one embodiment, the MaaS network 104 can include a distributed ledger that includes a ledger node for recording transactions related to various mobility services such as ticketing transactions for MaaS transportation services, media usage or consumption statistics, or payment settlements among various stakeholders such as content owners, transportation providers, or operators of the MaaS network 104.

[0018] The issuer nodes of all transportation service providers related to the MaaS network 104 can exchange data according to a standard or common communication protocol. The MaaS network 104 can include homogeneous issuer nodes that can comply with the MaaS standard communication specification. In one embodiment, the MaaS network 104 can also include heterogeneous issuer nodes that can comply with a dedicated communication protocol. The MaaS network 104 can provide plug-in-based support to the issuer nodes so that it can support such heterogeneous issuer nodes until each transportation service provider provides its support according to the MaaS standard communication specification.

[0019] The MaaS network 104 can enable issuer nodes associated with different transportation providers to participate in the MaaS network 104. The MaaS network 104 can provide bulk cluster management of issuer nodes through a node management device. All issuer nodes can comply with set protocols that enable operation on the MaaS network 104. The set protocols can mandate a common security architecture (for authentication and authorization of issuer nodes), network protocols (such as HTTP, MQTT, and AMQP), a unified data request or response format (such as JSON, CSV, XML formats), and an API / data schema. This can ensure that each issuer node complies with cluster-level configurations and device-level certificates (i.e., authentication credentials) (such as device profiles including company names, company IDs, gate IDs, and gate numbers). The patterns of cluster-level configurations and set protocols can facilitate the transportation provider to deploy new issuer nodes or replace existing issuer nodes in a plug-and-play manner. This can facilitate the MaaS network 104 to function as a homogeneous transportation network with interoperability among resources (such as issuer node devices) of various transportation providers.

[0020] Each of the plurality of issuer nodes 118A, 118B... 118N can include suitable logic, circuitry, code, and / or interfaces configured to operate as a ticket processing client for the transportation services of their respective transportation service providers. For example, each of the plurality of issuer nodes 118A, 118B... 118N can read, issue, recharge, or cancel tickets as a ticket processing client to create events related to their respective transportation services. Based on such events, transaction messages can be communicated to one or more subscriber nodes (such as a plurality of subscriber nodes 122A, 122B... 122N) of the MaaS network 104 via the broker node device 120. Examples of the plurality of issuer nodes 118A, 118B... 118N include, but are not limited to, consumer electronic devices having a travel planning or reservation application, ticket readers on turnstiles, ticket vending kiosks, point-of-sale (PoS) devices, mobile POS, ticket dispensers, and smart doors of transportation vehicles that can read tickets to start or end a journey.

[0021] Each of the plurality of subscriber nodes 122A, 122B... 122N can include suitable logic, circuitry, code, and / or interfaces configured to receive transaction messages from one or more of the plurality of issuer nodes 118A, 118B... 118N via the broker node device 120. Each transaction message can include a topic that one or more of the plurality of subscriber nodes 122A, 122B... 122N can subscribe to. Examples of subscriber node implementations include, but are not limited to, web servers, edge devices, edge nodes, cloud servers, cluster nodes of cloud-based servers, workstations, or any computer device having fog computing capabilities.

[0022] The first issuer node 118A among the plurality of issuer nodes 118A, 118B... 118N, and the first subscriber node 122A among the plurality of subscriber nodes 122A, 122B... 122N can be associated with a first transport provider. Other nodes such as the second issuer node 118B and the second subscriber node 122B can be associated with a first transport provider or a second transport provider that can be different from the first transport provider. Further, the first issuer node 118A can be associated with the first MP server 106A, the second issuer node 118B can be associated with the second MP server 106B, and so on for others.

[0023] The broker node device 120 can include suitable logic, circuitry, code, and / or interfaces configured to route transaction messages from issuer nodes (such as the first issuer node 118A) to subscriber nodes (such as the first subscriber node 122A). The decision to permit the broker node device 120 to route such transaction messages to subscriber nodes can be made by a server associated with the MaaS network 104 (not shown in FIG. 1). Exemplary implementations of the broker node device 120 can include, but are not limited to, application servers, cloud servers, mainframe servers, database servers, web servers, or other types of servers.

[0024] The broker node device 120 can be configured to communicate with each of the plurality of issuer nodes 118A, 118B ··· 118N and the plurality of subscriber nodes 122A, 122B ··· 122N through a suitable publish - subscribe network protocol such as, but not limited to, an MQTT - based messaging protocol, an AMQP - based messaging protocol, or a message - oriented middleware (MOM) - based messaging framework.

[0025] The plurality of MP nodes 124A, 124B, ... 124N can include suitable logic, circuitry, code, and / or interfaces configured to store transaction data related to respective mobility providers. For example, the first MP node 124A can store transaction data related to the first mobility provider. The transaction data can include records of user trips. Each trip can correspond to a MaaS transport service that can be provided by a first transport provider in at least one leg of the trip (e.g., related to the first MP server 106A). Each of the plurality of MP nodes can be referred to as a node of a first distributed ledger 124 capable of storing transaction data of various mobility providers of the MaaS network 104.

[0026] The plurality of MaaS nodes 126A, 126B, ... 126N can include suitable logic, circuitry, code, and / or interfaces configured to store transaction data related to all mobility providers of the MaaS network 104. The storage of transaction data related to each of the transport service providers can be used to settle payments between the transport service providers that provide transport services to the user. Each of the plurality of MaaS nodes 126A, 126B... 126N can correspond to a node of a second distributed ledger 126 capable of storing transaction data related to the MaaS network 104.

[0027] Each of the plurality of MP nodes 124A to 124N and each of the plurality of MaaS nodes 126A, 126B... 126N can be associated with the distributed ledger sub-node 128. For example, each of the first MP node 124A and the first MaaS node 126A can be associated with the driver sub-node 128A, the user sub-node 128B, and the document sub-node 128C of the distributed ledger sub-node 128. Further, each of the second MP node 124B and the second MaaS node 126B can be associated with the driver sub-node 128A, the user sub-node 128B, and the document sub-node 128C of the distributed ledger sub-node 128. Similarly, each of the Nth MP node 124N and the Nth MaaS node 126N can be associated with the driver sub-node 128A, the user sub-node 128B, and the document sub-node 128C of the distributed ledger sub-node 128. The driver sub-node 128A of the distributed ledger sub-node 128 can store driver profile information related to the mobility provider of the MaaS network 104. In one embodiment, the driver sub-node 128A can store an event timeline (or event tracking information) related to the driver. Exemplary information that can be included in the event timeline related to the driver includes, but is not limited to, a scorecard related to the driver, a profile related to the driver, behavior information related to the driver, and event contexts such as traffic information, the driver's behavior, and the driver's speech. The user sub-node 128B of the distributed ledger sub-node 128 can store user (or passenger) information related to the mobility provider of the MaaS network 104. In one embodiment, the user sub-node 128B can store an event timeline (or event tracking information) related to the user. Exemplary information that can be included in the event timeline related to the user includes, but is not limited to, user-specific settings and preferences (such as privacy settings).User-specific settings and preferences can help mobility providers and MaaS providers ensure compliance with rules such as data privacy standards, legal obligations, and the General Data Protection Regulation (GDPR) regarding the storage of user data in decentralized ledger nodes / sub-nodes. The document sub-node 128C of the decentralized ledger sub-node 128 can store log information related to the vehicles 112A, 112B...112N of the mobility providers in the MaaS network 104. Further, the document sub-node 128C can store notification information and messages generated based on one or more determined events related to the MaaS network 104. In certain embodiments, the document sub-node 128C can store a track ID (e.g., media content ID) related to media content that can be played or recommended for the user. The document sub-node 128C can further store a playback or resume ID related to a timestamp within the last played media content or the timestamp at which the playback of the media content was last paused, and a user ID related to the media content.

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

[0029] In one embodiment, at least two ledger nodes of each of the first distributed ledger 124 and the second distributed ledger 126 can store transaction data related to the MaaS transportation service. The MaaS transportation service can be related to one or more of a plurality of transportation providers and / or users 114 (e.g., passengers) who can utilize the MaaS transportation service through an integrated MaaS interface or a plurality of issuer nodes 118A, 118B... 118N. Transaction data related to the MaaS transportation service can be included in a series of state objects such as an initial state object and updated versions of the initial state object. Each state object can include a smart contract, contract code (or transaction rules agreed upon by the parties to the transaction), and state properties (which can be updated when the transaction data is updated based on transaction requests from the plurality of issuer nodes 118A, 118B... 118N).

[0030] In at least one embodiment, each of the first distributed ledger 124 and the second distributed ledger 126 can be a decentralized distributed database system that can maintain an immutable record of data operations or transaction records. A series of data operations can be grouped as blocks and further linked to previous data operation blocks to form a chain of multiple blocks. All data operation blocks can be stored in a decentralized manner such that at least two participants or nodes of each of the first distributed ledger 124 and the second distributed ledger 126 can store a subset of the multiple blocks related to one or more transactions in which these participants or nodes can participate. Further, each of the first distributed ledger 124 and the second distributed ledger 126 can include an operating system (e.g., Java Virtual Machine (JVM)) that can enable the deployment of smart contracts among multiple parties such as, for example, (a) mobility provider nodes and counterparty nodes (i.e., MaaS provider nodes) of a first transportation provider.

[0031] By way of example and not 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., Corda blockchain, Ethereum blockchain, or Hyperledger blockchain). Each of the first distributed ledger 124 and the second distributed ledger 126 can store a series of immutable state objects that the first distributed ledger 124 and the second distributed ledger 126 can track. The state objects can include a series of distributed ledger - compliant rules for different types of distributed ledger technologies. For example, the state objects can include transaction data such as smart contracts between parties, contract code (rules of the transaction), and content including state characteristics with certain state values. A smart contract can include a series of conditions that multiple parties to the smart contract can agree to interact with each other. The smart contract can be executed on one or more nodes of each of the first distributed ledger 124 and the second distributed ledger 126 and can manage transitions between state objects for generating transactions. The smart contract can be written once and reused for multiple state objects and can reference governing legal prose through cryptographic hashes.

[0032] Each of the first distributed ledger 124 and the second distributed ledger 126 can also use a secure cryptographic hash to identify parties and data and link state objects to previous versions of state objects to provide chains of provenance. The first distributed ledger 124 and the second distributed ledger 126 can store transactions between a group of parties so that only the relevant group of parties can view them. The parties associated with a transaction can store the current state object of that transaction in a vault (a database associated with each respective distributed ledger such as the first distributed ledger 124 and the second distributed ledger 126). Another party eligible to view or process a transaction (e.g., to verify the validity of the transaction) can retrieve the current state object of the transaction from the vault. Also, the state object of each of the first distributed ledger 124 and the second distributed ledger 126 can include a smart contract between the parties or nodes that can participate in the associated transaction.

[0033] In each of the first distributed ledger 124 and the second distributed ledger 126, a participant or a node (e.g., the first MP node 124A) can update a transaction by updating the state characteristics of an input state object (e.g., the first state object) to generate an output state object (e.g., the second state object). As a result, the updated transaction can form a provenance chain (which can be related to the transaction data). Each of the first distributed ledger 124 and the second distributed ledger 126 can agree on the updated transaction based on the determination of the validity of the updated transaction and the determination of the uniqueness of the updated transaction. In one embodiment, a participant of a node related to the updated transaction can determine the validity of the updated transaction by individually executing the smart contract and the validity confirmation logic related to the transaction. Further, the consensus nodes 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 there is no other transaction that has reached an agreement using the same input state object as the current transaction.

[0034] 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 can include a client-side interface (front-end) and a server-side interface (back-end). The decentralized application can be configured to implement a blockchain-related workflow (e.g., Corda flow) 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 at each of the plurality of subscriber nodes 122A, 122B... 122N and can be configured to encapsulate a client associated with the subscriber node. For example, the client-side interface of the decentralized application can be a Remote Procedure Call (RPC) client that can be configured on each subscriber node and counterparty node (i.e., MaaS provider node). The server-side interface of the distributed application can operate on nodes of each of the first distributed ledger 124 and the second distributed ledger 126 associated with the corresponding subscriber node and counterparty node.

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

[0036] In the case of multiple MaaS providers, an exemplary implementation can include multiple MaaS provider nodes, each of which can be associated with a specific MaaS provider and included in a separate distributed ledger for each MaaS provider. In some scenarios, multiple MaaS provider nodes can be included in a common distributed ledger such as the distributed ledger 126.

[0037] In one embodiment, the first MP node 124A and the first MaaS node 126A can be each one of a plurality of database nodes of the first distributed ledger 124 and the second distributed ledger 126, respectively, and can 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 can be configured to update an initial state object associated with the first distributed ledger 124 and the second distributed ledger 126, respectively, based on the transaction messages and output an updated state object. The first MP node 124A and the first MaaS node 126A can construct a transaction that can include an initial state object having initial transaction data and an updated state object having updated transaction data.

[0038] In one embodiment, the second distributed ledger 126 can also store travel details of one or more users (e.g., user 114) based on transaction messages received from one or more issuer nodes of the MaaS network 104. In one example, the transaction messages can include information related to the departure and destination of a user's (e.g., user 114) current ongoing trip, travel route information, the duration of the current ongoing trip, one or more legs of the current ongoing trip, the duration of each leg of the current ongoing trip, at least one transportation service provider, and details of a plurality of vehicles (e.g., a plurality of vehicles 112A, 112B ··· 112N) of at least one transportation service provider. The first distributed ledger node (e.g., the first MaaS node 126A) of the second distributed ledger 126 can send the travel details of the user (e.g., user 114) to the system 102.

[0039] In one embodiment, a second distributed ledger (e.g., including the first distributed ledger node, e.g., the first MaaS node 126A) can further store travel situations related to the ongoing travel of one or more users (e.g., user 114). The travel situations can include, but are not limited to, the active itinerary or ongoing itinerary of user 114's travel, the vehicle that user 114 can board to cover the active itinerary, and information related to the departure and destination related to the active itinerary. The first distributed ledger node (such as the first MaaS node 126A) can be configured to send the stored travel situations related to the ongoing travel of user 114 to the system 102.

[0040] The plurality of MP servers 106 can include suitable logic, circuitry, code, and / or interfaces configured to collectively manage trips and trip details related to a transportation service provider. For example, the first MP server 106A can be configured to manage trip details related to a first transportation service provider. The second MP server 106B can be configured to manage trip details related to a second transportation service provider. The Nth MP server 106N can be configured to manage trip details related to an Nth transportation service provider. Each of the plurality of MP servers 106 can be implemented as a cloud server and can execute operations through web applications, cloud applications, HTTP requests, repository operations, file transfers, and the like. Other implementation examples of each of the plurality of MP servers 106 include, but are not limited to, database servers, file servers, web servers, media servers, application servers, mainframe servers, or cloud computing servers. In at least one embodiment, each of the plurality of MP servers 106 can be implemented as a plurality of distributed cloud-based resources by using a plurality of techniques well known to those skilled in the art. In some embodiments, one or more of the plurality of MP servers 106 can be implemented within respective vehicles such as the first vehicle 112A, the second vehicle 112B,..., and the Nth vehicle 112N.

[0041] The communication network 108 can include a communication medium that enables each node of the MaaS network 104 to communicate with the plurality of MP servers 106 and the system 102. Further, the communication network 108 can include a communication medium that enables the system 102 to communicate with a plurality of display devices such as the first display device 110A, the second display device 110B, the Nth display device 110N, and the display device 116.

[0042] In an exemplary embodiment, the communication network 108 can include a mobile wireless network (such as shown in FIG. 4) that enables the system 102 to communicate with a plurality of display devices. In such a case, the mobile wireless network can be suitable for seamlessly transmitting media content and other information to such devices when different display devices (such as the first display device 110A and the second display device 110B) are being used within a vehicle (such as the first vehicle 112A and the second vehicle 112B) during a user 114's current ongoing trip or multiple legs of different trips.

[0043] Examples of the communication network 108 can include, but are not limited to, the Internet, a cloud network, a Wireless Fidelity (Wi-Fi) network, a Personal Area Network (PAN), a Local Area Network (LAN), or a Metropolitan Area Network (MAN), a mobile wireless network such as a Long-Term Evolution (LTE) network (e.g., a fourth-generation or fifth-generation (5G) mobile network). The various nodes of the MaaS network 104 can be configured to connect to the communication network 108 according to various wired or wireless communication protocols. Examples of such wired and wireless communication protocols can include, but are not limited to, Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, IEEE802.11, Light Fidelity (Li-Fi), 802.16, IEEE802.11s, IEEE802.11g, multi-hop communication, a wireless access point (AP), device-to-device communication, a cellular communication protocol, and at least one of the Bluetooth (BT) communication protocol.

[0044] The plurality of display devices can include a first display device 110A, a second display device 110B, ... and an Nth display device 110N. Each of such devices can include suitable logic, circuitry, and / or interfaces configured to display or render media content. In certain embodiments, at least one of such display devices can be an in-vehicle display of a vehicle (as one of a plurality of vehicles 112A, 112B... 112N). In another embodiment, at least one of such display devices can be a personal mobile device that a user 114 can carry throughout a travel period. Examples of such display devices can include, but are not limited to, an in-vehicle dashboard display, an in-vehicle rear seat entertainment device, an in-vehicle headrest display, or the personal mobile device of user 114.

[0045] Each of the first display device 110A, the second display device 110B, ... and the Nth display device 110N can include a display unit that can be implemented through at least one of a plurality of known technologies such as, but not limited to, a liquid crystal display (LCD) display, a light emitting diode (LED) display, a plasma display, or an organic LED (OLED) display technology, or other display devices. According to certain embodiments, the display unit of the display device can mean a display screen of a head-mounted device (HMD), a smart glasses device, a see-through display, a projection 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 can be a touch-responsive device that enables a user 114 to provide user input via the display device.

[0046] Each of the plurality of vehicles 112A, 112B, ..., 112N, such as the first vehicle 112A, the second vehicle 112B, ..., and the Nth vehicle 112N, can be owned, leased, or managed by a transportation service provider associated with the MaaS network 104. Each such vehicle can be provided as part of a public transportation service or a private transportation service. A trip can be divided into legs that can be covered through a plurality of vehicles 112A, 112B, ..., 112N (as one or more means of transportation) when a user 114 reserves a trip on the MaaS network 104. Examples of such means of transportation include, but are not limited to, trains, buses, cars, airplanes, taxis or cabs, trolleys, trams, ferries, high-speed trains, trucks, or motorcycles. Each of the plurality of vehicles 112A, 112B, ..., 112N can be associated with one of such means of transportation. In FIG. 1, a plurality of vehicles 112A, 112B, ..., 112N, such as the first vehicle 112A, the second vehicle 112B, and the Nth vehicle 112N, are depicted as cars, taxis, and trucks, but these are shown by way of example only and should not be construed as limiting the present disclosure. The present disclosure can also be applied to vehicles associated with other available public or private means of transportation.

[0047] The display device 116 can be the user 114's personal mobile device. The display device 116 can include suitable logic, circuitry, and / or interfaces configured to display or render media content. Exemplary implementations of the display device 116 include, but are not limited to, smartphones or cellular phones, audio players, wearable audio devices (such as headphones), smart wearable displays, tablets, laptop computers, or head-mounted displays. Further description of the display device 116 is omitted from the present disclosure for the sake of brevity. In some embodiments, the display device 116 can be a shared device within a transportation vehicle such as a bus or a train.

[0048] During operation, the system 102 can be configured to receive, from the MaaS network 104, travel details related to the user 114's current ongoing trip (as described, for example, in FIG. 3). Each of the first vehicle 112A, the second vehicle 112B, ... and the Nth vehicle 112N can be registered with a transportation service provider. The system 102 can determine the first vehicle 112A as the vehicle that can set the user 114 to complete the active first leg of the current ongoing trip.

[0049] The system 102 can generate a series of media content recommendations based on the received travel details and the media consumption history related to the user 114. In some embodiments, the series of media content recommendations can be further generated based on a user profile related to the user 114 and device specifications related to a display device (such as the first display device 110A).

[0050] The system 102 can control the first display device 110A to display the generated series of media content recommendations at any point during the period of the current ongoing trip. The first display device 110A can be used within the determined first vehicle 112A during the period of the active first leg of the current ongoing trip. The system 102 can receive a user selection of the first media content recommendation among the displayed series of media content recommendations. Details regarding the generation of the series of media content recommendations, the display of the series of media content recommendations, and the user selection of the media content recommendations are shown, for example, in FIG. 3.

[0051] System 102 can control the playback of first media content related to first media content recommendations on first display device 110A. System 102 can detect a first event that may require pausing the playback of the first media content at any point during the period of a currently ongoing trip (such as during the period of an active first leg of the trip). For example, the first event can be detected based on the end of the active first leg of the currently ongoing trip or user input to pause the playback of the first media content by user 114. System 102 can control to resume the playback of the first media content on second display device 110B during the period of a second leg of the currently ongoing trip or during the period of a different trip of user 114. When the playback is resumed, second display device 110B can be used within second vehicle 112B.

[0052] In some scenarios, a first media content or a portion of the first media content (such as chunks of a series of cached media streams) can be stored in a second vehicle 112B or a display device (e.g., a second display device 110B) within the second vehicle 112B, and further the second vehicle 112B can be physically close to the first vehicle 112A. In such a case, the first display device 110A and the second display device 110B can establish a communication link between each other based on the physical proximity of the first vehicle 112A and the second vehicle 112B, for example, via an Internet of Things (IoT) network (such as a vehicle-to-vehicle (V2V) network or a vehicle-to-everything (V2X) network). Accordingly, the first display device 110A can receive the first media content or chunks of a series of cached media streams from the second vehicle 112B or the second display device 110B. This method can be useful in the case of a handover (e.g., in a 5G cellular network), or when the network bandwidth of the communication network 108 is lacking. The first display device 110A can receive the first media content or chunks of a cached media stream from the second display device 110B associated with the second vehicle 112B. Similarly, the first display device 110A can receive other media content that was previously streamed or cached on the second display device 110B within the second vehicle 112B through an IoT network (such as a V2V network or a V2X network).

[0053] System 102 enables seamless streaming and playback of media content on different display devices (in-vehicle display or personal mobile device) throughout the duration of one or more trips, so that user 114 can view, pause, and then resume playback of media content at any point during such a trip. Such seamless streaming and playback of media content can be made possible for user 114 even if the trip is covered through vehicles managed by different transportation service providers. For example, system 102 can control the playback of the first media content to pause on the first display device 110A when the active first leg of the trip ends and resume on the second display device 110B when the second leg of the current ongoing trip or a different trip starts. Such control can be based on a user input via the first display device 110A to pause the playback and another user input via the second display device 110B to resume the paused playback.

[0054] FIG. 2 is a block diagram of an exemplary system for controlling playback of media content across devices in a MaaS transportation network according to an embodiment of the present disclosure. The description of FIG. 2 is made in relation to the elements of FIG. 1. FIG. 2 shows a block diagram 200 of system 102. System 102 can include a circuit 202, a memory 204, and a network interface 206. System 102 can further include an input / output (I / O) device 208. The memory 204 can include an AI model 204A.

[0055] Circuit 202 can include suitable logic, circuits, and interfaces configured to execute program instructions related to different operations executed by system 102. Circuit 202 can be implemented based on a number of processor technologies well-known in the art. Examples of processor technologies include, but are not limited to, 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, graphical processing units (GPU), and other processors.

[0056] Memory 204 can include suitable logic, circuits, and interfaces configured to store program instructions executable by circuit 202. Memory 204 can be configured to store travel details, user profiles, device specifications, and media consumption histories. Memory 204 can be further configured to store time stamps related to the pause of the playback of the first media content. Memory 204 can be further configured to store AI model 204A. Examples of implementations of memory 204 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 (SD) card.

[0057] The AI model 204A can be a classifier or a regression model that can be trained to identify the relationship between inputs (such as features in a training dataset that can include travel details, media consumption history, user profile data, device specifications, or a dataset of a series of media content) and output labels that can include a dataset of recommended media content classified from a series of media content. The AI model 204A can be defined by hyperparameters such as, for example, the number of weights, cost function, input size, and number of layers. The hyperparameters of the AI model 204A can be adjusted to update the weights so as to head towards the global minimum point of the cost function of the AI model 204A. The AI model 204A can be trained to output prediction / classification results for an input set after a plurality of training epochs based on the feature information in the training dataset. The prediction results can indicate the class labels of each input of the input set (for example, input features extracted from new / invisible instances).

[0058] The AI model 204A can include electronic data such as a software program executed by a processing device such as, for example, circuit 202, the code of a software program, a library, an application, a script, or other logic or instructions. The AI model 204A can include code and routines configured to enable a computer device such as circuit 202 to perform one or more operations of classifying one or more inputs (such as travel details, media consumption history, user profile data, device specifications, a series of media content) into recommended media content from a series of media content. In addition to or instead of this, the AI model 204A can also be implemented using hardware including a processor, a microprocessor (for example, one that performs or controls the execution of one or more operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). Alternatively, in some embodiments, a combination of hardware and software can be used to implement the AI model 204A.

[0059] Examples of the AI model 204A (such as one or more trained neural network models) include, but are not limited to, deep neural network (DNN), convolutional neural network (CNN), recurrent neural network (RNN), linear regression model, logistic regression model, decision tree model, K-means based model, or random forest model.

[0060] The I / O device 208 can include suitable logic, circuitry, and interfaces configured to receive input from a user and provide an output based on the received input. The I / O device 208, which can include various input and output devices, can be configured to communicate with the circuit 202. Examples of the I / O device 208 include, but are not limited to, a touch screen, keyboard, mouse, joystick, microphone, display device, and speaker.

[0061] The network interface 206 can include suitable logic, circuitry, code, and / or interfaces configured to facilitate communication between the circuit 202, the MaaS network 104, the plurality of MP servers 106, and the plurality of display devices via the communication network 108. The network interface 206 can be implemented using various known techniques that support wired or wireless communication between the system 102 and the communication network 108. The network interface 206 can include, but is not limited to, an antenna, radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a codec chipset, a subscriber identity module (SIM) card, or a local buffer circuit.

[0062] The 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). The wireless communication can use one or more of a plurality of 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), 5th generation networks such as 5G New Radio (NR) networks, Time Division Multiple Access (TDMA), Bluetooth, Wireless Fidelity (WiFi) (such as IEEE802.11a, IEEE 802.11b, IEEE 802.11g, or IEEE 802.11n), Voice over Internet Protocol (VoIP), Light Fidelity (Li-Fi), or Worldwide Interoperability for Microwave Access (Wi-MAX), protocols for email, instant messaging, and Short Message Service (SMS). The network interface 206 can communicate with a 5G communication network and includes suitable 5G support functions such as, but not limited to, 5G NR, V2X infrastructure, and 5G smart antennas.

[0063] Figure 3 is a block diagram showing exemplary operations for controlling the playback of media content across devices in a MaaS transportation network according to an embodiment of the present disclosure. The description of Figure 3 is made in relation to the elements of Figures 1 and 2. Figure 3 shows a block diagram 300 illustrating the exemplary operations 302 - 338 described herein. The exemplary operations shown in block diagram 300 can start at 302 and can be executed by any computer system, device, or apparatus such as the system 102 of Figure 1 or Figure 2. Although the exemplary operations related to one or more blocks of block diagram 300 are shown as discrete blocks, these can be further divided into additional blocks, combined into fewer blocks, or deleted depending on the implementation of the exemplary operations.

[0064] At 302, travel details can be received. In one embodiment, circuit 202 can be configured to receive travel details related to the current ongoing travel of user 114 from the MaaS network 104. In one embodiment, the received travel details can include context elements related to the current ongoing travel of user 114. Examples of travel details related to the current ongoing travel of user 114 include, but are not limited to, information corresponding to the departure and destination of the current ongoing travel, the duration of the current ongoing travel, information related to one or more legs of the current ongoing travel, the duration of each leg of the current ongoing travel, at least one transportation service provider related to the current ongoing travel, and details of the multiple vehicles used in the current ongoing travel. For example, such details can include the vehicle type or means of transportation related to each vehicle, and the transportation service type (private or public) related to each vehicle. In some cases, such details can also specify whether the vehicle includes an in - vehicle entertainment display.

[0065] At 304, a media consumption history can be received. In certain embodiments, circuit 202 can be configured to receive a media consumption history associated with user 114 from MaaS network 104. Examples of media consumption history include, but are not limited to, a user's viewing history of programs or shows, games, or other interactive content, a past viewing history of media content genres, the types of media content consumed over past trips, and logs listing specific times or media content consumption at specific destinations (such as times at home) or (such as in a vehicle or at home). Examples of types of media can include, for example, audio content, video content, audio-visual content related to specific genres of media content, audio-visual content related to preferred content lengths, game content, virtual reality (VR) or augmented reality (AR) content, and immersive 3D video.

[0066] At 306, a user profile can be received. In certain embodiments, circuit 202 can be configured to receive a user profile of user 114 from MaaS network 104. The user profile can include, for example, content preferences of user 114, 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 certain embodiments, the user profile can include details of travel destinations covered in a typical trip of user 114, the types of media content preferred by user 114, the types of vehicles preferred by user 114, the types of accounts (such as a paid subscription account) of user 114, and behavioral data points of user 114.

[0067] At 308, device specifications can be received. In one embodiment, circuit 202 can be configured to receive device specifications related to the first display device 110A from the MaaS network 104. The device specifications can 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.

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

[0069] In one embodiment, the context-aware recommendation model can be implemented as a machine learning model. Examples of machine learning models can 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.

[0070] In another embodiment, the context-aware recommendation model can be implemented as a neural network (NN) model. The NN model can be defined by hyperparameters such as, for example, the number of weights, cost function, input size, number of layers, and number of neurons per layer. During the training phase, the hyperparameters of the context-aware recommendation model can be adjusted and the weights updated to move towards the global minimum of the cost function. The context-aware recommendation model can be trained to output prediction / classification results for an input set after training for a plurality of epochs based on a training dataset. The prediction results can indicate the class labels (media content recommendations) for each input of the input set (e.g., input features extracted from a new / invisible instance).

[0071] The context-aware recommendation model can include electronic data such as a software program, code of a software program, library, application, script, or other logic or instructions, which is executed by a processing device such as circuit 202. The context-aware recommendation model can include code and routines configured to enable a computer device such as circuit 202 to perform one or more operations of classifying one or more inputs into a series of recommendations. In addition to or instead of this, the trained context-aware recommendation model can also be implemented using hardware including a processor, a microprocessor (e.g., one or more operations are performed or controlled), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). Alternatively, in some embodiments, a combination of hardware and software can be used to implement the trained context-aware recommendation model. In some embodiments, the context-aware recommendation model can be based on a hybrid architecture of multiple deep neural networks (DNNs).

[0072] At 312, a series of recommendations can be generated. In some embodiments, circuit 202 can be configured to generate a series of media content recommendations based on the received travel details and the media consumption history associated with user 114. The series of recommendations generated can include, but are not limited to, the type of media content preferred by user 114, the genre of media content based on previously played media content, or recommendations related to media content to be resumed. In some embodiments, circuit 202 can be further configured to generate a series of media content recommendations based further on the received user profile and device specifications. As an example, the series of media content recommendations generated can be related to, but are not limited to, media content such as thriller shows and horror shows. Such shows can be related to the genre or shows listed in the media consumption history or user profile.

[0073] In some embodiments, at least one of the series of media content recommendations generated can be generated based on a genre or media program that is considered popular among a particular user group, such as users within a particular age group. In another embodiment, at least one of the series of media content recommendations can be generated based on the preferences of other users having similar interests or a similar user profile compared to that of user 114.

[0074] In some embodiments, circuit 202 can build input features for a context-aware recommendation model. The input features can be built based on one or more of the received travel details, received media consumption history, received user profile, or received device specifications. Circuit 202 can then input the built input features into a (trained) context-aware recommendation model and generate a series of recommendations as the output of the context-aware recommendation model for the input features.

[0075] For example, the travel details can include the period of the ongoing travel of user 114 and information related to one or more vehicles that user 114 can use for the travel. The travel details can further include travel situations related to the ongoing travel (such as an identifier indicating the active itinerary of the ongoing travel). The media consumption history of user 114 can indicate the user's preferences regarding various content genres (such as thriller or horror) and preferred content formats (such as audio podcasts, video-on-demand (VOD) programs, or broadcast media content). Further, the media consumption history of user 114 can also list a series of programs that user 114 has previously watched during past travels.

[0076] The device specifications of a display device (e.g., the first display device 110A or a personal mobile device (e.g., the display device 116 of user 114)) can include, for example, screen size information, a series of supported display resolutions, and media format compatibility (such as related to the supported codec). Media content related to media content recommendations can conform to the device specifications (e.g., compatible screen resolutions and media formats).

[0077] At 314, model verification metrics can be generated. In certain embodiments, circuit 202 can be configured to generate model verification metrics. The model verification metrics can provide a quantitative measure of the accuracy with which a context-aware recommendation model can output media content recommendations for a given input to the context-aware recommendation model. As an example, circuit 202 can be configured to receive user input indicating a selection of a context-aware recommendation model. Circuit 202 can be configured to verify the context-aware recommendation model based on the user input. The model verification metrics can enable selection of a context-aware recommendation model from among various recommendation models that can be pre-trained for media content recommendation tasks. For example, such metrics can include a confusion matrix that describes the performance of the recommendation model with respect to test data.

[0078] At 316, an active first leg can be determined. In certain embodiments, circuit 202 can be configured to determine an active first leg of a currently ongoing trip. The currently ongoing trip can be divided into legs that may need to be covered through a plurality of vehicles (e.g., a plurality of vehicles 112A, 112B... 112N) of at least one transportation service provider associated with the MaaS network 104. The plurality of vehicles can include a first vehicle (e.g., first vehicle 112A) and a second vehicle (e.g., second vehicle 112B).

[0079] At 318, a first vehicle can be determined. In certain embodiments, circuit 202 can be configured to determine a first vehicle that can route user 114 to complete an active first leg of a currently ongoing trip.

[0080] At 320, a first display device (e.g., the first display device 110A) can be controlled. In certain embodiments, the circuit 202 can be configured to control the first display device 110A to display a generated series of media content recommendations. The first display device 110A can be used within a determined first vehicle 112A during an active first journey. Examples of the first display device 110A include, but are not limited to, the dashboard display of the first vehicle 112A, the rear seat entertainment device of the first vehicle 112A, the headrest display of the first vehicle 112A, or the personal mobile device of the user 114 (e.g., the display device 116). As an example, the first display device 110A can be controlled via the user interface (UI) of the personal mobile device if the first display device 110A can be connected to the personal mobile device (e.g., the display device 116).

[0081] At 322, a recommendation can be selected. In certain embodiments, the circuit 202 can be configured to receive a user selection of a first media content recommendation among a displayed series of media content recommendations. In certain embodiments, the context-aware recommendation model can be retrained based on the selection of the first media content.

[0082] At 324, a transport stream can be generated. In certain embodiments, the circuit 202 can be configured to generate a transport stream that includes first media content related to the first media content recommendation. In certain embodiments, the 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.

[0083] In 326, data stream chunking can be performed. In one embodiment, circuit 202 can be configured to perform a data stream chunking operation to generate a series of chunks of the generated transport stream. Each chunk of the generated series of chunks can be non-overlapping with other chunks of the generated series of chunks. The series of chunks can be generated in a form that allows the generated transport stream to be cached on a predicted edge network (such as an edge device associated with a base station of a mobile wireless network) where the first display device 110A is likely to connect during the course of a current trip.

[0084] In one embodiment, circuit 202 can be configured to store the generated series of chunks in media server 328. Media server 328 can control the playback of the first media content related to the first media content recommendation on the first display device 110A.

[0085] In 330, event-based playback can be controlled. In one embodiment, circuit 202 can be configured to detect a first event that may require pausing the playback of the first media content on the first display device 110A during the course of a current trip. Examples of the detected first event include, but are not limited to, the end of the travel itinerary, the end of the trip, pausing of media content based on user input, or the user looking away from the head or eyes from the first display device 110A. In one embodiment, circuit 202 can be further configured to control pausing the playback of the first media content on the first display device 110A based on the detection of the first event.

[0086] At 332, a media content identifier (ID) and a play / resume ID can be stored. In one embodiment, circuit 202 can be configured to determine a timestamp that can pause the playback of the first media content based on detected events within the entire duration of the first media content. Circuit 202 can further be configured to store a media content ID (e.g., a track ID that can identify the first media content and provide a location such as a uniform resource locator (URL) of the first media content) in the distributed ledger sub-nodes 128 (e.g., the document sub-node 128C and the user sub-node 128B). Further, circuit 202 can record this timestamp as a play / resume ID in a database such as the distributed ledger sub-node 128 (e.g., the document sub-node 128C). Circuit 202 can also store a user ID associated with user 114 in the distributed ledger sub-node 128 (e.g., the document sub-node 128C) together with the media content ID and the play / resume ID.

[0087] At 334, an (active) second leg can be determined. In one embodiment, circuit 202 can be configured to determine the second leg of the currently ongoing trip. In one scenario, the second leg can belong to the same trip as the trip of the first active leg. In another scenario, the second leg can belong to a different trip than the currently ongoing trip. Note that the second leg can or cannot follow immediately after the first active leg.

[0088] At 336, a second vehicle (e.g., the second vehicle 112B) can be determined. In one embodiment, circuit 202 can be configured to determine the second vehicle 112B that can configure user 114 to complete the second leg of the currently ongoing trip or the second leg of a different trip.

[0089] At 338, a second display device (e.g., the second display device 110B) can be controlled. In one embodiment, the circuit 202 can be configured to control the second display device 110B to display a generated series of media content recommendations. The second display device 110B can be used within the determined second vehicle 112B during the second leg. Examples of the second display device 110B include, but are not limited to, the dashboard display of the second vehicle 112B, the rear seat entertainment device of the second vehicle 112B, the headrest display of the second vehicle 112B, and the personal mobile device of the user 114 (e.g., the display device 116).

[0090] In one embodiment, the circuit 202 can be configured to control the first display device 110A to display a first option to pause the playback of the first media content on the first display device 110A based on the detected first event and resume the playback on the second display device 110B during the second leg. In one embodiment, the circuit 202 can be configured to receive a first user input including the selection of the displayed first option. In such a case, based further on the received first input, the playback of the first media content can be controlled to resume on the second display device 110B. Also, the playback of the first media content can be controlled to resume on the second display device 110B from the recorded timestamp (on the distributed ledger sub-node 128 (e.g., the document sub-node 128C)).

[0091] In one embodiment, the circuit 202 can be configured to control a second display device (e.g., the display device 116) to display a second option to resume playing the first media content based on a determination that the second vehicle 112B does not have an in-vehicle display. In such a case, the second display device can be the personal mobile device (e.g., the display device 116) of the user 114. The circuit 202 can be configured to receive a second user input including a selection of the second option. The playback of the first media content can be controlled to resume on the second display device (e.g., the display device 116) from the recorded timestamp based further on the received second input.

[0092] FIG. 4 is a block diagram showing an exemplary network environment for transmitting chunks of media content to a display device for seamless playback of the media content according to an embodiment of the present disclosure. The description of FIG. 4 is made in relation to the elements of FIGS. 1, 2, and 3. FIG. 4 shows a network environment 400. The network environment 400 includes a system 102, a virtual network operator 402, and an infrastructure provider 404. The network environment 400 can further include a virtual network 406 including a first base station 408A and a second base station 408B, an edge computer device 410, and a first display device 110A. The infrastructure provider 404 can manage the infrastructure of a mobile radio network 412 such as a fourth-generation or fifth-generation mobile network.

[0093] The virtual network operator 402 can be a network operator that resells network services and does not own or operate a telecommunications infrastructure. The virtual network operator 402 can provide network services based on a bandwidth license at a wholesale price from a telecommunications provider. The virtual network operator 402 can have one or more associated network devices including suitable logic, circuitry, code, and / or interfaces to perform the operations of the virtual network operator 402. The virtual network operator 402 can be configured to receive service requirements that the system 102 can transmit. The received service requirements can include service quality (QoS) requirements and a set of mobility network management functions. The QoS requirements can include, for example, but not limited to, a bandwidth of 100 megabits per second (Mbps), 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 can include, for example, but not limited to, information regarding mobility context management, location tracking, paging, reachability management, handover control, mobility anchoring, and path optimization.

[0094] Based on the received service requirements, the virtual network operator 402 can send network resource requests to an infrastructure provider 404 associated with a mobile radio network 412 (such as a 5G telecommunications network). The virtual network operator 402 can use the received service requirements to perform an analysis and send network resource requests to the infrastructure provider 404. For example, the virtual network operator 402 can perform an analysis to determine the amount of network resources (such as bandwidth, network channels, and network slices) available for communicating media content from the system 102 to any display device (such as the first display device 110A).

[0095] The infrastructure provider 404 can manage the network resources of a mobile radio network 412 (such as a 5G telecommunications network). The infrastructure provider 404 can include one or more associated network devices that can include suitable logic, circuitry, code, and / or interfaces configured to perform the operations of the infrastructure provider 404. The infrastructure provider 404 is configured to receive network resource requests from the virtual network operator 402. The resource controller of the infrastructure provider 404 can be configured to form a virtual network 406 in response to the received network resource request and allocate network resources of the mobile radio network 412 (such as a 5G telecommunications network) according to the service requirements of the received network resource request. The infrastructure provider 404 can also allocate new resources according to the service requirements, or adjust existing resources according to the service requirements. Therefore, the formed virtual network 406 can correspond to the resource allocation needs.

[0096] The virtual network 406 of the mobile radio network 412 (such as a 5G telecommunications network) can provide end-to-end customization capabilities to support various requirements for applications such as large-scale data management on the MaaS network 104 related to multiple transport service providers, as part of the network slicing function of the mobile radio network 412. Further, the mobility-driven network slicing of the mobile radio network 412 (such as a 5G telecommunications network) can support multiple network slices with different mobility management schemes. The mobility management scheme can be determined by the actually required level of mobility support from the mobile radio network 412 (such as a 5G telecommunications network). The mobility management scheme can be obtained by composing selected mobility management elementary functions. The virtual network 406 can be configured to reliably deliver infotainment application services to a display device (such as the first display device 110A) that can be used while moving within a vehicle (such as the first vehicle 112A) on a predicted route of a trip (reserved and managed via the MaaS network 104).

[0097] Each of the first base station 408A and the second base station 408B can include suitable logic, circuitry, code, and / or interfaces for wireless signal transmission and reception. Each of the first base station 408A and the second base station 408B can be a hub of 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 can be configured to transmit media content (e.g., the first media content) to a connected display device (such as the first display device 110A) via the virtual network 406.

[0098] The edge computer device 410 can include suitable logic, circuitry, and / or interfaces configured to cache such chunks of the transport stream of the first media content before the chunks are transmitted to the first display device 110A for playback of a portion of the first media content on the first display device 110A. Such chunks can be pre-cached before a network handover of the first display device 110A from the first base station 408A to the second base station 408B occurs. The edge computer device 410 can receive such chunks of the first media content from the system 102 via the virtual network 406.

[0099] The edge computer device 410 can include a computer device having storage capabilities and connectable to a network (e.g., an edge network). The edge network can include a plurality of switch or gateway devices located at an entry or exit point between networks and having computing capabilities to process or store information from a destination device such as the edge computer device 410. Details regarding the caching of chunks and the transmission of the cached chunks to the first display device 110A are described, for example, in FIG. 5.

[0100] A mobile radio network 412 (such as a 5G telecommunications network) can be an ultra-high density radio telecommunications network that can include a large number of base stations. As a result, frequent handovers and high handover delays can occur, which may cause communication failures that can affect the overall service quality of the mobile radio network 412. In one embodiment, Mobility Management as a Service (MMaaS) for the MaaS network 104 can suppress communication failures by configuring a handover policy using the travel route information of ongoing trips related to the MaaS network 104 and the application needs of the system 102. For example, the virtual network 406 can configure a handover policy by dynamically adjusting one or more handover control parameters (HCPs) based on the travel route information of the active first leg of the ongoing trip of the user 114.

[0101] In one embodiment, a broker node device 120 (which can be associated with the intelligent broker of the MaaS network 104) can be configured to determine a specific message routing policy for the transaction messages of the MaaS network 104 by calculating a probability-based score associated with various factors that can affect the transaction processing by the MaaS network 104. Thus, the selection of the message routing policy can be based on the calculated probability-based score that can be a trade-off of various factors related to the transaction processing of the MaaS network 104. Examples of such factors include, but are not limited to, systemic risk mitigation of the MaaS network 104, improvement of operations and system troubles related to the nodes of the MaaS network 104, cost-benefit for the users of the MaaS network 104 (e.g., price and / or benefit based on user preferences), and cost-benefit for the mobility providers and / or the organization executing the MaaS network 104. Examples of such factors further include, but are not limited to, traffic optimization related to the mobility providers of the MaaS network 104, energy consumption and carbon emissions related to the vehicles 112A, 112B... 112N of the mobility providers of the MaaS network 104, and time consumption of the users related to the transactions of the MaaS network 104. In one embodiment, the virtual network 406 can be further configured with a handover policy based on the selected message routing policy of the broker node device 120. As described, the selected message routing policy can be based on the calculated probability-based score that can be a trade-off between the various factors described above.

[0102] FIG. 5 is a sequence diagram showing an exemplary operation of transmitting a chunk of a transport stream of media content to a display device that plays the media content according to an embodiment of the present disclosure. The description of FIG. 5 is made in relation to the elements of FIGS. 1, 2, 3, and 4. FIG. 5 shows a sequence diagram 500 showing exemplary operations 502 to 520. The exemplary operations shown in sequence diagram 500 can start from 502 and can be executed by any computer system, device, or apparatus such as system 102, virtual network operator 402, infrastructure provider 404, virtual network 406, and edge computer device 410 of FIG. 1 or FIG. 2.

[0103] At 502, service requirements can be transmitted. In one embodiment, circuit 202 can be configured to transmit service requirements to virtual network operator 402. In one embodiment, virtual network operator 402 can be configured to receive the transmitted service requirements. The service requirements can include quality of service (QoS) requirements and a set of mobility network management functions. The QoS requirements can include, for example, but are not limited to, a bandwidth of 100 megabits per second (Mbps), 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 can include, for example, but are not limited to, information regarding mobility context management, location tracking, paging, reachability management, handover control, mobility anchoring, and path optimization. In one embodiment, the service requirements can be for transmitting first media content from system 102 to a display device such as first display device 110A via a 5G telecommunications network.

[0104] At 504, a network resource request can be sent. In certain embodiments, the virtual network operator 402 can be configured to send a network resource request to an infrastructure provider 404 associated with a mobile radio network 412 (such as a 5G telecommunications network) based on the received service requirements. In certain embodiments, the virtual network operator 402 can perform an analysis on the received service requirements and generate a network resource request based on this analysis.

[0105] At 506, network resources can be allocated. In certain embodiments, the infrastructure provider 404 can be configured to form a virtual network 406 and allocate network resources of the mobile radio network 412 (e.g., a 5G telecommunications network, e.g., communication network 108) in accordance with the service requirements. The allocation of network resources is further described, for example, in FIG. 4.

[0106] At 508, the first base station 408A can be determined. In one embodiment, the formed virtual network 406 is configured to determine the first base station 408A of the mobile radio network 412 to which the first display device 110A can connect in order to stream from the media server 328 a set of first chunks of a series of stored chunks for playback on the first display device 110A during the period of an ongoing trip. As an example, the virtual network 406 can store location information of a plurality of base stations associated with the virtual network 406. The virtual network 406 can receive the current location of the first vehicle 112A where the first display device 110A can be used. In one embodiment, the current location of the first vehicle 112A can be received from the first MP server 106A. The virtual network 406 is configured to determine the first base station 408A to which the first display device 110A can currently connect to stream the set of first chunks based on the stored location information of the plurality of base stations and the received current location of the first vehicle 112A.

[0107] At 510, the second base station 408B can be determined. In one embodiment, the formed virtual network 406 is configured to determine the second base station 408B of the mobile radio network 412 (such as a 5G telecommunications network) to which the first display device 110A is likely to connect after a handover from the first base station 408A based on travel route information related to the ongoing trip. In one embodiment, the virtual network 406 can receive travel route information related to the ongoing trip from the system 102. The virtual network 406 is configured to determine the second base station 408B based on the stored location information of the plurality of base stations and the received travel route information.

[0108] At 512, a set of second chunks can be transmitted. In certain embodiments, prior to handover, the formed virtual network 406 can be configured to transmit a set of second chunks of the stored series of chunks to the edge computer device 410 associated with the second base station 408B.

[0109] At 514, a set of second chunks can be cached. In certain embodiments, prior to handover, the edge computer device 410 can be configured to receive the transmitted set of second chunks and cache the received set of second chunks.

[0110] At 516, the cached set of second chunks can be transmitted. In certain embodiments, after handover, the edge computer device 410 can be configured to transmit the cached set of second chunks to the first display device 110A so that a portion of the first media content can be played on the first display device 110A.

[0111] As described, the edge computer device 410 can predictively cache a portion of the first media content (such as a set of second chunks of the media stream) before handover to the next base station. After handover to the next base station, the edge computer device 410 can transmit the cached portion of the first media content to a display device (e.g., the first display device 110A). Thus, by predictively caching a portion of the first media content in the edge computer device 410, communication disruptions that may occur during handover between base stations can be reduced and the delivery of media content can be optimized. The process described above can be repeated to pre-cache other portions of the first media content at other base stations where the first display device 110A is likely to connect during the period of the active first leg of the current ongoing trip. With the configured handover policy and use of the edge computer device 410, the first media content can be streamed seamlessly to any display device used during the period of the current ongoing trip.

[0112] In some scenarios, a first media content or a part of the first media content (such as a chunk of a series of cached media streams) can be stored in a second vehicle 112B or a display device (e.g., a second display device 110B) within the second vehicle 112B, and further the second vehicle 112B can be physically close to the first vehicle 112A. In such a case, the first display device 110A and the second display device 110B can establish a communication link between each other via, for example, an Internet of Things (IoT) network (such as a vehicle-to-vehicle (V2V) network or a vehicle-to-everything (V2X) network). Accordingly, the first display device 110A can receive the first media content or a chunk of a series of cached media streams from the second vehicle 112B or the second display device 110B. This method can be useful in cases of handover (e.g., in a 5G cellular network) or when there is a lack of network bandwidth. Similarly, the first display device 110A can also receive other media content that has been cached or previously streamed on the second display device 110B within the second vehicle 112B through an IoT network (such as a V2V network or a V2X network).

[0113] FIG. 6 is a diagram illustrating an exemplary scenario for the reproduction control of media content across devices in a MaaS transportation network according to an embodiment of the present disclosure. The description of FIG. 6 is made in relation to the elements of FIGS. 1, 2, 3, 4, and 5. FIG. 6 shows a scenario 600. The scenario 600 can include a representation 602 of the user 114's ongoing trip and a timeline 604 of the ongoing trip.

[0114] The ongoing trip can start from departure point A and end at destination D. The ongoing trip can be divided into three legs, such as a first leg 612 (between departure point A and first intermediate point B), a second leg 614 (between the first intermediate point B and second intermediate point C), and a third leg 616 (between the second intermediate point C and destination D). The three legs can be covered through a plurality of vehicles of at least one transportation service provider associated with the MaaS network 104. The plurality of vehicles can include a taxi 606, a train 608, and a bike 610.

[0115] During the period of the active first leg 612, circuit 202 can display a series of media content recommendations on the first display device 110A while the first display device 110A is being used within the taxi 606. Circuit 202 can receive a user selection of a first media content recommendation among the series of displayed media content recommendations at any point during the period of the active first leg 612. Circuit 202 can then control the playback of first media content associated with the first media content recommendation on the first display device 110A.

[0116] In some scenarios, a series of media content recommendations can include media content that was stored on or streamed on the user 114's display device 116 before the start of the active first leg 612. If the media content was played on the user 114's display device 116 up to a specific timestamp before the start of the active first leg 612, the circuit 202 can control the first display device 110A to prompt the user 114 to resume playing the media content from the same timestamp on the first display device 110A. In another scenario, the circuit 202 can control the display device 116 to display a series of media content recommendations even before the start of the first active leg 612 (e.g., while the user 114 is waiting for the taxi 606), or during the period between two legs of a trip (e.g., when the user 114 is waiting for the start of the second leg of the trip after the end of the first active leg 612). The circuit 202 can control the playback of the first media content on the display device 116 based on the selection of the first media content received from the user 114. The playback of the first media content on the display device 116 can be paused at a specific timestamp at the start of the first leg 612, and the circuit 202 can control the playback of the first media content to resume on the first display device 110A from the paused timestamp.

[0117] Circuit 202 can detect a first event that may require pausing the playback of the first media content during the period of the currently ongoing trip. The first event can include a user input for pausing the playback of the first media content (e.g., selection of the first option 624 on the first display device 110A). Circuit 202 can determine a first timestamp 618 at which it can pause the playback of the first media content based on the detected first event within the entire duration of the first media content. The first media content is paused, and circuit 202 can record the first timestamp 618 on the distributed ledger sub-node 128 (e.g., document sub-node 128C).

[0118] In one embodiment, the first display device 110A can include an image capture device. The first display device 110A can use the image capture device to capture multiple images of the user 114 while the user 114 is viewing the first media content on the first display device 110A. The first display device 110A can apply a line-of-sight (LoS) estimation technique to track the movement of the LoS of the user 114 in each of the multiple images of the user 114. The LoS can include the pose of the user 114's head and the direction of the eyes relative to a reference position. The first display device 110A can determine whether the user 114 is facing the first display device 110A at any given time based on the tracking of the LoS. In some scenarios, the first display device 110A can detect that the user 114 may be on a call based on the pose of the user 114's head and the direction of the eyes relative to a reference position, as well as the detection of a mobile phone near the user 114's ear or mouth in the multiple images of the user 114. When the first display device 110A determines that the LoS is away from the first display device 110A, or when it detects that the user 114 is on a call, the first display device 110A can 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 LoS of the user 114 is away from the first display device 110A, or when it detects that the user 114 is on a call, the first display device 110A can display a first option 624 that enables the user 114 to manually pause the playback of the first media content. The playback of the first media content is paused, and the circuit 202 can record a first time stamp 618 on the distributed ledger sub-node 128 (e.g., the document sub-node 128C).

[0119] In another scenario, the first display device 110A can receive user input from the user 114 for seeking the first media content. For example, this user input can indicate an instruction to rewind, fast forward, or skip a specific segment 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 seek the first media content to a new content playback timestamp. In response, the circuit 202 can record a timestamp corresponding to the (after movement) new content playback timestamp as the first timestamp 618 on the distributed ledger sub-node 128 (for example, the document sub-node 128C). In this way, the interruption type in the playback of media content can be suitably monitored. Examples of the interruption type in the playback of media content include, but are not limited to, automatic or manual stop of media content playback due to user inattention (such as when the user looks away from the first display device 110A or when the user is on a call), or manual seek of media content playback.

[0120] In another embodiment, the broker node device 120 can determine the failure of one or more transactions in the MaaS network 104 and predict the cause of failure of one or more transactions. The failure of one or more transactions can indicate a failure corresponding to a route associated with one or more transactions. Examples of such predicted failure causes include, for example, natural disasters (e.g., earthquakes, tsunamis, cyclones, storms, floods, volcanic eruptions), disasters (e.g., accidents at large intersections, pandemics / epidemics), or traffic disruptions (e.g., protest marches, traffic detours due to events / festivals, peak-hour traffic congestion). The broker node device 120 can also determine an alternative route associated with one or more transactions based on the determined failure of one or more transactions and the predicted cause of failure. The circuit 202 can be controlled to prompt the first display device 110A to display a prompt to the user 114 based on the predicted cause of failure and the determined alternative route. This prompt can indicate that there is a possibility that the current itinerary of the trip will be interrupted within a specific time (e.g., within a few minutes) due to the predicted cause of failure. The prompt can also indicate that the trip can be continued on the new itinerary of the alternative route. In such a case, the first display device 110A can be configured to automatically stop the playback of the first media content or to enable the user 114 to manually pause the playback of the first media content. Also in this case, the first media content is paused, and the circuit 202 can record the first timestamp 618 on the distributed ledger sub-node 128 (e.g., the document sub-node 128C).

[0121] In one embodiment, after the end of the first leg 612 of the trip and before the start of the second leg 614 (e.g., when user 114 gets out of taxi 606 and is waiting for train 608), the playback of the first media content can be resumed on the display device 116 of user 114. Circuit 202 can extract the first timestamp 618 from the distributed ledger sub-node 128 (e.g., document sub-node 128C) and control the display device 116 to resume the playback of the first media content from the extracted first timestamp 618. Further, the display device 116 can automatically stop the playback of the first media content before the start of the second leg 614 (e.g., at a predetermined time before the start of the second leg 614), or enable the user 114 to manually pause the playback of the first media content. Circuit 202 can store the current timestamp related to the playback of the first media content on the distributed ledger sub-node 128 (e.g., document sub-node 128C) as the first timestamp 618.

[0122] Circuit 202 can be controlled to resume playing the first media content on the second display device 110B that is in use within the train 608 during the second leg 614 of the journey. Circuit 202 can detect a second event that may require resuming the playback of the first media content at any point during the second leg 614. The second event can include a user input to resume the playback of the first media content (e.g., through selection of a second option 626 on the second display device 110B). Circuit 202 can retrieve the recorded first timestamp 618 from the distributed ledger sub-node 128 (e.g., the document sub-node 128C). From this retrieved first timestamp 618, the playback of the first media content can be resumed on the second display device 110B. Alternatively, circuit 202 can also control the second display device 110B to prompt the user 114 to provide a user input indicating a seek position within the first media content for which the user desires to resume the playback of the media content. Based on this user input indicating the seek position, the playback of the first media content can be resumed on the second display device 110B.

[0123] In another embodiment, circuit 202 can be configured to receive travel conditions related to the ongoing journey from a first distributed ledger node of the MaaS network 104 (e.g., the first MaaS node as shown in FIG. 7). Circuit 202 can detect a second event based on the received travel conditions, indicating that the user 114 may be on board a second vehicle 112B (such as the train 608) to cover the second leg 614 of the ongoing journey. Circuit 202 can retrieve the recorded first timestamp 618 from the distributed ledger sub-node 128 (e.g., the document sub-node 128C) based on the detected second event. From this retrieved first timestamp 618, it can be controlled to resume the playback of the first media content on the second display device 110B.

[0124] Circuit 202 can be controlled to temporarily stop the playback of the first media content on the second display device 110B based on the determination of a third event that can indicate the end of the active second leg 614 of the currently ongoing trip. Circuit 202 can determine a second timestamp 620 within the entire duration of the first media content, based on the detected third event, at which the playback of the first media content can be temporarily stopped. The playback of the first media content is temporarily stopped, and circuit 202 can record the second timestamp 620 on the distributed ledger sub-node 128 (e.g., the document sub-node 128C).

[0125] In an embodiment, circuit 202 can control the second display device 110B to display a notification that the active second leg 614 of the currently ongoing trip may be about to end. As a result, an alert can be issued to the user 114 to get off the train 608.

[0126] Circuit 202 can control the playback of the first media content on a display device associated with the bike 610 (e.g., the Nth display device 110N) during the third leg 616 of the trip. As shown, the third leg 616 can cover through the bike 610. In such a case, it may not be possible to view the first media content. Circuit 202 can detect a fourth event during the period of the currently ongoing trip, which may require restarting the playback of the first media content on the Nth display device 110N. The fourth event can include, for example, a user input to restart the playback of the audio content associated with the first media content.

[0127] Circuit 202 can retrieve the recorded second timestamp 620 from the distributed ledger sub-node 128 (e.g., the document sub-node 128C). From this retrieved second timestamp 620, the playback of the first media content (i.e., the audio content of the first media content) on the Nth display device 110N can be resumed. The audio content can be played throughout the active third leg 616 of the ongoing trip. Circuit 202 can, at any point, based on the determination of a fifth event indicating the end of the active third leg 616 of the ongoing trip or the end of the trip, control to temporarily stop the playback of the first media content (i.e., the audio content related to the first media content) on the Nth display device 110N. In another scenario, the fifth event can indicate the completion of the playback of the first media content (i.e., the audio content related to the first media content). In some embodiments, the audio content can be unrelated to the first media content. In such a case, the audio content can be, for example, a podcast, an audiobook, music or a piece of music, or the audio portion of another video content.

[0128] In one embodiment, circuit 202 can receive a user input from user 114 to resume playback of first media content on the user's personal computer device (e.g., display device 116) based on a determination that the Nth display device 110N associated with the bike 610 can only play audio content. For example, display device 116 can have the ability to play both the audio content and video content of the first media content. Circuit 202 can control display device 116 to resume playback of the first media content from the recorded second timestamp 620 based on the received user input to resume playback on display device 116. Thus, system 102 can enable seamless playback of the first media content across devices within the MaaS network 104.

[0129] In one embodiment, circuit 202 can receive media content playback settings related to the playback of first media content on first display device 110A during the period of the active first leg 612 of the currently ongoing trip. The media content playback settings can be received via user input from the first display device 110A. Examples of media content playback settings can include, but are not limited to, volume settings, display settings, and playback speed. Circuit 202 can store the received media content playback settings in distributed ledger sub-nodes 128 (e.g., document sub-node 128C and / or user sub-node 128B). Circuit 202 can retrieve the media content playback settings from the distributed ledger sub-nodes 128 (e.g., document sub-node 128C and / or user sub-node 128B) at the start or during another leg (e.g., second leg 614). When the first media content is played back on the second display device 110B, the retrieved media content playback settings can 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.

[0130] In one embodiment, a vehicle that a user 114 can ride in during a particular leg of a current trip can have a display device that can be part of a common in-vehicle infotainment system of the vehicle. For example, a first display device 110A can be part of the infotainment system of a taxi 606. The taxi 606 can also include one or more display devices other than the first display device 110A. In some cases, one or more display devices can also be part of the same infotainment system of the taxi 606. If the user 114 is regularly viewing first media content through a priority subscription model (e.g., is a premium member of a content provider that can provide the first media content), the circuit 202 can enable the user 114 to preferentially access the infotainment system therein if other users are present within the taxi 606. In such a case, the circuit 202 can control the playback of the first media content on the first display device 110A and can also control one or more functions of the infotainment system.

[0131] In one embodiment, a ticket related to a trip or a particular leg of a trip can include an offer, a promotional scheme, or a festive discount that can give the user 114 the right to access audio / video services related to the trip or the leg of the trip. In such a case, the user 114 may or may not be a subscriber to the audio / video services. The audio / video services can have tickets related to a trip or a leg of a trip pre-bundled therewith. In response thereto, the circuit 202 can provide these audio / video services (e.g., movies, television series, or online / web series) as one or more media contents within a series of recommended media contents that can be played back during the period of the trip or the leg of the trip.

[0132] In one embodiment, circuit 202 can monitor the state of each of a plurality of display devices (e.g., first display device 110A, second display device 110B, Nth display device 110N, and display device 116) that can be used during the period of a currently ongoing trip. Based on the state of each monitored display device, circuit 202 can determine first monitoring information indicating whether a certain display device among the plurality of display devices is malfunctioning. The first monitoring information can also indicate the period during which the display device is unused. In some scenarios, circuit 202 can perform a refund process or offer an offer through display device 116 based on the first monitoring information. As a result, the use of the display device can be optimized and the user cancellation rate can be reduced.

[0133] FIG. 6 shows the second leg 614 and the third leg 616 as legs of a single trip, but the scope of the present disclosure may not be limited in this way. In one embodiment, without departing from the scope of the present disclosure, the second leg 614 and / or the third leg 616 can be legs of a (single or multiple) trip that is different from the trip associated with the first leg 612. In FIG. 6, the first leg 612, the second leg 614, and the third leg 616 are shown as consecutive legs of a single trip. However, the present disclosure may not be limited in this way, and in some embodiments, without departing from the scope of the present disclosure, the second leg 614 can be any leg following the first leg 612, and the third leg 616 can be any leg following the second leg 614.

[0134] FIG. 7 is a sequence diagram showing an exemplary operation of a MaaS transportation network for payment settlement related to media use according to an embodiment of the present disclosure. The description of FIG. 7 is made in relation to the elements of FIGS. 1, 2, 3, 4, 5, and 6. FIG. 7 shows a sequence diagram 700 showing exemplary operations 702 to 718. The exemplary operations shown in sequence diagram 700 can start from 702 and can be executed by any computer system, device, or apparatus such as circuit 202 of system 102 in FIG. 2, MaaS network 104, first transportation service provider 720A, second transportation service provider 720B, and content owner 722.

[0135] At 702, first media consumption information can be collected. In an embodiment, circuit 202 can collect first media consumption information related to 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 period of a currently ongoing trip. The first media consumption information can include, but is not limited to, an identifier (such as a title) of the first media content selected by user 114 for playback, the duration of playback of the first media content, and the number of times the first media content has been viewed by user 114. The first media consumption information can further include, but is not limited to, the type and device specifications of each display device capable of playing the first media content, and the number of times the playback of the first media content can be paused and resumed.

[0136] At 704, a transaction message can be transmitted. In an embodiment, circuit 202 can transmit a transaction message that can include the collected first media usage information to MaaS network 104.

[0137] At 706, the first distributed ledger node can be updated. In certain embodiments, the MaaS network 104 is configured to receive the transmitted transaction message and can update a record on the first distributed ledger node of the MaaS network 104 (e.g., the first MaaS node 126A of the second distributed ledger 126). The record can be updated by executing a transaction on the first distributed ledger node (e.g., the first MaaS node 126A) based on the received transaction message. The updated record can aggregate media usage statistics related to the first media content from all users who may have viewed the first media content within a given period.

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

[0139] For example, the payment settlement rules can include scheduled automatic payment rules based on media usage statistics. The scheduled automatic payment rules can be related to configurable settlement models including payment settlement schedules at different intervals such as daily, weekly, bi-weekly, monthly, quarterly, or annual payments, although not limited thereto. In some cases, such rules can include the share (%) of the revenue of each of the provider of the MaaS network 104 and at least one transportation service provider (e.g., the first transportation service provider 720A and the second transportation service provider 720B). Such shares can be determined based on, for example, the duration or frequency of media viewing within the vehicles of each transportation service provider.

[0140] Media usage statistics can be used to settle payments for the use of media content during one or more trips managed by the MaaS network 104. Such payments can be settled between the (single or multiple) transport service provider(s) and the provider of the MaaS network 104. The provider of the MaaS network 104 can have a predetermined revenue sharing agreement with different transport service providers associated with the MaaS network 104. The MaaS network 104 can settle payments based on the predetermined revenue sharing agreement. For example, the MaaS network 104 can allocate 20% of the media usage revenue (determined based on the number of views and the duration of each view) to the provider of the MaaS network 104. The MaaS network 104 can evenly distribute the remaining media usage revenue among different transport service providers. Alternatively, the MaaS network 104 can also distribute the remaining media usage revenue among transport service providers in a ratio proportional to the travel distance or travel duration of the users logged by each transport service provider. Alternatively, the MaaS network 104 can also distribute the remaining media usage revenue among transport service providers in a ratio proportional to the total playback time logged for a particular transport service provider, the number of views recorded for a particular transport service provider, and / or the cost associated with the media content on each transport service provider.

[0141] 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 the first distributed ledger node (e.g., the 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 transport service provider (e.g., the first transport service provider 720A and the second transport service provider 720B).

[0142] In 712A and 712B, payments can be settled. In certain embodiments, the MaaS network 104 can be configured to settle payments for the playback of first media content between at least one transportation service provider (e.g., the first transportation service provider 720A and the second transportation service provider). The MaaS network 104 can settle payments by executing a stored first smart contract based on an updated record related to the first media content (at 706) and payment settlement rules that the provider of the MaaS network 104 and at least one transportation service provider can agree upon.

[0143] In 714, a second smart contract can be stored. In certain embodiments, the 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 royalty payment rules agreed upon by the provider of the MaaS network 104 and the content owner of the first media content (e.g., content owner 722). In certain embodiments, the royalty payment rules can determine the royalty amount for the content owner 722 based on media usage statistics. For example, the royalty amount can be determined as the price per viewing (in US dollars) × the total number of views of the first media content that can be recorded on the MaaS network 104 within a certain period. In certain embodiments, the royalty amount can be further determined based on engagement metrics such as total playback time or the number of interactions (such as the number of times the first media content has gone viral on a social media platform).

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

[0145] At 714, royalty payments can be settled. In some embodiments, the MaaS network 104 can settle royalty payments for the playback of the first media content with the content owner 722 of the first media content. The MaaS network 104 can settle the payment by executing the stored second smart contract based on the updated record related to the first media content and the royalty payment rules acceptable to the MaaS network 104 and the content owner 722.

[0146] The system 102 of the present disclosure can ensure effective monetization of media content through real-time payment allocation, distribution, and / or settlement using smart contracts. Payments can include consumption-based payments to the transportation service provider and the provider of the MaaS network 104, or royalty payments to the content owner of the media content.

[0147] FIG. 8 is a flowchart showing an exemplary method for controlling the playback of media content across devices in a MaaS transportation network according to an embodiment of the present disclosure. The description of FIG. 8 is made in relation to the elements of FIGS. 1, 2, 3, 4, 5, 6, and 7. FIG. 8 shows a flowchart 800. The method shown in the flowchart 800 can be executed by any computer system such as the system 102 or the circuit 202. The method can start at 802 and proceed to 804.

[0148] At 804, travel details can be received. In one or more embodiments, circuit 202 can be configured to receive travel details related to a user's (e.g., user 114) current ongoing trip from the MaaS network 104. For example, circuit 202 can receive travel details of user 114 from a first distributed ledger node (e.g., first MaaS node 126A) of the MaaS network 104. Receiving travel details is further described, for example, in FIGS. 3 and 7.

[0149] At 806, a first vehicle can be determined. In one or more embodiments, circuit 202 can be configured to determine a first vehicle (e.g., first vehicle 112A) that can set user 114 to complete an active first leg of a current ongoing trip, as described, for example, in FIG. 3.

[0150] At 808, a series of media content recommendations can be generated. In one or more embodiments, circuit 202 can be configured to generate a series of media content recommendations based on the received travel details and the media consumption history related to user 114, as described, for example, in FIG. 3.

[0151] At 810, a first display device can be controlled. In one or more embodiments, circuit 202 can be configured to control a first display device (e.g., first display device 110A) to display the generated series of media content recommendations. The first display device 110A can be used within the first vehicle 112A. Control of the first display device 110A to display the generated series of media content recommendations is further described, for example, in FIG. 3.

[0152] At 812, user selection can be received. In one or more embodiments, circuit 202 can be configured to receive a user selection of a first media content recommendation among a displayed series of media content recommendations. The first media content recommendation can be related to first media content selected for playback on the first display device 110A.

[0153] At 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 on the first display device 110A related to the first media content recommendation.

[0154] At 816, a first event can be detected. In one or more embodiments, circuit 202 can be configured to detect a first event that may require pausing the playback of the first media content during a period of a currently ongoing trip. Examples of the first event can include, but are not limited to, completion of an active first leg of the trip, or receiving a user input from user 114 that can indicate a command to pause the playback of the first media content.

[0155] At 818, playback of the first media content can be controlled to resume during a second leg of the currently ongoing trip or during a period of a different trip of user 114 on a second display device in use within a second vehicle (e.g., second vehicle 112B). In one or more embodiments, circuit 202 can be configured to control the playback of the first media content to resume during a second leg of the currently ongoing trip or during a period of a different trip of user 114 on the second display device 110B in use within the second vehicle 112B. Control for resuming the playback of the first media content on the second display device 110B is further described, for example, in FIG. 6. The control can proceed to termination.

[0156] Although flowchart 800 is shown as discrete operations such as 802, 804, 806, 808, 810, 812, 814, 816, and 818, the present disclosure is not so limited. Thus, in some embodiments, without detracting from the essence of the disclosed embodiments, such discrete operations can be further divided into additional operations, combined into fewer operations, or deleted, depending on a particular implementation.

[0157] Various embodiments of the present disclosure can provide a non-transitory computer-readable medium and / or storage medium storing instructions executable by a machine and / or computer to operate a system (such as system 102). These instructions can cause the machine and / or computer to perform operations including receiving travel details related to a user's (such as user 114) ongoing trip from a Mobility as a Service (MaaS) network (such as MaaS network 104). The operations can further include determining a first vehicle (such as first vehicle 112A) that can configure user 114 to complete an active first leg of the ongoing trip. The operations can further include generating a series of media content recommendations based on the received travel details and the user 114's media consumption history. The operations can further include controlling a first display device (such as first display device 110A) to display the generated series of media content recommendations. The first display device 110A can be used within the determined first vehicle 112A during the period of the active first leg. The operations can further include receiving a user selection of a first media content recommendation of the series of displayed media content recommendations. The operations can further include controlling the playback of the first media content associated with the first media content recommendation on the first display device 110A. The operations can further include detecting a first event that may require pausing the playback of the first media content during the period of the ongoing trip. The operations can further include controlling to resume the playback of the first media content on a second display device (such as second display device 110B) used within a second vehicle (such as second vehicle 112B) during the period of a second leg of the ongoing trip or during another trip of user 114.

[0158] Exemplary aspects of the present disclosure can provide a system (such as system 102 of FIG. 1) that includes a circuit (such as circuit 202). The circuit can be configured to receive travel details related to a user's (e.g., user 114) ongoing trip from a mobility as a service (MaaS) network (such as MaaS network 104). Circuit 202 can be configured to determine a first vehicle (such as first vehicle 112A) to set user 114 to complete an active first leg of the ongoing trip. Circuit 202 can be configured to generate a series of media content recommendations based on the received travel details and the user's 114 media consumption history. Circuit 202 can be configured to control a first display device (such as first display device 110A) to display the generated series of media content recommendations. The first display device 110A can be used within the determined first vehicle 112A during the period of the active first leg. Circuit 202 can be configured to receive a user selection of a first media content recommendation of the series of displayed media content recommendations. Circuit 202 can be configured to control the playback of the first media content related to 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 the playback of the first media content during the period of the ongoing trip. Circuit 202 can be configured to control to resume the playback of the first media content on a second display device (such as second display device 110B) used within a second vehicle (such as second vehicle 112B) during the period of a second leg of the ongoing trip or during another trip of user 114.

[0159] According to an embodiment, the ongoing trip can be divided into legs to be covered through a plurality of vehicles (such as a plurality of vehicles 112A, 112B... 112N) of at least one transportation service provider associated with the MaaS network 104. The plurality of vehicles 112A, 112B... 112N can include a first vehicle 112A and a second vehicle 112B.

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

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

[0162] According to an embodiment, circuit 202 can be configured to control the first display device 110A to pause the playback of the first media content on the first display device 110A based on the detected first event and display a first option to resume the playback on the second display device 110B in a second leg of the ongoing trip. Circuit 202 can be configured to receive a first user input that includes a selection of the displayed first option. The playback of the first media content can be controlled to resume on the second display device 110B further based on the received first input.

[0163] According to an embodiment, each of the first display device 110A and the second display device 110B can be any one of a dashboard display of the first vehicle 112A and the second vehicle 112B, a rear seat entertainment device of the first vehicle 112A and the second vehicle 112B, a headrest display of the first vehicle 112A and the second vehicle 112B, or a personal mobile device of the user 114 (for example, the display device 116).

[0164] According to an embodiment, the circuit 202 can be configured to control the second display device 110B to display a second option to resume playing the first media content based on a determination that the second vehicle 112B may not have an in-vehicle display. The second display device 110B can be a personal mobile device of the user 114 (for example, the display device 116). The circuit 202 can be further configured to receive a second user input including a selection of the second option. The playing of the first media content can be controlled to resume on the second display device 110B based on the received second input.

[0165] According to an embodiment, the circuit 202 can be configured to control to temporarily stop playing the first media content on the first display device 110A based on a determination that the detected first event may indicate the end of the first active journey of the current ongoing trip.

[0166] According to an embodiment, the circuit 202 can be configured to determine a time stamp at which the playing of the first media content can be temporarily stopped based on the detected event within the entire duration of the first media content. The circuit 202 can be further configured to record the time stamp on a database (for example, the distributed ledger sub-node 128 (for example, the document sub-node 128C)).

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

[0168] According to an embodiment, the circuit 202 can be configured to receive travel situations related to the ongoing trip from a first distributed ledger node (e.g., the first MaaS node 126A) of the MaaS network 104. The circuit 202 can be configured to detect a second event indicating that the user 114 may be riding in the second vehicle 112B to cover the second leg of the ongoing trip based on the received travel situations. The circuit 202 can be further configured to search for the recorded timestamp from the distributed ledger sub-node 128 (e.g., the document sub-node 128C) based on the detected second event. The playback of the first media content can be controlled to resume on the second display device 110B from the searched timestamp.

[0169] According to an embodiment, the 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. The circuit 202 can be further configured to generate a series of chunks of the generated transport stream. Each chunk of the generated series of chunks can be non-overlapping with other chunks of the generated series of chunks. The circuit 202 can be configured to store the generated series of chunks in a media server.

[0170] According to some embodiments, circuit 202 can be configured to send service requirements including quality of service (QoS) requirements and a set of mobility network management functions to a virtual network operator (e.g., virtual network operator 402). The virtual network operator 402 can receive the sent service requirements and, based on the received service requirements, send network resource requests to an infrastructure provider (e.g., infrastructure provider 404) associated with the mobile radio network (e.g., communication network 108).

[0171] According to some embodiments, infrastructure provider 404 can form a virtual network (e.g., virtual network 406) according to the service requirements and allocate network resources of the mobile radio network (e.g., communication network 108).

[0172] According to some embodiments, the formed virtual network 406 can determine a first base station (e.g., first base station 408A) of the mobile radio network (e.g., communication network 108) to which the first display device 110A can connect in order to stream a first set of chunks of a series of chunks stored on the media server for playback on the first display device 110A during the period of the ongoing trip. The formed virtual network 406 can determine a second base station (e.g., second base station 408B) of the mobile radio network (e.g., communication network 108) to which the first display device 110A is likely to connect after handover from the first base station 408A based on the trip route information associated with the ongoing trip. The formed virtual network 406 can send a second set of chunks of the series of chunks stored to an edge computer device (e.g., edge computer device 410) associated with the second base station 408B before handover. [[ID=IO]]

[0173] According to an embodiment, the edge computer device 410 can receive and cache the transmitted set of second chunks before handover. After handover, the edge computer device 410 can transmit the cached set of second chunks to the first display device so that a part of the first media content can be played on the first display device 110A.

[0174] According to an embodiment, the circuit 202 can be configured to collect first media consumption information related to the first media content on the first display device 110A and the second display device 110B during the period of the currently ongoing trip. The circuit 202 can further be configured to transmit a transaction message including the collected first media usage information to the MaaS network 104. The MaaS network 104 can receive the transmitted transaction message and can be configured to update a record on the first distributed ledger node (e.g., the first MaaS node 126A) of the MaaS network 104. The record can be updated by executing a transaction on the first distributed ledger node (e.g., the first MaaS node 126A) based on the received transaction message. The updated record can aggregate media usage statistics related to the first media content from all users who may have viewed the first media content.

[0175] According to an embodiment, the MaaS network 104 can store a first smart contract that can store payment settlement rules 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., the first transportation service provider 720A and the second transportation service provider 720B). Based on the updated record related to the first media content, the MaaS network 104 can execute the stored first smart contract to settle payments between the provider of the MaaS network 104 and at least one transportation service provider (e.g., the first transportation service provider 720A and the second transportation service provider 720B).

[0176] According to an embodiment, the MaaS network 104 can store a second smart contract that can store royalty payment rules agreed upon by the provider of the MaaS network 104 and the content owner of the first media content (e.g., the content owner 722). Based on the updated record related to the first media content, the MaaS network 104 can execute the stored second smart contract to settle royalty payments with the content owner 722.

[0177] The present disclosure can be implemented in hardware or in a combination of hardware and software. The present disclosure can be implemented in a centralized manner within at least one computer system, or in a distributed manner where different elements can be distributed across a plurality of interconnected computer systems. A computer system or other device adapted to execute the methods described herein may be suitable. A combination of hardware and software can be a general-purpose computer system including a computer program that can control the computer system to execute the methods described herein when loaded and executed. The present disclosure can be implemented in hardware including a part of an integrated circuit that also executes other functions.

[0178] The present disclosure includes all features enabling the implementation of the methods described herein, and can also be incorporated into a computer program product that can execute these methods when loaded into a computer system. A computer program in this context means any expression in any language, code, or notation of a set of instructions intended to cause a system with information processing capabilities to execute a specific function, either directly or after performing one or both of a) conversion to another language, code, or notation, and b) replication in a different content form.

[0179] Although the present disclosure has been described with reference to several 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 the present disclosure. Also, many modifications can be made to adapt a particular situation or content to the teachings of the present disclosure without departing from its scope. Accordingly, the present disclosure is not intended to be limited to the specific embodiments disclosed, but is intended to include all embodiments falling within the scope of the appended claims.

Description of Reference Numerals

[0180] 110A First display device 110B Second display device 110N Nth display device 600 Scenario 602 Representation of a journey 604 Timeline 606 Taxi 608 Train 610 Motorcycle 612 First journey 614 Second journey 616 Third journey 618 First timestamp 620 Second timestamp 622? 624 First option

Claims

1. Receiving travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network, Determining a first vehicle to configure the user to complete an active first leg of the current ongoing trip, Generating a series of media content recommendations based on the received travel details and the user's related media consumption history, Controlling a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations, Receiving a user selection of a first media content recommendation among the displayed series of media content recommendations, Controlling the playback of first media content related to the first media content recommendation on the first display device, Detecting a first event that requires pausing the playback of the first media content during the period of the current ongoing trip, Based on the detection of the first event, controlling the first display device to pause the playback of the first media content, During the period of a second leg of the current ongoing trip or during a different trip of the user, controlling to resume the playback of the first media content on a second display device used within a second vehicle, Comprising a circuit configured as such, The circuit is further configured to receive a user profile including content preferences related to the user and device specifications related to the first display device, Based on one or two or more of the received travel details, the media consumption history, the received user profile, and the device specifications, constructing input features for a context-aware recommendation model trained based on a media content recommendation task, Inputting the constructed input features into the context-aware recommendation model, Generating the series of media content recommendations as an output of the context-aware recommendation model for the input, Further configured as such, A system characterized by this.

2. The current ongoing trip is divided into legs to be covered through a plurality of vehicles of at least one transportation service provider related to the MaaS network, The plurality of vehicles includes the first vehicle and the second vehicle. The system according to claim 1.

3. The series of media content recommendations are further generated based on the received user profile and the device specifications. The system according to claim 1.

4. The circuit controls the first display device to display a first option for pausing the playback of the first media content on the first display device based on the detected first event and resuming the playback on the second display device in the second leg of the ongoing trip, receives a first user input including a selection of the displayed first option, and is further configured such that the playback of the first media content is controlled to resume on the second display device based on the received first user input. The system according to claim 1.

5. Each of the first display device and the second display device is one of the dashboard display of the first vehicle, the rear seat entertainment device of the first vehicle, the headrest display of the first vehicle, and the user's personal mobile device. The system according to claim 1.

6. The circuit controls the second display device, which is the user's personal mobile device, to display a second option for resuming the playback of the first media content based on a determination that the second vehicle does not have an in-vehicle display, receives a second user input including a selection of the second option, and is further configured such that the playback of the first media content is controlled to resume on the second display device based on the received second user input. The system according to claim 1.

7. The circuit is further configured to control the playback of the first media content on the first display device to pause based on a determination that the detected first event indicates the end of the active first leg of the ongoing trip. The system according to claim 1.

8. The circuit determines a time stamp at which the playback of the first media content is paused based on the detected first event within the entire duration of the first media content. Record the time stamp in a database The system according to claim 1, further configured as such

9. The playback of the first media content is controlled to resume on the second display device from the recorded time stamp The system according to claim 8

10. The circuit Receives travel situations related to the ongoing trip from a first distributed ledger node of the MaaS network Based on the received travel situations, detects a second event indicating that the user is on board the second vehicle to cover the second leg of the ongoing trip Based on the detected second event, searches the database for the recorded time stamp Further configured as such The playback of the first media content is controlled to resume on the second display device from the retrieved time stamp The system according to claim 8

11. The circuit Generates a transport stream including the first media content based on the device specifications of the first display device Generates a series of chunks of the generated transport stream, where each chunk does not overlap with other chunks of the series Stores the generated series of chunks in a media server The system according to claim 1, further configured as such

12. The circuit is further configured to send service requirements including quality of service (QoS) requirements and a series of mobility network management functions to a virtual network operator, and the virtual network operator Receives the sent service requirements Based on the received service requirements, sends a network resource request to an infrastructure provider related to the mobile wireless network The system according to claim 11

13. The infrastructure provider forms a virtual network and allocates network resources of the mobile wireless network according to the service requirements The system according to claim 12

14. The formed virtual network During the period of the ongoing trip, to stream a first set of chunks of the series of stored chunks on the media server so that it can be played on the first display device, determine a first base station of the mobile wireless network to which the first display device is connected, Based on the travel route information related to the ongoing trip, determine a second base station of the mobile wireless network to which the first display device is likely to connect after handover from the first base station, Before the handover, transmit a second set of chunks of the series of stored chunks to an edge computer device associated with the second base station, The system according to claim 13.

15. The edge computer device, Before the handover, receive the transmitted second set of chunks, Cache the transmitted second set of chunks, After the handover, transmit the cached second set of chunks to the first display device so that a part of the first media content can be played on the first display device, The system according to claim 14.

16. The circuit, During the period of the ongoing trip, collect first media consumption information related to the first media content on the first display device and the second display device, Transmit a transaction message including the collected first media consumption information to the MaaS network, Is further configured such that the MaaS network, Receives the transmitted transaction message, Updates a record on a first distributed ledger node of the MaaS network, Is configured such that, The record is updated by executing a transaction on the first distributed ledger node based on the received transaction message, The updated record aggregates media usage statistics related to the first media content from all users who have viewed the first media content, The system according to claim 1.

17. The MaaS network, Store a first smart contract that stores payment settlement rules agreed upon by the provider of the Maas network and at least one transportation service provider associated with the Maas network, Based on the updated record related to the first media content, execute the stored first smart contract to settle payments between the provider of the Maas network and the at least one transportation service provider, The system according to claim 16.

18. The Maas network, Store a second smart contract that stores royalty payment rules agreed upon by the provider of the Maas network and the content owner of the first media content, Based on the updated record related to the first media content, execute the stored second smart contract to settle royalty payments with the content owner, The system according to claim 16.

19. Receive travel details related to a user's ongoing trip from a Mobility as a Service (Maas) network, Determine a first vehicle that sets the user to complete an active first itinerary of the ongoing trip, Generate a series of media content recommendations based on the received travel details and the user's media consumption history, Control a first display device used within the determined first vehicle during the period of the active first itinerary to display the generated series of media content recommendations, Receive a user selection of a first media content recommendation from the displayed series of media content recommendations, Control the playback of the first media content related to the first media content recommendation on the first display device, Detect a first event that requires pausing the playback of the first media content during the period of the ongoing trip, Based on the detection of the first event, control the first display device to pause the playback of the first media content, During the period of the second leg of the current ongoing trip or during a different trip of the user, control to resume playback of the first media content on a second display device used within a second vehicle. Comprising a circuit configured as such. The circuit is, Based on a determination that the second vehicle does not have an in-vehicle display, control the second display device, which is the user's personal mobile device, to display a second option for resuming the playback of the first media content. Receive a second user input including selection of the second option. Further configured as such. The playback of the first media content is controlled to resume on the second display device further based on the received second user input. A system characterized by this.

20. Receive trip details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network, Determine a first vehicle that sets the user to complete an active first leg of the current ongoing trip, Generate a series of media content recommendations based on the received trip details and the media consumption history associated with the user, Control a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations, Receive a user selection of a first media content recommendation among the displayed series of media content recommendations, Control the playback of the first media content related to the first media content recommendation on the first display device, Detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip, Based on the detection of the first event, control to pause the playback of the first media content on the first display device, During the period of the second leg of the current ongoing trip or during a different trip of the user, control to resume playback of the first media content on a second display device used within a second vehicle. Comprising a circuit configured as such. The circuit is, Determine a timestamp at which the playback of the first media content is paused within the entire duration of the first media content based on the detected first event, Record the timestamp in a database, Receive travel situations related to the current ongoing trip from a first distributed ledger node of the MaaS network, Detect a second event indicating that the user is in the second vehicle to cover the second leg of the current ongoing trip based on the received travel situations, Search for the recorded timestamp from the database based on the detected second event, Further configured to be, The playback of the first media content is controlled to resume on the second display device from the searched timestamp, A system characterized by this.

21. Receive travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network, Determine a first vehicle that sets the user to complete the active first leg of the current ongoing trip, Generate a series of media content recommendations based on the received travel details and the media consumption history related to the user, Control a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations, Receive a user selection of a first media content recommendation among the displayed series of media content recommendations, Control the playback of the first media content related to the first media content recommendation on the first display device, Detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip, Control to pause the playback of the first media content on the first display device based on the detection of the first event, Control to resume the playback of the first media content on a second display device used within a second vehicle during the period of the second leg of the current ongoing trip or during a different trip of the user, Comprising a circuit configured as such, The circuit is, Generate a transport stream including the first media content based on the device specifications of the first display device, Generate a series of chunks of the generated transport stream, where each chunk does not overlap with other chunks of the series of chunks, Store the generated series of chunks in a media server, Further configured as, A system characterized by this.

22. Receive travel details related to the user's current ongoing trip from a Mobility as a Service (MaaS) network, Determine a first vehicle that sets the user to complete the active first itinerary of the current ongoing trip, Generate a series of media content recommendations based on the received travel details and the media consumption history related to the user, Control the first display device used within the first vehicle during the period of the active first itinerary to display the generated series of media content recommendations, Receive a user selection of a first media content recommendation among the displayed series of media content recommendations, Control the playback of the first media content related to the first media content recommendation on the first display device, Detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip, Based on the detection of the first event, control the first display device to pause the playback of the first media content, Control to resume the playback of the first media content on a second display device used within a second vehicle during the period of the second itinerary of the current ongoing trip or during a different trip of the user, Comprising a circuit configured as, The circuit is, During the period of the current ongoing trip, collect first media consumption information related to the first media content on the first display device and the second display device, Transmit a transaction message including the collected first media consumption information to the MaaS network, Further configured as, and the MaaS network is, Receive the transmitted transaction message, Updating a record on a first distributed ledger node of a MaaS network, configured as, wherein the record is updated by executing a transaction on the first distributed ledger node based on the received transaction message, and the updated record aggregates media usage statistics related to the first media content from all users who have viewed the first media content, characterized by a system.

23. In a system, receiving travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network, determining a first vehicle to configure the user to complete an active first itinerary of the current ongoing trip, generating a series of media content recommendations based on the received travel details and the user's media consumption history, controlling a first display device used within the determined first vehicle during the period of the active first itinerary to display the generated series of media content recommendations, receiving a user selection of a first media content recommendation among the displayed series of media content recommendations, controlling playback of the first media content related to the first media content recommendation on the first display device, detecting a first event that requires pausing the playback of the first media content during the period of the current ongoing trip, controlling to pause the playback of the first media content on the first display device based on the detection of the first event, controlling to resume playback of the first media content on a second display device used within a second vehicle during the period of a second itinerary of the current ongoing trip or during a different trip of the user, receiving a user profile including content preferences related to the user and device specifications related to the first display device, Constructing input features for a context-aware recommendation model trained based on a media content recommendation task based on one or more of the received travel details, the media consumption history, the received user profile, and the device specifications; Inputting the constructed input features into a context-aware recommendation model; Generating the series of media content recommendations as an output of the context-aware recommendation model for the input; A method characterized by including the above.

24. In a system, Receiving travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network; Determining a first vehicle for setting the user to complete an active first leg of the current ongoing trip; Generating a series of media content recommendations based on the received travel details and the media consumption history related to the user; Controlling a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations; Receiving a user selection of a first media content recommendation among the displayed series of media content recommendations; Controlling playback of the first media content related to the first media content recommendation on the first display device; Detecting a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; Based on the detection of the first event, controlling to pause the playback of the first media content on the first display device; During the period of a second leg of the current ongoing trip or during a different trip of the user, controlling to resume playback of the first media content on a second display device used within a second vehicle; Based on a determination that the second vehicle does not have an in-vehicle display, controlling the second display device, which is the user's personal mobile device, to display a second option for resuming the playback of the first media content; Receiving a second user input including a selection of the second option; comprising, the playback of the first media content is controlled to resume on the second display device further based on the received second user input, A method characterized by the above.

25. In a system, receiving travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network; determining a first vehicle that sets the user to complete an active first itinerary of the current ongoing trip; generating a series of media content recommendations based on the received travel details and the user's related media consumption history; controlling a first display device used within the determined first vehicle during the period of the active first itinerary to display the generated series of media content recommendations; receiving a user selection of a first media content recommendation among the displayed series of media content recommendations; controlling the playback of the first media content related to the first media content recommendation on the first display device; detecting a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; controlling to pause the playback of the first media content on the first display device based on the detection of the first event; controlling to resume the playback of the first media content on a second display device used within a second vehicle during the period of a second itinerary of the current ongoing trip or during a different trip of the user; determining a timestamp at which the playback of the first media content is paused based on the detected first event within the entire duration of the first media content; recording the timestamp in a database; receiving travel status related to the current ongoing trip from a first distributed ledger node of the MaaS network; detecting a second event indicating that the user is on board the second vehicle to cover the second itinerary of the current ongoing trip based on the received travel status; Searching for the recorded timestamp from the database based on the detected second event; including; the playback of the first media content is controlled to resume on the second display device from the searched timestamp; A method characterized by the above. **Claim 26** In a system, Receiving travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network; Determining a first vehicle for setting the user to complete an active first itinerary of the current ongoing trip; Generating a series of media content recommendations based on the received travel details and the user's related media consumption history; Controlling a first display device used within the determined first vehicle during the period of the active first itinerary to display the generated series of media content recommendations; Receiving a user selection of a first media content recommendation among the displayed series of media content recommendations; Controlling the playback of the first media content related to the first media content recommendation on the first display device; Detecting a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; Controlling to pause the playback of the first media content on the first display device based on the detection of the first event; Controlling to resume the playback of the first media content on a second display device used within a second vehicle during the period of a second itinerary of the current ongoing trip or during a different trip of the user; Generating a transport stream including the first media content based on the device specifications of the first display device; Generating a series of chunks of the generated transport stream, where each chunk does not overlap with other chunks of the series of chunks; Storing the generated series of chunks in a media server; including; A method characterized by the above. **Claim 27** In a system, Receiving travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network, Determining a first vehicle to configure the user to complete an active first leg of the current ongoing trip, Generating a series of media content recommendations based on the received travel details and the user's related media consumption history, Controlling a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations, Receiving a user selection of a first media content recommendation among the displayed series of media content recommendations, Controlling playback of first media content related to the first media content recommendation on the first display device, Detecting a first event that requires pausing the playback of the first media content during the period of the current ongoing trip, Based on the detection of the first event, controlling the first display device to pause the playback of the first media content, Controlling to resume playback of the first media content on a second display device used within a second vehicle during the period of a second leg of the current ongoing trip or during a different trip of the user, Collecting first media consumption information related to the first media content on the first display device and the second display device during the period of the current ongoing trip, Sending a transaction message including the collected first media consumption information to the MaaS network, including, In the MaaS network, Receiving the sent transaction message, Updating a record on a first distributed ledger node of the MaaS network, including, The record is updated by executing a transaction on the first distributed ledger node based on the received transaction message, The updated record aggregates media usage statistics related to the first media content from all users who have viewed the first media content, A method characterized by this.

28. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a system, cause the system to receive travel details related to a user's current ongoing trip from a Mobility-as-a-Service (MaaS) network; determine a first vehicle to configure the user to complete an active first leg of the current ongoing trip; generate a series of media content recommendations based on the received travel details and a media consumption history associated with the user; control a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations; receive a user selection of a first media content recommendation among the displayed series of media content recommendations; control playback of first media content associated with the first media content recommendation on the first display device; detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; control, based on the detection of the first event, pausing the playback of the first media content on the first display device; control resuming playback of the first media content on a second display device used within a second vehicle during the period of a second leg of the current ongoing trip or during a different trip of the user; receive a user profile including content preferences associated with the user and device specifications associated with the first display device; construct input features for a context-aware recommendation model trained based on a media content recommendation task based on one or more of the received travel details, the media consumption history, the received user profile, and the device specifications; input the constructed input features into the context-aware recommendation model; generate the series of media content recommendations as an output of the context-aware recommendation model for the input; and cause operations including the above to be performed. A non-transitory computer-readable medium characterized by the above. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a system, cause the system to receive travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network; determine a first vehicle to configure the user to complete an active first leg of the current ongoing trip; generate a series of media content recommendations based on the received travel details and a media consumption history associated with the user; control a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations; receive a user selection of a first media content recommendation among the displayed series of media content recommendations; control playback of first media content related to the first media content recommendation on the first display device; detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; control, based on the detection of the first event, pausing the playback of the first media content on the first display device; control resuming playback of the first media content on a second display device used within a second vehicle during the period of a second leg of the current ongoing trip or during a different trip of the user; control the second display device, which is the user's personal mobile device, to display a second option for resuming the playback of the first media content based on a determination that the second vehicle does not have an in-vehicle display; receive a second user input including selection of the second option; perform operations including controlling the playback of the first media content to resume on the second display device further based on the received second user input; A non-transitory computer-readable medium, characterized by the above. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a system, cause the system to receive travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network; determine a first vehicle to configure the user to complete an active first leg of the current ongoing trip; generate a series of media content recommendations based on the received travel details and a media consumption history associated with the user; control a first display device used within the determined first vehicle during a period of the active first leg to display the generated series of media content recommendations; receive a user selection of a first media content recommendation among the displayed series of media content recommendations; control playback of first media content associated with the first media content recommendation on the first display device; detect a first event that requires pausing the playback of the first media content during a period of the current ongoing trip; control, based on the detection of the first event, pausing the playback of the first media content on the first display device; control resuming playback of the first media content on a second display device used within a second vehicle during a period of a second leg of the current ongoing trip or during a different trip of the user; determine a timestamp at which the playback of the first media content is paused based on the detected first event within an entire duration of the first media content; record the timestamp in a database; receive travel situation related to the current ongoing trip from a first distributed ledger node of the MaaS network; detect a second event indicating that the user is riding in the second vehicle to cover the second leg of the current ongoing trip based on the received travel situation; retrieve the recorded timestamp from the database based on the detected second event; perform operations including The playback of the first media content is controlled to resume on the second display device from the retrieved timestamp. A non-transitory computer-readable medium characterized by the above.

31. A non-transitory computer-readable medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a system, cause the system to receive travel details related to a user's current ongoing trip from a Mobility-as-a-Service (MaaS) network; determine a first vehicle for setting the user to complete an active first leg of the current ongoing trip; generate a series of media content recommendations based on the received travel details and the user's related media consumption history; control a first display device used within the determined first vehicle during the period of the active first leg to display the generated series of media content recommendations; receive a user selection of a first media content recommendation from the displayed series of media content recommendations; control the playback of the first media content related to the first media content recommendation on the first display device; detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; control to pause the playback of the first media content on the first display device based on the detection of the first event; control to resume the playback of the first media content on a second display device used within a second vehicle during the period of a second leg of the current ongoing trip or during a different trip of the user; generate a transport stream including the first media content based on the device specifications of the first display device; generate a series of chunks of the generated transport stream, each chunk not overlapping with other chunks of the series of chunks; store the generated series of chunks in a media server; perform operations including A non-transitory computer-readable medium characterized by the above. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a system, cause the system to receive travel details related to a user's current ongoing trip from a Mobility as a Service (MaaS) network; determine a first vehicle to configure the user to complete an active first leg of the current ongoing trip; generate a series of media content recommendations based on the received travel details and a media consumption history associated with the user; control a first display device used within the determined first vehicle during a period of the active first leg to display the generated series of media content recommendations; receive a user selection of a first media content recommendation of the displayed series of media content recommendations; control playback of first media content associated with the first media content recommendation on the first display device; detect a first event that requires pausing the playback of the first media content during the period of the current ongoing trip; control, based on the detection of the first event, pausing the playback of the first media content on the first display device; control resuming playback of the first media content on a second display device used within a second vehicle during a period of a second leg of the current ongoing trip or during a different trip of the user; collect first media consumption information related to the first media content on the first display device and the second display device during the period of the current ongoing trip; send a transaction message including the collected first media consumption information to the MaaS network; perform operations including the MaaS network to receive the sent transaction message; update a record on a first distributed ledger node of the MaaS network; perform operations including The record is updated by executing a transaction on the first distributed ledger node based on the received transaction message, and the updated record aggregates media usage statistics related to the first media content from all users who have viewed the first media content. A non-transitory computer-readable medium characterized by the above.

Images