This document discusses Payment Tokenisation 2.0 by EMVCo. It outlines the key concepts and roles in the payment tokenisation ecosystem, including token requestors, token service providers, and token vaults. It describes the processes for obtaining a token through a token request, issuing a token by performing token assurance, generation, and provisioning. It also covers token transaction processing flows, including token payment requests, domain restriction controls, de-tokenisation to PAN, authorization, and re-tokenisation.

1. Tokenisation 2.0
By EMVCo

2. EMVCo
● Worldwide interoperability & acceptance of secure payment transactions
● 6 member organisations : American Express, Discover, JCB, Mastercard, UnionPay, and Visa
● Separate working group “Tokenisation Working Group”

3. Tokenisation
Concept of replacing high-value data with
low-value representation,
While making it useful only for a transaction
taking place in a specific domain

4. Tokenisation
Concept of replacing high-value data with
low-value representation,
While making it useful only for a transaction
taking place in a specific domain

5. Tokenisation
Replacing the 16 digit account number,
Primary Account Number (PAN) with
a unique digital identifier called a TOKEN
T

6. Payment Tokenisation 1.0
● Tokenisation Ecosystem Environment
● Token Service Provider requirements
● Token Assurance ID&V Methods
● Payment Token processing
● Payment Token Transaction Flows

7. Payment Tokenisation 2.0
● Range of Token Requestor Types
● Payment Token Assurance Method
● Payment Token Programme
● Clarified roles, responsibilities and minimum requirements
● Payment Account Reference (PAR)
● Expansion of e commerce use cases

8. Payment Tokenisation Ecosystem
● Cardholder
● Card Issuer
● Merchant
● Acquirer
● Payment System & Payment Network
● Token Requestor & Token User
● Token Service Provider

9. Token Service Provider
Entities authorised to provide Payment Tokens
to registered Token Requestors
within a Token Programme
T

10. Token Service Provider Ctd.
● Registering with EMVCo
● Registration and management of Token Requestors
● Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance
and Token Provisioning
● Maintenance of security and related controls
● Establishing Token Domain Restriction Controls
● Support and management of Token Processing, including De-Tokenisation T

11. Token Service Provider Ctd.
● Responsible for integrating into relevant Token Programmes
● Building and managing interfaces that integrate with Token Requestors and Card Issuers
● Operate a Token Vault in accordance with the policies and processes
T

12. Payment Token
Process 1
Obtaining a Token

13. Cardholder
Merchant
Token Requestor
Token Service Provider
Card Issuer
PAN
PAN
Request
Response
Request Response
T
T
T

14. Token Request

15. Token Requestors
Provide Token Service Providers and Card Issuers
with information that helps identify a number of elements
that can be used within Token Provisioning to facilitate Token
Issuance

16. Token Requestor Types
● Acquirer
● Card Issuer
● Merchant
● Third Party Wallet
● Payment Enabler
● Payment Intermediary
● Payment Manager

17. Acquirer [Token Requestor Type]
Commercial relationship with the Merchant and with the Payment System Processes payment
transactions through a Payment Network(s) on behalf of the Merchant.
Behalf of the Merchant,
● Manages and stores PAN or Payment Token
● Initiate Token Payment Requests
● Stores payment-related data
● Directly involved in Token Processing but no direct relationship with the Consumer

18. Card Issuer [Token Requestor Type]
● Single issuer programme is enabled OR
● Financial institution offering a service directly to their Cardholders / clients.
● Single Card Issuer branded application Token Processing occurs directly with the Merchant.
● Services may be provided through home banking interface.
● Financial services provided directly to their Cardholders.
● No unique Merchant integration is required.

19. Merchant [Token Requestor Type]
● A Merchant that does business for itself and / or its subsidiaries.
● Provides Merchant-branded checkout experience.
● A direct relationship exists between the Cardholder and Merchant.
● Token Payment Request initiated by Merchant using a unique Payment Token assigned to the
Merchant, not a Shared Payment Token

