Reliable timestamping credentials

Abstract

The present invention provides a process for generating access credentials by a communication device, which may include determining whether the communication device successfully performed a predetermined shutdown sequence when the communication device last transitioned to an inactive state, determining whether the communication device has synchronized with an authorized network after transitioning back to an active state, and generating an access credential including a timestamp. The access credential may indicate whether the access credential has reliable timestamp information. The access credential may be provided to an access device associated with an authorized network to authenticate the communication device.

Description

[0001] This invention application is a divisional application of the invention patent application with international application number PCT / US2017 / 030844, international application date May 3, 2017, application number 201780031742.2 entering the Chinese national phase, and name “Reliable Timestamp Credential”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Patent Application No. 15 / 165,675, filed May 26, 2016, the entire contents of which are incorporated herein by reference for all purposes. Background Art

[0004] A replay attack may refer to the unauthorized capture of a sender's data communications, where the unauthorized party retransmits the captured data as if the retransmission originated from the original sender. In a computer network environment, an unauthorized party may use a replay attack to gain access to restricted services by posing as an authorized user. For example, access credentials that a user provides to an authorized entity to gain access to a service provider's services may be captured by an unauthorized party. The unauthorized party in possession of the access credentials may resend the access credentials to the authorized entity to obtain services from the service provider.

[0005] Embodiments of the present invention address these and other problems individually and collectively. Summary of the invention

[0006] In order to reduce the possibility that access credentials obtained through a replay attack can be reused by an unauthorized party, the access credentials may only be valid for a limited time. The access credential may include a timestamp indicating that the access credential was generated. By checking the timestamp information, the authorized entity receiving the access credential can determine the obsolescence of the access credential and whether the access credential has expired. If an expired access credential is received, this may indicate that the access credential has been compromised and an unauthorized party may attempt to access a service using the expired access credential. Therefore, the authorized entity can deny access to the service. However, the effectiveness of this technique for mitigating replay attacks may depend on the reliability of the timestamp information in the access credential. Therefore, some embodiments of the present invention relate to techniques for providing reliable timestamp information for use in access credentials.

[0007] According to some embodiments, a communication device may include: a processor; and a memory coupled to the processor and storing computer-readable code, which, when executed by the processor, causes the communication device to perform the operations of an access credential generation process. The process for generating the access credential may include transitioning the communication device from an active state to an inactive state; and transitioning the communication device from the inactive state back to the active state. After transitioning back to the active state, the process may include receiving a request to generate an access credential. The process may also include determining whether the communication device successfully performs a predetermined shutdown sequence when the communication device transitions to the inactive state; after transitioning back to the active state, determining whether the communication device has synchronized with an authorized network; and generating an access credential including a timestamp.

[0008] According to some embodiments, if the communication device successfully performs a predetermined shutdown sequence or has synchronized with an authorized network after transitioning back to the active state, the access credential may indicate that the access credential has reliable timestamp information. When the communication device fails to successfully perform a predetermined shutdown sequence and has not synchronized with an authorized network after transitioning back to the active state, the access credential may indicate that the access credential has unreliable timestamp information. The access credential may be provided to an access device associated with an authorized network to authenticate the communication device. The authorized network may determine the reliability of the timestamp information in the access credential based on the indication provided by the access credential. If the timestamp information is unreliable, the authorized network may request additional authentication information from the communication device. If the timestamp information is reliable, the authorized network may determine whether to grant access by determining that the access credential has expired based on the timestamp information. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A system for accessing services according to some embodiments is illustrated.

[0010] Figure 2 Illustrated is a timing diagram of a technique for generating a timestamp for access credentials according to some embodiments.

[0011] Figure 3 A timing diagram is illustrated of a technique for generating a timestamp for access credentials after a power cycle of a communications device, according to some embodiments.

[0012] Figure 4 Illustrated is an example of a timing diagram for generating access credentials according to some embodiments.

[0013] Figure 5 A flow diagram of a process for generating access credentials according to some embodiments is illustrated.

[0014] Figure 6 Illustrated is a flow diagram of a process for synchronizing time information between a communication device and an authorized network according to some embodiments.

[0015] Figure 7 A flow diagram of a process for generating a timestamp for access credentials according to some embodiments is illustrated.

[0016] Figure 8 A flow diagram of a predetermined shutdown sequence is illustrated according to some embodiments.

[0017] Fig. 9 A flow diagram of a startup sequence according to some embodiments is illustrated.

[0018] Fig.10 A block diagram of a communication device according to some embodiments is illustrated.

[0019] Fig.11 Illustrated is a block diagram of an exemplary system in which time-stamped access credentials may be used in accordance with some embodiments. DETAILED DESCRIPTION

[0020] One technique to mitigate the threat of replay attacks is to limit the amount of time that an access credential is valid. For example, an access credential may be associated with a threshold amount of time to live, and once this amount of time has expired, the access credential will become invalid and can no longer be used to authenticate the user. Thus, even if an unauthorized party possesses a time-limited access credential, if the unauthorized party attempts to use the access credential beyond the time limit of the access credential, the unauthorized party will not be able to gain access to services associated with the authorized user.

[0021] In order for an authorized entity to verify that an access credential is used within its time limit, a timestamp may be included in the access credential. The timestamp may reflect the time when the access credential was generated. When the authorized entity receives the access credential, the authorized entity may retrieve the timestamp information and determine the amount of time that has elapsed since the access credential was generated. This elapsed time may be compared to the time to live of the access credential to determine whether the access credential has expired. If the access credential has expired, access to the service may be denied even if the underlying account information (e.g., an account identifier) ​​is valid.

[0022] The effectiveness of this technique in preventing replay attacks may depend on the reliability of the timestamp information included in the access credential. For example, if the timestamp information is inaccurate, access to a service may be erroneously denied even if the access credential has not expired. As another example, if the timestamp information included in the access credential can be manipulated by a user, then by setting the timestamp information in the access credential to a future point in time, the access credential may be used beyond its time limit. Accordingly, some embodiments of the present invention relate to techniques for providing reliable timestamp information for use in access credentials.

[0023] Before discussing the details of some embodiments of the present invention, a description of some terms may aid in understanding the various embodiments.

