Patent Application
20240289760
The present disclosure relates to provision of a subscription service for ADS features.
Within the automotive field, there has for quite some years been activity in development of autonomous vehicles. An increasing number of modern vehicles have advanced driver-assistance systems, ADAS, to increase vehicle safety and more generally road safety. ADAS—which for instance may be represented by adaptive cruise control, ACC, collision avoidance system, forward collision warning, etc.—are electronic systems that may aid a vehicle driver while driving. Moreover, in a not-too-distant future, Autonomous Driving, AD, will to greater extent find its way into modern vehicles. AD along with ADAS will herein be referred to under the common term Automated Driving System, ADS, corresponding to all different levels of automation, for instance as defined by the SAE J3016 levels (0-5) of driving automation. An ADS may be construed as a complex combination of various components that can be defined as systems where perception, decision making, and operation of the vehicle—at least in part—are performed by electronics and machinery instead of a human driver. This may include handling of the vehicle, destination, as well as awareness of surroundings. While the automated system has control over the vehicle, it allows the human operator to leave all or at least some responsibilities to the system. To perceive its surroundings, an ADS commonly combines a variety of sensors, such as e.g. radar, LIDAR, sonar, camera, navigation and/or positioning system e.g. GNSS such as GPS, odometer and/or inertial measurement units, upon which advanced control systems may interpret sensory information to identify appropriate navigation paths, as well as obstacles and/or relevant signage.
One approach for ADS feature providers—such as ADS features developing companies—to provide ADS-supporting vehicles and/or its operators with ADS features for activation, may be to offer ADS features as services activated through subscriptions. Such subscriptions may for instance support different vehicle configurations and timespans, e.g. from yearly subscriptions to per hour or even per minute activations. Assuming a standard centralized solution where the ADS feature provider controls its feature subscriptions, potential occupants and/or operators of ADS-supporting vehicles—which in this context may be referred to as users, customers and/or end customers—need to communicate with the ADS feature provider and/or a subscription management system e.g. billing B2B company to activate a vehicle ADS feature. The ADS feature provider may then need to interact with the e.g. billing B2B company, which in turn may need to communicate with the OEM that controls the vehicle fleet. Moreover, the OEM may need to communicate with the ADS feature provider to understand the technical aspects of the activation and requirements on the vehicle configuration, and further need to identify the actual vehicle for the requested activation and validate that the vehicle supports that particular feature, taking into consideration potential vehicle updates e.g. done at services. Furthermore, the OEM may then need to relate the customer to the vehicle and further communicate with the ADS feature provider to receive the activation information. Moreover, the ADS feature provider may then bill the customer through the billing company as the OEM sends the activation information to the vehicle. Evidently, it may be a complicated process with many actors and handovers, where the identity of the customer needs to be protected and at the same time shared in order to find the vehicle identity, while fulfilling GDPR and similar regulations. Accordingly, subscription handling of ADS features involving transactions and handovers as described above implicates complexity, potentially along with significant backend and/or transaction costs.
In view thereof, subscription-based activation—and potentially deactivation—of ADS features in a vehicle, may alternatively be realized based on blockchain technology, as e.g. described in European patent application EP 21 201 973.1, by the same inventor and applicant. As disclosed therein, by using a distributed approach and/or mechanism based on smart contracts for handling feature subscription in vehicles, process complexity of the backend and/or transaction costs of subscription handling may be limited and/or decreased while at the same time limiting and/or decreasing number of handovers between potential different parties, such as an ADS feature provider, customer(s) and vehicle fleet OEM, and potentially further a subscription management system such as e.g. a billing B2B company. Moreover, the use of smart contracts in this context may further enable an ADS feature provider to retain control and transparency of the process such as current status and history—which otherwise would have been challenging to collect and maintain—while business and identity aspects of both the customer and of the ADS feature provider may remain protected. That is, as compared to an assumed standard centralized solution, a blockchain-based subscription and potential license handling may be distributed to the vehicles, instead of subscriptions being handled centrally. Such a distributed approach may cover not only the ADS features activation process and potential payment. but also the validation of the vehicle configuration and identification, which—in addition to protecting private information between parties—significantly may decrease the number of handovers and process complexity of negotiating information between parties for activating a subscription in a customer vehicle.
However, although such a blockchain-based subscription-handling solution may enable an efficient process where complexity and/or transactions cost of ADS feature subscription handling may be limited, e.g. as compared to the previously described standard centralized solution(s), there is still room for improvement for blockchain-based subscription management of ADS features.
It is therefore an object of embodiments herein to provide an approach which in an improved and/or alternative manner supports subscription management of ADS features, such as provides an improved and/or alternative subscription service for ADS features.
The object above may be achieved by the subject-matter disclosed herein. Embodiments are set forth in the appended claims, in the following description and in the drawings.
The disclosed subject-matter relates to a method performed by a subscription management system for provision of a subscription service for ADS features. The subscription management system deploys on a private blockchain network comprising a set of nodes, a smart contract identifying data indicative of a user being eligible for one or more subscription options representing various ADS feature sets, the user-indicative data comprising a respective unique private key and public key personal to the user. The subscription management system further deploys, on a public blockchain network supporting minting of NFTs—and for instance comprising at least one of said set of nodes—a smart contract generating a whitelisting request transaction comprising the unique private and public keys. The subscription management system further deploys a smart contract adding the whitelisting request transaction to the public blockchain, the addition whitelisting the unique public key for minting of NFTs on the public blockchain network. Moreover, the subscription management system deploys on the public blockchain network, a smart contract identifying data indicative of said public key having been included in minting of an NFT on the public blockchain, which NFT comprises and/or points to data indicative of an at least first subscription option out of the one or more subscription options and further comprises a unique address associated with the user derived from the unique public key. The management subscription system further deploys on the private blockchain network, a smart contract generating a subscription activation transaction comprising data indicative of the unique address and comprising and/or pointing to the at least first subscription option. Furthermore, the subscription management system deploys a smart contract adding the subscription activation transaction to the private blockchain, the addition whitelisting activation of the ADS feature set of the at least first subscription option.
The disclosed subject-matter further relates to a subscription management system for—and/or adapted and/or configured for—provision of a subscription service for ADS features. The subscription management system comprises a user eligibility identifying unit for—and/or adapted and/or configured for—deploying on a private blockchain network comprising a set of nodes, a smart contract identifying data indicative of a user being eligible for one or more subscription options representing various ADS feature sets, which user-indicative data comprises a respective unique private key and public key personal to the user. The subscription management system further comprises a whitelist transaction generating unit for—and/or adapted and/or configured for—deploying on a public blockchain network supporting minting of NFTs—and for instance comprising at least one of said set of nodes—a smart contract generating a whitelisting request transaction comprising the unique private and public keys. Furthermore, the subscription management system comprises a whitelist transaction adding unit for—and/or adapted and/or configured for—deploying a smart contract adding the whitelisting request transaction to the public blockchain, the addition whitelisting the unique public key for minting of NFTs on the public blockchain network. Moreover, the subscription management system comprises an NFT identifying unit for—and/or adapted and/or configured for—deploying on the public blockchain network, a smart contract identifying data indicative of the public key having been included in minting of an NFT on the public blockchain, which NFT comprises and/or points to data indicative of an at least first subscription option out of the one or more subscription options and further comprises a unique address associated with the user derived from the unique public key. The subscription management system further comprises a subscription transaction generating unit for—and/or adapted and/or configured for—deploying on the private blockchain network, a smart contract generating a subscription activation transaction comprising data indicative of the unique address and comprising and/or pointing to the at least first subscription option. Moreover, the subscription management system comprises a subscription transaction adding unit for—and/or adapted and/or configured for—deploying a smart contract adding the subscription activation transaction to the private blockchain, the addition whitelisting activation of the ADS feature set of the at least first subscription option.
Furthermore, the disclosed subject-matter relates to at least a first node comprising a subscription management system described herein.
Moreover, the disclosed subject-matter relates to a computer program product comprising a computer program containing computer program code means arranged to cause a computer or a processor to execute the steps of a subscription management system described herein, stored on a computer-readable medium or a carrier wave.
The disclosed subject-matter further relates to a non-volatile computer readable storage medium having stored thereon said computer program product.
Thereby, there is introduced an approach enabling community-based subscription handling of ADS features. That is, since there is deployed on a private blockchain network comprising a set of nodes, a smart contract identifying data indicative of a user being eligible for one or more subscription options representing various ADS feature sets, which user-indicative data comprises a respective unique private key and public key personal to the user, there is identified on a private blockchain to which plural nodes—e.g. at least a service provider node and/or a subscription—bundling node—are connected, an event reflecting that a user, such as e.g. a vehicle owner, assigned a respective unique private key and public key, is deemed permitted—for instance following funding e.g. by a credit card and/or blockchain wallet being registered related to said user—to subscribe to one or more subscriptions of various ADS features and/or feature constellations, e.g. as bundled by an OEM. Accordingly, with support from one or more blockchain-stored smart contracts on the private network, e.g. deployed via the exemplifying service provider node(s), there is identified and made known on the private blockchain of a user assigned—e.g. via the exemplifying subscription-bundling node(s)—unique private and public keys derivable from the user-indicative data, which user is deemed legitimate for signing up for ADS feature(s) subscription(s). Furthermore, that is, since there is deployed on a public blockchain network supporting minting of NFTs—and for instance comprising at least one of said set of nodes—a smart contract generating a whitelisting request transaction comprising the unique private and public keys, there is submitted on a public blockchain supporting, offering and/or comprising a community and/or market place, and to which one or more nodes out of the set of nodes—e.g. the exemplifying service provider node(s) and/or subscription-bundling node(s)—may be connected, an entry comprising the same user-associated keys as used in the private domain and representing a request for whitelisting of the user in the public domain. Accordingly, with support from one or more blockchain-stored smart contracts—e.g. deployed via the exemplifying service provider node(s)—there is requested on the NFT-supporting public blockchain—in an entry in which there is embedded at least the unique respective private key and public key associated with the user-permission for the public key—and subsequently for said user—to be approved by, be a party of and/or act on the public blockchain network. Moreover, that is, since there is deployed a smart contract adding the whitelisting request transaction to the public blockchain, which addition whitelists the unique public key for minting of NFTs on the public blockchain network, there is logged to the public blockchain network—e.g. following consensus of the whitelisting request transaction being reached on the network—the whitelisting request transaction, whereby the unique public key associated with the user—and/or a unique address derived and/or hashed from the unique public key—is provided approval rights for minting of NFTs on the public blockchain network. Accordingly, by the whitelisting request transaction with support from one or more smart contracts being added to the network—for instance provided that content of the whitelisting request transaction is found to comply with requirements and/or conditions stipulated in said smart contract(s)—the unique public key—and subsequently the user—is thus given a right to participate in the NFT-supporting public blockchain network, such as acting e.g. minting in the community and/or market place thereof, e.g. in relation to one or more subscription options. Furthermore, that is, since there is deployed on the public blockchain network, a smart contract identifying data indicative of the public key having been included in minting of an NFT on the public blockchain, which NFT comprises and/or points to data indicative of an at least first subscription option out of the one or more subscription options and further comprises a unique address associated with the user derived from the unique public key, there is identified on the NFT-supporting public blockchain network, an event reflecting that an NFT has been minted on the public blockchain, which NFT is connected to and/or associated with the unique public key of said user, and which NFT holds and/or indicates information of a—from the public key hashed and/or derived—unique address and further of one or more subscription options. Accordingly, with support from one or more blockchain-stored smart contracts on the public network, e.g. deployed via the exemplifying subscription-bundling node(s), there is learned that there has been created and/or called—for instance by the user—a mint function on the public blockchain creating an NFT indicating that the unique public key—or a unique address hashed therefrom—is associated with and/or owns said NFT, and further indicating one or more pinpointed subscription options. Subsequently, by identifying that there has occurred a minting of the user-owned NFT on the NFT-supporting blockchain, there may be acknowledged that one or more ADS subscription options identifiable in the NFT, have been selected, such as to be subscribed to by the user. Moreover, that is, since there is deployed on the private blockchain network, a smart contract generating a subscription activation transaction comprising data indicative of the unique address and comprising and/or pointing to the at least first subscription option, there is submitted in the private domain—e.g. via the exemplifying subscription-bundling node(s)—an entry holding and/or embedding data revealing the unique address associated with the user in the public domain, and comprising and/or pointing to the selected one or more subscription options. Furthermore, since there is deployed a smart contract adding the subscription activation transaction to the private blockchain, which addition whitelists activation of the ADS feature set of the at least first subscription option, there is logged to the private blockchain network—e.g. following consensus of the subscription activation transaction being reached on the network—the subscription activation transaction, whereby information of the unique address and further of the selected subscription option(s) is made available on and/or via the private network, subsequently providing approval rights for activation and/or handling of ADS features set(s) of said subscription option(s). Accordingly, by the subscription activation transaction with support from one or more smart contracts being added to the network—for instance provided that content of the subscription activation transaction is found to comply with requirements and/or conditions stipulated in said smart contract(s)—the unique address—or an owner thereof or of the NFT associated therewith—is thus enabled activation of one or more ADS features covered by the one or more subscription options identifiable in the subscription activation transaction. This in turn may enable for and/or support subsequent interaction on the private blockchain between the user—and/or the owner of the unique address—and an ADS-equipped vehicle on the private blockchain network supporting the ADS features covered by the at least first subscription option, for activation and/or handling of the at least first subscription and/or the ADS feature set associated therewith, such as without further involvement of e.g. an ADS feature provider and/or subscriptions bundling provider e.g. OEM.
For that reason, an approach is provided for in an improved and/or alternative manner support subscription management of ADS features, such as provided an improved and/or alternative subscription service for ADS features.
In other words, with the approach and/or setup introduced herein, private data related to e.g. internal workings of available and/or supported ADS features, potential validation information, detailed subscription information and/or business intelligence etc., may be handled on a private blockchain—e.g. between participants such as an ADS feature provider and subscriptions bundling provider e.g. OEM—while at the same time subscriptions of ADS features may be handled on an NFT-supporting public blockchain network providing the ability of minting subscriptions as NFTs. Thereby, privacy requirements and/or needs may be met while at the same time subscription handling may be offered in, to and/or at a public community and/or market place of an NFT-supporting network. That is, ownership of subscriptions may be handled via a public domain, while e.g. configuration and/or status thereof may be handled via a private domain. Thus, with the introduced concept involving community-based subscription management and providing an approach for connecting both private and public domains as discussed herein, toggling of ADS features may be supported and/or enabled in an efficient and/or improved manner.
The technical features and corresponding advantages of the above-mentioned method will be discussed in further detail in the following.
The various aspects of the non-limiting embodiments, including particular features and advantages, will be readily understood from the following detailed description and the accompanying drawings, in which:
Non-limiting embodiments of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which currently preferred embodiments of the disclosure are shown. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Like reference characters refer to like elements throughout. Dashed lines of some boxes in the figures indicate that these units or actions are optional and not mandatory.
In the following, according to embodiments herein which relate to provision of a subscription service for ADS features, there will be disclosed an approach enabling community-based subscription handling of ADS features.
In general, smart contract(s) described throughout this disclosure, may follow general principles of smart contracts on blockchains as known in the art—which may involve programs and/or program code stored on a blockchain that for instance may run when predeterminable conditions are met, automate actions, and/or trigger next actions when conditions are met—however herein configured to control, trigger and/or assist in providing a subscription service for—and/or supporting subscription management of—ADS features. Throughout, a smart contract may for instance be activated upon reception of data from which a transaction is to be based, following which such a transaction—e.g. along with data generated from the smart contract—may be added to the blockchain. Addition of a transaction may—as known in the art—for instance be preceded by consensus having had to been reached on the blockchain prior to the addition. Consensus may be reached in any feasible—e.g. known—manner, such as based on a proof-of-stake approach for instance using consensus algorithm(s) which all—or essentially all—blockchain network nodes may have the ability to run. For instance, a prerequisite for reaching consensus may involve network-connected nodes—such as a majority thereof and/or to an extent stipulated by a proof-of-stake approach—respectively finding a transaction legitimate, eligible and/or allowed. Throughout the disclosure, “a smart contract” may refer to one or more common and/or various smart contracts, and further, according to an example, to “chaincode”.
Referring now to the figures, there is depicted in
As illustrated in an exemplifying manner in exemplifying
The data indicative of the user 4 being eligible for one or more subscription options, may be of any feasible format. Furthermore, deploying on a private blockchain network 3 a smart contract identifying data indicative of a user 4 being eligible for one or more subscription options—representing various ADS feature sets—may be accomplished in any feasible manner, such as by any party and/or node 31, 2 on the private network 3. The private blockchain network 3—to which nodes may be added and/or be removed from over time—may be represented by any arbitrary feasible blockchain network e.g. a peer-to-peer blockchain network, for instance known in the art, and comprise any feasible nodes 31—such as service provider node(s) 5 and/or subscription-bundling nodes(s) 6—as well as other nodes such as e.g. computational nodes, and similarly any arbitrary number of ADS-equipped vehicles 2 and/or nodes associated therewith. Accordingly, nodes 31, 2—for instance including ADS-supporting vehicles 2 such as customer vehicles 2 e.g. a fleet of vehicles 2 for instance associated with and/or belonging to the same OEM—may be connected into a virtual network 3, sharing a blockchain supporting smart contracts through which said nodes 31, 2 may interact. ADS-supporting vehicles 2 potentially comprised in the private blockchain network 3, may potentially have and/or be assigned own respective unique private and public keys and/or blockchain wallets. Similarly, the exemplifying service provider node(s) 5 and subscription-bundling node(s) 6, may have respective validators on the private blockchain 3. Throughout the disclosure, unique private and public keys as referred to herein, may refer to blockchain-related unique private and public keys generated and/or defined as known in the art. The set of nodes 31 on the private network 3 may comprise any arbitrary number and/or constellation of nodes. Optionally, however, and as indicated above, said set of nodes 31 may comprise at least a service provider node 5—e.g. at least a first service provider node—dedicated to an ADS feature provider, and/or a subscriptions-bundling node 6—e.g. at least a first subscription-bundling node—dedicated to a subscriptions bundling provider such as an OEM. Thereby, parties relevant and/or of interest in the subscription process of ADS features, may act and/or be participants of the private network 3, by being associated with and/or controlling nodes 5, 6 thereof. Accordingly, the smart contract—which may be represented by any feasible one or more smart contracts configured to identify data indicative of a user 4 being eligible for one or more subscription options representing various ADS feature sets—may for instance be deployed via the exemplifying service provider node(s) 5. Moreover, the user 4 may refer to any person and/or customer, and may optionally be associated with—e.g. own, lease, share, be assigned a right to use, etc.—an ADS-equipped vehicle 2 connected to the private blockchain network 3. Thereby, the user 4 may have a connection to a vehicle 2 participating in the private blockchain network 3, which vehicle 2 supports one or more ADS features to which one may potentially subscribe. According to an example, “deploying [ . . . ] a smart contract identifying data indicative of a user” may refer to “identifying [ . . . ] with support from a smart contract data indicative of a user” and/or merely “identifying [ . . . ] data indicative of a user”, whereas “on a private blockchain network” may refer to “on a blockchain consortium network”, “on a peer-to-peer, virtual and/or permissioned blockchain network” and/or “on a private distributed ledger technology, DLT, network”. Furthermore, the phrase “private blockchain network comprising a set of nodes” may according to an example refer to “private blockchain network comprising a set of smart contracts”. The phrase “data indicative of a user being eligible”, on the other hand, may refer to “data holding and/or revealing a user being eligible” and/or merely “a user being eligible”. Moreover, “respective unique private key and public key personal to said user” may refer to “respective unique private key and public key associated with and/or unique to said user”, and according to an example further to “wallet on the blockchain personal to said user”. Moreover, “user being eligible for one or more subscription options [ . . . ]” may refer to “a user being eligible for signing up for one or more subscription options”. The phrase “representing various ADS feature sets”, on the other hand, may refer to “indicating various ADS feature sets”, whereas “ADS feature sets” may refer to “ADS feature sets available for and/or offered for activation and/or handling”.
Respective subscription option—which for instance may be bundled by an OEM—may comprise respective subscription time constraints—and/or data indicative of subscription time constraints—which may be of any arbitrary feasible temporal dimensions, for instance relating to a subscription start time, duration and/or end time, such as limiting a subscription to start and/or end at predeterminable point in time and/or have a predeterminable subscription period. Furthermore, according to an example, respective subscription option may further comprise respective subscription cost—and/or data indicative of subscription cost—associated with respective subscription option. Such a potential subscription cost may be of any arbitrary feasible amount, for instance associated with blockchain credits, and may further include zero and/or be empty, i.e. signaling no cost. Furthermore, the subscription options may be represented by any arbitrary number of options, e.g. ranging from a single subscription option up to numerous thereof, and may potentially further respectively be restricted to specific geographical areas. The in respective subscription option indicated ADS feature set—which may be available for activation—may comprise any arbitrary feasible one or more ADS features in any feasible combination, e.g. ranging from a single ADS feature up to numerous thereof. Furthermore, there may in respective subscription option be indicated required ADS-related vehicle configuration pertinent the corresponding ADS feature set, which may be represented by any feasible vehicle configurations relevant in view of said corresponding ADS feature set and/or a therewith associated ADS 21, for instance relating to hardware and/or software—and/or dynamic and/or static—vehicle configurations, such as required ADS-related and/or ADS-relevant equipment and/or sensors such as e.g. surrounding detecting sensors, supported ADS software versions, supported country registration, etc. That is, for an ADS feature to be able—and/or allowed—to be activated in a vehicle, said vehicle need to comply with various prerequisites, such as for instance comprising specific functioning sensor sets and/or equipment, running a certain ADS software version, being registered in a country in which activation is allowable etc., all of which may be representing the ADS-related vehicle configuration(s).
Which ADS features and corresponding required ADS-related vehicle configuration that are supported—and subsequently may be available for bundling into differing subscription options—may be stored in, embedded in, coded into, derivable from and/or available through any feasible source e.g. a digital source such as a table, matrix and/or database, e.g. updated periodically and/or as deemed relevant, for instance provided and/or updated by an ADS features provider e.g. via the exemplifying service provider node(s) 5. In accordance therewith, data revealing one or more ADS features available and/or supported for activation—and corresponding required vehicle configurations relevant therefor such as required ADS-related sensors and/or equipment, supported ADS software versions and/or supported country registrations etc.—may subsequently form basis for one or more subscription alternatives. Optionally—for instance prior to there being deployed on the private blockchain network 3 a smart contract identifying data indicative of a user 4 being eligible for one or more subscription options representing various ADS feature sets—the subscription management system 1 may—e.g. by means of an optional ADS features identifying unit 101—be adapted and/or configured for deploying a smart contract on the private blockchain network 3, defining available ADS features and corresponding required ADS-related vehicle configurations. Thereby, available, possible and/or supported ADS features and corresponding required ADS-related vehicle configurations, may be handled, provided, stored and/or coded—such as via the exemplifying service provider node(s) 5—in one or more smart contracts, and subsequently be made available on and/or derivable from the private blockchain network 3 for subsequent bundling into differing ADS features subscription options. According to an example, the subscription option(s) bundled therefrom and thus available and/or offered for subscription, may in a similar manner potentially be stored in, embedded in, coded into, derivable from and/or available through any feasible source e.g. a digital source such as a table, matrix and/or database available from the private blockchain network 3—and/or in a smart contract such as coded onto the private blockchain 3—e.g. updated periodically and/or as deemed relevant, for instance via the exemplifying subscription-bundling node(s) 6.
In association with identifying data indicative of a user 4 being eligible for one or more subscription options representing various ADS feature sets and which user-indicative data comprises a respective unique private key 41 and public key 42 personal to the user 4—as described above—the subscription management system 1 may further optionally—e.g. by means of an optional eligibility transaction generating unit 103—be adapted and/or configured for deploying on the private blockchain network 3, a smart contract generating a user eligibility transaction comprising data indicative of the unique private and public keys 41, 42, and further—e.g. by means of an optional eligibility transaction adding unit 104—be adapted and/or configured for deploying a smart contract adding the user eligibility transaction to the private blockchain 3, the addition whitelisting the user 4 for monetary transfer(s) of tokens on the private blockchain 3 for ADS feature set(s) activation. Thereby, there is with support from one or more blockchain-stored smart contracts, submitted on the private blockchain network 3—e.g. via the exemplifying service provider node(s) 5—an entry holding data revealing the unique private and public keys 41, 42 associated with the eligible user 4, which entry is logged to the private blockchain network 3—e.g. following consensus of the user eligibility transaction being reached on said network 3—following which the user 4 is given approval rights for monetary activity on the private blockchain 3 in terms of ADS feature(s) activation and/or handling. Deploying on the private blockchain network 3 a smart contract generating such a user eligibility transaction, may be accomplished in any feasible manner, such as by any party and/or node on the private network 3, for instance via the exemplifying service provider node(s) 5 and/or subscription-bundling node(s) 6. The smart contract generating a user eligibility transaction may be represented by any feasible one or more smart contracts configured to generate a user eligibility transaction comprising the unique private and public keys 41, 42. Similarly, the smart contract(s) adding the user eligibility transaction to the private blockchain 3—and which e.g. may be activated upon the user eligibility transaction being sent and/or provided as input thereto—may be configured in any feasible manner for adding the user eligibility transaction to the private blockchain 3 and whitelisting the user 4 for monetary transfer(s) of tokens on the private blockchain 3 for ADS feature set(s) activation. According to an example, “deploying [ . . . ] a smart contract generating a user eligibility transaction” may refer to “generating [ . . . ] with support from a smart contract a user eligibility transaction”, whereas “user eligibility transaction” may refer to “user eligibility record, entry and/or data” and/or merely “transaction”. Similarly, according to an example, “deploying [ . . . ] a smart contract adding the user eligibility transaction to the private blockchain” may refer to “adding [ . . . ] with support from a smart contract the user eligibility transaction to the private blockchain”, whereas “the addition whitelisting said user for monetary transfer(s) of tokens on said private blockchain for ADS feature set(s) activation” may refer to “the smart contract whitelisting said user for monetary transfer(s) of tokens on said private blockchain for ADS feature set(s) activation” and/or “the addition providing, rendering and/or giving approval rights to said user for monetary transfer(s) of tokens on said private blockchain for ADS feature set(s) activation”.
As illustrated in an exemplifying manner in exemplifying
With this approach and/or setup, the user 4 may for instance be anonymous in the public domain 7, while known—e.g. tied via a credit card—in the private domain 3. The public blockchain network 7—to which nodes may be added and/or be removed from over time—may comprise any arbitrary number and/or constellation of nodes, and may further be represented by any arbitrary feasible public blockchain network supporting minting of NFTs in any feasible—e.g. known—manner, such as public blockchain network supporting, offering and/or comprising a community and/or market place, such as for instance commonly known OpenSea. In accordance therewith, nodes—e.g. including one or more nodes of the set of nodes 31 also comprised in the private blockchain network 3—may be connected into a virtual network 7, sharing a blockchain supporting smart contracts through which said nodes may interact in a form of community and/or market place. Minting of NFTs referred to herein may be accomplished in any feasible manner such as based on minting of NFTs as known in the art, e.g. as provided and/or supported by exemplifying OpenSea. Similarly, deploying on a public blockchain network 7 supporting minting of NFTs—and e.g. comprising at least one of said set of nodes 31—a smart contract generating a whitelisting request transaction comprising the unique private and public keys 41, 42, may be accomplished in any feasible—e.g. known—manner, such as by any party and/or node on the public network 7, for instance via the exemplifying service provider node(s) 5 and/or via the exemplifying subscription-bundling node(s) 6. The smart contract may be represented by any feasible one or more smart contracts configured to generate a whitelisting request transaction comprising the unique private and public keys 41, 42. Upon generating the whitelisting request transaction, the private key 41 may potentially be used for signing of said transaction, as known in the art. Moreover, generating of a whitelisting request transaction may occur at any arbitrary feasible time instant following data having been identified on the private blockchain network 3 indicative of the user 4 in question being eligible, such as essentially instantly thereafter, a predeterminable time thereafter and/or when circumstances—e.g. compute resources—so allow. According to an example, “deploying [ . . . ] a smart contract generating a whitelisting request transaction” may refer to “generating [ . . . ] with support from a smart contract a whitelisting request transaction”, whereas “whitelisting request transaction” may refer to “whitelisting request record, entry and/or data”, “transaction representing a request for whitelisting and/or approval of said user” and/or merely “transaction”. Moreover, “a public blockchain network” may according to an example refer to “a public distributed ledger technology, DLT, network”. Furthermore, according to an example, the whitelisting request transaction may further comprise data indicative of and/or specifying one or more subscription option out of the set of subscription options, e.g. at least a first subscription option for which said user 4 is and/or may be eligible.
As illustrated in an exemplifying manner in exemplifying
The smart contract(s) adding the whitelisting request transaction to the public blockchain 7—and which e.g. may be activated upon the whitelisting request transaction being sent and/or provided as input thereto—may be configured in any feasible manner for adding the whitelisting request transaction to the public blockchain 7 and whitelisting the unique public key 42 for minting of NFTs on the public blockchain network 7. Moreover, the user 4 may be represented by and/or identified on the NFT-supporting public network 7 by his/her unique public key 42, and/or a unique address derived and/or hashed therefrom. According to an example, “deploying [ . . . ] a smart contract adding the whitelisting request transaction to the public blockchain” may refer to “adding [ . . . ] with support from a smart contract the whitelisting request transaction to the public blockchain”, whereas “the addition whitelisting said public key for minting NFTs” may refer to “the smart contract whitelisting said public key for minting NFTs”, “the addition providing, rendering and/or giving approval rights to said public key to mint NFTs”, “the addition enabling said unique public key to mint NFTs” and/or “the addition whitelisting said public key for minting of subscription-related NFTs”. Moreover, “whitelisting said unique public key” may according to an example refer to “whitelisting said unique public key and/or a unique address derived and/or hashed from said unique public key”.
As illustrated in an exemplifying manner in exemplifying
Deploying on the public blockchain network 7 a smart contract identifying data indicative of the public key 42 having been included in minting of an NFT on the public blockchain 7, may be accomplished in any feasible manner, such as by any party and/or node on said public network 7, e.g. via the exemplifying subscription-bundling node(s) 6 and/or service provider node(s) 5. Moreover, the unique address associated with the user 4, may be derived from the unique public key 42 personal to the user 4 in any feasible—e.g. known—manner, such as being hashed therefrom. Furthermore, the at least first subscription option may refer to any one, two or more subscription options out of the one or more subscription options respectively representing differing ADS feature sets. The subscription option(s) may for instance be—and/or have been—selected by the user 4 prior to and/or connection with minting the NFT. The subscription option(s) available and/or offered for subscription, may for instance be stored in, embedded in, coded into, derivable from and/or available through any feasible source e.g. a digital source such as a table, matrix and/or database available from the public blockchain network 7 e.g. updated periodically and/or as deemed relevant, for instance via the exemplifying subscription-bundling node(s) 6 and/or service provider node(s) 5. Optionally, however, the one or more subscription options and corresponding required ADS-related vehicle configurations may be derivable from a smart contract deployed on the public blockchain network 7. Thereby, available and/or offered subscription options may be defined in one or more smart contracts on the public blockchain 7, e.g. via the exemplifying subscription-bundling node(s) 6 and/or service provider node(s) 5. In such a manner, the various available subscription options may be updated and/or retrievable in a convenient manner. Additionally or alternatively, the subscription option(s) may have been defined and/or selected in connection with the user 4 being deemed eligible for subscriptions e.g. following the potential funding e.g. by a credit card and/or blockchain wallet being registered related to said user 4, as previously described. According to an example, “deploying [ . . . ] a smart contract identifying data indicative of said public key having been included in minting of an NFT” may refer to “identifying [ . . . ] with support from a smart contract data indicative of said public key having been included in minting of an NFT”, “deploying [ . . . ] a smart contract identifying data indicative of said public key having been comprised, embedded and/or involved in minting of an NFT” and/or “deploying [ . . . ] a smart contract identifying data indicative of that said public key has been included in minting of an NFT”, whereas “data indicative of said public key having been included in minting of an NFT” may refer to “data holding and/or revealing said public key having been included in minting of an NFT”. In a similar manner, “data indicative of at least a first subscription option” may refer to “data holding and/or revealing at least a first subscription option”, whereas “data indicative of an at least first subscription option” may refer to “data indicative of at least a first selected subscription option”. Moreover, “comprising a unique address associated with the user” may refer to “comprising data indicative of a unique address associated with the user”, whereas “comprising a unique address associated with the user derived from said unique public key” may refer to merely “comprising a unique address derived from said unique public key” and according to an example further to merely “comprising and/or pointing to said unique public key”. Furthermore, according to an example, the user-owned NFT may as an alternative to being selected for subscription to be used by the user 4, be made available and/or offered in the community and/or marketplace of the NFT-supporting blockchain 7, such as put up for e.g. sale, lease, hire and/or trade. Thus, a subscription need not necessarily be tied to a specific ADS-equipped vehicle 2 associated with a specific user 4, but may potentially be activated in any private blockchain-connected vehicle 2 supporting the ADS features associated with said subscription.
As illustrated in an exemplifying manner in exemplifying
Deploying on the private blockchain network 3 a smart contract generating such a subscription activation transaction, may be accomplished in any feasible manner, such as by any party and/or node on the private network 3, for instance via the exemplifying subscription-bundling node(s) 6 and/or service provider node(s) 5. The smart contract may be represented by any feasible one or more smart contracts configured to generate a subscription activation transaction comprising data indicative of the unique address and comprising and/or pointing to the at least first subscription option. Moreover, generating of a subscription activation transaction may occur at any arbitrary feasible time instant following the previous identifying of data indicative of that said public key had been included in minting of an NFT on the public blockchain 7, such as essentially instantly thereafter, a predeterminable time thereafter and/or when circumstances—e.g. compute resources—so allow. According to an example, “deploying [ . . . ] a smart contract generating a subscription activation transaction” may refer to “generating [ . . . ] with support from a smart contract a subscription activation transaction”, whereas “subscription activation transaction” may refer to “subscription activation record, entry and/or data” and/or merely “transaction”.
As illustrated in an exemplifying manner in exemplifying
In other words, with the approach and/or setup introduced herein, private data related to e.g. internal workings of available and/or supported ADS features, potential validation information, detailed subscription information and/or business intelligence etc., may be handled on a private blockchain 3—e.g. between participants such as an ADS feature provider and subscriptions bundling provider e.g. OEM—while at the same time subscriptions of ADS features may be handled on an NFT-supporting public blockchain network 7 providing the ability of minting subscriptions as NFTs. Thereby, privacy requirements and/or needs may be met while at the same time subscription handling may be offered in, to and/or at a public community and/or market place of an NFT-supporting network 7. For instance, ownership of subscriptions may be handled via a public domain 7, while e.g. configuration and/or status thereof may be handled via a private domain 3. Thus, with the introduced concept involving community-based subscription management and providing an approach for connecting both private and public domains 3, 7 as discussed herein, toggling of ADS features may be supported and/or enabled in an efficient and/or improved manner.
The smart contract(s) adding the subscription activation transaction to the private blockchain 3—and which e.g. may be activated upon the subscription activation transaction being sent and/or provided as input thereto—may be configured in any feasible manner for adding the subscription activation transaction to the private blockchain 3 and whitelisting activation of the ADS feature set of the at least first subscription option. Potentially, the whitelisting of activation of the ADS feature set of the at least first subscription option, may be supplemented by whitelisting of monetary transfer associated with the at least first subscription option. Furthermore, potential subsequent activation of the ADS feature set of the at least first subscription option, may be achieved in any feasible manner, such as e.g. described in European patent application EP 21 201 973.1, by the same inventor and applicant. According to an example, “deploying [ . . . ] a smart contract adding the subscription activation transaction to the private blockchain” may refer to “adding [ . . . ] with support from a smart contract the subscription activation transaction to the private blockchain”, whereas “the addition whitelisting activation of the ADS feature set of the at least first subscription option” may refer to “the smart contract whitelisting activation of the ADS feature set of the at least first subscription option” and/or “the addition providing, rendering and/or giving approval rights to said unique address for activation of the ADS feature set of the at least first subscription option” and according to an example further to “the addition whitelisting activation of the ADS feature set of the at least first subscription option and further whitelisting monetary transfer associated with the at least first subscription option”.
As further shown in
In Action 1002, the subscription management system 1 deploys—e.g. with support from the user eligibility identifying unit 102—on a private blockchain network 3 comprising a set of nodes 31, a smart contract identifying data indicative of a user 4 being eligible for one or more subscription options representing various ADS feature sets, the user-indicative data comprising a respective unique private key 41 and public key 42 personal to the user 4.
Optionally, said set of nodes 31 may comprise at least a service provider node 5 dedicated to an ADS feature provider and/or a subscriptions-bundling node 6 dedicated to a subscriptions bundling provider, such as an OEM.
Further optionally, said user 4 may be associated with an ADS-equipped vehicle 2 connected to the private blockchain network 3.
In optional Action 1001, which potentially may precede Action 10002, the subscription management system 1 may deploy—e.g. with support from the optional ADS features defining unit 101—a smart contract on the private blockchain network 3, defining available ADS features and corresponding required ADS-related vehicle configurations.
In optional Action 1003, the subscription management system 1 may deploy—e.g. with support from the optional eligibility transaction generating unit 103—on the private blockchain network 3, a smart contract generating a user eligibility transaction comprising data indicative of the unique private and public keys 41, 42.
In optional Action 1004, which may follow upon Action 1003, the subscription management system 1 may deploy—e.g. with support from the optional eligibility transaction adding unit 104—a smart contract adding the user eligibility transaction to the private blockchain 3, the addition whitelisting the user 4 for monetary transfer(s) of tokens on the private blockchain 3 for ADS feature set(s) activation.
In Action 1005, the subscription management system 1 deploys—e.g. with support from the whitelist transaction generating unit 105—on a public blockchain network 7 supporting minting of Non-fungible tokens, NFTs, and for instance comprising at least one of the set of nodes 31, a smart contract generating a whitelisting request transaction comprising the unique private and public keys 41, 42.
In Action 1006, the subscription management system 1 deploys—e.g. with support from the whitelist transaction adding unit 106—a smart contract adding the whitelisting request transaction to the public blockchain 7, the addition whitelisting the unique public key 42 for minting of NFTs on the public blockchain network 7.
In Action 1007, the subscription management system 1 deploys—e.g. with support from the NFT identifying unit 107—on the public blockchain network 7, a smart contract identifying data indicative of the public key 42 having been included in minting of an NFT on the public blockchain 7, said NFT comprising and/or pointing to data indicative of an at least first subscription option out of the one or more subscription options and further comprising a unique address associated with the user 4 derived from the unique public key 42.
Optionally, Action 1007 may comprise the one or more subscription options and corresponding required ADS-related vehicle configurations being derivable from a smart contract deployed on the public blockchain network 7.
In Action 1008, the subscription management system 1 deploys—e.g. with support from the subscription transaction generating unit 108—on the private blockchain network 3, a smart contract generating a subscription activation transaction comprising data indicative of the unique address and comprising and/or pointing to the at least first subscription option.
In Action 1009, the subscription management system 1 deploys—e.g. with support from the subscription transaction adding unit 109—a smart contract adding the subscription activation transaction to the private blockchain 3, the addition whitelisting activation of the ADS feature set of the at least first subscription option
According to an example, the approach introduced herein may be exemplified as data being distributed between—on one hand—community management and subscription NFTs on the public blockchain 7—and on the other hand—vehicle APIs and potentially payment rails on the private blockchain 3. Respective public and private blockchains 3, 7 may be used to manage ADS feature subscriptions, and further, the same keys 41, 42 may be used on both blockchains 3, 7. The private domain 3 may further support KYC—i.e. “know your customer/client”—and/or fiat payments, and private data be kept outside the public blockchain 7. Potential KYC information may be hashed to void security issues. Moreover, the setup may support both static and dynamic NFTs for subscriptions, which may be relevant in consideration of OEM impact of bundling.
According to a further example, the approach introduced herein may further additionally or alternatively be exemplified by an ADS feature provider storing—e.g. coding—into a smart contract in the private domain 3, which ADS features that may be toggled, API(s) and potentially further cost models. The address thereof may e.g. be stored in embedded software for queries. An OEM—e.g. subscriptions bundling provider—may then provide a public address of a user 4 to the ADS feature provider, who may then whitelist the user's 4 public address—which is used in both the public and private networks 7, 3—for subscription minting. The OEM may further provide fiat payment data information to the ADS feature provider, who may connect this to the user's 4 wallet in the private domain 3. The whitelisting of the user 4 may be submitted e.g. by the ADS feature provider to the public contract together with details about the subscription e.g. defined according to OEM specification (bundling, costs, whitelist). The user 4 may then mint a subscription on the public blockchain 7, for instance either a dynamic NFT that may be reused or a static NFT for one-time subscription. Furthermore, details of the subscription may potentially be stored both centralized and distributed to support cases where bundling needs to be updated. The public mint may emit an event that is taken onto on the private blockchain 3 and the subscription may be recreated in that domain 3. This may trigger transfer of a subscription fee on the private blockchain 3 from the user's 4 wallet to the ADS feature provider's wallet, which further may be mirrored by a fiat transaction. A vehicle 2 may then sign the subscription check transaction with the user's 4 public key 42 and provide the vehicle's 2 key. The subscription status may be checked in a smart contract, which may include vehicle configuration and details of what features are included and the reply to the vehicle 2 may include that information. Subscription may be linked to OEM bundle, OEM bundle linked to ADS feature sets. The features may then be active in the vehicle 2 according to the reply.
According to a yet further example, the approach introduced herein may further additionally or alternatively be exemplified by an ADS service provider and OEM collaborating in a private blockchain 3, with each party having their validators on the private blockchain 3. The private blockchain 3 may potentially be storing information related to the ADS service provider and/or ADS features provided therefrom, and not necessarily OEM information. Moreover, in the private blockchain 3, vehicles 2 may be participants and have their own wallets. Furthermore, the ADS feature provider may configure possible ADS feature settings e.g. in a smart contract on the private blockchain 3 including vehicle requirements etc. When a user 4 then e.g. buys a vehicle 2 from the OEM, the user 4 may sign up and register for subscription service and e.g. submit his or her public key 42 on the public blockchain 7, or e.g. receive one from the ADS feature provider. As the user 4 e.g. buys the vehicle 2 and registers his or her wallet, the same wallet may be created in the private blockchain, which may tie the user's 4 wallet to his or her credit card for payments in the private domain 3. The OEM may bundle the ADS feature provider's configuration into subscription options for their OEM, and this information may be coded onto the private blockchain e.g. in a subcontract or as a configuration to the ADS feature provider's configuration contract. The OEM may further set up the NFTs for minting in the public blockchain 7. Payload for the NFT may be both distributed—for e.g. for static meta data such as image—and centralized e.g. for dynamic subscription data such as payment status. The registration of the user's 4 wallet may also whitelist the user's 4 public wallet for subscription minting in the public blockchain 7. When the user 4 then mints a subscription in the public blockchain 7, this may trigger a minting of a subscription to the user 4 on the private blockchain. The private subscription may be done in a smart contract—e.g. provided by the ADS feature provider—and may translate the OEM bundling to ADS features configuration. The subscription may be noted to be paid for by the user's 4 wallet, and a financial transaction may be done e.g. using the user's 4 credit card and may be transacted on-chain on the private blockchain 3 e.g. through a smart contract to divert the payment to the right receivers. Notably, ownership of the subscription may be managed by the public blockchain 7 while the configuration and status of the subscription may be managed by the private blockchain 3. Then, when the user 4 potentially e.g. sits in a—e.g. his or her—vehicle 2, the user 4 may use the NFT on the public blockchain to prove that he or she is the owner of the specific subscription on the private blockchain 3. This verification may trigger a transaction from the vehicle 2, with said vehicle's 2 wallet, that may be executed on the private blockchain 3 to verify the subscription and vehicle configuration and ability to enable the ADS features. As the user 4 potentially uses the ADS features, certain information regarding use and status may be stored on the private blockchain signed with the vehicle's 2 wallet.
The person skilled in the art realizes that the present disclosure by no means is limited to the preferred embodiments described above. On the contrary, many modifications and variations are possible within the scope of the appended claims. It should furthermore be noted that the drawings not necessarily are to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein. Additionally, in the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality.
| Number | Date | Country | Kind |
|---|---|---|---|
| 23158427.7 | Feb 2023 | EP | regional |