20. Third Party Wallet [Token Requestor Type]
● A digit wallet branded by a third party where multiple Card Issuer programmes co-exist.
● The digital wallet application is only provided directly to the Consumer and not through an
Issuer.

21. Payment Enabler [Token Requestor Type]
● A non-Card Issuer third party where multiple Card Issuer programmes are enabled through a
single consumer interface.
Payment
Enabler
Card Issuer 1
Card Issuer 2
Card Issuer 3
singleconsumerinterface

22. Payment Intermediary [Token Requestor Type]
● An entity that provides Consumer authentication and passes payment credentials to a
Merchant but is not directly involved in Token Processing.

23. Payment Manager [Token Requestor Type]
● An entity that does not interface directly with the Consumer but facilitates payments for the
Merchant.

24. Payment Tokenisation 2.0
● Range of Token Requestor Types
● Payment Token Assurance Method
● Payment Token Programme
● Clarified roles, responsibilities and minimum requirements
● Payment Account Reference (PAR)
● Expansion of e commerce use cases
T

25. Token Request
Registered Token Requestor requests a Payment Token from the Token Service Provider.
Token Requestor needs to provide a PAN or a Payment Token / Token Reference ID.
2 types of Token Requests:
● Token Request with PAN
● Token Request with Payment Token / Token Reference ID
T

26. Token Request with PAN
[Token Request Type]
The Token Service Provider SHALL provide a common method that a registered Token Requestor
can use to submit a request through.
Fields for Token Request with PAN:
PAN, PAN Expiry Date, Token Requestor ID, Token Assurance Method & Data, Token Location,
Device Information
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
PAN

27. Token Request with Payment Token /
Token Reference ID [Token Request Type]
The Token Service Provider SHALL provide a common method that a registered Token Requestor
can use to submit a request through.
2 possibilities: Token Requestor is the same as the Token Requestor associated with the input
Payment Token, and not the same
Fields for Token Request with a Payment Token / Token Reference ID:
Token Expiry Date, Token Requestor ID, Token Request Authorisation, Payment
Token, Token Reference ID, Token Assurance Method & Data, Token Location, Device Information
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T
T

28. Issuance of
Payment Tokens

29. Token Service Provider [TSP]
● Registering with EMVCo
● Registration and management of Token Requestors
● Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance
and Token Provisioning
● Maintenance of security and related controls
● Establishing Token Domain Restriction Controls
● Support and management of Token Processing, including De-Tokenisation T

30. Step 1: Token Assurance
● Performing ID&V prior to Token Issuance to verify that the Cardholder is the rightful user of the
PAN.
● This binds the Payment Token to the underlying PAN and Cardholder.
T

31. Step 1: Token Assurance Ctd
Verification Methods Used
● Card Issuer Account Verification
● Interactive Cardholder Authentication – 1 Factor
● Interactive Cardholder Authentication – 2 Factor (Capable of supporting 3-D Secure)
● Risk Oriented Non-Interactive Cardholder Authentication
● Card Issuer Asserted Authentication
T

32. Payment Tokenisation 2.0
● Range of Token Requestor Types
● Payment Token Assurance Method
● Payment Token Programme
● Clarified roles, responsibilities and minimum requirements
● Payment Account Reference (PAR)
● Expansion of e commerce use cases

33. Step 2:Token Generation
Process of creating a Payment Token and its associated Token Expiry Date for a specific
underlying PAN for use by a specific Token Requestor and Token Domain(s), as identified the
Token Requestor ID.
● The Token Service Provider SHALL provide the Token Vault with the Payment Token / Token
Expiry Date mapping to the underlying PAN / PAN Expiry Date.
T

34. Step 3:Token Issuance
● Process of issuing a Payment Token and related data in preparation for Token Provisioning.
● Token Service Providers SHALL only issue Payment Tokens through the response to a Token
Request from a registered Token Requestor with a valid Token Requestor ID.
T

35. Step 4: Token Provisioning
Process of delivering a Payment Token and related data
to the Token Location.
T

36. Token Response
For any Token Request, the interfaces SHALL provide a response message
Fields for Response to Token Request:
Request Status, Reason Code, Token Expiry Date, Token Reference ID, Payment Token, Token
Reference ID, Token Assurance Method, Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T