[0024] A "communication device" may be a device including one or more electronic components (e.g., an integrated chip) that can communicate with another device. For example, a communication device may be a computing device having at least one processor coupled to a memory that stores instructions or codes executed by the processor. Examples of communication devices may include portable communication devices. A "portable communication device" may be a communication device that can be transported and operated by a user and may include one or more electronic components (e.g., an integrated chip). A portable communication device may provide remote communication capabilities to a network. A portable communication device may be configured to transmit data or communications to other devices and receive data or communications from other devices. A portable communication device may be in the form of a mobile device such as a mobile phone (e.g., a smart phone, a cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant device (PDA), a wearable device (e.g., a watch, a health monitoring device such as a fitness bracelet, etc.), an electronic reader device, etc., or in the form of a card (e.g., a smart card) or a pendant, etc. Examples of portable communication devices may also include portable computing devices (e.g., laptops, netbooks, ultrabooks, etc.). The portable communication device may also take the form of a vehicle (eg, an automobile) or be integrated as a part of a vehicle (eg, a vehicle's information system).

[0025] A "server computer" may include a powerful computer or computer cluster. For example, a server computer may be a large mainframe, a small computer cluster, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing for servicing requests from one or more client computers. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0026] An "issuer" may generally refer to a business entity (e.g., a bank) that maintains an account of a user associated with a portable communication device, such as an account registered in a mobile application installed on the portable communication device. The issuer may also send account parameters associated with the account to the portable communication device. The issuer may be associated with a host system that performs some or all of the functions of the issuer on behalf of the issuer. In some embodiments, the issuer may refer to a provider of a software application.

[0027] A "merchant" may generally be an entity that participates in a transaction and may sell goods or services, or provide access to goods or services.

[0028] An "acquirer" may generally be a commercial entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may include such a single-entity issuer-acquirer.

[0029] "Access device" can be any suitable device for interacting with a communication device and for communicating with an authorization server. In some embodiments, the access device can communicate with an authorization server via a merchant computer or a transaction processing network. The access device can be located at any suitable location, for example, at the merchant's location. The access device can have any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), information kiosks, security systems, access systems, websites or network servers, etc. The access device can use any suitable contact or contactless, wired or wireless operating mode to send or receive data from a communication device or associated with a communication device. In some embodiments where the access device can include a POS terminal, any suitable POS terminal can be used, and it can include a reader, a processor and a computer-readable medium. The reader can include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader for interacting with a portable communication device.

[0030] An "authorization request message" may be an electronic message sent to request authorization of a transaction. The authorization request message may be sent to a transaction processing network and / or an issuer of a transaction card (e.g., a payment card). The authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with transactions made by a user using a transaction device or a transaction account. The authorization request message may include information that can be used to identify an account. The authorization request message may also include additional data elements, such as one or more of a service code, an expiration date, and the like. The authorization request message may also include transaction information (such as any information associated with the current transaction, such as a transaction amount, a merchant identifier, a merchant location, and the like), as well as any other information that can be used to determine whether to identify and / or authorize the transaction. The authorization request message may also include other information, such as information identifying the access device that generated the authorization request message, information about the location of the access device, and the like.

[0031] An "authorization response message" may be an electronic message reply to an authorization request message. The authorization response message may be generated by the issuing financial institution or a transaction processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns to the merchant's computer in response to the authorization request message in the electronic message (directly or through the transaction processing network) indicating approval of the transaction. The code may be used as evidence of authorization. As described above, in some embodiments, the transaction processing network may generate the authorization response message or forward the authorization response message to the merchant.

[0032] "Token" may include an alternative identifier for a certain information. For example, a transaction token may include an identifier for a transaction account, which is an alternative to an account identifier (such as a primary account number (PAN)). For example, a token may include a series of alphanumeric characters that may be used as an alternative to an original account identifier. For example, a token "4900 0000 0000 0001" may be used in place of a PAN "4147 0900 0000 1234". In some embodiments, a token may be format-retaining and may have a digital format (e.g., ISO 8583 financial transaction message format) that conforms to an account identifier used in an existing transaction processing network. In some embodiments, a token may be used to initiate, authorize, settle, or resolve a transaction in place of a PAN. In other systems that typically provide an original certificate, a token may also be used to represent an original certificate. In some embodiments, a token value may be generated so that the original PAN or other account identifier cannot be restored by computationally using the token value. In addition, in some embodiments, the token format may be configured to allow an entity that receives a token to identify it as a token and to identify the entity that issued the token.

[0033] The "real account identifier" may include an original account identifier associated with an account. For example, the real account identifier may be a primary account number (PAN) issued by an issuer for a card account (e.g., a credit card, a debit card, etc.). For example, in some embodiments, the real account identifier may include a sixteen-digit value, such as "4147 0900 0000 1234". The first six digits of the real account identifier (e.g., "414709") may represent an actual issuer identifier (BIN) that may identify the issuer associated with the real account identifier.

[0034] "Account parameters" may refer to information associated with an account that can be used to conduct transactions on the account. Examples of account parameters may include information that can be used to identify a user's account (e.g., a real account identifier, an alternative account identifier, a token, etc.), data or information related to the state of the account, one or more keys used to generate cryptographic information, data or information related to one or more keys, etc. Account parameters may be semi-static or dynamic. A dynamic account parameter may be an account parameter with a limited lifespan, and once expired, it may no longer be used to conduct transactions until the account parameter is replenished, refreshed, or updated. A dynamic account parameter may be frequently replenished during the lifespan of an account. A semi-static account parameter may be an account parameter with an extended lifespan longer than a dynamic account parameter, and may not be replenished as frequently as a dynamic account parameter, or may not be replenished at all during the lifespan of an account.

[0035] A "key" may refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm may be an encryption algorithm that transforms original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms may include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0036] A "limited use key" or "LUK" may refer to a key that may be used only for a limited time or for a limited number of transactions, and may need to be renewed or replenished when the limited use is exhausted. A LUK may be associated with a set of one or more limited use thresholds that restrict the use of the LUK, wherein once the use of the LUK is exhausted or exceeds the set of one or more limited use thresholds, further transactions using the LUK will be denied, even if the underlying account remains in good standing. The set of one or more limited use thresholds may include at least one of the following: a number of transactions for which the LUK may be used; a life time indicating the duration for which the LUK is valid; and / or a cumulative transaction amount indicating a total transaction amount of one or more transactions for which the LUK is valid; or any combination thereof.

[0037] A "limited use threshold" may refer to a condition that limits the use of a piece of information. When a base condition is met, the limited use threshold may be exceeded or exhausted. For example, the limited use threshold may include a time to live indicating an amount of time that a piece of information is valid, and once the amount of time has elapsed, the limited use threshold is exceeded or exhausted and the piece of information may become invalid and may no longer be used. As another example, the limited use threshold may include a number of times that a piece of information may be used, and once the piece of information has been used the number of times, the limited use threshold is exceeded or exhausted and the piece of information may become invalid and may no longer be used.

[0038] A "transaction processing network" may include a network that can process and route transaction request messages. An exemplary transaction processing network may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary transaction processing network may include VisaNetTM. A transaction processing network such as VisaNetTM is capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNetTM may specifically include a VIP system (account integrated payment system) that processes authorization requests and a BaseII system that performs clearing and settlement services.

[0039] The details of some embodiments of the invention will now be described.

[0040] Figure 1A system 100 for implementing network services according to some embodiments is illustrated. The system 100 may include: a communication device 110 operated by a user; an access device 160 through which a user of the communication device 110 can interact to obtain services associated with a service provider; and an authorization server 180 associated with the service provider, which authenticates the user or the communication device 110 to grant access to the service. Examples of services that may be provided by the system 100 may include access to restricted content or information, access to a user's online account, access to network resources, access to restricted areas, access to goods or services related to a transaction, and the like. Any of these services may be restricted so that only authenticated users may be granted access to these services. For example, in order for a user to gain access to a service, the user may be required to provide a valid access credential. The access credential may include account information identifying the user's account associated with the service provider and other authentication information used to authenticate the user.

[0041] The communication device 110 may communicate with the authorization server 180 via a communication network 182 (e.g., the Internet, a mobile or cellular network, etc.). For example, the communication device 110 may communicate with the authorization server 180 to download an access application. The access application may enable the communication device 110 to interact with the access device to obtain services associated with a service provider. In some embodiments, the access application may be downloaded from an application store associated with the authorization server 180 or a service provider. The communication device 110 may also communicate with the authorization server 180 from time to time to request and / or update account parameters used by the access application and to synchronize the communication device 110 with the authorization server 180. For example, the communication device 110 may obtain the authorized network time from the authorization server 180 so that the clock and / or timing parameters of the access application are synchronized with the authorization server 180.

[0042] When a user attempts to access a service using the communication device 110, the user may launch an access application on the communication device 110 and instruct the access application to generate access credentials for the service provider, the access credentials being used to authenticate the user and / or the communication device 110. The communication device 110 may interact with the access device 160 and provide the access credentials to the access device 160. For example, the access credentials may be provided to the access device 160 using a wired or wireless connection, or the access credentials may be encoded in an image (e.g., a QR code, a barcode, etc.) displayed on the communication device 110, which is then scanned or captured by the access device 160.

[0043] The access device 160 may send the access credentials to the authorization server 180 via the authorization network 184 to authenticate the user and / or the communication device 110. It should be appreciated that in some embodiments, the authorization server 180 may be implemented as part of the authorization network 184. When the authorization server 180 receives the access credentials, the authorization server 180 may determine the validity of the access credentials, and if the access credentials are valid, the user and / or the communication device 100 may be granted access to the requested service.

[0044] According to some embodiments, the access credential may have a limited lifespan and may expire after a survival time amount. For example, the access credential may have a survival time of 5 minutes, 10 minutes, 15 minutes, or 30 minutes, etc., from the time the access credential is generated, after which the access credential will no longer be valid. In order to allow the authorization server 180 to verify whether the access credential has expired, the access credential may include timestamp information indicating when the access credential was generated by the access application. Although the device time provided by the local clock application maintained by the communication device 110 can be used as the timestamp information, this local clock application is typically user adjustable, and the device time can be manipulated by the user changing the settings on the communication device 110. Therefore, using the device time provided by the local clock application directly as the timestamp in the access credential may lead to unreliable results. For example, a user may configure the local clock application to set the device time to a future point in time in an attempt to extend the lifespan of the access credential beyond its effective usage limit.

[0045] Another option is to have the access application obtain the authorized network time from the authorization server 180 each time an access credential is generated. Because the authorized network time is provided by the authorization server 180, the user is generally not able to manipulate this time information received from the authorization server 180. However, the communication device 110 may not always have a network connection. For example, the communication device 110 may be a portable communication device that may be carried to a location where a network connection is limited or unavailable (e.g., underground, inside a building, a location with limited signal reception, etc.). Therefore, when the access credential is being generated, there may be a situation where the communication device 110 is unable to communicate with the authorization server 180 to obtain the authorized network time.

