Systems and Methods for Use in Facilitating Interoperability in Network Traffic

This application claims the benefit of, and priority to, U.S. Patent Application No. 63/719,588, filed on Nov. 12, 2024, U.S. Patent Application No. 63/757,702, filed on Feb. 12, 2025, U.S. Patent Application No. 63/829,592, filed on Jun. 24, 2025, and U.S. Patent Application No. 63/862,578, filed on Aug. 12, 2025. The entire disclosure of each of the above applications is incorporated herein by reference.

The present disclosure generally relates to systems and methods for use in facilitating interoperability in network traffic.

This section provides background information related to the present disclosure which is not necessarily prior art.

Network traffic is known to be limited to parties enabled to participate in a network, whereby others are limited from initiating network traffic. In connection with specific service networks, users are often required to enroll to participate in the network. In this way, the users are permitted to initiate traffic on the network (e.g., toll payment messaging, etc.), and also permitted, generally, to enroll with other networks in order to also initiate traffic on those networks.

Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.

Example embodiments will now be described more fully with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

Network traffic may be limited to users enrolled in the given network. Toll agents, for example, require users to enroll, whereby the users enroll with specific credentials to enable the toll agencies to charge for tolls as users utilize toll roads. The network traffic for the toll transactions are generally efficient. That said, when a user is not enrolled, the toll agency extends substantial time and resources to identify the user and to seek payment from the user for use of the toll roads. As such, there is a technical need to provide interoperability between networks to enable enrolled users to interact with toll agents regardless of the toll agents to which the users are enrolled.

Uniquely, the systems and methods herein provide for interoperability between networks, where users are enrolled with at least one of the networks.

In particular, identifiers (e.g., license plates, vehicle identification numbers (VINs), transponder IDs, etc.) are enrolled, through a remote commerce platform, whereby the identifiers are bound to credentials associated with accounts, for one or more toll agents (broadly, service providers). In connection therewith, the remote commerce platform is enabled to perform a search for the identifiers, regardless of the toll agents at which the users are enrolled. Likewise, toll agents are permitted to request identifiers from remote commerce platforms, for which those toll agents do not enroll users (i.e., the identifiers enrolled by other toll agents). In this way, the users are permitted to enroll with a single toll agent (broadly, service provider) (or not enroll with certain toll agents at all), and then use the enrolled credential with other toll agents, without separately enrolling therewith. Likewise, the toll agents may enroll users with one remote commerce platform (or not enroll users at all), and still again have access to users enrolled through toll agents and/or other remote commerce platforms.

In this manner, a centralized enrollment is enabled and maintained as a technical solution to disparate enrollment data.

1 FIG. 100 100 illustrates an example systemin which one or more aspects of the present disclosure may be implemented. Although the systemis presented in one arrangement, other embodiments may include systems arranged otherwise depending, for example, on types of service providers (e.g., toll agents, etc.), accessibility to commerce platforms, privacy regulations and/or concerns, etc.

100 102 104 106 108 110 112 1 FIG. 1 FIG. In the illustrated embodiment, the systemgenerally includes toll agents,, two processing networks,, and two digital wallet providers,, each couple in communication through one or more networks. The one or more networks, as represented by the arrowed lines in, may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, a combination thereof, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in, or any combination thereof.