37. Payment Token
Process 2
Payment Token Transaction
Processing

38. Cardholder Merchant
Card Issuer
Transaction Routing
De-Tokenise/
Re-Tokenise
Domain
Restriction
Controls
Token Payment
Request
Token
Authorisation
Request
PAN
Authorisation
Request
T
T
T
T
PAN
Authorisation
Response
Token
Authorisation
Response
T
TToken Service
Provider
Response
Acquirer
To
Payment Network

39. Types of
Transactions

40. Cardholder-Initiated Transaction
Cardholder directly presents a payment credential.
May use various authentication and verification features.
T
Mobile NFC at Point
of Sale
Mobile / Digital
Wallet E-Commerce
Card-On-File E-
Commerce

41. Merchant-Initiated Transaction
Always a result of a previous Cardholder interaction
Types:
● Industry-specific authorisation practices extends the initial Cardholder-Initiated
Transaction
● Standing instructions that provide express permission for additional purchases
T

42. Token Payment Request
Originates from the point of interaction between the Cardholder and the Merchant (such a
Terminal, website or application)
For the purposes of Token Processing, the fields and data included in Token Payment Requests
are defined AND
These are following existing message standards.
Examples: Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token
Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference
(subjected to Condtions such as R – Required, C – Conditional, O – Optional)
T

43. Transaction Routing
Routing and Account Range Tables:
Need to clearly distinguish Token BINs and Token BIN Ranges from traditional PAN BINs and PAN
BIN ranges in order to ensure the underlying integrity of payment processing.
T

44. Transaction Routing Ctd.
Payment Network
The Payment Network may interface with the Token Service Provider in order to verify the state of
the Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date in the
Token Vault for the affiliated Payment Token.
The Payment Network SHOULD be aware that a Payment Token transaction may include a Token
Cryptogram and authentication data.

45. Token Authorisation Request
Includes the request between the Acquirer and the Payment Network
● Not including Token Domain Restriction Controls
● Not including De-Tokenisation
● Token Authorisation request process continues until De-Tokenisation has been completed

46. Token Authorisation Request Ctd.
After receipt of the Token Payment Request,
Acquirer
● Performs routine processing checks
● Pass the Token Processing related data and other relevant payment data to the Payment
Network
(including setting the Token Presentment Mode to indicate the specific method in which the
Payment Token was input into the Terminal or other Merchant point of interaction)

47. Token Authorisation Request Ctd.
For the purposes of Token Processing, the fields and data included in Token Authorisation are
defined AND
These are following existing message standards.
Examples: Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token
Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T

48. Token Domain Restriction Controls
● Optionally performed
● Validating the Payment Token against the established Token Domain Restriction Controls
● Processing may be performed independently of the De-Tokenisation function

49. Token Domain Restriction Controls Ctd.
Controls depend upon the availability of specific Token Control Fields and Payment Token related
data in Token Processing messages to restrict Payment Token use to the appropriate Token
Domain(s).
Token Service Providers and participating Payment Networks provide the Token Control Field.
Types based on transactions:
● Cardholder-Initiated
● Merchant-Initiated

50. Cardholder-Initiated Transaction
Cardholder-Initiated Transactions SHALL contain the relevant cryptography generated during the
payment interaction and be validated.
Token Control Fields:
Token Cryptogram, POS Entry Mode, Merchant Identifiers
(subjected to Condtions such as R – Required, C – Conditional, O – Optional)

51. Merchant-Initiated Transaction
When the Merchant is the Token Requestor, Merchant-related fields in the existing ISO 8583
messages SHOULD be used to limit the use of a Payment Token.
Token Control Fields:
Token Cryptogram, POS Entry Mode, Original Transaction Reference, Merchant-Initiated
Transaction Identifier
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T

52. De-Tokenisation
Converting a Payment Token and Token Expiry Date to an underlying
PAN and PAN Expiry Date.
May or may not include the application of Token Domain Restriction Controls.
T PAN