[0046] Figure 2 Illustrated is a timing diagram of a technique for generating a reliable timestamp for use in access credentials according to some embodiments. Figure 2 The timestamp generation technique shown in can be more reliable than the techniques discussed above because it does not require a constant network connection to the authorization server and does not use the local device time from a user-configurable timer on the communication device as the timestamp information. It should be understood that Figure 2The timelines shown in FIG. 1 may not necessarily be drawn to scale, with circled numbers indicating that various events depicted may occur at different times than specifically shown.

[0047] At event ①, the communication device is powered on and started. The communication device may have a system timer, such as a timer (e.g., implemented in hardware), which starts timing from an initial value (e.g., zero) when the communication device is powered on. The system timer can be accessed by the user and is therefore not user configurable. As long as the communication device is powered on, the system timer will continue to time. If the communication device is turned off, the system timer will restart from its initial value when the communication device restores power. Therefore, the system timer can be used to indicate how long the communication device has been powered on. For example, the counter value of the system timer can be converted into a time unit (e.g., hours, minutes, seconds, etc.) by multiplying the counter value by the duration of the periodic interval at which the counter is incremented.

[0048] In event ②, the user can communicate with the authorized network (e.g., the authorized server), download the access application associated with the service provider and install it on the communication device. In some embodiments, instead of downloading the access application from the authorized network, the access application can be downloaded from the application store. When the access application is installed on the communication device, the access application can communicate with the authorized network (e.g., the authorized server) to synchronize the access application and the communication device with the authorized network. For example, when the communication device is synchronized with the authorized network, the access application can receive the authorized network time from the authorized network. The authorized network time can be, for example, the current universal coordinated time (UTC), the current local time at the authorized server, or the current time of any clock maintained by the authorized server. The received authorized network time can be stored as the authorized network synchronization time on the communication device. Moreover, when the communication device is synchronized with the authorized network, the access application can store the system synchronization elapsed time reflecting the system time of the system timer on the communication device. Whenever the communication device communicates with the authorized network to synchronize with the authorized network (e.g., request and / or update account parameters), the authorized network synchronization time and the system synchronization elapsed time stored on the communication device can be updated with the authorized network time received from the authorized network and the system time of the system timer, respectively.

[0049] At event ③, the communication device may interact with the access device to request access to the service from a service provider associated with the access device. The communication device may receive a request to generate an access credential to authenticate the user and / or the communication device. The request may be initiated from the access service or by the access application (e.g., in response to user input to generate the access credential). The access credential may include a timestamp indicating when the access credential was generated.

[0050] In order to generate a timestamp for the access credential, the access application may retrieve the authorized network synchronization time and the system synchronization elapsed time stored on the communication device indicating the most recent time that the communication device was synchronized with the authorized network. The access application may determine whether the communication device is synchronized with the authorized network based on the value of the authorized network synchronization time. For example, if the authorized network synchronization time has a default value (e.g., zero), this may indicate that the communication device has not yet synchronized with the authorized network. In this case, the communication device may not have reliable time information synchronized with the authorized network. Therefore, the access application may generate an access credential indicating that the access credential has unreliable timestamp information. In some embodiments, the access credential may provide this indication by setting the timestamp included in the access credential to a reset value (e.g., zero) and / or by setting a separate timestamp reliability flag included in the access credential to a value indicating that the timestamp information is unreliable.

[0051] If the authorized network synchronization time has a non-default value (e.g., a non-zero value), this may indicate that the communication device has successfully synchronized with the authorized network. Therefore, the timestamp included in the access credential may be set to the sum of the difference between the authorized network synchronization time and the current system time of the system timer of the communication device and the system synchronization elapsed time. The difference between the current system time of the system timer of the communication device and the system synchronization elapsed time reflects the amount of time that has elapsed since the last time the communication device was synchronized with the authorized network. Therefore, by adding this amount of time to the authorized network synchronization time stored on the communication device and using the addition result as the timestamp information, a reliable timestamp synchronized with the authorized network can be generated. In some embodiments, by making the timestamp have a non-reset value (e.g., a non-zero value), and / or by setting a separate timestamp reliability flag included in the access credential to a value indicating that the timestamp information is reliable, the access credential may provide an indication that the access credential has reliable timestamp information. This technique for generating a timestamp does not require the communication device to have a valid network connection when the access credential is generated, because all the information required to generate the timestamp (e.g., the most recent authorized network synchronization time, system timer information, etc.) is locally available on the communication device. Furthermore, this technique of generating timestamps is more reliable because it does not rely on time information that can be manipulated by the user.

[0052] In addition to the timestamp, the access credentials generated by the access application may also include account information associated with the user's account. For example, the account information may include an account identifier or a token used as a substitute for a real account identifier. The account credentials may also include a password generated by encrypting the account information and / or timestamp using an encryption key. In some embodiments, the encryption key may be a limited use key with its own set of usage restrictions. The access credentials may then be provided to the access device to request authorization to access the requested service. In some embodiments, the access credentials may be transmitted to the access device using a wired or wireless (e.g., NFC, WiFi, Bluetooth, etc.) connection. In some embodiments, the access application may encode the access credentials in an image (e.g., a QR code or a barcode), and the access application may provide the image to the access device by displaying the image on the communication device. In this case, the access device may use a camera or other optical scanner (e.g., a QR code reader or a barcode reader) to capture the image displayed on the communication device. The access device may also decode the image to retrieve the underlying information of the access credentials.

[0053] Once the access device obtains the access credential, the access device may send the access credential to the authorization server for verification. The authorization server may verify that the account information in the access credential identifies a valid account. The authorization server may also verify the password by regenerating the password using a copy of the encryption key and comparing the regenerated password to the password provided in the access credential. The authorization server may also determine whether the access credential has reliable timestamp information (e.g., via the value of the timestamp and / or a timestamp reliability flag).

[0054] If the access credential indicates that the timestamp information is authentic, the authorization server may compare the timestamp information to the current authorized network time at the authorization server and calculate the amount of time that has elapsed since the access credential was generated. The authorization server may then determine whether the access credential has been used within its survival threshold. If the access credential has not expired, the account information and / or password is verified to be valid, and the authorization server may then grant authorization to the user and / or communication device to access the requested service.

[0055] If the access credential indicates that the timestamp information may be unreliable, the authorization server may not be able to verify whether the access credential is expired because the timestamp information included in the access credential may be inaccurate. In this case, if the account information and / or password is verified, the authorization server may request advanced authentication from the user. For example, the authorization server may request the user to enter biometric information (e.g., fingerprint) or other user authentication information such as a PIN, password, or password on the communication device or on the access device to provide additional assurance that the user is authorized to access the service.

[0056] The authorization server can deny access to the service if the account information and / or password is invalid, or if the access credentials indicate that the timestamp is reliable but the access credentials have expired.

[0057] exist Figure 2 In the timeline shown in , the access application is able to generate a reliable timestamp based on the authorized network synchronization time and system timer information stored on the communication device. However, as mentioned above, if the communication device is turned off, the system timer of the communication device will restart from its initial value once power is restored to the communication device. Therefore, if the communication device is power cycled and the system timer is restarted, the difference between the current system time and the system synchronization elapsed time of the system timer previously stored on the communication device may not necessarily provide an accurate measurement of the amount of time that has elapsed since the most recent synchronization event.

[0058] Figure 3 A timing diagram illustrating a technique for generating reliable time stamps to account for power cycling of a communication device in accordance with some embodiments. Figure 3 The timeline shown in can be Figure 2 It is to be understood that Figure 3 The timelines shown in FIG. 1 may not necessarily be drawn to scale, with circled numbers indicating that various events depicted may occur at different times than specifically shown.

[0059] At event ④, the communication device shuts down. For example, shutdown may occur in response to the communication device receiving user input commanding the communication device to shut down (e.g., a user engaging a power button of the communication device). As part of the shutdown process, the access application or the communication device may execute a predetermined shutdown sequence. If the communication device was previously synchronized with an authorized network (e.g., if the authorized network synchronization time has a non-default value), the predetermined shutdown sequence may be executed.

