Personal Information Device --> Payment Device:
request for payment
Definitions
request for payment (Information Flow): Request to deduct cost of service from user's payment account.
Personal Information Device (Source Physical Object): The 'Personal Information Device' provides the capability for travelers to receive formatted traveler information wherever they are. Capabilities include traveler information, trip planning, and route guidance. Frequently a smart phone, the Personal Information Device provides travelers with the capability to receive route planning and other personally focused transportation services from the infrastructure in the field, at home, at work, or while en-route. Personal Information Devices may operate independently or may be linked with vehicle on-board equipment. This subsystem also supports safety related services with the capability to broadcast safety messages and initiate a distress signal or request for help.
Payment Device (Destination Physical Object): The 'Payment Device' enables the electronic transfer of funds from the user of a service (I.e. a traveler) to the provider of the service. Potential implementations include smart cards that support payment for products and services, including transportation services and general purpose devices like smart phones that support a broad array of services, including electronic payment. In addition to user account information, the payment device may also hold and update associated user information such as personal profiles, preferences, and trip histories.
Included In
This Triple is in the following Service Packages:
This triple is associated with the following Functional Objects:
- Personal Interactive Traveler Information
- Personal Shared Use Planning
- Personal Trip Planning and Route Guidance
This Triple is described by the following Functional View Data Flows:
This Triple has the following triple relationships:
| Relationship | Source | Destination | Flow |
|---|---|---|---|
| Interactive | Payment Device | Personal Information Device | actuate secure payment |
Communication Solutions
No communications solutions identified.Characteristics
| Characteristic | Value |
|---|---|
| Time Context | Now |
| Spatial Context | Adjacent |
| Acknowledgement | True |
| Cardinality | Unicast |
| Initiator | Source |
| Authenticable | True |
| Encrypt | True |
| Interoperability | Description |
|---|---|
| National | This triple should be implemented consistently within the geopolitical region through which movement is essentially free (e.g., the United States, the European Union). |
Security
| Information Flow Security | ||||
|---|---|---|---|---|
| Confidentiality | Integrity | Availability | ||
| Rating | Moderate | Moderate | High | |
| Basis | Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |
| Security Characteristics | Value |
|---|---|
| Authenticable | True |
| Encrypt | True |