53. De-Tokenisation Ctd.
Fields Included in De-Tokenisation Requests:
Payment Token, Token Expiry Date
T

54. PAN Authorisation
The Card Issuer completes the PAN-level and
Account-level validation and the authorisation check, and
returns the PAN in the authorisation response.
PAN

55. PAN Authorisation Request
Request to the Card Issuer.
Contains the data necessary, including Token Processing related data, to determine the Card
Issuer authorisation decision.
For the purposes of Token Processing, the fields and data associated with PAN Authorisation
requests are defined AND These are following existing message standards.
Examples: Payment Token (PAN), PAN Expiry Date, POS Entry Mode, Token Requestor ID, Token
Expiry Date, Token Assurance Method & data, Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
PAN
T

56. PAN Authorisation Response
Corresponding response from the Card Issuer on the notification of the approve or decline
decision.
For the purposes of Token Processing, the fields and data associated with PAN Authorisation
responses are defined AND These are following existing message standards.
Examples: Payment Token (PAN), Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T
PAN

57. Re-Tokenisation
Includes the corresponding response process,
PAN and PAN Expiry Date are tokenised back to
the affiliated Payment Token and Token Expiry Date.
TPAN

58. Re-Tokenisation Ctd.
Fields Included in De-Tokenisation Responses:
PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry
Date, Token Assurance Method, Token Assurance Data, Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T

59. Token Authorisation Response
Response between the Payment Network and the Acquirer
● Not including Tokenisation & application of Token Domain Restriction Controls.
● Relevant response data comes from the PAN Authorisation response.
T

60. Token Authorisation Response Ctd.
For the purposes of Token Processing, the fields and data included in Token Authorisation are
defined AND
These are following existing message standards.
Examples: Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token
Assurance Method, Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T

61. Token Payment Response
Provides the results of the authorisation decision
For the purposes of Token Processing, the fields and data included in Token Payment Response
are defined AND
These are following existing message standards.
Examples: Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token
Assurance Method, Payment Account Reference
(subjected to Conditions such as R – Required, C – Conditional, O – Optional)
T
T

62. Token Vault
● Storage and mechanism for Payment Token / Token Expiry Date mapping to the underlying
PAN / PAN Expiry Date
● Storage of the association between a Payment Token and its assigned Token Domain
Restriction Controls
● Strong physical and logical security measures

63. Token Vault Ctd.
Additional
● Large issuers are developing their own token vaults with own databases that translates a PAN
to a token
● Visa, MasterCard and American Express supplies for Tokenisation vault services ( Example:
Apply pay uses these services)

64. Token Location
●The mode of storage for a Payment Token and related data
●The Token Location SHALL NOT change during the life of the Payment Token

65. Token Location Description
00 Not specified
01 Remote storage: e.g. a single Merchant’s card-on-file data store
02 EMVCo and Payment System type approved secure element / Integrated Circuit Card
(ICC)
03 Local device storage: e.g. Payment Token and related data stored using the data storage
mechanisms of a Cardholder device, such as when utilising Host Card Emulation (HCE)
04 Local hardware secured storage: e.g. using a Trusted Execution Environment (TEE) to
ensure appropriately restricted access to data
05 Remote hardware secured storage: e.g. ISO 13491 compliant storage
06 Shared storage: e.g. e-commerce multi-merchant wallet accessing a card-on-file data
store
07 Temporary storage: e.g. guest checkout
08 – 99 Reserved for future use

66. Token Service Provider Interfaces
Common fields of any external interface that each Token Service Provider supports.
Examples of the authenticated methods through which these interactions may occur:
● Web services
● ISO 8583 message exchange through an existing Payment Network interface
● File / batch

67. Token Service Provider Interfaces Ctd.
The interfaces SHOULD be implemented and made available by the Token Service Provider
to be used by all participating entities that interact with the Token Service Provider.

68. Token Service Provider Interfaces Ctd.
Examples:
● Unlink Payment Token
● Suspend Payment Token
● Activate Payment Token
● Update Payment Token Attributes
● Update PAN Attributes