[0060] The predetermined shutdown sequence may include storing a local device shutdown time on the communication device that reflects the device time indicated by a user-configurable timer of the communication device at the time the communication device was being shut down. The user-configurable timer may be, for example, a clock application that provides local time or other time information. The predetermined shutdown sequence may also store an authorized network device shutdown time that reflects the sum of the most recent authorized network synchronization time stored on the communication device and the difference between the current system time of the system timer when the communication device was shut down and the system synchronization elapsed time previously stored on the communication device. This authorized network device shutdown time provides shutdown time information that is synchronized with the authorized network and represents the current authorized network time of the authorized network at the time the communication device was shut down.

[0061] If both the local device shutdown time and the authorized network device shutdown time are successfully stored, the predetermined shutdown sequence can be completed by setting the device shutdown indicator to an asserted state. The local device shutdown time, the authorized network device shutdown time, and the device shutdown indicator can be stored in a non-volatile memory (e.g., flash memory) so that their values ​​can be retained when the communication device is shut down. In some embodiments, in order to reduce memory usage, the memory location used to store the authorized network synchronization time can be reused to store the authorized network device shutdown time.

[0062] At event ⑤, the communication device is turned on again and started up. The system timer of the communication device is restarted from its initial value. As part of the startup sequence, the access application or the communication device can determine whether the predetermined shutdown sequence was properly executed when the communication device was last turned off. For example, the device shutdown indicator can be checked to determine whether it is in an asserted state or a deasserted state. If the device shutdown indicator is in a deasserted state, this may indicate that the communication device is improperly shut down. For example, if the battery of the communication device is out of power before the predetermined shutdown sequence is completed, or the battery has been consumed to a level that cannot provide sufficient power to execute the predetermined shutdown sequence, this situation may occur. If it is determined that the predetermined shutdown sequence is not properly executed, the authorized network synchronization time stored on the communication device can be reset to its default value (e.g., zero). By resetting the authorized network synchronization time back to its default value, the access application can be notified that the communication device is no longer synchronized with the authorized network.

[0063] If the device shutdown indicator is in an asserted state when the communication device is turned on again, indicating that the predetermined shutdown sequence is properly executed, the authorized network synchronization time stored on the communication device can be set to the authorized network device shutdown time and the sum of the difference between the current device time indicated by a user-configurable timer (e.g., a clock application) when the communication device is turned on again and the local device shutdown time previously stored on the communication device. The difference between the current device time indicated by the user-configurable timer and the local device shutdown time previously stored on the communication device reflects the amount of time the device has been turned off. Although the user-configurable timer can generally be manipulated by the user, the user-configurable timer cannot be manipulated when the communication device is turned off. Therefore, the difference between the current device time and the local device shutdown time when the communication device is turned on again can provide a reliable measurement of how long the communication device has been turned off. According to some embodiments, the user-configurable timer of the communication device can keep time when the communication device is turned off by using a real-time clock (RTC) running on a power source different from the main battery of the communication device (e.g., a capacitor), so that the RTC can continue to run even if the main battery is completely exhausted. In some embodiments, when the communication device is started up using the Network Time Protocol (NTP), a user-configurable timer of the communication device can obtain the current device time. For example, when the communication device is started up, the communication device can obtain the local time provided by the cellular network. Once the authorized network synchronization time stored on the communication device is updated, the system synchronization elapsed time can be reset to zero and the device power off indicator can also be reset back to the asserted state.

[0064] At event ⑥, after the communication device has undergone a power cycle of being turned off and on, it can interact with the access device to request access to services from a service provider associated with the access device. The communication device can receive a request to generate an access credential to authenticate the user and / or the communication device. In order to generate a timestamp for the access credential, the access application can retrieve the authorized network synchronization time and the system synchronization elapsed time stored on the communication device indicating the most recent time when the communication device was synchronized with the authorized network. The access application can determine whether the communication device has reliable time information synchronized with the authorized network. For example, if the authorized network synchronization time has a default value (e.g., zero), this can indicate that the communication device has not yet synchronized with the authorized network, or that the predetermined shutdown sequence is not properly completed, making the authorized network time information on the communication device unreliable. In this case, the access application can generate an access credential with an indication indicating that the access credential has unreliable timestamp information. In some embodiments, the access credential can provide this indication by setting the timestamp included in the access credential to a reset value (e.g., zero) and / or by setting a separate timestamp reliability flag included in the access credential to a value indicating that the timestamp information is unreliable.

[0065] If the authorized network synchronization time has a non-default value (e.g., a non-zero value), this can indicate that the communication device has reliable time information synchronized with the authorized network (e.g., the communication device has been synchronized with the authorized network after being turned on again, or a predetermined shutdown sequence was appropriately performed to update the authorized network time information stored on the communication device when the communication device was turned off). Therefore, the timestamp included in the access credential can be set to the authorized network synchronization time and the sum of the difference between the current system time of the system timer of the communication device and the system synchronization elapsed time. In some embodiments, the access credential can provide an indication that the access credential has reliable timestamp information by having the timestamp have a non-reset value (e.g., a non-zero value), and / or by setting a separate timestamp reliability flag included in the access credential to a value indicating that the timestamp information is reliable. The access device can then obtain the access credential and authenticate the user and / or communication device using similar techniques as discussed above.

[0066] To better understand the reliable timestamping techniques described above, Figure 4 An example timing diagram illustrating generation of access credentials for example values ​​of various timing parameters according to some embodiments. Figure 4 The timing diagram shown in the Figure 2-3 It should be understood that Figure 4 The timelines shown in the drawings may not necessarily be drawn to scale, and various events illustrated as indicated by circled numbers may occur at different times than specifically shown, and various timing parameters may have different values ​​than specifically shown.

[0067] At event ①, the communication device is powered on and started. The system timer of the communication device starts counting from an initial value of zero. At event ②, after the device has been turned on for 1 hour, the user can download an access application associated with the service provider and install it on the communication device. At this time, the system timer can reflect a value corresponding to 1 hour because the communication device has been powered on for 1 hour. When the access application is installed on the communication device, the access application can communicate with the authorized network, synchronize the access application and the communication device with the authorized network, and the access application can receive the authorized network time from the authorized network. In some embodiments, whenever the access application communicates with the authorized network, the access application can synchronize with the authorized network, such as requesting and / or updating account parameters used by the access application. In this example, the authorized network time received from the authorized network at event ② is 7:00 UTC time. The access application can store this as the authorized network synchronization time. In addition, the access application can store the current system time (e.g., 1 hour) of the system timer as the system synchronization elapsed time.

[0068] In event ③, after the communication device has been powered on for two hours, the communication device can interact with the access device to request access to services from the service provider associated with the access device. At this time, the system timer has a value corresponding to 2 hours because the communication device has been powered on for two hours. In order to generate a timestamp for the access credential, the access application can retrieve the authorized network synchronization time (e.g., 7:00 UTC) previously stored on the communication device and the system synchronization elapsed time (e.g., 1 hour) previously stored on the communication device. Since the authorized network synchronization time has a non-default value, the access application can determine that the communication device has reliable time information synchronized with the authorized network. Therefore, the timestamp included in the access credential can be set to the difference between the authorized network synchronization time (e.g., 7:00 UTC) and the current system time of the system timer of the communication device and the system synchronization elapsed time (e.g., 2 hours - 1 hour = 1 hour). Therefore, the value of the timestamp included in the access credential generated in event ③ can be 8:00 UTC, which is the authorized network time at the authorization server when the access credential is generated in event ③.

[0069] At event ④, the communication device is powered off after the communication device has been powered on for three hours. At this point, the system timer may have a value corresponding to 3 hours because the communication device has been powered on for three hours. As part of a predetermined shutdown sequence, the communication device may store a local device power-off time on the communication device that reflects the device time indicated by a user-configurable timer (e.g., a clock application) of the communication device. In the example shown, when the communication device is powered off, the device time of the user-configurable timer on the communication device may be 15:00. Therefore, the local device power-off time stored on the communication device may have a value of 15:00. This device time may correspond to the local time at the location of the communication device.

[0070] The predetermined shutdown sequence may also store an authorized network device shutdown time that reflects the sum of the most recent authorized network synchronization time stored on the communication device (e.g., 7:00 UTC) and the difference between the current system time of the system timer and the system synchronization elapsed time previously stored on the communication device (e.g., 3 hours - 1 hour = 2 hours). Thus, the authorized network device shutdown time stored on the communication device may have a value of 9:00. This authorized network device shutdown time may correspond to the authorized network time at the authorization server when the communication device was powered off.

