Electronic framework for personalized program assistance
Patent Information
- Application Number
- CN202510725902.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-04-21
- Filing Date
- 2025-06-03
- Publication Date
- 2026-10-23
Smart Images
Figure CN122970101A_ABST
Abstract
Description
Technical Field
[0001] This disclosure generally relates to an electronic framework, also known as a protocol or architecture, for connecting ecosystems to enable vehicle users to receive personalized assistance. Background Technology
[0002] The number and variety of smart devices and connected systems have grown dramatically in recent times. Various forecasts indicate that this rapid growth will continue as technologies become more affordable and energy-efficient. As the complexity and capabilities of these connected systems increase, creating a framework that enables smooth operation and effective communication between various entities becomes increasingly challenging. Summary of the Invention
[0003] Disclosed herein is an electronic framework for providing personalized assistance to vehicle users. The electronic framework includes a controller installed in the vehicle, the controller having a processor and tangible, non-transitory memory on which instructions are recorded. A central platform communicates with the controller. The central platform is located remotely relative to the vehicle. Multiple local platforms communicate with the central platform, each local platform having its own resources.
[0004] The controller is adapted to request interaction between the central platform and at least one of multiple local platforms. The central platform is adapted to verify the respective credentials of the multiple local platforms, assess the availability of their respective resources, and generate a resource access plan based on the availability of their respective resources. The central platform is adapted to transmit the resource access plan to the controller and the multiple local platforms. The central platform and the multiple local platforms include a common set of application programming interfaces (APIs) for enabling resource booking and resource cancellation for their respective resources in the resource access plan.
[0005] The central platform can be adapted to define a common set of APIs and negotiate resource access plans with multiple local platforms based on this common set of APIs. The resource access plans are updated according to the negotiation. The central platform can be adapted to execute an authentication module when receiving a registration request from at least one of the multiple local platforms and to specify respective participation levels for the multiple local platforms. The respective participation levels include a first-tier access level and a second-tier access level. The central platform can be adapted to provide the controller with state updates to the resource access plans as needed by users.
[0006] In some embodiments, the central platform is adapted to execute a scheduling module, including queuing the respective resources based in part on the nature of the respective resources and their respective locations on the user's route. Executing the scheduling module includes performing priority checks when the controller requests multiple respective resources.
[0007] Multiple local platforms may include a first local platform and a second local platform. In some embodiments, a central platform is adapted to transmit a participation request from the first local platform to the second local platform when the first local platform submits a participation request to the central platform to engage with the second local platform. The central platform is adapted to transmit an access authorization message and one or more negotiation restrictions to the first local platform when the participation request is successful. The central platform is adapted to submit alternative resource recommendations to the first local platform when the participation request is unsuccessful. The electronic framework may include a user-operated mobile application adapted to interface with a controller. The mobile application may be hosted by an infotainment unit in the vehicle.
[0008] The central platform can be adapted to communicate with multiple local platforms via a publish-subscribe messaging protocol, such as Message Queuing Telemetry Transport (MQTT). Multiple local platforms may include transportation hubs, accommodation facilities, and food service establishments. Multiple local platforms may include home systems, paid parking facilities, and other vehicles. Multiple local platforms may include charging stations, roadside units, and payment units.
[0009] Disclosed herein is a method for establishing an electronic framework to provide personalized assistance to users in a vehicle with a controller having a processor and tangible, non-transitory memory on which instructions are recorded. The method includes establishing bidirectional communication between a central platform and the controller. The central platform is remotely located relative to the vehicle and communicatively engages with multiple local platforms, each possessing its own resources. The method includes adapting the controller to request the central platform to interact with at least one of the multiple local platforms. The method includes verifying the respective credentials of the multiple local platforms via the central platform, assessing the availability of their respective resources, and generating a resource access plan based on the availability of their respective resources. The resource access plan is transmitted via the central platform to the controller and the multiple local platforms. The method includes incorporating a common set of application programming interfaces (APIs) in the central platform and the multiple local platforms to enable resource reservation and cancellation for their respective resources within the resource access plan.
[0010] The above-mentioned features and advantages, as well as other features and advantages of this disclosure, will become apparent from the following detailed description of the best implementation mode, when taken in conjunction with the accompanying drawings. Attached Figure Description
[0011] Figure 1 This is a schematic fragment of an electronic framework used to provide personalized assistance to vehicle users, which includes a central platform;
[0012] Figure 2 yes Figure 1 A schematic diagram of example architectures that the framework can adopt;
[0013] Figure 3 yes Figure 1Flowchart of an example authentication module that can be executed by the central platform;
[0014] Figure 4 yes Figure 1 Flowchart of example operation modules that can be executed by the central platform;
[0015] Figure 5 yes Figure 1 Flowchart of an example scheduling module executable by the central platform;
[0016] Figure 6 yes Figure 1 A flowchart of example request mechanisms that the framework can adopt.
[0017] Representative embodiments of this disclosure are illustrated by way of non-limiting examples in the accompanying drawings, and are described in further detail below. It should be understood that the novel aspects of this disclosure are not limited to the specific forms shown in the drawings listed above. Rather, this disclosure is intended to cover modifications, equivalents, combinations, sub-combinations, arrangements, groupings, and substitutions falling within the scope of this disclosure, such as those covered by the appended claims. Detailed Implementation
[0018] Referring to the accompanying drawings, the same reference numerals refer to the same components. Figure 1 An electronic framework 10, also known as a protocol or architecture, is schematically shown for providing personalized assistance to a user 12 of a vehicle 14. The user 12 may be a driver or passenger of the vehicle 14. The vehicle 14 may include, but is not limited to, passenger cars, SUVs, light trucks, heavy vehicles, minivans, buses, vehicles, bicycles, mobile robots, agricultural implements (e.g., tractors), sports-related equipment (e.g., golf carts), boats, aircraft, trains, or other mobile platforms. The vehicle 14 may be a fully electric vehicle, a hybrid / partially electric vehicle, or a vehicle with an internal combustion engine. The vehicle 14 may be an autonomous vehicle or a partially autonomous vehicle. It should be understood that the vehicle 14 may take many different forms and have additional components.
[0019] The electronic frame 10 can be accessed by the user 12 upon request, for example, via a mobile application 16, which can be hosted or executed by the infotainment unit 18 of the vehicle 14. The infotainment unit 18 may include a touchscreen or other I / O device and may be integrated into the dashboard, overhead sun visor (not shown), or other suitable location of the vehicle 14. The mobile application 16 may be hosted or executed by the user 12's smart device 20 (e.g., a mobile phone, tablet).
[0020] The electronic framework 10 provides intelligent planning, sequencing, and routing capabilities by seamlessly connecting to and collecting information from a heterogeneous IoT ecosystem, thereby creating a personalized and optimized experience for the users 12 of the vehicle 14. (Reference) Figure 1 The vehicle 14 includes a controller C, which has at least one processor P and at least one memory M (or a non-transitory, tangible computer-readable storage medium). The memory M may store a set of controller executable instructions, and the processor P may execute the set of controller executable instructions stored in the memory M.
[0021] refer to Figure 1 The electronic framework 10 provides a functional architecture for the application-level platform, featuring a central platform 22 and multiple local platforms 30, each with its own resources / services. The central platform 22 implements protocols for applications participating in the ecosystem to book, schedule, negotiate, and manage resources. The multiple local platforms 30 can be independent or isolated ecosystems.
[0022] refer to Figure 1 The central platform 22 includes at least one processor 24 and at least one memory 26 (or a non-transitory, tangible computer-readable storage medium). [Reference] Figure 1 Vehicle 14 may include a connectivity module 28 adapted to send and receive information from central platform 22 wirelessly. Central platform 22 operates as a back-office, managing the entire process. Central platform 22 may include one or more servers hosted on the Internet for storing, managing, and processing data. Central platform 22 may be operated electronically and / or by an administrator with access to electronic devices such as desktop computers, laptops, tablets, mobile phones, or wearable devices. Central platform 22 may be a private or public entity maintained by an organization.
[0023] The central platform 22 is adapted to selectively execute one or more modules, including authentication module 150, operation module 200, and scheduling module 300, which will be referred to separately below. Figure 3-5 Description. Each local platform 30 includes one or more connected devices or IoT devices. As those skilled in the art will understand, the Internet of Things (IoT) is a network of devices that can communicate with each other using the Internet and with the cloud. For example, connected devices in a home ecosystem may include garage doors, wall-mounted chargers, front doors, and lighting systems. Connected devices in a smart city may include parking spaces. Vehicle 14 can be considered as an IoT device and / or part of an IoT ecosystem. Electronic frame 10 can be applied to other IoT devices and users 12 in the home.
[0024] Figure 1An example of local platform 30 is shown herein. It should be understood that the example shown is a non-limiting example and may include other types of systems. Local platform 30 may include smart home system 32, paid parking facility 34 (e.g., commercial garage), charging station 36, roadside unit 38, and toll collection unit 40 (for collecting road tolls). Local platform 30 may include food service establishment 42 (e.g., restaurant or cafe), transportation hub 44 (e.g., airport, train station, bus station, etc.), and accommodation facility 46 (e.g., hotel, motel, vacation rental market, etc.). Local platform 30 may include other vehicles 48. Controller C and / or central platform 22 may download and store additional information, such as user profiles related to user 12, from cloud database 52.
[0025] As described below, controller C is adapted to request central platform 22 to interact with at least one of multiple local platforms 30. Central platform 22 is adapted to verify the respective credentials of the multiple local platforms 30, assess the availability of their respective resources, and generate a resource access plan based on the availability of their respective resources. Central platform transmits the resource access plan to controller C and the multiple local platforms.
[0026] Electronic Framework 10 enables the IoT ecosystem to seamlessly access resources from heterogeneous ecosystems on demand or periodically. Central Platform 22 and Local Platform 30 include a common set of Application Programming Interfaces (APIs) for enabling resource booking and cancellation for their respective resources within a resource access plan. An API is a set of rules and protocols that allow different software applications to communicate and interact with each other, enabling them to exchange data, features, and functionalities. Central Platform 22 defines and controls the operation of the APIs, while Local Platform 30 implements and utilizes the APIs. Local Platform 30 can expose available APIs to Central Platform 22.
[0027] Now for reference Figure 2 This illustrates an example architecture 100 that the electronic framework 10 can adopt. Here, components of the local (IoT) ecosystem 110 interact with each other and with a central platform 120. The local (IoT) ecosystem 110 includes a mobile application 112 that interacts with a service protocol layer 114, which contains APIs, basic services, and protocols for various requests. The service protocol layer 114 further interacts with a layered service abstraction layer 116 and an ecosystem resource layer 118. (Reference) Figure 2 The central platform 120 includes various operational control mechanisms 122, such as authentication, trust establishment, API definition, and access requirements. The central platform 22 implements protocols to integrate or register trusted devices (e.g., smart device 20, vehicle 14) for deploying application services. The central platform 22 is suitable for handling user requests, analyzing device status, facilitating information exchange, status prediction, and recommending options.
[0028] Now for reference Figure 3 A flowchart of an example authentication module 150 is shown. Module 150 may be embodied as computer-readable code or instructions stored on and at least partially executed by the central platform 22. Module 150 need not be applied in the specific order described herein. Furthermore, it should be understood that certain blocks or steps may be omitted.
[0029] from Figure 2 Beginning at block 152, the central platform 22 (“CP”) receives a registration request from at least one local platform 30. The central platform 22 performs an API negotiation and registration procedure, whereby the resources provided by the local platforms 30 are cataloged and registered. The API negotiation takes into account limitations and constraints (e.g., time limits) associated with each resource provided. Continuing to block 154, the central platform 22 specifies a respective participation level for each of the multiple local platforms 30. The respective participation level may include several levels, such as a Tier 1 access level (providing more services) and a Tier 2 access level (providing fewer services). The participant level may be based on the outcome of the API negotiation.
[0030] Proceeding to block 156, the list of local platforms 30 managed by central platform 22 is updated. According to block 158, central platform 22 can be adapted to provide resource status updates to controller C when needed and / or periodically. Then module 150 ends.
[0031] The central platform 22 can employ the machine learning module 50 to perform some of the aforementioned functions, such as specifying participation levels based on historical data. In some embodiments, the machine learning module 50 may include a neural network trained using a training dataset retrieved by the central platform 22. The training process can be performed in a closed-loop or iterative manner, with the neural network trained until certain criteria are met, i.e., until the difference between the network output and the actual situation falls below a certain threshold. The neural network converges as a predefined loss function associated with the training dataset is minimized. Convergence marks the completion of training.
[0032] The electronic framework 10 can be configured to be "adaptive" and updated continuously or periodically after collecting additional training data for the machine learning module 50. It should be understood that the electronic framework 10 is not limited to a specific neural network method.
[0033] Now for reference Figure 4 A flowchart of an example operation module 200 is shown. Module 200 may be embodied as computer-readable code or instructions stored on and at least partially executed by the central platform 22. Module 200 need not be applied in the specific order described herein. Furthermore, it should be understood that certain blocks or steps may be omitted.
[0034] Beginning at block 202, controller C is adapted to send a request to central platform 22 to interact with at least one local platform 30. Continuing to block 204, central platform 22 is adapted to verify the respective credentials of the multiple local platforms 30, assess the availability of their respective resources, and generate a resource access plan based on the availability of their respective resources.
[0035] Proceeding to block 206, central platform 22 is adapted to transmit the resource access plan to controller C and local platform 30. Continuing to block 208, controller C is adapted to negotiate respective resources (e.g., available time and quantity, cost per unit, etc.) with local platform 30 via a direct link or through central platform 22. According to block 210, the resource access plan is updated according to the negotiated terms.
[0036] Proceeding to block 212, controller C is adapted to transmit the updated resource access plan to local platform 30 and central platform 22. Controller C can reserve and / or cancel resources in the resource access plan through central platform 22. Continuing to block 214, controller C is adapted to request confirmation of the updated resource access plan from local platform 30, i.e., verify the accuracy of the updated resource access plan. Local platform 30 can provide resource status change feedback to central platform 22. Controller C can request confirmation of resource reservations and / or resource cancellations from local platform 30. Then module 200 ends.
[0037] Now for reference Figure 5 A flowchart of an example scheduling module 300 is shown. Module 300 may be embodied as computer-readable code or instructions stored on and at least partially executed by the central platform 22. Module 300 need not be applied in the specific order described herein. Furthermore, it should be understood that certain blocks or steps may be omitted.
[0038] Starting at block 302, central platform 22 is adapted to queue the respective resources or services required by user 12, partly based on the nature of the service and the location on the route taken by user 12. Continuing to block 304, central platform 22 is adapted to map the services to the respective resources provided by local platform 30. Proceeding to block 306, central platform 22 is adapted to determine whether controller C is requesting multiple services. If yes (block 306=YES), module 300 continues to block 308 to run a priority conflict process to see which service has a higher priority and whether a conflict exists. If not (block 306=NO), module 300 continues to block 310 to perform a commission assessment. Then module 300 ends.
[0039] Now for reference Figure 6A flowchart illustrating an example request mechanism 400 that may be employed by the local platform 30 is shown. Module 400 may be embodied as computer-readable code or instructions stored on and at least partially executed by the local platform 30. Modules 400 need not be applied in the specific order described herein. Furthermore, it should be understood that certain blocks or steps may be omitted.
[0040] Local platform 30 here includes a first local platform (LP1) and a second local platform (LP2). Starting at block 402, the first local platform checks the request to engage with the second local platform using data provided by the central platform 22. Continuing to block 404, the first local platform submits a participation request to the central platform 22 to engage with the second local platform. The central platform 22 is adapted to transmit the participation request to the second local platform.
[0041] Proceeding to block 406, the registration process and negotiation take place between the second local platform and the central platform 22. A common set of application programming interfaces (APIs) allows the second local platform and the central platform 22 to negotiate the terms of engagement. If the negotiation is successful (block 406=YES), module 400 continues to block 408, notifying the first local platform that access has been authorized and providing notification of the engagement terms (e.g., cost, time, tiered access level, etc.). If the negotiation fails (block 406=NO), module 400 continues to block 410, where the central platform 22 submits alternative resource recommendations to the first local platform.
[0042] Electronic framework 10 can employ subscription-based hierarchical participation or access control for local platform 30. In some embodiments, central platform 22 can communicate with local platform 30 and controller C according to a publish-subscribe messaging protocol. The publish-subscribe messaging protocol can be Message Queuing Telemetry Transport (MQTT) or other mechanisms. The term "MQTT" includes variants and updates of MQTT. MQTT is a bidirectional communication protocol that allows decoupling between client devices and server applications. The publish-subscribe messaging protocol can use an encryption model with certificates, usernames, and passwords protecting the connection.
[0043] Furthermore, the electronic framework 10 can assist in extracting user needs from its own connected devices, personal details, historical data, and profile information. The controller C can be adapted to transmit contextual data to the central platform 22, including at least one of vehicle location data, vehicle status data, user preference data, and usage history data. The central platform 22 is adapted to analyze the contextual data to determine one or more services from multiple local platforms 30 to recommend to the user 12. The central platform 22 and / or the controller C are adapted to construct constraints to identify information relevant to other ecosystems to present optimal routes, optimize travel costs, and predefined user experiences. The controller C is adapted to receive service recommendations from the central platform 22. (Reference) Figure 1The mobile application 16 can be used to solicit user input for resource recommendations. In some embodiments, the electronic frame 10 can be accessed by a respective controller C in each individual vehicle. In a fleet, the electronic frame 10 can be accessed by a controller in the master vehicle.
[0044] In summary, the electronic framework 10 enables efficient access to different local platforms 30 by vehicle 14 and provides conflict resolution management for resources between requesters and suppliers. Framework 10 provides APIs and services for authentication, information requests, reservations, conflict resolution, and / or prediction of future availability of requested resources, whether local or centralized.
[0045] refer to Figure 1 Various components of the electronic frame 10 can communicate via a wireless network 54, which can be a short-range or long-range network. The wireless network 54 can be a local area network (LAN) in the form of a serial communication bus. The LAN can include, but is not limited to, a command unit area network (MAY), a command unit area network with flexible data rates (MAY-FD), Ethernet, Bluetooth, Wi-Fi, and other forms of data. The wireless network 54 can be a wireless local area network (LAN) that links multiple devices using a wireless distribution method, a wireless metropolitan area network (MAN) that connects multiple wireless LANs, or a wireless wide area network (WAN) that covers a large area (such as adjacent towns and cities). Those skilled in the art can employ other types of network technologies or carrier systems.
[0046] As used herein, the terms “dynamic” and “dynamically” describe steps or processes performed in real time, characterized by monitoring or otherwise determining the state of parameters and periodically or periodically updating the state of parameters during routine execution or between iterations of routine execution.
[0047] Figure 1The controller C includes a computer-readable medium (also called a processor-readable medium), including a non-transitory (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., a computer's processor). Such a medium can take many forms, including, but not limited to, non-volatile and volatile media. Non-volatile media can include, for example, optical discs or magnetic disks and other persistent storage. Volatile media can include, for example, dynamic random access memory (DRAM), which can constitute main memory. Such instructions can be transmitted via one or more transmission media, including coaxial cables, copper wires, and optical fibers, including wires constituting a system bus connected to the computer processor. Some forms of computer-readable media include, for example, floppy disks, floppy disks, hard disks, magnetic tape, other magnetic media, CD-ROMs, DVDs, other optical media, physical media with perforated patterns, RAM, PROMs, EPROMs, FLASH-EEPROMs, other memory chips or cassette tapes, or other media from which a computer can read.
[0048] The lookup tables, databases, data repositories, or other data stores described herein can include various mechanisms for storing, accessing, and retrieving various types of data, including hierarchical databases, a set of files in a file system, application databases in proprietary formats, relational database management systems (RDBMS), etc. Each such data store can be contained within a computing device employing a computer operating system as described above and can be accessed via a network in one or more ways. File systems can be accessed from the computer operating system and can include files stored in various formats. RDBMS can employ Structured Query Language (SQL) and languages for creating, storing, editing, and executing stored procedures, such as the PL / SQL language described above.
[0049] The flowcharts illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or code portion comprising one or more executable instructions for implementing a specified logical function. It should also be noted that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a purpose-specific hardware-based system or a combination of purpose-specific hardware and computer instructions that perform a specified function or action. These computer program instructions may also be stored in a computer-readable medium that can instruct a controller or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions / actions specified in the flowchart and / or block diagram blocks.
[0050] The numerical values of parameters (e.g., quantities or conditions) in this specification (including the appended claims) should be understood to be modified by the term “about” in each respective case, regardless of whether “about” actually appears before the numerical value. “About” indicates that the stated numerical value allows for some slight imprecision (close to exact in value; approximately or reasonably close to the value; almost). If the imprecision provided by “about” is not understood in this common sense in the art, then “about” as used herein at least indicates variations that may arise from common methods of measuring and using these parameters. Furthermore, the disclosure of ranges includes the disclosure of each value throughout the range and further subdivisions of the range. Each value within the range and the endpoints of the range are disclosed herein as separate embodiments.
[0051] The detailed description and accompanying drawings or figures support and describe the disclosure, but the scope of the disclosure is defined only by the claims. While some best modes and other embodiments for implementing the claimed disclosure have been described in detail, various alternative designs and embodiments exist to practice the disclosure as defined in the appended claims. Furthermore, features of the embodiments shown in the drawings or the various embodiments mentioned in this specification are not necessarily to be construed as embodiments independent of each other. Rather, each feature described in one example of an embodiment may be combined with one or more other desired features from other embodiments to produce other embodiments not described in the text or by reference to the drawings. Thus, such other embodiments fall within the scope of the appended claims.
Claims
1. An electronic framework for providing personalized assistance to vehicle users, the electronic framework comprising: A controller installed in the vehicle, which has a processor and tangible, non-transitory memory on which instructions are recorded; A central platform that communicates with the controller, located remotely relative to the vehicle; Multiple local platforms communicate with the central platform, and each local platform has its own resources; The controller is adapted to request the central platform to interact with at least one of multiple local platforms; The central platform is suitable for verifying the credentials of multiple local platforms, assessing the availability of their respective resources, and generating resource access plans based on the availability of their respective resources. The central platform is suitable for transmitting resource access plans to the controller and multiple local platforms; and The central platform and multiple local platforms include a set of common application programming interfaces (APIs) for enabling resource booking and cancellation for their respective resources within the resource access plan.
2. The electronic framework of claim 1, wherein the central platform is adapted to define a common set of APIs and negotiate resource access plans with multiple local platforms based on the common set of APIs, and update the resource access plans according to the negotiation.
3. The electronic frame of claim 1, wherein the central platform is adapted to: The authentication module is executed when a registration request is received from at least one of multiple local platforms. Specify the participation level for each of the multiple local platforms. Each participation level includes a first-level access level and a second-level access level.
4. The electronic framework of claim 1, wherein the central platform is adapted to provide the controller with status updates of the resource access plan when required by the user.
5. The electronic framework of claim 1, wherein the central platform is adapted to execute a scheduling module, including queuing the respective resources based in part on the nature of the respective resources and their respective positions on the user routes.
6. The electronic framework of claim 5, wherein the execution scheduling module includes performing a priority check when the controller requests multiple respective resources.
7. The electronic frame as claimed in claim 1, wherein: Multiple local platforms include a first local platform and a second local platform; The central platform is adapted to transmit the participation request from the first local platform to the second local platform when the first local platform submits a participation request to the central platform to contact the second local platform.
8. The electronic frame as claimed in claim 7, wherein: The central platform is adapted to transmit an access authorization message and one or more negotiated restrictions to the first local platform upon successful participation request; The central platform is suitable for submitting alternative resource recommendations to the first local platform when participation requests are unsuccessful.
9. The electronic frame of claim 1, further comprising: A user-operated mobile application that is designed to interface with a controller; The vehicle includes an infotainment unit, and the mobile application is hosted by the infotainment unit.
10. The electronic framework of claim 1, wherein the central platform is adapted to communicate with multiple local platforms via a publish-subscribe messaging protocol, including Message Queuing Telemetry Transport (MQTT).