102 104 100 102 104 114 102 104 102 104 114 114 114 102 104 114 Each of the toll agents,in the systemis generally associated with a toll road, or multiple toll roads in one region, or multiple regions. The toll roads are operated, maintained and controlled by the toll agents,, and also made accessible to users, and vehicle(including equipment onboard the vehicle (e.g., onboard equipment (OBE), etc.), for example, of a user, to travel from one location to another, whereby the toll agent,,charges a fee (e.g., in general, per mile, per toll plaza, etc.). The toll agents,may each include a scanning device (not shown (e.g., input device, network interface, etc., mounted to a gantry, bridge, overpass, or spanning structure, etc.)) (e.g., a roadside unit (RSU), etc.) at one or more points along the toll roads, which is configured to capture an identifier from the vehicle(e.g., through image capture, wireless communication, etc.). The scanning device may be configured to capture an image or the identifier, or receive/read the identifier from a wireless broadcast technology, etc. The identifier may include, for example, a license plate number, a VIN, or an identifier emitted or readable, from a toll device attached to the vehicle(e.g., a transponder ID from a transponder attached to the vehicle, etc.), etc. It should be appreciated that the toll agents,may be configured to charge the user or vehiclefor entry to, exit from, or travel on the toll road(s), etc., i.e., a pay point, where the identifier is captured.

114 It should be appreciated that a toll event may be captured in a number of different technical manners, where the toll event includes the vehiclepassing a pay point, etc.

114 114 102 104 102 104 114 114 114 102 104 114 114 102 104 114 114 114 102 104 102 104 It should be appreciated that the vehiclemay include a network-based application (e.g., executable instructions, etc.), which configures the vehicleto wirelessly communicate (e.g., via a network interface, etc.) with the toll agents,(e.g., including a toll plaza thereof, etc.) (e.g., similar to a toll transponder, etc.). In this additional manner, the toll agents,may be configured to capture, by the scanning device, an identifier of the vehicle(e.g., and/or potentially, a card identifier, as explained herein) as emitted by the vehicle, as the vehiclepasses through the toll agents,. The vehicle identifier may be transmitted (e.g., broadcast, etc.), from the vehicle, as part of wireless communication between the vehicleand the toll agents,. In yet another example, the vehiclemay be configured to record toll events automatically, via telematics data generated/captured by the vehicle, when the vehiclepasses through or by a scanning device at the toll agents,(or at another location). The toll event may further be identified based on a combination of telematics and/or wireless communication with the toll agents,, etc.

102 104 102 104 114 102 104 It should be understood that the toll agents,may also be configured to capture images of vehicle identifiers as the vehicles passes through or by scanning devices (e.g., cameras, etc.), as toll events, for all vehicles or where there is a lack of wireless communication. In the former, the toll agents,may be configured to discard toll events identified based on image capture when there is also wireless communication with the vehicle(e.g., to avoid duplicative toll events, etc.), or vice-versa. As described herein, the toll agents,are configured to store the toll events in memory.

114 It should be appreciated that the data captured (e.g., via scanning devices (e.g., cameras capturing a license plate of the vehicle, etc.), via telematics, etc.) may be transmitted as described herein separately, or together as a batch or group. What's more, in some examples, such captured data may be transmitted by type (e.g., based on how the data is captured, etc.), or in combination by type, etc.

102 104 102 104 114 102 104 1 FIG. While the toll agents,are illustrated inand labeled as toll agents, it should be appreciated that the toll agents,are more generally considered to be service providers. Each of the service providers, in turn, may broadly include any type of service provider associated with one or more vehicles, including, for example, an electric vehicle (EV) charging agent, which is configured to provide for EV charging of the vehiclefor a fee, or a food service provider, which is configured to offer foods, through a drive through, parking lot, etc., in exchange for payment, or a fuel agent, which is configured to provider fuel for a fee, etc. (e.g., the toll agents,are not limited to roadway traffic, etc.). In addition, it should be appreciated that the present disclosure is not limited to vehicle and/or tolling use cases. Any wallet provider may associate an alias (e.g., an identifier, etc.) belonging to a user/consumer within the scope of the present disclosure, and which may then be used for any payment use case, not just for in-vehicle or vehicle-associated commerce, etc.

102 104 106 108 130 102 104 130 102 106 It should be appreciated that the toll agents,may be configured to interact with the processing networks,directly, or through a payment service provider (PSP)(or acquirer bank institution) (e.g., associated with the toll agents,, etc.), as suited to the particular implementation. The PSPis configured, for example, to receive transaction request from the toll agent(e.g., as a authorization payload, etc.), for example, and to compile and transmit an authorization request (e.g., consistent with one or more standards, including, specifically, the ISO 8583 standard, ISO 20022 standard, etc.) to the processing network, for example.

106 108 124 126 106 108 106 108 The processing networks,are generally payment processing networks, which are configured to facilitate transactions through messaging between financial institutions (e.g., an acquirer bank associated with a service provider and the issuerassociated with the user(or vehicle owner/operator), etc.), to provide authorization, clearing and settlement for the transactions. The processing networks,may include, for example, the MASTERCARD, VISA, DISCOVER, etc., processing networks. The processing networks,may be configured to communicate with the financial institutions through one or more standards, including, specifically, the ISO 8583 standard, ISO 20022 standard, etc.

106 116 120 108 118 122 116 118 110 112 102 104 116 118 120 122 102 104 In this example embodiment, the processing networkincludes a secure remote commerce platformand a tokenization platform, while the processing networkincludes a secure remote commerce platformand a tokenization platform. In particular, each of the remote commerce platforms,is configured to enable enrollment of an account, through the wallet providers,, for payment of fees at the toll agents,. In the example embodiment (but not required in all embodiments), the remote commerce platforms,are configured consistent with the secure remote commerce standard, which is provided from EMVCo®. Further, the token platforms,are configured to generate tokens for use in place of account credentials (e.g., PANs, etc.) for transactions at the toll agents,.

110 112 116 118 102 104 In connection with the above, the wallet providers,are configured to act as digital card facilitators (DCFs) for the platforms,. The DCFs, in turn, are configured to facilitate remote transactions, by authenticating users and providing account credentials as appropriate. The DCFs are also configured to gather/facilitate user consent from the users, whereby the account credentials specific to the users (broadly, data) will be securely shared with parties to initiate transactions (e.g., the toll agents,, or others service providers, etc.).

1 FIG. 100 124 106 108 124 In addition, as shown in, the systemalso includes an issuer, which is configured to issue a payment accounts to users and also to interact with the processing network,in connection with facilitating transactions funds by the account issued thereby. The payment accounts are generally credit accounts, debit accounts, prepaid accounts, etc., which are generally associated with a primary account number (PAN), an expiration date, etc. (broadly, credentials), which enable the accounts to be identified and used to fund transactions. The issuerincludes, generally, a bank or other financial institution, etc.

1 FIG. 114 114 114 114 128 110 112 118 118 12 104 With continued reference to, the vehicle, in turn, may include, without limitation, an automobile, a van, a truck, a boat, a watercraft, an airplane, an ATV, a motorcycle, etc. Relatedly, it should be appreciated that communication with the vehiclemay take various forms. In various embodiments herein, the communication may be implemented through messaging consistent with one or more applicable vehicle to everything (V2X) standard formats, such as for example, the SAE J3217 standard, etc. The messaging may be initiated, by the vehicle, or received by the vehicle, in this way with the communication device, the wallet providers,, the commerce platforms,, and the toll agents,, etc.

100 126 114 126 128 128 128 128 110 112 128 128 110 112 128 110 112 Additionally, for purposes of illustration, the systemalso includes a user, which is a person or individual, who is associated with the vehicle(e.g., owner, operator, driver, etc.). The user, in turn, is associated with a communication device. The communication devicemay include a smartphone, laptop, tablet, computer, etc., which is configured to permit the user to participate as described herein. That is, for example, the communication devicemay include a network-based application, which configured the communication deviceto communicate with the wallet provideror, in the manner described herein. Additionally, or alternatively, the communication devicemay include a web browser, which configured the communication deviceto access a website associated with the wallet provideror, whereby the communication deviceis configured to communicate with the wallet provideror, in the manner described herein.

128 128 124 124 124 The communication devicemay further include an application or a web browser (in combination with a website, etc.), which configured the communication deviceto communicate with the issuer. Relatedly, it should be appreciated that the issueris configured to issue a payment account to the issuer.

114 124 110 112 126 126 Notwithstanding the above, it should be appreciated that the vehiclemay also, likewise be configured, via an application, web browser, etc., to communicate with the issuer, wallet provideror, etc. (on behalf of the user) where the useris illustrated below.

3 13 FIGS.- 1 FIG. 116 106 114 116 102 104 118 108 It should be understood that each of the parts illustrated is configured, by executable instructions, to perform one or more of the methods described herein, in whole or in part, or alone or in combination, especially with reference to. In doing so, each part is specifically configured to communicate with the other parts, as described, via the one or more networks illustrated by the arrowed lines shown in. In particular, the remote commerce platform(as part of the processing network) is configured to enroll users, through identifiers of vehicles (or more generally, identifiers), or broadly aliases or proxies for the user, vehicle, account, etc., whereby a payment token is bound to the identifier of the vehicle. The remote commerce platformis then configured to respond to requests for authentication, profile look-ups and checkout requests based on the identifiers of the vehicles from the toll agents,(or broadly service providers) regardless of whether the users directly enrolled through the specific toll agent, or not. The remote commerce platform(as included in the processing network) is configured in the same manner.

114 126 102 104 106 108 110 112 124 1 FIG. While only one vehicle(and one user), two toll agents,, two processing network,, two wallet providers,, and one issuerare illustrated in, a different number of these parts may be included in other system embodiments.

2 FIG. 1 FIG. 200 100 200 200 100 102 104 106 108 110 112 114 124 200 116 118 120 122 200 100 200 illustrates an example computing devicethat can be used in the system. The computing devicemay include, for example, one or more servers, workstations, personal computers, laptops, tablets, smartphones, PDAs, POS devices, etc. In addition, the computing devicemay include a single computing device, or it may include multiple computing devices located in close proximity or distributed over a geographic region, so long as the computing devices are specifically configured to function as described herein. In particular, in the example systemof, each of the toll agents,, the processing networks,, the providers,, the vehicle, and the issuermay include, or be implemented in, computing device, coupled to one or more networks, etc. In addition, the platforms,,,may each be considered a computing device consistent with the computing device. That said, however, the systemshould not be considered to be limited to the computing device, as described below, as different computing devices and/or arrangements of computing devices may be used. In addition, different components and/or arrangements of components may be used in other computing devices.

2 FIG. 200 202 204 202 202 202 Referring to, the example computing deviceincludes a processorand a memorycoupled to (and in communication with) the processor. The processormay include one or more processing units (e.g., in a multi-core configuration, etc.). For example, the processormay include, without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a gate array, and/or any other circuit or processor capable of the functions described herein.

204 204 204 204 202 202 204 202 204 The memory, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memorymay include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memorymay be configured to store, without limitation, transaction data, identifiers, tokens, card identifiers, service identifiers, payloads, rules, and/or other types of data (and/or data structures) suitable for use as described herein. Furthermore, in various embodiments, computer-executable instructions may be stored in the memoryfor execution by the processorto cause the processorto perform one or more of the functions described herein, such that the memoryis a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processorthat is performing one or more of the various operations herein. It should be appreciated that the memorymay include a variety of different memories, each implemented in one or more of the functions or processes described herein.

200 206 202 206 200 114 100 200 206 206 206 In addition in the example embodiment, the computing deviceincludes an output devicethat is coupled to (and is in communication with) the processor. The output deviceoutputs information, either visually or audibly, to a user of the computing device, for example, the vehicle, users associated with other parts of the system, etc. Various interfaces may also be displayed at computing device, and in particular at output device, to display such information. The output devicemay include, without limitation, a presentation unit such as a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an “electronic ink” display; speakers; another computer; etc. In some embodiments, the output devicemay include multiple devices.

200 208 200 208 202 206 208 The computing devicealso includes an input devicethat receives inputs from the user of the computing device(i.e., user inputs) such as, for example, selections of payment account options, inputs of payment accounts to be added, etc. The input deviceis coupled to (and is in communication with) the processorand may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. Further, in various example embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, may behave as both the output deviceand the input device.

200 210 202 204 210 200 202 210 202 In addition, the illustrated computing devicealso includes a network interfacecoupled to (and in communication with) the processorand the memory. The network interfacemay include, without limitation, a wired network adapter, a wireless network adapter, a mobile network adapter, or other device capable of communicating to/with one or more different networks. Further, in some example embodiments, the computing devicemay include the processorand one or more network interfaces (including the network interface) incorporated into or with the processor.

3 FIG. 300 300 100 200 300 100 200 300 100 200 300 illustrates an example methodfor use in facilitating interoperability in network traffic, through adding an account and an identifier. The example methodis described with reference to the system, and also reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

126 114 116 102 At the outset, the userintends to bind an account to the identifier of the vehicle(e.g., license plate number, VIN, other identifier, etc.) in the remote commerce platformfor use at the toll agent.

126 301 110 106 116 114 126 124 126 110 To do so, the usersubmits, at, through wallet provider, a card enrollment request to the processing network, and specifically, the remote commerce platform. The card enrollment request includes the identifier from the vehicle(e.g., a license plate number, VIN, etc.), details for the account/card (e.g., PAN, expiration date, CVC, etc.), and assurance data (e.g., identity and verification data, as necessary, etc.). The assurance data may include signed, unsigned data representative of the wallet provider's identification and verification processes, whereby the useris confirmed to be who he/she says he/she is (e.g., through biometric authentication, etc.), relative to a third party (e.g., the issuer, government agency, etc.), whereby the identifier of the useris effectively assured. The request further includes an identifier specific to the wallet providerand a service identifier specific to the type of service being purchased, or a “tolling payment” identifier in this example, etc.

302 116 120 303 120 124 116 124 304 116 At, the remote commerce platformsubmits a tokenization request to the tokenization platform. The tokenization request includes the details of the card/account (e.g., PAN, expiration date, etc.), etc. At, the tokenization platformsubmits, to the issuer, a request for authorization to tokenize the account at the remote commerce platform, in general or specific to the type of service (i.e., toll payment, in this example). In response, the issuerdecides whether the account is eligible or enabled for tokenization, and responds, at, with permission, in this example, to tokenize the account with the remote commerce platform.

305 120 116 120 120 At, the tokenization platformtokenizes the account by generating a token specific to the account and a unique ID, for example, a token unique reference (TUR) (which is linked to and specific to the token) for the token, and return the TUR (and potentially, the token) to the remote commerce platform. It should be appreciated that the token includes a numeric or alpha-numeric value, which is different than the PAN for the account, yet usable to identify the account (or at least the POAN), through the tokenization platform. As such, the tokenization platformalso stores a mapping between the token and/or the TUR, and also the PAN and/or the account in memory thereof.

116 114 114 120 116 126 110 110 126 102 The remote commerce platform, in turn, stores the unique ID for the token (e.g., the TUR, etc.) in memory along with the identifier of the vehicle, whereby the token, and also the TUR, is bound to the identifier of the vehicle(e.g., is linked to the identifier, is matched to the identifier, etc.). The tokenization platform(or the remote commerce platform, in some examples) then also generates a card identifier (DigitalCardId) for the bound account and identifier as part of a profile for the userand returns, at 306, the card identifier to the wallet provider. The wallet providerthen stores the card identifier in association with the user, for later use with the toll agent.

4 FIG. 400 400 100 200 400 100 200 400 100 200 400 illustrates an example methodfor use in facilitating interoperability in network traffic, through getting a user profile. The example methodis described with reference to the system, and also reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

126 114 114 116 3 FIG. At the outset, it should be appreciated that the userassociated with the vehiclehas enrolled the identifier of the vehiclewith at least the remote commerce platform(as explained, for example, with reference to).

126 104 104 114 401 116 126 116 114 104 126 114 In connection with the userpassing through the toll agent, the toll agentreads the identifier of the vehicleand submits, at, a request to the remote commerce platformto get the profile of the user(from the remote commerce platform). The request includes the identifier of the vehicle. The request may further include a service identifier specific to the service being purchased (e.g., a toll service, etc.), and an identifier specific to the toll agent. In one or more examples, the request may still further include an identity token or other identifier specific to the userand/or other suitable identifier of the vehicle, if applicable.

116 114 204 402 104 116 In response, the remote commerce platformlooks up the identifier of the vehiclein memoryfor the card identifier(s) and returns, at, a response to the request to the toll agent. The response includes one or more card identifiers or DigitalCardId(s), which are bound to the vehicle identifier. Each account in this example is identified by a masked version of the card identifier, or other data to identify accounts relative to one another, if required or desired. The accounts may further be associated with a date the card was bound by the remote commerce platform, and/or the date of last use of the account.

104 400 118 114 100 104 The toll agentthen repeats the steps of methodwith the remote commerce platform, to identify each of the accounts enrolled for the vehicleand available through the remote commerce platforms in system(or others, etc.). The toll agentmay then select one of the accounts, for example, based on a date of last use, card type, prior usage, associated remote commerce platform, or otherwise, etc.

5 FIG. 500 500 100 200 500 100 200 500 100 200 500 illustrates an example methodfor use in facilitating interoperability in network traffic, through initiating a purchase with an account from the profile. The example methodis described with reference to the system, and also reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

400 104 501 116 104 116 126 502 104 116 120 120 116 116 116 From the prior method, the toll agentselects an account, by card identifier (i.e., DigitalCardId), (e.g., based on the timestamp of the last used card, or the last card created, or card type, etc.) and then submits, at, a checkout request to the remote commerce platform, for example. The checkout request includes the card identifier, the identifier of the toll agent, the service identifier and the transaction detail (e.g., amount, type of payload required, currency, etc.). In response, the remote commerce platformlooks up the token for the userbased on the card identifier, compiles the token payload and returns, at, the token payload to the toll agent. In particular, the remote commerce platformrequests the token from the tokenization platformbased on the card identifier (or the TUR, where the card identifier is mapped to the TUR, as applicable), whereupon the token for the account is provided from the tokenization platformto the remote commerce platform. The remote commerce platformalso compiles a cryptogram, for example, a dynamic and encrypted element unique to each transaction, from the transaction based on the amount of the transaction, time of the transaction, etc. In at least one embodiment, the remote commerce platformmay verify the service identifier (e.g., specific to toll type services, etc.) against the service identifier for the token to ensure and/or determine if the type of service being purchased is permitted/eligible.

5 FIG. 104 106 130 104 106 124 124 104 106 Although not shown in, upon receipt of the token payload, the toll agentsubmits an authorization request for the transaction to the processing network(from which the card identifier was selected), via an acquirer and/or PSPassociated with the toll agent(e.g., consistent with the ISO 8583, or ISO 20022 format, etc.). The processing networkvalidates the cryptogram and, based on the validation, forwards the authorization request to the issuer. The issuerthen approves or declines the transaction based on the authorization request and responds to the toll agent, via the processing networkand the acquirer (and/or PSP), with an authorization response.

124 106 The transaction is later cleared and settled between the issuerand the acquirer, through the processing network.

6 FIG. 600 600 100 200 600 100 200 600 100 200 600 illustrates an example methodfor use in facilitating interoperability in network traffic, through enrolling an account. The example methodis described with reference to the system, and also reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

601 126 110 102 114 At, the userinstructs the wallet providerto add an account, with a PAN XXXX-XXXX-XXXX-1234, for use with enabled service providers (in this case, the toll agent), to be linked to an alias (in this case, the identifier of the vehicle, which, in this example, is a license plate number ERT-123).

602 110 116 116 603 116 124 116 120 600 116 110 604 In response, at, the wallet providersubmits a request for enrollment of the account, via an application programming interface (API) of the remote commerce platform. The request includes the PAN XXXX-XXXX-XXXX-1234 along with the expiration date and CVC (card verification code) (broadly, credentials) for the account. The request is submitted through an API call to the remote commerce platform, i.e., Enroll API, in this example, but may be submitted otherwise in other examples. In response, at, the remote commerce platformverifies with the issuerthat the account is eligible for tokenization. If the account is eligible, the remote commerce platformcooperates with the tokenization platformto generate a token (and potentially, a TUR) for the account and to store the same in memory. This may be done at this specific point in method, or at later point, as appropriate. The remote commerce platformthen returns a card identifier specific to the account (and the token) to the wallet provider, at.

110 126 605 116 The wallet providerrequests authentication of the user, at, via the Authentication API call to the remote commerce platform(or otherwise in other embodiments).

606 116 124 124 607 126 128 126 126 126 126 126 608 126 124 609 116 126 116 110 610 At, the remote commerce platforminitiates authentication through the issuer. In response, the issuerissues, at, an identification and verification (ID&V) challenge to the user. This may include, for example, a one-time passcode to the communication deviceof the user(i.e., to device known to be associated with the user), or an instruction for biometric authentication (relative to a biometric reference known to be associated with the user, etc.), of other suitable techniques to identify the userand also verify the identity of the user, etc. Regardless of technique, at, the userresponds by completing the ID&V challenge. The issuerthen provides, at, the authentication result to the remote commerce platform. The result generally includes data indicative of the identity of the userand the technique of verification, etc. Next, as shown, verification data is then provided from the remote commerce platformto the wallet provider, at. The verification data may include, for example, general information about verification technique/event implemented (or potentially, in process) as well as assurance data or proof indicating that the challenge was indeed successfully performed (or is being performed successfully).

611 110 116 110 602 614 102 116 611 Upon receipt of the verification data, at, the wallet providersubmits an add consumer identities (ACI) API call to the remote commerce platform, which includes, among other things, the license plate ERT-123, the card identifier (DigitalCardId), the verification data (e.g., proof of challenge success, etc.), and an indication of the type of assurance required to use the token. In certain implementations, no authentication is required to use the token, while in other implementations (as illustrated below), user authentication is required to use the token. In addition, optionally, in some embodiments, the wallet providermay include a recipient identifier or recipientId in the request for enrollment of the account (at), which may in turn trigger, at, a notification of enrollment (and, potentially, various enrollment data) to be sent to the toll agent(or other service provider) as the recipient (e.g., by the remote commerce platform, etc.) (e.g., in response to the verification data, at, or before or after; etc.).

612 116 116 613 110 110 116 110 102 At, the remote commerce platformbinds the license plate number to the token and card identifier and then stores the same in memory thereof. The remote commerce platformthen returns, at, a correlation identifier and a recognition token (e.g., which serves as a unique identifier for the binding operation, etc.) to the wallet provider. The correlation identifier is a unique identifier that correlates a series of two or more requests to a single session of activity (e.g., an ID tracing to the interaction between the wallet providerand the remote commerce platform, etc.). In this way, the account provided through the wallet provideris enrolled and usable, via the license plate number, with the toll agent.

116 104 104 116 104 104 104 That said, because the remote commerce platformis accessible to the toll agent, the license plate number is also usable by the toll agentto initiate a transaction to the account, or another account, bound to the license plate number through the remote commerce platform. In addition, in embodiments in which the recipientId is added to the request for enrollment, enrollment data may also be sent to the toll agentinforming the toll agentthat the toll agentis permitted to initiate a transaction using the license plate number as well.

7 FIG. 700 700 100 200 700 100 200 700 100 200 700 illustrates an example methodfor use in facilitating interoperability in network traffic, through proceeding with payment for a toll (without separate authentication of the user). The example methodis described with reference to the system, and also reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

6 FIG. 126 114 104 701 104 702 114 114 114 After enrollment, as explained with reference to the methods above including in, for example, the userdrives the vehiclethrough a toll plaza (e.g., having a scanning device) of the toll agent, at. In response, the toll agentcaptures, at, the license plate ERT-123 from the vehicle(e.g., through an image of the vehicle(combined with image processing to extract the license plate number), from wireless broadcast of the license plate number from the vehicle, etc.).

104 703 116 118 116 104 104 126 104 118 104 126 116 126 The toll agentsubmits, at, a checkout request to the remote commerce platform(and potentially, the remote commerce platform, optionally). The checkout request is submitted as a Checkout API call to the remote commerce platform, in this example. The request includes the license plate number ERT-123 and the details of the transaction (e.g., amount, currency, timestamp, etc.). In this example embodiment, the toll agentis aware that authentication of the user is not required (as part of the transaction), for instance, based on the toll agentbeing present in particular region that does not require such authentication (e.g., an unregulated region, etc.). As such, the assurance data here only includes the license plate number as the identity token for the user. It should be appreciated that the toll agent, or the remote commerce platformmay check assurance requirements in other embodiments (e.g., to determine if authentication is instead required (e.g., despite being in an unregulated region, etc.), etc.). Further, the toll agentmay also authenticate the user(potentially apart from the remote commerce platform, etc.), based on an image of the user, captured by the toll plaza, etc. (and specifically facial biometric therein, etc.), in other embodiments.

116 704 116 120 116 120 116 700 126 In response to the checkout request, the remote commerce platformfinds, at, the license plate number ERT-123 in memory and identifies the card identifier bound to that license plate number. The remote commerce platformretrieves, from the tokenization platform, the token for the card identifier and also generates a cryptogram for the transaction (e.g., based on the amount of the transaction, timestamp, etc.). It should be understood that the remote commerce platformmay instead look up the token in memory thereof in other examples (i.e., without interacting with the tokenization platform). In addition, the remote commerce platformchecks the assurance for the card identifier, which, in this example, indicates that no authentication is required, whereby in methodthere is no authentication of the userand the license plate number is sufficient to initiate the transaction.

116 705 104 The remote commerce platformcompiles the token and the cryptogram into a transaction payload and returns, at, the transaction payload to the toll agent.

104 706 130 104 130 106 124 106 124 130 104 707 The toll agentsubmits, at, the payload, or part thereof, to the PSPassociated with the toll agent. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram and the details of the transaction. In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates to the toll agentthe successful authorization of the transaction, at.

116 703 118 104 116 126 114 116 118 118 118 116 126 114 118 104 116 118 7 FIG. As indicated above, the initial request is provided to the remote commerce platform, at, but may also be provided to the remote commerce platform. In such embodiments, the toll agentmay only get a positive response from the remote commerce platform(when the userenrolled the license plate number for the vehicleat the remote commerce platform, but not the remote commerce platform), as above. The remote commerce platformmay respond with an indication that the license plate number is not enrolled, or alternatively, the remote commerce platformmay respond consistent with the remote commerce platform(when the useralso enrolled the license plate number of the vehicleat the remote commerce platform), whereby the toll agentselects among the remote commerce platforms,to proceed consistent with.

8 FIG. 800 800 100 200 800 100 200 800 100 200 800 illustrates an example methodfor use in facilitating interoperability in network traffic, through proceeding with payment for a toll (with authentication of the user). The example methodis described with reference to the system, and also reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

6 FIG. 126 114 104 801 104 802 114 114 208 114 After enrollment, as explained in, for example, the userdrives the vehiclethrough a toll plaza of the toll agent, at. In response, the toll agentcaptures, at, the license plate ERT-123 from the vehicle(e.g., through an image of the vehicle(e.g., camera input device, etc.) (combined with image processing to extract the license plate number), from wireless broadcast of the license plate number from the vehicle, etc.).

104 126 104 104 126 126 700 104 104 803 116 118 114 126 In this example embodiment, the toll agentis aware that authentication of the useris required, for instance, based on the toll agentbeing present in particular region that requires such authentication (e.g., a regulated region, etc.). For instance, the toll agentmay know to authenticate the userin this example (as compared to directly checking out the user, as in method) based on the market in which the toll agentis present (e.g., a regulated market requiring authentication versus an unregulated marked allowing direct checkout). As such, the toll agentmay submit, at, an authentication lookup request, via the Authentication/Lookup API call, to the remote commerce platform(and/or potentially, the remote commerce platform, optionally), where the request includes the license plate number ERT-123 and, potentially, the details of the transaction (e.g., amount, currency, timestamp, etc.). This request may be submitted based on the license plate number (broadly, the particular alias for the vehicleor the user) thereby requiring assurance.

116 804 104 110 104 126 126 In response, the remote commerce platformfinds the license plate number ERT-123 in memory and submits, at, an authentication instruction back to the toll agent. The authentication instruction includes URI data associated with the wallet provider(e.g., an API endpoint for the toll agentto call for authentication of the user, etc.) for the authentication challenge, and also the card identifier for the user, as linked to the license plate number.

104 805 110 116 126 110 126 128 126 806 126 128 128 126 128 110 128 104 114 128 128 807 126 128 128 110 110 126 110 126 808 110 126 104 The toll agent, in turn, at, requests (e.g., based on the URI data, etc.) the wallet provider(i.e., the wallet provider that enrolled the card/account with the remote commerce platform) to authenticate the user. The wallet providerthen identifies the user(e.g., based on suitable identifier, etc.), and also the communication deviceassociated with the user, and submits, at, an authentication challenge to the user, at the communication device. This may include, for example, a one-time passcode to the communication deviceof the user, or biometric authentication at the communication device(e.g., through a wallet application specific to the wallet provider, or native to the communication device, etc.), etc. The authentication challenge may include the details of the transaction, including the name and/or location of the toll agent, amount of the toll, location of the vehicle(or communication device) at the toll plaza (automatically captured by the communication device, etc.), etc. At, the user(via the communication device) consents to the transaction by providing (or the communication deviceprovides) an authentication input back to the wallet provider, whereby the wallet providerauthenticates the user. Based on successful authentication, the wallet providerthen provides a proof of authentication of the user, at, (i.e., verification data from the wallet providerthat the userinitiated the transaction and is in fact informed of the transaction) to the toll agent.

104 809 116 110 The toll agentthen submits, at, a checkout request, via the Checkout API call, to the remote commerce platform. The request includes the license plate number ERT-123, and verification data from the wallet providerand also details of the transaction (e.g., amount, currency, etc.).

810 116 116 120 116 116 811 104 In response, at, the remote commerce platformfinds the license plate number ERT-123 in memory, confirms that the verification data is present, based on the verification data required for the token, and then identifies the bound card identifier for the license plate number. The remote commerce platformthen retrieves, from the tokenization platform, the token for the card identifier, and then, the remote commerce platformalso generates a cryptogram for the transaction (e.g., based on the amount of the transaction, timestamp, etc.). The remote commerce platformcompiles the token and the cryptogram into a transaction payload and returns, at, the transaction payload to the toll agent.

104 812 130 104 130 106 124 106 124 130 104 813 7 FIG. The toll agentsubmits, at, the transaction payload, or part thereof, to the PSPassociated with the toll agent, as is consistent with. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram and the details of the transaction. In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates to the toll agentthe successful authorization of the transaction, at.

116 118 104 116 126 114 116 118 118 114 118 116 126 114 118 116 118 8 FIG. Again, as indicated above, the initial request is provided to the remote commerce platform, but may also be provided to the remote commerce platform. In such embodiments, the toll agentmay only get a positive response from the remote commerce platform(when the userenrolled the license plate number of the vehicleat the remote commerce platform, but not the remote commerce platform), as above. The remote commerce platformmay respond with an indication that the license plate number of the vehicleis not enrolled, or alternatively, the remote commerce platformmay respond consistent with the remote commerce platform(when the useralso enrolled the license plate number of the vehicleat the remote commerce platform), whereby the toll agents selects among the remote commerce platform,to proceed consistent with.

9 FIG. 900 900 100 200 900 100 200 900 100 200 900 illustrates an example methodfor use in facilitating interoperability in network traffic, through proceeding with payment for a toll. The example methodis described with reference to the system, and also with reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

126 114 104 901 104 902 114 114 208 114 After enrollment, the userdrives the vehiclethrough a toll plaza of the toll agent, at. In response, the toll agentcaptures, at, the license plate number from the vehicle(e.g., through an image of the vehicle(e.g., camera input device, etc.) (combined with image processing to extract the license plate number), from wireless broadcast of the license plate number from the vehicle, etc.).

104 903 116 118 114 In this example embodiment, the toll agentsubmit, at, an authentication request, via an authentications/authenticate API call, to the remote commerce platform(and potentially, the remote commerce platform, optionally), where the request includes the license plate number for the vehicle(as an account reference) and, potentially, the details of the transaction (e.g., amount, currency, timestamp, etc.). This request may be submitted based on the license plate (broadly, the particular alias for the user) requiring assurance.

116 110 904 110 116 110 905 116 110 110 In response, the remote commerce platformidentifies the license plate number in memory as being associated with the wallet provider, at. The wallet provider, as identified by the license plate number, is previously enrolled with the remote commerce platform, whereby the license plate number was linked or identified to the specific wallet provider. At, the remote commerce platformnotifies the identified wallet providerof the intent to initiate a transaction associated with the license plate number and indicates the authentication request. The notification includes the license plate number. The notification may be provided as an API call to the wallet provider, or otherwise.

110 126 128 126 906 126 128 126 128 128 104 126 128 128 110 110 126 126 907 110 110 126 126 116 Based thereon, the wallet provideridentifies the user, and also the communication deviceassociated with the user, and submits, at, an authentication challenge to the user. This may include, for example, a one-time passcode to the communication deviceof the user, or a push notification to a wallet application included in the communication device(e.g., via app ID, etc.), or a biometric authentication (e.g., through the wallet application or native to the communication device, etc.), etc. The authentication challenge may include the details of the transaction, including the name and/or location of the toll agent, amount of the toll, etc. In response, the userconsents to the transaction by providing an authentication input, via the communication device, (or the communication deviceresponds (e.g., reports a location thereof, etc.)) back to the wallet provider, which permits the wallet providerto rely on the response as authentication of the useror to authenticate the user. At, the wallet providerprovides an authentication complete result (i.e., assurance from the wallet providerthat the userinitiated the transaction and/or is informed of the transaction, and also the technique by which the userwas authenticated and/or informed, which may be broadly considered proof of authentication) to the remote commerce platform.

908 116 110 116 909 110 104 910 116 110 At, the remote commerce platformgenerates verification data for the transaction, which includes the proof of authentication from the wallet provider. The remote commerce platformprovides an authentication response, at, which indicates the authentication of the user is complete and includes the verification data from the wallet provider. In turn, the toll agentsubmits, at, a checkout request, via the Checkout API, to the remote commerce platform. The request includes the license plate number, and verification data from the wallet providerand also details of the transaction (e.g., amount, currency, timestamp, etc.).

911 116 116 120 116 120 116 116 912 104 In response, and based on the inclusion of the proof of authentication, at, the remote commerce platformfinds the license plate number in memory and identifies a bound card identifier. The remote commerce platformretrieves, from the tokenization platform, the token for the card identifier. It should be understood that the remote commerce platformmay instead lookup the token in memory thereof in other examples (i.e., without interacting with the tokenization platform). The remote commerce platformalso generates a cryptogram for the transaction (e.g., based on the amount of the transaction, timestamp, etc.). The remote commerce platformcompiles the token and the cryptogram into a transaction payload and returns, at, the transaction payload to the toll agent.

104 913 130 104 130 106 124 106 124 130 104 914 The toll agentsubmits, at, the transaction payload, or part thereof, to the PSPassociated with the toll agent. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram, and the details of the transaction (from the transaction payload). In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates to the toll agentthe successful authorization of the transaction, at.

116 118 104 116 114 116 118 118 114 118 116 126 114 118 104 116 118 9 FIG. 9 FIG. Again, as indicated above, the initial request is provided to the remote commerce platformin, but may also be provided to the remote commerce platform. In such embodiments, the toll agentmay only get a positive response from the remote commerce platform(when the user enrolled the license plate number of the vehicleat the remote commerce platform, but not the remote commerce platform), as above. The remote commerce platformmay therefore respond (to the authentication API) with an indication that the license plate number of the vehicleis not enrolled, or alternatively, the remote commerce platformmay respond consistent with the remote commerce platform(when the useralso enrolled the license plate number of the vehicleat the remote commerce platform), whereby the toll agentselects among the remote commerce platforms,to proceed consistent with.

10 FIG. 1000 1000 100 200 1000 100 200 1000 100 200 1000 illustrates an example methodfor use in facilitating interoperability in network traffic, through proceeding with payment for a toll (with authentication of a user). The example methodis described with reference to the system, and also with reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

114 104 1001 104 1002 114 114 208 114 After enrollment, the user drives the vehiclethrough a toll plaza of the toll agent, at. In response, the toll agentcaptures, at, the license plate number from the vehicle(e.g., through an image of the vehicle(e.g., camera input device, etc.) (combined with image processing to extract the license plate number), from wireless broadcast of the license plate number from the vehicle, etc.).

104 1003 116 126 116 110 1004 110 116 110 1005 116 110 110 In turn, the toll agentsubmits, at, a checkout request, via the Checkout API call, to the remote commerce platform. The request includes the license plate number as the identity token for the userand also details of the toll transaction (e.g., amount, currency, timestamp, etc.). In response, the remote commerce platformidentifies the license plate number in memory as being associated with the wallet provider, at. The wallet provideris identified by the license plate number, based on the license plate number being previously enrolled with the remote commerce platform, whereby the license plate number was linked or identified to the specific wallet provider. At, the remote commerce platformnotifies the wallet providerof the intent to initiate a transaction associated with the license plate number and indicates an authentication request. The notification includes the license plate number. The notification may be provided as an API call to the wallet provider, or otherwise

110 126 128 126 1006 126 128 126 128 128 104 126 128 128 110 110 126 126 1007 110 110 126 126 116 Based thereon, the wallet providerthen identifies the user, and also the communication deviceassociated with the user, and submits, at, an authentication challenge to the user. This may include, for example, a one-time passcode to the communication deviceof the user, or a push notification to a wallet application included in the communication device(e.g., via app ID, etc.), or a biometric authentication (e.g., through the wallet application or native to the communication device, etc.), etc. The authentication challenge may include the details of the toll transaction, including the name and/or location of the toll agent, amount of the toll, etc. The userconsents to the transaction by providing an authentication input, via the communication device, (or the communication deviceresponds (e.g., reports a location thereof, etc.)) back to the wallet provider, which permits the wallet providerto rely on the response as authentication of the useror to authenticate the user. At, the wallet providerprovides an authentication assurance, or indication that authentication is complete result (i.e., assurance from the wallet providerthat the userinitiated the transaction and/or is informed of the transaction, and also the technique by which the userwas authenticated and/or informed, which may be broadly considered proof of authentication) to the remote commerce platform.

1008 116 116 120 116 120 116 116 1009 104 At, the remote commerce platformfinds the license plate number in memory and identifies a bound card identifier. The remote commerce platformretrieves, from the tokenization platform, the token for the card identifier. It should be understood that the remote commerce platformmay instead look up the token in memory thereof in other examples (i.e., without interacting with the tokenization platform). In addition, the remote commerce platformalso generates a cryptogram for the transaction (e.g., based on the amount of the transaction, timestamp, etc.). The remote commerce platformcompiles the token and the cryptogram into a transaction payload and returns, at, the transaction payload to the toll agent.

104 1010 130 104 130 106 124 106 124 130 104 1011 The toll agentsubmits, at, the transaction payload, or part thereof, to the PSPassociated with the toll agent. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram and the details of the transaction (based on the transaction payload, etc.). In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates to the toll agentthe successful authorization of the transaction, at.

9 10 FIGS.- 9 FIG. 10 FIG. 104 126 116 110 116 110 126 110 116 With reference to, the toll agentdirectly initiates the authentication of the userwith the remote commerce platform(to use the wallet provider), as compared to the methods above. The remote commerce platform, in turn, then uses an outbound notification to instruct the wallet providerto trigger authentication of the user, whereby the wallet providernotifies the remote commerce platformwhen that authentication is complete. It should be appreciated that the authentication may be included in other methods as a separate sequence, as in, or integrated with the checkout, as in.

116 118 104 116 126 116 118 118 114 118 116 126 114 118 104 116 118 9 FIG. 10 FIG. Again, as indicated above, the initial request is provided to the remote commerce platformin, but may also be provided to the remote commerce platform. In such embodiments, the toll agentmay only get a positive response from the remote commerce platform(when the userenrolled the license plate at the remote commerce platform, but not the remote commerce platform), as above. The remote commerce platformmay therefore respond (to the Checkout API) with an indication that the license plate number of the vehicleis not enrolled, or alternatively, the remote commerce platformmay respond consistent with the remote commerce platform(when the useralso enrolled the license plate number of the vehicleat the remote commerce platform), whereby the toll agentselects among payloads from the remote commerce platforms,to proceed consistent with.

11 FIG. 1100 1100 100 200 1100 100 200 1100 100 200 1100 illustrates an example methodfor use in facilitating interoperability in network traffic, through proceeding with payment for one or more tolls associated with a trip. The example methodis described with reference to the system, and also with reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

104 114 114 114 114 114 114 126 114 104 1101 1102 114 126 128 114 114 104 114 After enrollment, the user may embark on a trip that includes travel through one or more toll plazas associated with the toll agent. In connection therewith, the trip generally includes movement of the vehiclefrom a starting destination (e.g., from a location where the vehiclestarts its engine or powers on the engine, from a location where the vehiclehas not moved for a threshold amount of time, etc.) to another destination, going through one or more toll plazas, and ending when the vehicleis parked (e.g., when the vehicleturns off its engine, when the vehicledoes not move for a threshold amount of time, etc.). In connection therewith, in this example, the userdrives the vehiclethrough the toll plazas of the toll agent, at. In response, at, the vehicle, or a wallet application associated with the userin a communication device, records the toll event for the given trip to a ledger associated with and/or specific to the trip. In example embodiments, the toll event is automatically recorded by the vehicle, for instance, via telematics data when the vehiclepasses through or by a scanning device at the toll plaza of the toll agent(or at another location). It should be understood, in this embodiment, the vehicle, during the duration of the trip, does not initially call for payment, but rather records the toll event(s) for the trip.

126 114 128 It should be appreciated that the usermay designate the trip by route, time interval, or otherwise to the vehicle(or the communication device), so that the toll event is not reported for payment immediately or individually, in this example embodiment.

126 114 114 114 126 128 1103 110 114 126 114 Subsequent to the trip (e.g., as indicated by an input from the user, or a location of the vehicle, or a state of the vehicle(e.g., engine turns off, engine powered off, etc.), etc.), the vehicle, or wallet application of the userat the communication device, sends, at, the toll event information for the trip to the wallet provider. The toll event information includes a listing of toll events for the trip, for example, by toll plaza identifier, time/date, location, etc. The toll event information also includes a license plate number for the vehicle, and other information identifying the userand/or the vehicle, as necessary or desired.

110 1104 116 126 128 In turn, the wallet providersubmits, at, a checkout request, via the Checkout API call, to the remote commerce platform. The request includes the card identifier (identified to the useror communication device), the license plate number, and details of the toll events as assurance data for the trip.

110 126 128 126 126 128 128 126 128 128 104 126 110 110 110 110 116 Optionally (not shown), in connection therewith, the wallet providermay identify the user, and also the communication deviceassociated with the user, and submit an authentication challenge to the user, via the communication device. This may include, for example, a one-time passcode to the communication deviceof the user, or a push notification to a wallet application included in the communication device(e.g., via app ID, etc.), or a biometric authentication (e.g., through the wallet application or native to the communication device, etc.), etc. The authentication challenge may include the details of the toll transaction, including the name and/or location of the toll agent, amount, etc. The userconsents to the transaction by providing an authentication input back to the wallet provider, which permits the wallet providerto authenticate the user. The wallet providermay then provide an authentication assurance, or indication that authentication is complete (i.e., assurance from the wallet providerthat the user is informed of the transaction) to the remote commerce platform.

1105 116 104 116 120 116 104 At, the remote commerce platforminitiates the transaction by making an outbound Payment API call to the toll agent. In particular, the remote commerce platformretrieves, from memory thereof (or from the tokenization platform), the token for the card identifier and also generates a cryptogram for the transaction (e.g., based on the amount of the transaction, timestamp, etc.). The remote commerce platformcompiles the token and the cryptogram, along with the listing of toll events and the license plate number, into a transaction payload and provides the transaction payload to the toll agent.

104 1106 1107 130 104 130 106 124 106 124 130 104 1108 The toll agentcalculates, at, an amount for the toll events, and submits, at, an authorization request (including the token and the cryptogram) for the amount to the PSPassociated with the toll agent. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram and the details of the transaction (based on the transaction payload, etc.). In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates to the toll agentthe successful authorization of the transaction, at.

116 104 104 114 114 114 126 In turn, based on the successful authorization of the transaction for the toll events identified by the remote commerce platform, the toll agentdesignates the specific toll events, as identified in the listing and the license plate number, to be paid in memory thereof. In this way, the toll agentis permitted to manage accounting of toll payments connected with records of vehicles (including the vehicle) passing through the toll plazas thereof, without requiring payment specifically at the time that the vehiclepasses through the toll plaza(s), while also consolidating payments for the vehicles(and user) passing through the toll plaza one or more times during a trip to a single transaction.

12 FIG. 1200 1200 100 200 1200 100 200 1200 100 200 1200 illustrates an example methodfor use in facilitating interoperability in network traffic, for toll events for one or more trip, through, for example, aggregating one or more toll events and/or via a vehicle to everything (V2X) standard, etc.). The example methodis described with reference to the system, and also with reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