[0071] At event ⑤, 1 hour after the communication device is powered off, the communication device is turned on again and started. The system timer of the communication device is restarted from its initial value of zero. When the communication device is turned on again, the device time indicated by the user-configurable timer (e.g., clock application) of the communication device may be the time 16:00. The communication device may obtain this device time from the RTC clock or through the NTP protocol. Since the predetermined shutdown sequence is properly executed at event ④, the authorized network synchronization time stored on the communication device is updated to the authorized network device shutdown time (e.g., 9:00 UTC) and the difference between the current device time indicated by the user-configurable timer and the local device shutdown time previously stored on the communication device (e.g., 16:00-15:00=1 hour) The sum. Therefore, the authorized network synchronization time stored on the communication device can be updated to have a value of 10:00 UTC. The system synchronization elapsed time is also reset back to zero.

[0072] At event ⑥, after the communication device has been turned on again for 1 hour, the communication device can interact with the access device to request access to services from the service provider associated with the access device. At this time, the system timer can have a value corresponding to 1 hour because the communication device has been powered on for one hour. In order to generate a timestamp for the access credential, the access application can retrieve the authorized network synchronization time (e.g., 10:00 UTC) and the system synchronization elapsed time (e.g., 0 hours) stored on the communication device. Since the authorized network synchronization time has a non-default value, the access application can determine that the communication device has reliable time information synchronized with the authorized network. Therefore, the timestamp included in the access credential can be set to the difference between the authorized network synchronization time (e.g., 10:00 UTC) and the current system time of the system timer of the communication device and the system synchronization elapsed time (e.g., 1 hour-0 hours=1 hour). Therefore, the value of the timestamp included in the access credential generated in event ⑥ can be 11:00 UTC, which is the authorized network time at the authorization server when the access credential is generated in event ⑥.

[0073] Figure 5 A flow chart of a process 500 that can be performed by a communication device according to some embodiments is illustrated. At block 502, the communication device is transitioned from an active state (e.g., powered on) to an inactive state (e.g., powered off). For example, the communication device may receive an instruction from a user to turn off the communication device, or the battery of the communication device may have reached a minimum threshold, causing the communication device to automatically shut down. In some embodiments, as part of transitioning the communication device to the inactive state, the communication device may attempt to perform a predetermined shutdown sequence.

[0074] At block 504, the communication device is transitioned from the inactive state back to the active state. For example, the communication device may receive an instruction from the user to power on the communication device, which may occur after the battery of the communication device has been charged. At block 506, after transitioning back to the active state, the communication device may receive a request to generate access credentials used by the authorized network to authenticate the user and / or the communication device, granting access to the service.

[0075] At block 508, when the communication device transitions to the inactive state at block 502, the process 500 may determine whether the communication device successfully performs a predetermined shutdown sequence (e.g., by checking the state of a device shutdown indicator). If it is determined that the communication device successfully performs the predetermined shutdown sequence, it may be assumed that the communication device has reliable time information synchronized with the authorized network. Therefore, at block 510, the process 500 may generate an access credential that includes a timestamp indicating the time when the access credential was generated. In some embodiments, the access credential may provide an indication that the access credential has reliable timestamp information (e.g., by having a non-reset value in the timestamp).

[0076] If it is determined that the communication device did not properly perform the predetermined shutdown sequence, the process 500 can determine whether the communication device has synchronized with the authorized network after transitioning back to the active state at block 512 (e.g., by checking the value of the authorized network synchronization time stored on the communication device). If it is determined that the communication device has synchronized with the authorized network after transitioning back to the active state, it can be assumed that the communication device has reliable time information synchronized with the authorized network. Therefore, the process 500 can continue to block 510 to generate an access credential with reliable timestamp information.

[0077] If it is determined that the communication device has not synchronized with the authorized network after transitioning back to the active state, and the predetermined power-off sequence was not properly executed when the communication device last transitioned to the inactive state, it can be assumed that the communication device does not have reliable time information. In this case, the process 500 can still generate an access credential at block 514, but the access credential can provide an indication that the access credential has unreliable timestamp information (e.g., having a reset value in the timestamp). At block 516, the access credential is provided to an access device associated with the authorized network to authenticate the user and / or the communication device.

[0078] Figure 6A flow chart of a process 600 that can be performed by a communication device to synchronize time information stored on the communication device with an authorized network (e.g., an authorized server) according to some embodiments is illustrated. Process 600 can be performed from time to time when the communication device has a network connection and is able to communicate with the authorized server. At block 602, the communication device can communicate with the authorized network to synchronize the communication device with the authorized network. This can occur according to a predetermined schedule as a background task, or when a user interacts with an access application associated with the authorized network. At block 604, the communication device can store the authorized network synchronization time on the communication device. When the communication device is synchronized with the authorized network, the authorized network synchronization time can be updated with the authorized network time received from the authorized network. At block 606, the communication device can also store a system synchronization elapsed time on the communication device. When the communication device is synchronized with the authorized network, the system synchronization elapsed time can be updated with the current system time of the system timer of the communication device.

[0079] Figure 7 A flow chart of a process 700 that can be performed by a communication device to generate a timestamp for an access credential according to some embodiments is illustrated. For example, when a user requests access to a service using an access application on a communication device, the process 700 can be performed. At block 702, the process 700 can determine whether the authorized network synchronization time stored on the communication device is a default value (e.g., zero) when the access credential is generated. If it is determined that the authorized network synchronization time has a default value, then at block 704, the timestamp included in the access credential can be set to a reset value (e.g., zero). By making the reset value the timestamp information, the authorization server can be notified that the timestamp information in the access credential is unreliable and additional authentication measures can be taken before granting access to the requested service. If it is determined that the authorized network synchronization time has a non-default value, then at block 706, the timestamp included in the access credential can be set to the authorized network synchronization time stored on the communication device and the sum of the difference between the current system time of the system timer of the communication device when the access credential is generated and the system synchronization elapsed time stored on the communication device.

[0080] Figure 8A flow chart of a process 800 of a predetermined shutdown sequence that can be performed by a communication device according to some embodiments is illustrated. The predetermined shutdown sequence can be performed when the communication device transitions from an active state to an inactive state to maintain synchronization with an authorized network. When the communication device transitions to the inactive state, if the communication device is currently not synchronized with the authorized network (e.g., the authorized network synchronization time has a default value), it may not be necessary to perform the predetermined shutdown sequence because the communication device is not synchronized with the authorization anyway. Therefore, in some embodiments, when the communication device transitions from an active state to an inactive state, the predetermined shutdown sequence can only be performed if the authorized network synchronization time stored on the communication device has a non-default value.

[0081] At block 802, when the communication device transitions from an active state to an inactive state, the process 800 may store a local device shutdown time on the communication device, reflecting the device time indicated by the user-configurable timer of the communication device. The user-configured timer may be, for example, a clock application that displays the time on the communication device. In some embodiments, this device time may be the current local time of the location of the communication device. At block 804, the process 800 may store an authorized network device shutdown time, reflecting the sum of the difference between the authorized network synchronization time and the current system time of the system timer of the communication device and the system synchronization elapsed time stored on the communication device when the communication device transitions from an active state to an inactive state. At block 806, the process 800 may set a device shutdown indicator to an asserted state. When the communication device transitions back to an active state, this device shutdown indicator may be checked to determine whether a predetermined shutdown sequence was properly executed when the communication device last transitioned to an inactive state.

[0082] Fig. 9 A flow chart of a process 900 of a startup sequence that can be performed by a communication device according to some embodiments is illustrated. For example, a startup sequence can be performed when the communication device transitions from an inactive state to an active state. At block 902, process 900 can determine whether a device shutdown indicator is in an asserted state when the communication device transitions from an inactive state to an active state. When the communication device finally transitions to the inactive state, the device shutdown indicator provides an indication of whether a predetermined shutdown sequence was properly executed. At block 910, if the device shutdown indicator is not in an asserted state when the communication device transitions from an inactive state to an active state, the authorized network synchronization time stored on the communication device is reset to its default value.

[0083] At block 904, if the device power-off indicator is in the asserted state when the communication device transitions from the inactive state to the active state, the authorized network synchronization time stored on the communication device may be set to the sum of the authorized network device power-off time previously stored on the communication device and the difference between the current device time indicated by the user-configurable timer of the communication device and the local device power-off time previously stored on the communication device when the communication device transitions from the active state to the inactive state. At block 906, the process 900 may reset the system synchronization elapsed time (e.g., to zero). At block 908, the process 900 may also reset the device power-off indicator to a de-asserted state.