69. Payment Tokenisation 2.0
● Range of Token Requestor Types
● Payment Token Assurance Method
● Payment Token Programme
● Clarified roles, responsibilities and minimum requirements
● Payment Account Reference (PAR)
● Expansion of e commerce use cases

70. Token Programme
Comprised of the policies, processes and registration programmes facilitating:
● Generation and issuance of Payment Tokens.
● De-Tokenisation
● Token Domain Restriction Controls
● Token Vault

71. Payment Tokenisation Requirements
Baseline requirements for Payment Tokenisation for:
● Token Service Provider
● Token Requestor
● Additional Stakeholders
● Token Vault
● Token Location

72. Payment Account Reference (PAR)
Linkage mechanism of Token Processing transactions with
transactions associated with the underlying PAN
without the Full PAN being available
Term “PAR” in this technical framework refers to the overall concept, rather than any specific
component (for example,PAR Data, PAR Field).

73. PAN vs PAR
Field Name Length Format
PAN Variable (up to 19) Numeric
PAR 29 Alphanumeric
*Implementation of field formats is defined by each Token Service Providers’ interface.
*Alphanumeric fields consist of uppercase Alphanumeric Roman characters.

74. T
PAR
T
T

75. Payment Account Reference (PAR) Ctd.
● Implementation of PAR is outside of the scope of this technical framework and EMVCo.
● Payment Tokens affiliated with the same underlying PAN will consistently have the same PAR
Data assigned.
● PAR Data is unique in its assignment to a given PAN and is not intended to be a PAN
replacement or a consumer identifier.

76. PAR and EMV Terminal Processing
● EMVCo has defined EMV Tag ‘9F24’ for the identification of PAR data provisioned in an EMV
based Card / Form Factor.
● The terminal SHOULD be able to support the EMV Tag without disruption to the terminal.
● The terminal SHOULD be capable of reading PAR data.
● The terminal SHOULD pass PAR data to the Merchant’s POS system.
● The terminal SHOULD pass PAR data with other EMV data to the Merchant’s Payment
Processor or Acquirer.

77. Shared Payment Token (Use Case 4)
Attribute Potential Considerations
Token Domain
Restriction
Controls
Token Domain Restriction Controls may include:
Token Cryptogram
POS Entry Mode
Merchant Identifiers
Note: POS Entry Mode is set to indicate an e-commerce transaction.
Token
Location
The Token Location may include:
06 Shared Storage
07 Temporary Storage
Cardholder
Point of
Interaction
A Cardholder registers and interacts with either the Token Requestor or with each
individual Merchant (Token User). A transaction is undertaken using the Shared Payment
Token and may incorporate transaction specific Token Processing related data e.g. Token
Cryptogram.
Token User integration with the Token Requestor to enable a transaction may be required.

78. T
PAR
T
T
Merchant
Merchant
Merchant

79. Response/Request with Fields
Type Fields
Token Request with PAN PAN, PAN Expiry Date, Token Requestor ID, Token
Assurance Method & Data, Token Location, Device
Information
Token Request with
Payment Token / Token
Reference ID
Token Expiry Date, Token Requestor ID, Token Request
Authorisation, Payment Token, Token Reference ID, Token
Assurance Method & Data, Token Location, Device
Information
Token Response Request Status, Reason Code, Token Expiry Date, Token
Reference ID, Payment Token, Token Reference ID, Token
Assurance Method, Payment Account Reference
Token Payment Request Payment Token (PAN), Token Expiry Date, POS Entry
Mode, Token Cryptogram, Token Requestor ID, Merchant
Identifiers, Payment Account Reference

80. Response/Request with Fields Ctd.
Type Fields
Token Authorisation
Request
Payment Token (PAN), Token Expiry Date, POS Entry
Mode, Token Cryptogram, Token Requestor ID, Merchant
Identifiers, Payment Account Reference
Domain Restriction Controls
for Cardholder-Initiated
Token Cryptogram, POS Entry Mode, Merchant Identifiers
Domain Restriction Controls
for Merchant-Initiated
Token Cryptogram, POS Entry Mode, Original Transaction
Reference, Merchant-Initiated Transaction Identifier
De-Tokenisation Request Payment Token, Token Expiry Date
De-Tokenisation Response PAN, PAN Expiry Date, Token Requestor ID, Payment
Token, Token Expiry Date, Token Assurance Method, Token
Assurance Data, Payment Account Reference