1201 104 114 114 114 114 114 114 After enrollment (as explained above), the user embarks, at, on a trip that includes travel through one or more toll plazas associated with the toll agent, for example. In connection therewith, the trip generally includes movement of the vehiclefrom a starting destination (e.g., from a location where the vehiclestarts its engine or powers on, from a location where the vehiclehas not moved for a threshold amount of time, etc.) to another destination, going through one or more tolls, and ending when the vehicleis parked (e.g., when the vehicleturns off its engine or powers off, when the vehicledoes not move for a threshold amount of time, etc.).

126 114 104 114 1202 1202 114 126 128 114 114 114 104 114 114 12 FIG. In connection therewith, in this specific example, the userdrives the vehiclethrough at least three toll plazas of the toll agent. As shown in, the vehiclepasses through a first toll plaza, at. In response, at, the vehicle, or a wallet application associated with the userin the communication deviceor an application native to the vehicle(e.g., SDK, etc.), records the first toll event for the trip to a ledger (e.g., data structure, etc.) associated with and/or specific to the trip. This may be done on a per trip basis, or per toll event, etc. In example embodiments, the first toll event is automatically recorded by the vehicle, for instance, via telematics data when the vehiclepasses through or by a scanning device at the first toll plaza of the toll agent(or based on wireless communication with the toll plaza, as explained above). The toll event is recorded with an identifier of the toll plaza (e.g., toll plaza #1234, etc.) and/or a location (e.g., latitude, longitudes, etc.) thereof, time/date, etc. The vehicle, during the duration of the trip, does not initially call for payment, but rather records the toll event(s) for the trip. That said, in other embodiment, the vehiclemay call for payment at one or more intervals, or per toll event, etc.

1200 114 1203 1203 114 126 128 114 Subsequently, in the method, the vehiclepasses through a second toll plaza, at. In response, at, the vehicle, or a wallet application associated with the userin the communication deviceor an application native to the vehicle(e.g., SDK, etc.), records the second toll event for the trip to a ledger associated with and/or specific to the trip. The toll event is again recorded with an identifier of the second toll plaza and/or a location thereof, time/date, etc.

1200 114 1204 1204 114 126 128 114 And then, in the method, the vehiclepasses through a third toll plaza, at. In response, at, the vehicle, or a wallet application associated with the userin the communication deviceor an application native to the vehicle(e.g., SDK, etc.), records the toll event for the trip to a ledger associated with and/or specific to the trip. The third toll event is recorded with an identifier of the toll plaza and/or a location thereof, time/date, etc.

126 114 In some example embodiments, it should be appreciated that the usermay designate the trip by route, time interval, or otherwise to the vehicle, so that the toll event(s) is(are) not reported for payment immediately or individually. In other example embodiments, however, the toll event(s) may be reported for payment immediately or individually.

12 FIG. 1205 114 114 114 114 With continued reference to, at, in this example, the vehicledetermines that the trip is ended, when the vehicleis parked (e.g., when the vehicleturns off its engine or powered off, when the vehicledoes not move for a threshold amount of time, etc.).

126 114 114 114 114 126 128 1206 Subsequent to the trip (e.g., as indicated by an input from the user, or a location of the vehiclebeing at a destination, or following the vehicledetermining that the trip is ended, or following a time period after the vehicledetermines that the trip is ended; etc.), the vehicle, or wallet application of the userin the communication device, compiles, at, package data for the trip (including the toll event(s) thereof, individually, as applicable). In this embodiment, the package data includes an array of transaction data with each separate transaction concatenated to represent: transaction data 1 for the first toll event, transaction data 2 for the second toll event, and transaction data 3 for the third toll event.

It should be appreciated that any number of toll events/transactions may be included in the trip, or that the toll events may be compiled into package data based on other criteria (e.g., distance, time interval, user preference, etc.).

1207 114 110 110 1208 104 1209 104 114 114 104 104 104 114 114 126 114 114 At, the vehiclerequests an unpredictable number from the wallet provider(e.g., as a per transaction reference for telematics, etc.). In turn, the wallet providerforwards the request, at, to the toll agent. And, at, the toll agentreturns the unpredictable number to the vehicle, for instance, via firebase cloud messaging. That said, in other example embodiments, following the request, the vehiclemay receive the unpredictable number from the toll agentvia a road side unit of the toll agent, etc. The unpredictable number may include a dynamic number (e.g., a number that is not, or cannot be, replicated) that can then be used (e.g., by the toll agentor other party that provided the unpredictable number to the vehicle, etc.) to authenticate the vehicle(and/or the user). For instance, upon receipt of the unpredictable number, the vehicle, for example, may sign the unpredictable number with a private key, thereby providing a level of confirmation that the vehicleis who it says it is.

1210 114 114 104 114 128 114 128 114 128 116 110 114 114 116 611 114 114 6 FIG. At, the vehiclegenerates a signed device specific data identity token (idToken), with device specific data (deviceSpecificData) as a claim of the identity token, for the package data. The device specific data includes a device identifier specific to the vehicle(e.g., VIN, license plate number, etc.), a transaction ID specific to the package data, the transaction data array (or concatenated data), a timestamp, the unpredictable number, a recipient ID (e.g., for the toll agent, etc.), and a secure remote commerce (SRC) digital card ID. The vehicle(or the communication device) signs the device specific data with a private key specific to the vehicle(or the communication device). That is, for example, during enrollment (see, e.g.,), the vehicle(or the communication device) is enrolled with the remote commerce platform, via the wallet provider, for example. In connection therewith, the vehiclegenerates a public-private key pair specific to the vehicleand shares the public key with the remote commerce platform(e.g., at step, etc.) (whereby the private key remains secure, secret to the vehicle). Again, in this example, the vehiclesigns the device specific data with the private key, and generates a signed device specific data identity token or idToken containing the device specific data as the claim. That said, it should be appreciated that the data token may be signed in other manners, or include other content, within the scope of the present disclosure.

1211 114 110 110 306 604 611 110 1212 104 102 104 3 FIG. 6 FIG. 12 FIG. At, the vehiclesends the signed device specific data to the wallet provider. In response, the wallet providercreates a message including the signed device specific data (e.g., as a claim of the idToken, as a name of the idToken, which is inside the idToken, etc.) and also the card identifier specific to the account, as identified from the device identifier (e.g., as provided at stepinor steps/in, etc.) (e.g., such that the device specific data is inside the idToken, and the card identifier is inside the device specific data; etc.). The wallet providerthen provides, at, the message to the toll agent. In this specific embodiment, the message is consistent with one or more applicable vehicle to everything (V2X) standard formats, such as for example, the SAE J3217 standard, etc. While the V2X standard is described with regard to the above discussion, it should also be appreciated that other communications within(and any of the communications described herein, for example, involving the toll agents,) may also be consistent with the V2X standard.

114 104 110 104 116 It should be appreciated that in one or more embodiments, the vehiclemay be configured to communicate directly with the toll agent(e.g., in real time, etc.) (e.g., also consistent with the V2X standard(s), etc.), rather than communicating through the wallet provider. In this example, the signed device specific data includes the card identifier or other suitable token reference, etc., or the toll agentmay be configured to secure the card identifier, for example, from the remote commerce platformor otherwise, etc.

104 1213 The toll agentcalculates, at, a total amount of the tolls identified in the message, as a sum of the different toll events included therein.

114 1214 104 110 114 110 104 1215 12 FIG. It should be appreciated that the vehiclemay embark on various additional trips (i.e., as indicated by “another trip” in), whereby, at, the toll agentreceives, from the wallet provider, another message for each of the subsequent trip(s) (after the vehicleand the wallet providerperform as indicated above), and then, the toll agentcalculates, at, a total amount of the tolls identified in the additional message(s), as a sum of the different toll events included therein.

1216 104 114 114 104 104 208 114 114 114 104 Next, at, the toll agentidentifies any toll event captured through a license plate number of the vehicle. That is, the communication between the vehicleand the toll agent, at the toll plaza, may be incomplete (or does not occur), whereby the toll agentcaptures an image of the vehicle's license plate number (e.g., via the camera input device, etc.) as the vehiclepasses therethrough to thereby identify the vehicleand record a toll event for the vehicle. As such, the toll agentidentifies the toll event(s), captured via image of the vehicle's license plate number, but not captured otherwise. These toll events are also those toll events missed by telematics, as described herein.

1217 104 110 At, the toll agentidentifies the toll events to a specific card identifier based on license plate number (e.g., based on the message from the wallet providerwhich includes the card identifier linked to the license plate number, etc.) and aggregates the toll events, which are specific to an interval (e.g., last 7 days, last month, etc.), or based on an aggregate amount of the toll event (e.g., above $10.00, above $20.00, etc.). In this example, the toll events are aggregated based on common card identifiers, which are also associated with license plate number or other vehicle identifiers. When the threshold condition is meant (e.g., interval or aggregate amount, etc.), the toll agent aggregates the toll amounts for the toll events to be aggregated, along with the data specific to the toll events (e.g., toll plaza identifier, time/date, etc.).

1218 104 104 In addition, at, the toll agentgenerates a device specific data JSON object for the toll event(s) identified by license plate captured by the toll agentat the toll plaza. This JSON object is representative of the toll event(s), including, without limitation, the device identifier (e.g., license plate number, VIN, etc.), the transaction data (e.g., toll amount, toll plaza identifier, etc.) a timestamp (e.g., time/date, etc.), a srcDigitalCardID, a recipient ID, etc.

1219 104 1202 1204 104 104 104 116 104 1220 104 104 104 1213 104 At, the toll agentgenerates assurance data idToken for the toll even(s) identified at steps-. In particular, the toll agentincludes the array of signed device specific data token(s) in the signed data private claim of the idToken, effectively signing them with a key specific to the toll agent. That is, the key is a private key for the toll agent, which is part of a key pair generated at onboarding with the remote commerce platform (with the public key shared with the remote commerce platform). Each signed device specific data token is specific to a trip (or toll event, depending on how they are sent to the toll agent, etc.) and includes the toll events for that trip. At, the toll agentgenerates an assurance data idToken for the license plate identified toll events. In particular, the toll agentincludes the device specific data JSON object for the toll event(s) identified by license plate by the toll agent(at step) in the signed_data private claim, effectively signing it with a key specific to the toll agent.

104 1221 116 The toll agentthen submits, at, via a Checkout API, a payload request for a transaction to fund the toll event(s) to the remote commerce platform. The payload request includes, for example, the card identifier for the account to fund the toll events, transaction details (e.g., amount and sum of the toll events, etc.), and the assurance data tokens for the vehicle captured and the license plate identified toll events. The assurance data tokens include a listing of the toll events therein and related details.

In this way, the toll events, whether telematics-based or license plate-based, are forwarded together in the same payload request (for one transaction), yet the two types of toll events are included in separate assurance data identity tokens to identify the difference in verification, etc., associated with the same.

1222 116 114 128 104 116 114 116 1223 120 116 104 1224 In response, at, the remote commerce platformverifies the signature(s) included in the assurance data idToken(s) based on the public keys shared from the vehicle(or the communication device) during enrollment and the toll agentduring onboarding, respectively. In addition, the remote commerce platformvalidates the card identifier included in the transaction request as linked or bound to the device identifier for the vehicle. When verified, and validated, the remote commerce platformgenerates, at, a transaction payload, which includes a token specific to the account (e.g., retrieved from the tokenization providerbased on the card identifier or other token reference) and a cryptogram, which is representative of, among other things, the transaction amount for the sum or total of the toll events, timestamp, etc. The transaction payload may include further details of the transaction, as necessary or desired. The transaction payload is transmitted from the remote commerce platformto the toll agent, at.

104 1225 130 104 130 106 124 106 124 130 1226 104 104 The toll agentthen communicates, at, the transaction payload to the PSP(or an acquirer associated with the toll agentas part of an authorization request for the transaction to pay the tolls. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram and the details of the transaction (based on the transaction payload, etc.). In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates, at, the successful authorization of the transaction to the toll agent. The toll agentis then permitted to mark the toll events included therein as paid.

104 1227 116 116 116 1228 110 126 In turn, the toll agentissues, at, custom data, via the Confirmation API of the remote commerce platform, to the remote commerce platform. The custom data may include any suitable data including, as in this example, receipt data indicating the specific toll event paid by the transaction. The remote commerce platformthen provides, at, the customer data to the wallet provider, to be populated into an interface for the userto review, as desired.

13 FIG. 1300 1300 100 200 1300 100 200 1300 100 200 1300 illustrates an example methodfor use in facilitating interoperability in network traffic, through proceeding with payment for a toll. The example methodis described with reference to the system, and also with reference to the computing device. However, it should be understood that the method(and other methods herein) are not limited to the systemor the computing device, as the method, for example, may be implemented, at least in part, in other parts of suitable systems, or in multiple other computing devices or systems. Likewise, the systems and the computing devices herein (including the systemand the computing device) should not be understood to be limited to the example method.

126 114 104 1301 104 1302 114 114 208 114 After enrollment, the userdrives the vehiclethrough a toll plaza of the toll agent, at. In response, the toll agentreads, at, the license plate number from the vehicle(e.g., through an image of the vehicle(e.g., camera input device, etc.) (combined with image processing to extract the license plate number), from wireless broadcast of the license plate number from the vehicle, etc.).

104 1303 116 114 116 1304 116 116 In turn, the toll agentsubmits, at, a profile request to the remote commerce platform. The request includes the license plate number of the vehicle, as the identity token therefore. In response, the remote commerce platformsearches for the license plate number, and identifies one or more card identifier specific to the license plate number. At, the remote commerce platformreturns a listing of the card identifiers for the account linked to the license plate number at the remote commerce platform.

1303 1304 11188 104 It should be appreciated that stepsandmay be duplicated with the remote commerce platform, whereby no card identifier, or additional card identifier may be returned to the toll agent.

104 1305 116 116 104 126 116 110 1306 110 116 1307 116 110 110 In response, the toll agentselect a card identifier (e.g., based on card type, a last used card identifier, a most recently issued card identifier, etc.), and submits, at, a checkout request, via the Checkout API call, to the remote commerce platform. That is, the remote commerce platformexposes the Checkout API, and the toll agentcalls the checkout API as a request to checkout. The request includes the license plate number as the identity token (or idToken) for the userand also details of the toll transaction (e.g., amount, currency, timestamp, etc.). In response, the remote commerce platformidentifies the license plate number in memory as being associated with the wallet provider, at. The wallet provideris identified by the license plate number, based on the license plate number being previously enrolled with the remote commerce platform. At, optionally, the remote commerce platformnotifies the wallet providerof the intent to initiate a transaction associated with the license plate number and indicates an authentication request. The notification includes the license plate number. The notification may be provided as an API call to the wallet provider, or otherwise

110 126 128 126 1308 126 128 126 128 128 104 126 128 128 110 110 126 126 1309 110 110 126 126 116 Based thereon, the wallet providerthen identifies the user, and also the communication deviceassociated with the user, and submits, at, optionally, an authentication challenge to the user. This may include, for example, a one-time passcode to the communication deviceof the user, or a push notification to a wallet application included in the communication device(e.g., via app ID, etc.), or a biometric authentication (e.g., through the wallet application or native to the communication device, etc.), etc. The authentication challenge may include the details of the toll transaction, including the name and/or location of the toll agent, amount of the toll, etc. The userconsents to the transaction by providing an authentication input, via the communication device, (or the communication deviceresponds (e.g., reports a location thereof, etc.)) back to the wallet provider, which permits the wallet providerto rely on the response as authentication of the useror to authenticate the user. At, optionally, the wallet providerprovides an authentication assurance, or indication that authentication is complete result (i.e., assurance from the wallet providerthat the userinitiated the transaction and/or is informed of the transaction, and also the technique by which the userwas authenticated and/or informed, which may be broadly considered proof of authentication) to the remote commerce platform.

1310 116 116 120 116 120 116 116 1311 104 At, the remote commerce platformfinds the license plate number in memory and identifies a bound card identifier. The remote commerce platformretrieves, from the tokenization platform, the token for the card identifier. It should be understood that the remote commerce platformmay instead look up the token in memory thereof in other examples (i.e., without interacting with the tokenization platform). In addition, the remote commerce platformalso generates a cryptogram for the transaction (e.g., based on the amount of the transaction, timestamp, etc.). The remote commerce platformcompiles the token and the cryptogram into a transaction payload and returns, at, the transaction payload to the toll agent.

104 1312 130 104 130 106 124 106 124 130 104 1313 The toll agentsubmits, at, the transaction payload, or part thereof, to the PSPassociated with the toll agent. The PSPinitiates, through the processing network, for example, and the issuer, authorization of the transaction based on the token, the cryptogram and the details of the transaction (based on the transaction payload, etc.). In connection therewith, the processing networkvalidates the cryptogram and the issuerapproves the transaction, whereby the PSPindicates to the toll agentthe successful authorization of the transaction, at.

In view of the above, the systems and methos herein facilitate interoperability in network traffic. As such, the enrollment of users with a remote commerce platform, through one service provider, extends the enrollment to other service providers which rely on the remote commerce platform (even where the service provider enrolls users through a different remote commerce platform). What's more, it should be appreciated that the above technical improvement is imposed in real time (e.g., within milliseconds, up to one second, etc.), whereby the accessibility of the user to different service providers is extended beyond the enrollment of the user for similar interactions based on the identifier of the user, or broadly, proxy or alias.

In this way, the systems and methods herein leverage the license plate number for the vehicle to initiate a secure interaction based thereon. As such, extended functionality is provided through the toll agent and remote commerce platform with limited impact on the user, or devices associated therewith.

Additional example embodiments of the present disclosure are further provided as follows.

Embodiment 1. A computer-implemented method for use in facilitating interoperability of network traffic, the computer-implemented method comprising: identifying, by a vehicle computing device, a first toll event at a first toll plaza of a toll agent, as part of a trip; identifying, by the vehicle computing device, a second toll event at a second toll plaza of the toll agent, as part of the trip; generating, by the vehicle computing device, package data for the trip, the package data including an array of transaction data for the first toll event and the second toll event; generating a token for the trip, wherein the token includes signed device specific data, the device specific data including a device identifier for the vehicle, the package data, and a timestamp; and transmitting, by the vehicle computing device, the token to the wallet provider.

Embodiment 2. The computer-implemented method of Embodiment 1, further comprising determining the trip is ended, based on a condition of the vehicle; and wherein generating the package data includes generating the package data based on the trip ending.

Embodiment 3. The computer-implemented method of Embodiment 1 or Embodiment 2, wherein the package data includes a concatenated listing of the array of transaction.

Embodiment 4. The computer-implemented method of any one of Embodiments 1-3, further comprising signing, by the vehicle computing device, the device specific data with a private key specific to the vehicle computing device.

Embodiment 5. A computer-implemented method for use in facilitating interoperability of network traffic, the computer-implemented method comprising: receiving, for each of one or more trips, a message from a wallet provider computing device, each message including a signed data packet for each of the one or more trips and a card identifier, each signed data packet signed by a private key specific to a vehicle involved in one or more toll events represented by the signed data packet; calculating, by a toll agent computing device, an amount for the toll event(s) of the one or more trips; generating, by the toll agent computing device, an assurance data token based on the signed data packet; and calling, by the toll agent computing device, a checkout application programming interface (API) of a remote commerce platform, to initiate a transaction for payment of a toll(s) associated with the toll event(s), the checkout API call including the generated assurance data token.

Embodiment 6. The computer-implemented method of Embodiment 5, further comprising: identifying, by the toll agent computing device, one or more toll events based on a license plate number of the vehicle; and generating, by the toll agent computing device, a second assurance data token for the identified one or more toll events based on the license plate number; and/or wherein the checkout API call includes the second assurance data token.

Embodiment 7. The computer-implemented method of Embodiment 6, wherein the assurance data token based on the signed data packet is specific to one or more other toll event identified at one or more toll plazas, based on telematics.

Embodiment 8. The computer-implemented method of any one of Embodiments 5-7, further comprising: verifying, by the remote commerce platform, each of the signed data packet(s) based on a public key specific to the private key and shared by the vehicle; and generating a checkout payload for the transaction, based on the signed data packet being verified; and/or wherein generating the assurance data token includes signing, by the toll agent computing device, an array of the signed device specific data.

Embodiment 9. A computer-implemented method for use in facilitating interoperability of network traffic, the computer-implemented method comprising: receiving, at a computing device of a processing network, a checkout request for a service from a service provider, the checkout request including an alias; identifying, by the computing device, a token specific to an account, based on the alias; compiling, by the computing device, a checkout payload including the token and a cryptogram specific to a transaction for the service from the service provider; and returning the checkout payload to the service provider.

Embodiment 10. The computer-implemented method of Embodiment 9, further comprising: receiving, by the computing device, a request from the service provider; and instructing, by the computing device, the service provider to authenticate the user, prior to receiving the checkout request, the checkout request including verification data from authentication of the user.

Embodiment 11. The computer-implemented method of Embodiment 9 or Embodiment 10, further comprising, prior to receiving the checkout request, enrolling the user, by which the token is bound to the account, through a different service provider.

Embodiment 12. The computer-implemented method of any one of Embodiments 9-11, wherein the alias is an identifier of a vehicle.

Embodiment 13. The computer-implemented method of Embodiment 12, further comprising: reading, by a scanning device of a toll agent, the alias; and submitting, by a computing device of the toll agent, to multiple remote commerce platforms, a checkout request for a toll, the checkout request including the alias.

Embodiment 14. The computer-implemented method of Embodiment 13, wherein the alias includes a license plate, a vehicle identification number (VIN), or a transponder identifier; and/or wherein the service from a service provider includes one of: a toll from a toll agent and an EV charging from an EV charging agent.

Embodiment 15. A computer-implemented method for use in facilitating interoperability of network traffic, the computer-implemented method comprising: receiving, by a commerce platform computing device, a vehicle identifier from a toll agent, the vehicle identifier specific to a vehicle and captured at a toll plaza of the toll agent; identifying, by the commerce platform computing device, a wallet provider associated with the vehicle identifier; requesting, by the commerce platform computing device, from the identified wallet provider, authentication of a user associated with the vehicle, whereby the wallet provider authenticates the user at the vehicle or a communication device associated with the user; receiving, by the commerce platform computing device, from the wallet provider, an authentication complete result; and providing, by the commerce platform computing device, a transaction payload for a transaction to pay a toll for the vehicle passing through the toll plaza, the transaction payload including a token specific to the card identifier.

Embodiment 16. The computer-implemented method of Embodiment 15, wherein the vehicle identifier is a license plate number.

Embodiment 17. The computer-implemented method of Embodiment 15 or Embodiment 16, wherein receiving the vehicle identifier includes: exposing, by the commerce platform computing device, a checkout application programming interface (API); and receiving the vehicle identifier as part of a checkout request, via the checkout API.

Embodiment 18. The computer-implemented method of any one of Embodiments 15-17, further comprising retrieving, by the commerce platform computing device, the card identifier based on the vehicle identifier.

Embodiment 19. The computer-implemented method of any one of Embodiments 15-18, further comprising: requesting, by the commerce platform computing device, from a tokenization platform, the token indicative of an account, based on the card identifier; and receiving, at the commerce platform computing device, from the tokenization platform, the token.

Embodiment 20. The computer-implemented method of any one of Embodiments 15-19, further comprising: capturing, by a toll agent, the vehicle identifier of the vehicle at the toll plaza; and transmitting the vehicle identifier to the commerce platform computing device.

Embodiment 21. The computer-implemented method of Embodiment 20, further comprising: requesting, by the toll agent, from the commerce platform computing device, the card identifier associated with the vehicle identifier; and receiving, by the toll agent, from the commerce platform computing device, the card identifier; and submitting, by the toll agent, the card identifier with the vehicle identifier to the commerce platform computing device.

Embodiment 22. The computer-implemented method of any one of Embodiments 15-21, wherein the transaction payload further includes a cryptogram specific to the transaction.

Embodiment 23. A computer-implemented method for use in facilitating interoperability of network traffic, the computer-implemented method comprising: identifying, by a computing device, a first toll event for a vehicle at a first toll plaza of a toll agent, as part of a trip; identifying, by the computing device, a second toll event for the vehicle at a second toll plaza of the toll agent, as part of said trip; generating, by the computing device, toll event information for the trip, the toll event information including a listing of the first toll event and the second toll event; determining, by the computing device, that the trip is ended; based on the determination that the trip is ended, transmitting the toll event information for the trip to a wallet provider computing device; submitting, by the wallet provider computing device, via a checkout application programming interface (API), to a remote commerce platform computing device, a request to transact for an aggregate toll, the request including a card identifier specific to an account associated with the vehicle, a device identifier of the vehicle, and the listing of toll events; whereby the remote commerce platform computing device submits, via a make payment API call to the toll agent, an instruction, which includes the listing of toll events and a token specific to the card identifier.

Embodiment 24. The computer-implemented method of Embodiment 23, wherein identifying the first toll event for the vehicle is based on a location of the vehicle and/or wireless interaction with the toll plaza of the toll agent.

Embodiment 25. The computer-implemented method of Embodiment 23 or Embodiment 24, wherein the computing device is a computing device integrated into the vehicle.

Embodiment 26. The computer-implemented method of any one of Embodiments 23-25, wherein the computing device is a communication device separate form the vehicle.

Embodiment 27. The computer-implemented method of any one of Embodiments 23-26, further comprising identifying, by the computing device, a third toll event for the vehicle at a third toll plaza of the toll agent, as part of said trip; and wherein determining that the trip is ended is based on the vehicle reaching a destination identified by a user associated with the vehicle or a condition of the vehicle.

Embodiment 28. The computer-implemented method of any one of Embodiments 23-27, wherein the instruction to make payment further includes a cryptogram, which is specific to the transaction.

Embodiment 29. The computer-implemented method of any one of Embodiments 23-28, further comprising: requesting, by the remote commerce platform computing device, from a tokenization platform, the token indicative of the account, based on the card identifier; and receiving, at the remote commerce platform computing device, from the tokenization platform, the token.

Embodiment 30. The computer-implemented method of Embodiment 29, wherein the remote commerce platform computing device and the tokenization platform are part of a processing network; and further comprising: receiving, by the processing network, an authorization request from a payment service provider (PSP) associated with the toll agent, the authorization request including a payment for the listing of toll events; and transmitting the authorization request to an issuer of the account.

Again and as previously described, it should be appreciated that the functions described herein, in some embodiments, may be described in computer executable instructions stored on a computer readable media, and executable by one or more processors. The computer readable media is a non-transitory computer readable storage medium. By way of example, and without limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.

It should also be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the operations recited in the claims such as, for example: (a) identifying a first toll event at a first toll plaza of a toll agent, as part of a trip; (b) identifying a second toll event at a second toll plaza of the toll agent, as part of the trip; (c) generating package data for the trip, the package data including an array of transaction data for the first toll event and the second toll event; (d) generating a token for the trip, wherein the token includes signed device specific data, the device specific data including a device identifier for the vehicle, the package data, and a timestamp; (e) transmitting, by the vehicle computing device, the token to the wallet provider; (f) determining the trip is ended, based on a condition of the vehicle; and/or (g) signing the device specific data with a private key specific to the vehicle computing device.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the operations recited in the claims such as, for example: (a) receiving, for each of one or more trips, a message from a wallet provider computing device, each message including a signed data packet for each of the one or more trips and a card identifier, each signed data packet signed by a private key specific to a vehicle involved in one or more toll events represented by the signed data packet; (b) calculating an amount for the toll event(s) of the one or more trips; (c) generating an assurance data token based on the signed data packet; (d) calling, by the toll agent computing device, a checkout application programming interface (API) of a remote commerce platform, to initiate a transaction for payment of a toll(s) associated with the toll event(s), the checkout API call including the generated assurance data token; (g) identifying one or more toll events based on a license plate number of the vehicle; (h) generating a second assurance data token for the identified one or more toll events based on the license plate number; (i) verifying each of the signed data packet(s) based on a public key specific to the private key and shared by the vehicle; and/or (j) generating a checkout payload for the transaction, based on the signed data packet being verified.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the operations recited in the claims such as, for example: (a) receiving a checkout request for a service from a service provider, the checkout request including an alias; (b) identifying a token specific to an account, based on the alias; (c) compiling a checkout payload including the token and a cryptogram specific to a transaction for the service from the service provider; (d) returning the checkout payload to the service provider; (e) receiving a request from the service provider; (f) instructing the service provider to authenticate the user, prior to receiving the checkout request, the checkout request including verification data from authentication of the user; and/or (g) enrolling the user, by which the token is bound to the account, through a different service provider.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the operations recited in the claims such as, for example: (a) receiving a vehicle identifier from a toll agent, the vehicle identifier specific to a vehicle and captured at a toll plaza of the toll agent; (b) identifying a wallet provider associated with the vehicle identifier; (c) requesting, from the identified wallet provider, authentication of a user associated with the vehicle, whereby the wallet provider authenticated the user at the vehicle or a communication device associated with the user; (d) receiving, by the commerce platform computing device, from the wallet provider, an authentication complete result; (e) providing a transaction payload for a transaction to pay a toll for the vehicle passing through the toll plaza, the transaction payload including a token specific to the card identifier; (f) retrieving the card identifier based on the vehicle identifier; (g) requesting, from a tokenization platform, the token indicative of an account, based on the card identifier; and/or (h) receiving, at the commerce platform computing device, from the tokenization platform, the token.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the operations recited in the claims such as, for example: (a) identifying a first toll event for a vehicle at a first toll plaza of a toll agent, as part of a trip; (b) identifying a second toll event for the vehicle at a second toll plaza of the toll agent, as part of said trip; (c) generating toll event information for the trip, the toll event information including a listing of the first toll event and the second toll event; (d) determining that the trip is ended; (e) based on the determination that the trip is ended, transmitting the toll event information for the trip to a wallet provider computing device; (f) submitting, via a checkout application programming interface (API), to a remote commerce platform computing device, a request to transact for an aggregate toll, the request including a card identifier specific to an account associated with the vehicle, a device identifier of the vehicle, and the listing of toll events; (g) identifying a third toll event for the vehicle at a third toll plaza of the toll agent, as part of said trip; (h) requesting, from a tokenization platform, the token indicative of the account, based on the card identifier; and/or (i) receiving, from the tokenization platform, the token.

Example embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.

When a feature is referred to as being “on,” “engaged to,” “connected to,” “coupled to,” “associated with,” “included with,” or “in communication with” another feature, it may be directly on, engaged, connected, coupled, associated, included, or in communication to or with the other feature, or intervening features may be present. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

In addition, as used herein, the term product may include a good and/or a service.

Although the terms first, second, third, etc. may be used herein to describe various features, these features should not be limited by these terms. These terms may be only used to distinguish one feature from another. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first feature discussed herein could be termed a second feature without departing from the teachings of the example embodiments.

None of the elements recited in the claims are intended to be a means-plus-function element within the meaning of 35 U.S.C. § 112(f) unless an element is expressly recited using the phrase “means for,” or in the case of a method claim using the phrases “operation for” or “step for.”

The foregoing description of example embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.