[0084] Fig.10 Illustrated is a block diagram of a communication device 1000 in which some embodiments of the processes described herein may be implemented. The communication device 1000 may be, for example, a portable communication device such as a mobile phone, a wearable device, a car, or other communication device capable of being transported or carried by a user.

[0085] The communication device 1000 may include device hardware 1003 coupled to the memory 1002. The device hardware 1003 may include a processor 1004, a communication subsystem 1005, a user interface 1008, and a display screen 1007 (which may be part of the user interface 1008). In some embodiments, the device hardware 1003 may include a contactless interface 1008. The device hardware 1003 may also include a system timer 1009, such as a hardware timer that counts or ticks when the communication device is powered on or in an active state. In some embodiments, the system timer may be implemented in software.

[0086] Processor 1004 can be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers), and is used to control the operation of communication device 1000. Processor 1004 can execute various programs in response to program code or computer-readable code stored in memory 1002, and can maintain multiple programs or processes executed simultaneously. Communication subsystem 1005 may include one or more RF transceivers and / or connectors, which can be used by communication device 1000 to communicate with other devices and / or be connected to an external network. User interface 1008 may include any combination of input elements and output elements to allow a user to interact with communication device 1000 and call the function of communication device. In some embodiments, display screen 1007 may be a part of user interface 1008, and may be a touch screen that accepts user input.

[0087] The contactless interface 1006 may include one or more RF transceivers to interact with a contactless reader of an access device to conduct a transaction (e.g., a payment transaction, an access transaction, an information exchange, etc.). In some embodiments, the contactless interface 1006 may be accessed by a mobile system (OS) 1014 using a host card emulation API 1016 without the use of a secure element. In some embodiments, the display 1007 may also be used as a contactless interface, such as to perform transactions using a QR code, a barcode, etc.

[0088] The memory 1002 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM) or any other non-temporary storage media or a combination thereof. The memory 1002 may store an OS 1014 and an application environment 1010 in which one or more applications reside, including an access application 1020 (e.g., a wallet application, a bank application, a payment application, a merchant application, a transportation application, a service provider application, a web browser, etc.) to be executed by the processor 1004. In some embodiments, the OS 1014 may implement a set of card simulation APIs 1016, and the access application 1020 may call the card simulation API to operate the contactless interface 1006 to interact with the access device. In some embodiments, the application environment 1010 may also include a clock application 1040 used by the communication device 1000 to keep time. The clock application 1040 may implement a user-configurable timer 1042, which the user may configure to display time information on the communication device 1000. For example, the user configurable timer 1042 may be invoked to display the local time on the communication device 1000 .

[0089] According to some embodiments, the access application 1020 can implement security-sensitive functions, such as a token request function 1024, an account parameter supplement function 1026, an access credential generator 1022, etc. In some embodiments, the access credential generator may include a password generation function. The token request function 1024 may be called to request a token from a remote server (e.g., an authorization server such as a cloud-based transaction server, a token server, an issuer, or a main processing system). The token may be used as a substitute for a real account identifier to conduct a transaction, for example, by sending the token to an access device, which forwards the token to an authorization server. The authorization server may then map the token back to an account identifier to identify the user's account. Using a token instead of a real account identifier may be safer because the real account identifier is not transmitted when conducting a transaction. The token request function 1024 may be called at, for example, registration time to request an initial token, or may be called when the life of the current token expires.

[0090] The account parameter supplement function 1026 may be called to supplement or update account parameters, such as a limited use key from a remote server (e.g., such as a cloud-based transaction server, a token server, an issuer or an authorization server of a main processing system, etc.). At the time of a transaction, the limited use key may be used to generate a password that is provided to an access device to conduct a transaction. The limited use key may be associated with a set or one or more limited use thresholds (e.g., valid for a predetermined time period, for a predetermined number of transactions, and / or for a predetermined cumulative transaction amount) to limit the use of the LUK. When one or more of the limited use thresholds of the LUK have expired or are about to expire, the account parameter supplement function 1026 may be called to request a new LUK.

[0091] The access credential generator 1022 can be called at the transaction time to generate the access credential. The access credential may include an account identifier or token, a password generated by the password generation function of the access credential generator 1022, and / or a timestamp indicating the time when the access credential was generated. The access credential may also include other transaction information, such as an application transaction counter value that counts the number of transactions executed from the access application, etc. In some embodiments, a password may be generated by receiving dynamic transaction data (e.g., transaction amount, transaction date, unpredictable number, etc.) from the access device and encrypting the dynamic transaction data using a LUK. In some embodiments, a password may be generated by encrypting a static string using a LUK (e.g., if the access device does not support transmitting dynamic data to a portable communication device). A password may also be generated by encrypting the timestamp of the access credential or by encrypting any combination of the above data elements.

[0092] The access credential generator 1022 can encapsulate the access credential in an appropriate form that can be provided to the access device. For example, the access credential generator 1022 can encapsulate the access credential into one or more protocol messages for transmission to the access device. In some embodiments, the access credential generator 1022 can encode the access credential into an image such as a QR code or a barcode. The encoded image can be displayed on the communication device 1000, and the access device can capture or scan the encoded image to obtain the access credential.

[0093] According to some embodiments, the timestamp generation techniques described in the present invention may be used to provide a reliable timestamp for the access credential. The access application 1020 may provide a timing parameter storage function 1031 to store various timing parameters and time information for generating a reliable timestamp synchronized with the authorization server. For example, the timing parameter storage function 1031 may store the authorized network synchronization time 1032, the system synchronization elapsed time 1033, the authorized network shutdown time 1034, and / or the local device shutdown time 1035.

[0094] When the communication device 1000 is synchronized with an authorized network (e.g., an authorized server), the authorized network synchronization time 1032 is used to record the most recent authorized network time received from the authorized network. For example, when the communication device 1000 communicates with the authorized network to request a token, the communication device 1000 may synchronize with the authorized network, perform account parameter replenishment, or otherwise interact with the authorized network. When the communication device 1000 is synchronized with the authorized network, the system synchronization elapsed time 1035 is used to record the system time of the system timer 1009 and provide an indication of how long the communication device 1000 has been turned on or in an active state when the most recent synchronization event occurred. The authorized network shutdown time 1034 is used to record the authorized network time when the communication device 1000 is powered off or transitioned to an inactive state. When the communication device 1000 transitions to an inactive state, because the communication device 1000 may not always have a network connection, the authorized network shutdown time 1034 can be derived from the authorized network synchronization time 1032, the system synchronization elapsed time 1035, and the system time of the system timer at the time of the transaction. When the communication device 1000 is powered off or transitions to an inactive state, the local device power-off time 1035 is used to record the local device time of the user-configurable timer 1042 .

[0095] In some embodiments, the authorized network shutdown time 1034 and the local device shutdown time 1035 can be stored in a non-volatile memory (e.g., flash memory) so that their values ​​can be retained when the communication device loses power or is turned off. The authorized network synchronization time 1032 and the system synchronization elapsed time 1033 can be stored in a volatile (e.g., RAM) or non-volatile memory. In some embodiments, the memory location of the authorized network synchronization time 1032 can be the same as the memory location of the authorized network shutdown time 1034 because once the authorized network shutdown time 1034 is determined when the communication device transitions to an inactive state, the value of the authorized network synchronization time 1032 is not needed, and once the authorized network shutdown time 1034 at startup is derived from the authorized network shutdown time 1034 when the communication device transitions to an active state, the authorized network shutdown time 1034 is not needed.

[0096] Fig.11 A block diagram of an exemplary system 1100 that can use the reliable timestamping techniques described herein according to some embodiments is illustrated. System 1100 can be, for example, a cloud-based transaction system for conducting cloud-based transactions. It should be understood that the reliable timestamping techniques described herein can be applied to other types of systems that may or may not be related to transaction processing.

[0097] System 1100 may include a portable communication device 1110, a cloud-based transaction platform (CBP) 1180, and a mobile application platform (MAP) 1170. CBP 1180 may be implemented using one or more computing devices and may be associated with or operated by an issuer, a transaction processor, and / or other suitable entity. CBP 1180 implements a set of functions including account management and account parameter generation and replenishment to enable cloud-based transactions via portable communication device 1110.