81. Response/Request with Fields Ctd.
Type Fields
PAN Authorisation Request Payment Token (PAN), PAN Expiry Date, POS Entry Mode,
Token Requestor ID, Token Expiry Date, Token Assurance
Method & data, Payment Account Reference
PAN Authorisation
Response
Payment Token (PAN), Payment Account Reference
Token Authorisation
Response
Payment Token (PAN), Last 4 Digits of PAN, PAN Product
ID, Token Assurance Method, Payment Account Reference
Token Payment Response Payment Token (PAN), Last 4 Digits of PAN, PAN Product
ID, Token Assurance Method, Payment Account Reference
De-Tokenisation Response PAN, PAN Expiry Date, Token Requestor ID, Payment
Token, Token Expiry Date, Token Assurance Method, Token
Assurance Data, Payment Account Reference

82. Field Name Length Format
PAN Variable (up to 19) Numeric
PAN Expiry Date 4 Numeric
PAR 29 Alphanumeric
Token Requestor ID 11 Numeric
Token Assurance Method 2 Numeric
Token Location 2 Numeric
Token Assurance Data Variable Implementation Specific
Device Information Variable Alphanumeric
Data Fields

83. Field Name Length Format
Token Request Authorisation Variable Implementation Specific
Payment Token Variable (up to 19) Numeric
Token Expiry Date 4 Numeric
Token Reference ID Variable Implementation Specific
Request Status 1 Numeric
Reason Code Variable Alphanumeric
Transaction Data Variable Implementation Specific
Token Cryptogram Variable Implementation Specific
Data Fields Ctd.

84. Thank you
Update completed

85. References
https://www.emvco.com/about/overview/
https://www.emvco.com/wp-content/uploads/2017/03/EMVCo-Website-Content-8.0-Operating-
Principles-PDF_v1.1-1.pdf
https://www.emvco.com/about/working-groups/
http://www.paymentscardsandmobile.com/emv-payment-tokenization-2-0/
https://www.emvco.com/wp-
content/uploads/2017/09/EMV_Payment_Tokenisation_Technical_Framework_PR_FINAL.pdf
https://www.pymnts.com/in-depth/2014/visas-next-big-business-tokens-and-data/
http://www.sequent.com/what-is-tokenization/
https://www.vantiv.com/about/newsroom/article-payments-networks-101

86. Additional for
FAQ

87. Will Tokenisation replace EMV or provide another option?
●EMV as the security for a plastic card in a card-present transaction
●Tokenisation as the security for digital transactions, whether mobile or online.
●Still, BOTH helps to secure our payment system

88. Payment Account
●The unique financial relationship between account holder(s) and a financial institution for a
specific financial funding source (e.g. credit, debit, commercial, prepaid) represented by one or
more PANs.

89. Are tokens valid for one payment transaction only?
No!
●The payments industry has moved away from single-use tokens due to the valid concern that we
will quickly run out of unique tokens.
●As a solution one can use more of Shared Tokens!
Example: In Apple Pay, a token (for a specific phone) does not change. It is the same token used
for all transactions. What changes is a cryptogram, which is different for each transaction and
ensures that a token cannot be duplicated and used elsewhere.

90. What does Tokenisation have to do with Host Card Emulation
(HCE)?
Host Card Emulation > placing card data in the cloud
Why?
● To avoid all the technical and business complexities of card credentials stored on devices in
secure elements, financial institutions are looking to move card credential data to the cloud.
● Reducing the number of actors and barriers to integration to existing systems
Example: Android’s support for Host Card Emulation in the KitKat OS
Tokenisation comes in?
Passing encrypted card data every time a user wants to transact is simply not feasible from both a
security and user experience point of view