ISO/TR 21724-1:2020 高度道路交通システム—一般的な輸送サービスアカウントシステム—パート1：フレームワークとユースケース | ページ 6

3.1

actor

user playing a coherent set of roles when interacting with the system within a particular use case (3.6)

Note 1 to entry: A user can, for instance, be a human, an Organisation or another (sub)system.

3.2

secureID

evidence that a transport service user (customer) is entitled, at the Point of Entry (POE) to the transport service, to benefit from a transport service provided by a transport service manager

Note 1 to entry: A secureID may consist of a set of data elements defined in a standardized format stored on an electronic media, e.g. a smartphone, used for a secure storage of the information and a secure communication of the information to the media accepting devices installed either at the POE or at the Point of Sales (POS). The set of data elements and their content (values) can vary depending on the type of payment method, type of media and electronic identification application stored on the media and the type of transport service provided.

Note 2 to entry: A secureID may consist of a simple vehicle ID as given by the vehicle number plate and read by the roadside equipment (RSE) by means of Automatic Number Plate Recognition (ANPR).

Note 3 to entry: A secureID may also consist of a biometric identification, e.g. finger-print or facial recognition of the transport service user.

3.3

open interface

public standard (or generally accepted specification) for connecting hardware to hardware and software to software

[SOURCE: https://encyclopedia2.thefreedictionary.com/open+interface , 22 March 2016]

3.4

open payment

use of open industry interface standards and specifications for the electronic remuneration and provision of transport services

Note 1 to entry: See Reference [7] for more information on open payment architecture.

3.5

payment method

timing and location of remuneration for services including whether the payment is required prior to, at the time of, or post access to transport or related services

3.6

use case

description of typical interactions between the actors (3.1) and the (sub)system itself, capturing the functional requirements of the (sub)system by defining a sequence of actions performed by one or more actors and the system