[0098] MAP 1170 is used to facilitate communication between CBP 1180 and mobile applications 1114 (e.g., access applications) installed in portable communication device 1110. MAP 1170 can be implemented using one or more computing devices and can be associated with or operated by a service provider of mobile application 1114 (such as an issuer, mobile wallet provider, merchant, and / or other suitable entity). In some embodiments, MAP 1170 can be associated with or operated by the same or different entity as CBP 1180. MAP 1170 is used to intermediate requests between mobile application 1114 and CBP 1180 and ensure that requests and responses initiated by either party are fulfilled once a connection to portable communication device 1110 is established, such as via communication network 1182 (e.g., Internet, mobile or cellular network, etc.). It should be understood that in some embodiments, one or more functionalities of CBP 1180, MAP 1170, and / or issuer or host processing system 1172 can be integrated into the same computing system or different computing systems. In some embodiments, any one or more of the CBP 1180, MAP 1170, and / or issuer or host processing system 1172 may act as an authorization server.

[0099] The portable communication device 1110 (e.g., communication device 1000) can be used to conduct cloud-based transactions (e.g., payment transactions) facilitated by the CBP 1180 and / or the MAP 1170. The portable communication device 1110 includes device hardware 1132, a mobile operating system (OS) 1122, and an application environment 1112. The device hardware 1132 may include a contactless interface 1134 that can contactlessly transmit or otherwise present information to another device (such as a contactless reader 1162 of the access device 1160). Examples of the contactless interface 1134 may include a near field communication (NFC) interface that can send and receive communications using radio frequency or other wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, etc. Examples of the contactless interface 1134 may also include an optical interface such as a display to present information such as a quick response (QR) code, a barcode, etc.

[0100] The application environment 1112 of the portable communication device 1110 may include mobile applications 1114, such as access applications provided by a service provider (e.g., an issuer). For example, if the service provider of the mobile application 1114 is an issuer, the mobile application 1114 may be a mobile banking application or a mobile payment application. If the service provider is a mobile wallet provider (such as a mobile network operator or a third-party wallet provider that supports multiple issuers), the mobile application 1114 may be a mobile wallet application. With respect to merchants, the mobile application 1114 may be a merchant's own transaction application from which a consumer may conduct e-commerce or point-of-sale transactions, or a mobile wallet application that supports multiple merchants.

[0101] In some embodiments, the mobile application 1114 may include on-device cloud-based transaction logic integrated into the mobile application 1114 to support cloud-based transactions. The on-device cloud-based transaction logic performs functions to facilitate cloud-based transactions, such as to obtain account parameters provided for the transaction and deliver them to the mobile operating system 1122 for transmission via the contactless interface 1134. For example, the on-device cloud-based transaction logic may use a cryptographic key (e.g., a limited-use key) provided from the CBP 1180 to generate a transaction cryptogram that is transmitted to the access device 1160 via the contactless interface to conduct the transaction. The transaction cryptogram may be sent to the transaction processing network 1184 (e.g., acting as an authorization network) to obtain authorization for the transaction. The on-device cloud-based transaction logic also manages the initial service profile parameters provided after the account has been opened to ensure that requests for account parameter replenishment and other account parameter management activities are initiated.

[0102] To provision the portable communication device 1110 for cloud-based transactions, the CBP 1180 may configure a portfolio of accounts associated with the issuer and provide the portable communication device 1110 with account parameters for use when conducting cloud-based transactions. The account portfolio established by the CBP 1180 may include features such as risk parameters (e.g., speed control) that govern triggers for when account parameters on the provisioned device will need to be refreshed for the accounts in each portfolio. To ensure consistent performance and availability, a minimum set of parameters that can be configured in a service profile may be implemented by the CBP 1180. To ensure that cloud-based payment transactions are processed according to the rules specified in the service profile for the account portfolio, the CBP 1180 performs various core functions during the life of the enabled account. These functions may include provisioning, active account management, confirmation of transactions, transaction processing, lifecycle management, and post-payment.

[0103] Before an account is provisioned as a cloud-based transaction account, CBP 1180 may create a service profile for the portfolio. Provisioning may include obtaining a registered account, creating account information such as an alternate account identifier (e.g., an alternate primary account number (PAN)), or a token that acts as an account identifier substitute that can be used to conduct transactions in place of a real account identifier (e.g., a real PAN), and having established a legacy service profile for the portfolio. Once an account is provisioned, the relevant service profile details are shared with both transaction processing and on-device cloud-based transaction logic to ensure that decisions can be made at transaction processing time and during user use of the mobile application.

[0104] After the account is opened, active account management may be performed by the CBP 1180. Active account management may be initiated from a transaction processing activity or from a mobile application activity. Once the account has been opened, the active account management capability generates an initial set of account parameters to be deployed to the portable communication device 1110. The account parameters may include account information generated during provisioning (e.g., an alternative account identifier or token) and dynamic information to ensure that the set of account parameters has only limited use or a limited lifespan once delivered to the device. Depending on which type of transaction is supported, the dynamic information may include limited use keys or dynamic data. For example, the dynamic information may include a limited use key (LUK) for calculating a cryptogram and limited use dynamic data for supporting legacy dynamic card verification values ​​or code-based implementations.

[0105] During transaction processing, if the service profile parameters maintained by CBP 1180 for a particular account indicate that the account parameters on the portable communication device 1110 need to be replaced, the active account management capabilities of CBP 1180 can connect to the portable communication device 1110 via MAP 1170 to replenish the account parameters. Similarly, if the on-device service profile parameters stored on the portable communication device 1110 indicate that account parameter replenishment is required or is about to be required (i.e., by monitoring account parameter thresholds), the mobile application 1114 can request account parameter replenishment from CBP 1180.

[0106] Once the portable communication device 1110 has been provided for cloud-based transactions, transactions can be conducted via the portable communication device 1110 by interacting with a contactless reader 1162 of an access device 1160 (e.g., at a merchant location). Components of the access device 1160 may include a point of sale (POS) terminal 1164 and / or an electronic cash register 1166. In some embodiments, the access device 1160 may be a network server associated with a merchant, and the portable communication device 1110 may communicate with the access device 1160 via a computer network. The access device 1160 may be coupled to an acquirer 1174 (e.g., via a merchant computer not shown). The acquirer 1174 may be connected to an issuer or main processing system 1172 via a transaction processing network 1184. The transaction processing network 1184 may include one or more server computers. A server computer is typically a powerful computer or computer cluster. For example, a server computer may be a mainframe, a small computer cluster, or a group of servers that work like a unit. In one example, the server computer may be a database server coupled to a network server. The transaction processing network 1184 may use any suitable wired or wireless network, including the Internet.

[0107] Transaction processing network 1184 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction scoring services, and clearing and settlement services. Exemplary transaction processing networks may include VisaNet TM Such as VisaNet TM VisaNet is a transaction processing network that processes credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, it includes the VIP system (Visa Integrated Payment System) that processes authorization requests and the Base II system that performs clearing and settlement services.

[0108] Each entity (eg, acquirer 1174, transaction processing network 1184, issuer, or host processing system 1172) may include one or more computers to enable communications or perform one or more of the functions described herein.

[0109] To conduct a cloud-based transaction, a user of the portable communication device 1110 may tap the portable communication device 1110 against the contactless reader 1162 of the access device 1160 (e.g., via NFC), or display an image (such as a QR code or barcode) on the screen of the portable communication device 1110 that can be scanned by the contactless reader 1162 (e.g., an optical scanner or camera) of the access device 1160. In some embodiments, the portable communication device 1110 may provide access credentials such as an account identifier (e.g., an alternative account identifier, a token, etc.) and additional information (such as limited-use account parameters or information derived from the limited-use account parameters) to the access device 1160. For example, the access credential information may be encoded in a QR code or barcode that is scanned by the access device 1160; or the access credential information may be transmitted to the access device 1160 via NFC. In some embodiments, the limited-use account parameters included in the access credential may include a transaction password and a timestamp.

[0110] The access device 1160 or a merchant computer coupled to the access device 1160 may generate an authorization request message including the account identifier and additional information (e.g., limited use account parameters or information derived from the limited use account parameters) and forward the authorization request message to the acquirer 1174. In some embodiments, to provide compatibility with legacy protocol messages, legacy protocol messages may not have a specific field in the authorization request message designated for timestamp information, which may be transmitted in an existing data field, such as an unpredictable numeric data field. The authorization request message is then sent to the transaction processing network 1184. The transaction processing network 1184 then forwards the authorization request message to a corresponding issuer or host processing system 1172 associated with the issuer of the account (associated with the portable communication device 1110).

[0111] After the issuer or host processing system 1172 receives the authorization request message, the authorization request message may be parsed, and the information in the authorization request message may be sent to CBP 1180 for verification. An authorization response message is then sent back to the transaction processing network 1184 to indicate that the current transaction is authorized (or not authorized). The transaction processing network 1184 then forwards the authorization response message back to the acquirer 1174. In some embodiments, even if the issuer or host processing system 1172 has authorized the transaction, the transaction processing network 1184 may still reject the transaction, for example, depending on the value of the fraud risk score or depending on whether the limited use account parameters are verified by CBP 1180. The acquirer 1174 then sends the authorization response message to the merchant computer and / or access device 1160. The authorization response result may be displayed by the access device 1160, or may be printed out on a physical receipt. Alternatively, if the transaction is an online transaction, the merchant may provide a web page or other indication of the authorization response message as a virtual receipt. The receipt may include transaction data for the transaction.

[0112] At the end of the day, conventional clearing and settlement processes may be performed by the transaction processing network 1184. The clearing process may refer to the process of exchanging financial details between acquirers and issuers to facilitate posting to a customer's payment account and reconciling the user's settlement position.

[0113] The various entities or components described herein may be associated with or operate one or more computer devices to facilitate the functions described herein. Any entity or component, including any computer, computing system, server, or database, may use any suitable number of subsystems to facilitate the functions described herein. The components of such subsystems may be interconnected via a system bus. Additional subsystems, such as printers, keyboards, fixed disks (or other memories including computer-readable media), monitors coupled to display adapters, and others may also be coupled to the system bus. Peripherals and input / output (I / O) devices coupled to an I / O controller (which may be a processor or any suitable controller) may be connected to a computer system by any means known in the art, such as serial ports. For example, a serial port or external interface may be used to connect a computer device to a wide area network such as the Internet, a mouse input device, or a scanner. Interconnection via a system bus allows a central processor to communicate with each subsystem and control the execution of instructions from a system memory or fixed disk and the exchange of information between subsystems. The system memory and / or fixed disk may embody a computer-readable medium.

[0114] Any of the computing devices, communication devices, computers, servers, etc. described herein can be implemented using one or more processors coupled to a memory that stores code or instructions that, when executed by one or more processors, cause the device to perform one or more of the methods and processes described herein. The memory, storage media, and computer-readable media described herein for containing code or code portions may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information (such as, computer-readable instructions, data structures, program modules, or other data), including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage devices, cassettes, magnetic tape, disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium that can be used to store or transmit the desired information and can be accessed by a computer.

[0115] The methods and processes described herein are exemplary in nature, and methods and processes according to some embodiments may perform one or more steps in an order different from the order described herein, include one or more additional steps not specifically described, omit one or more steps, combine one or more steps into a single step, split one or more steps into multiple steps, and / or any combination thereof.

[0116] Any software component or function described in this application can be implemented as a software code executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language (such as, for example, Java, C++ or Perl). The software code can be stored as a series of instructions or commands on a computer-readable medium (such as, a random access memory (RAM), a read-only memory (ROM), a magnetic medium (such as a hard disk or floppy disk), or an optical medium (such as a CD-ROM). Any such computer-readable medium can reside on or inside a single computing device and can exist on or inside different computing devices within a system or network.

[0117] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0118] Unless clearly indicated to the contrary, the use of "a", "an", or "the" is intended to mean "one or more".

Claims

1. A method executed by a server computer, the method include: receiving, by the server computer, an authentication request including access credentials having a timestamp generated by a communication device, the authentication request being received after the communication device transitions from an active state to an inactive state and then back to the active state; determining, by the server computer, whether the communication device has successfully executed a predetermined shutdown sequence by determining whether the access credential has reliable timestamp information; authenticating, by the server computer, the communication device when the access credential has reliable timestamp information by having a non-reset value in the timestamp indicating that the communication device has successfully performed the predetermined shutdown sequence and the access credential has not expired; as well as An upgraded authentication of the communication device is requested by the server computer when the access credential has unreliable timestamp information indicating that the communication device did not successfully execute the predetermined shutdown sequence. 2 . The method of claim 1 , wherein the access credential indicates that the access credential has unreliable timestamp information by having a reset value in the timestamp.

3. The method according to claim 1, wherein the communication device stores the authorized network time provided from the network as the authorized network synchronization time, and stores the system synchronization elapsed time updated using the system time of the system timer of the communication device when the communication device is synchronized with the server computer. 4 . The method of claim 3 , wherein when the access credential is generated when the authorized network synchronization time stored on the communication device has a default value, the timestamp included in the access credential has a reset value.

5. The method of claim 3, wherein when the access credential is generated when the authorized network synchronization time stored on the communication device has a non-default value, the timestamp included in the access credential has a value that is a sum of: The authorized network synchronization time; and The difference between the current system time of the system timer of the communication device and the system synchronization elapsed time when the access credential is generated.

6. The method according to claim 3, wherein the predetermined shutdown sequence include: storing a local device off time on the communication device, the local device off time reflecting a device time indicated by a user configurable timer of the communication device when the communication device transitions from the active state to the inactive state; as well as An authorized network device off time is stored on the communication device reflecting the sum of: The authorized network synchronization time; and a difference between a current system time of the system timer and the system synchronized elapsed time when the communication device transitions from the active state to the inactive state; as well as A device off indicator on the communication device is set to an asserted state.

7. The method of claim 6, wherein if the device off indicator is in the asserted state when the communication device transitions from the inactive state back to the active state, setting the authorized network synchronization time on the communication device to the sum of: The authorized network device shutdown time; and The difference between a current device time indicated by the user configurable timer and the local device off time when the communication device transitions from the active state to the inactive state.

8. The method of claim 6, wherein if the device off indicator is not in the asserted state when the communication device transitions from the inactive state back to the active state, setting the authorized network synchronization time on the communication device to a default value.

9. The method of claim 1, wherein the access credential is encoded in a QR code or a barcode.

10. The method of claim 1, wherein the access credential comprises a password generated from a limited-use key.

11. A server computer, include: processor; as well as a memory storing computer readable code that, when executed by the processor, causes the server computer to perform operations including: receiving an authentication request including an access credential having a timestamp generated by a communication device, the authentication request being received after the communication device transitions from an active state to an inactive state and then back to the active state; determining whether the communication device has successfully executed a predetermined shutdown sequence by determining whether the access credential has reliable timestamp information; authenticating the communication device when the access credential has reliable timestamp information by having a non-reset value in the timestamp indicating that the communication device has successfully performed the predetermined shutdown sequence and the access credential has not expired; as well as An upgraded authentication of the communication device is requested when the access credential has unreliable timestamp information indicating that the communication device did not successfully execute the predetermined shutdown sequence.

12. The server computer of claim 11, wherein the access credential indicates that the access credential has unreliable timestamp information by having a reset value in the timestamp.

13. The server computer according to claim 11, wherein the communication device stores an authorized network time provided by a network as an authorized network synchronization time, and stores a system synchronization elapsed time updated using a system time of a system timer of the communication device when the communication device is synchronized with the server computer.

14. The server computer according to claim 13, wherein when the access credential is generated when the authorized network synchronization time stored on the communication device has a default value, the timestamp included in the access credential has a reset value.

15. The server computer of claim 13, wherein when the access credential is generated when the authorized network synchronization time stored on the communication device has a non-default value, the timestamp included in the access credential has a value that is a sum of: The authorized network synchronization time; and The difference between the current system time of the system timer of the communication device and the system synchronization elapsed time when the access credential is generated.

16. The server computer according to claim 13, wherein the predetermined shutdown sequence include: storing a local device off time on the communication device, the local device off time reflecting a device time indicated by a user configurable timer of the communication device when the communication device transitions from the active state to the inactive state; as well as An authorized network device off time is stored on the communication device reflecting the sum of: The authorized network synchronization time; and a difference between a current system time of the system timer and the system synchronized elapsed time when the communication device transitions from the active state to the inactive state; as well as A device off indicator on the communication device is set to an asserted state.

17. The server computer of claim 16, wherein if the device off indicator is in the asserted state when the communication device transitions from the inactive state back to the active state, the authorized network synchronization time on the communication device is set to the sum of: The authorized network device shutdown time; and The difference between a current device time indicated by the user configurable timer and the local device off time when the communication device transitions from the active state to the inactive state.

18. The server computer of claim 16, wherein if the device off indicator is not in the asserted state when the communication device transitions from the inactive state back to the active state, the authorized network synchronization time on the communication device is set to a default value.

19. The server computer of claim 11, wherein the access credential is encoded in a QR code or a barcode.

20. The server computer of claim 11, wherein the access credentials comprise a password generated from a limited-use key.

Images