System and method for dynamic URL generation using smart cards

Abstract

This invention provides embodiments of smart cards, and systems and methods for secure data access using smart cards. [Solution] The smart card 100 is formed on a substrate 102 and includes a microprocessor and memory containing an applet, a counter, and a unique identifier. The smart card dynamically generates a unique uniform resource location (URL) and transmits the URL via a contactless communication interface to facilitate secure data access from other devices.

Description

Technical Field

[0001] The present disclosure relates to smart cards, and more particularly, to systems and methods for dynamically generating a Uniform Resource Locator by a smart card.

Background Art

[0002] Consumers are increasingly adopting electronic payment methods such as credit cards and debit cards for purchases. Consumers typically carry at least one credit card or debit card, and often, consumers carry multiple cards. Consumers may prefer to use a credit card or debit card for reasons of convenience, to obtain rewards based on spending, to simplify their budget by receiving monthly statements, or to avoid carrying large amounts of cash. In many regions, credit card or debit card transactions exceed cash transactions.

[0003] At the same time, the widespread use of communication devices such as smartphones, smartwatches, laptop computers, tablets, etc. has made it possible to access data including financial information such as account balances and purchase activities. The availability of these devices creates an expectation among consumers that they can easily access data at home, outside of home, and on mobile devices.

[0004] Given these trends, data security is becoming increasingly important in many areas, with the protection of financial and other sensitive data being a particular concern. Despite significant investments in developing, implementing, and maintaining security measures, data theft and fraud result in losses of millions, if not billions, annually. Organizations handling financial or other sensitive data bear the cost of data security and are liable for theft or other losses resulting from data security breaches. In addition to the monetary costs, data security breaches undermine user trust in businesses, and large-scale or otherwise noteworthy breaches often attract significant attention.

[0005] Therefore, there is a critical and conflicting need to protect sensitive data while ensuring that authorized users can access it immediately. [Overview of the project]

[0006] Therefore, the purpose of this disclosure is to describe a smart card that enhances data security while promoting accessibility. Various embodiments provide a smart card and systems and methods incorporating a smart card, a proximity communication device, and a remote server.

[0007] Embodiments of this disclosure provide a smart card. The smart card comprises a substrate, a memory embedded in the substrate including an applet, a counter, and a unique customer identifier, a contactless communication interface embedded in the substrate, and a microprocessor embedded in the substrate. The microprocessor communicates data with the memory and the contactless communication interface. When the contactless communication interface enters the communication range of a communication device, the microprocessor increments the counter and synchronizes the value of the counter with the value of the counter, which includes a second counter stored in the communication device. The applet generates a unique uniform resource locator (URL) based on the incremented value of the counter and the unique customer identifier. The unique URL is transmitted to the communication device via the contactless communication interface.

[0008] Embodiments of this disclosure provide a system for secure access to information. The system comprises a server containing financial information, a smart card, and a communication device having a communication range. The smart card has a microprocessor, a contactless communication interface, and memory. The memory stores an applet, a counter, and a unique customer identifier. When the contactless communication interface enters the communication range, the microprocessor is configured to increment the value stored in the counter and synchronize the incremented counter value with the communication device. The applet is configured to generate a unique URL based on the incremented value of the counter and the unique customer identifier. The contactless communication interface is configured to send the URL to the communication device. Upon receiving the unique URL, the communication device opens the URL to display the financial information received from the server.

[0009] Embodiments of the present disclosure provide a method for accessing information. This method includes bringing a smart card, which includes a contactless communication interface, a microprocessor, and memory for storing an applet, a counter, and a unique customer identifier, into the communication range of a communication device; incrementing a value stored in the counter and synchronizing that value with the counter included in the communication device; generating a unique URL based on the incremented counter value and the unique customer identifier; sending the unique URL to the communication device via the contactless communication interface; synchronizing the value of the counter included in the communication device with a server containing financial information; adding location information associated with the communication device to the unique URL; and sending the unique URL to the server. [Brief explanation of the drawing]

[0010] [Figure 1A] A diagram showing an exemplary embodiment of a smart card. [Figure 1B] Figure 1A shows an exemplary embodiment of the contact pad of a smart card. [Figure 2] A diagram illustrating an exemplary embodiment of a system for secure data access using smart cards. [Figure 3] A diagram illustrating an exemplary embodiment of a method for providing secure data access using smart cards. [Figure 4A] This figure shows an exemplary embodiment of an authentication selection user interface displayed by a software application. [Figure 4B] This figure shows an exemplary embodiment of an authentication user interface displayed by a software application. [Figure 4C] Figure showing an exemplary embodiment of an information user interface displayed by a software application. [Figure 5] A diagram illustrating an exemplary embodiment of a user interface for authentication and information displayed on a web browser. [Modes for carrying out the invention]

[0011] One aspect of this disclosure is to provide a smart card that dynamically generates uniform resource locators and systems and methods using the smart card in order to provide convenient and secure access to account data.

[0012] Figure 1A shows a smart card 100 according to an exemplary embodiment. In this embodiment, the smart card 100 may be a payment card, such as a credit card, debit card, or gift card, issued by a service provider 101, as indicated on the front or back of the smart card 100. The smart card 100 may be formed from a substrate 102 which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In one embodiment, the smart card 100 may have physical properties conforming to the ID-1 format of ISO / IEC 7810, or otherwise, the smart card 100 may conform to ISO / IEC 14443. However, the smart cards according to this disclosure may have different properties, and it should be understood that this disclosure does not require the smart card to be implemented as a payment card.

[0013] The smart card 100 may also include identification information 103 displayed on the front and / or back of the card, and a contact pad 104. The contact pad 104 can establish contact with another communication device such as a smartphone, laptop, desktop, or tablet computer. The smart card 100 may also include processing circuits, an antenna, and other components not shown in Figure 1A. These components may be located behind the contact pad 104 or elsewhere on the substrate 102. The smart card 100 may also include a magnetic strip or tape that may be located on the back of the card (not shown in Figure 1A).

[0014] Figure 1B shows an exploded view of the contact pad 104 of the smart card 100 according to an exemplary embodiment. As shown in Figure 1B, the contact pad 104 may include a processing circuit 105 for storing and processing information. The processing circuit 105 includes a microprocessor 106 and memory 107. It is understood that the processing circuit 105 may include additional components, such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamper-proof hardware, as necessary to perform the functions described herein.

[0015] Memory 107 may be read-only memory, write-once / read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM. Smart card 100 may include one or more of these memories. Read-only memory is programmable at the factory as read-only or one-time programmable. One-time programmability allows it to be written once and read multiple times. Write-once / read-multiple memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten but can be read multiple times. Read / write memory may be programmed and reprogrammed multiple times after leaving the factory and can also be read multiple times.

[0016] Memory 107 can store an applet 108, a counter 109, and a customer identifier 110. The applet 108 may be a software application intended to run on a smart card, such as a Java Card applet. However, it is understood that the applet is not limited to a Java Card applet and may be any software application that can run on a smart card or other device with limited memory. The counter 109 may be a numeric counter sufficient to store integers. The customer identifier 110 may be a unique alphanumeric identifier assigned to a smart card user, which may distinguish the smart card user from all other smart card users. In one embodiment, the customer identifier 110 may identify both the customer and the account assigned to that customer, and further may identify a specific smart card 101 associated with the customer's account.

[0017] Memory 107 is divided into several zones. Each zone has a different level of security. The microprocessor 106 can track which memory addresses belong to which zone and the status of access to each zone. In an exemplary embodiment, memory 107 can be divided into four zones: a secret zone, a confidential zone, a usage zone, and a public zone.

[0018] The secret zone can be used to store information that can only be used by the microprocessor 106, such as passwords and encryption keys. Information stored in this zone cannot be read outside the smart card. In one embodiment, the secret zone may be implemented by another processor capable of performing encryption functions. The encryption key is either passed to the secret zone or generated in the secret zone. In either case, the key is stored in the secret zone and used to support the encryption service. If necessary, the encryption key can be exported from the secret zone.

[0019] Using a confidential zone, a list of all transactions conducted with the card can be saved. The confidential zone may have password protection. In an exemplary embodiment, the password is known only to the card issuer. The card issuer can examine the card's history for evidence of system misuse. The confidential zone may have read-only access restrictions to prevent modification of the information stored in this zone. For example, the transaction list may be made unmodifiable. In another embodiment, the applet 108 and any associated memory can be protected by a firewall from other applets stored on the smart card 100. In this embodiment, the applet 108 can process the transmission or reception of any information.

[0020] The usage zone can be used to store information that may be updated or changed periodically. Depending on the data's confidentiality, a password may be implemented in this zone. The usage zone may have both password-protected read and write access. In one embodiment, a unique URL generated by the smart card can be stored in the usage zone of the memory 107.

[0021] The public zone can be used to hold less-confidential information such as the card issuer's name and address, or the counter 109. The public zone may have read-only access rights without a password.

[0022] Although the processor and memory elements of the foregoing exemplary embodiments have been described with reference to contact pads, the present disclosure is not limited thereto. It is understood that these elements can be implemented outside the pads, completely separated from the pads, or in addition to the processor and memory elements disposed within the contact pads as further elements.

[0023] As shown in FIG. 1B, the smart card 100 may include an antenna 111. The antenna 111 can be disposed within the smart card 100 around the processing circuit 105 of the contact pad 104. For example, the antenna 111 can be integral with the processing circuit, and the antenna 111 can be used with an external booster coil. As another example, the antenna 111 can be external to the contact pad 104 and the processing circuit 105.

[0024] In certain embodiments, the coil of the smart card 100 can function as the secondary side of an air-core transformer. The terminal can communicate with the smart card 100 by blocking power or amplitude modulation. The smart card 100 can infer data transmitted from the terminal using the gap in the power connection of the smart card, which can be functionally maintained via a capacitor. The smart card 100 can communicate back by switching the load or load modulation of the coil of the smart card. The load modulation can be detected at the coil of the terminal by interference.

[0025] FIG. 2 shows a system for secure data access using a smart card according to an exemplary embodiment. As shown in FIG. 2, the system 200 may include a smart card 201, a portable communication device 202, a fixed communication device 203, and a server 204. In certain embodiments, the smart card 201 can be the same as the smart card 100 described with reference to FIGS. 1A and 1B.

[0026] The portable communication device 202 may include a microprocessor, memory, a contactless communication interface having a communication range (not shown in Figure 2), and a display. The portable communication device 202 may also include means for receiving user input, such as a keypad, touchscreen, voice command recognition, stylus, and other input / output devices. The display may be any type of display screen, including an LCD display or an LED display. Exemplary portable communication devices include, but are not limited to, smartphones, laptop computers, tablet computers, personal digital assistants, palmtop computers, or other portable computing devices.

[0027] The portable communication device 202 may include a software application associated with or working with the smart card 201 and / or a web browser to display data received from the network connection. The software application or web browser may be configured to run on the portable device. The contactless communication interface may be any short-range wireless communication interface, such as near-field communication (NFC) and radio frequency identification (RFID). In one embodiment, the contactless communication interface may be an NFC interface compliant with ISO 18092 / ECMA-340. This contactless communication interface may allow data communication with the smart card 201 when the smart card 201 is within the communication range of the interface. When the smart card 201 is within the data communication range of the portable communication device 202, the smart card 201 may synchronize the value of a counter stored in its memory with a counter stored by the portable communication device 202, and furthermore, the smart card 201 may transmit a unique URL to the portable communication device 202.

[0028] The portable communication device 202 may have data connectivity to a network such as the Internet via a wireless communication network, cellular network, wide area network, local area network, wireless personal area network, wide body area network, or a combination thereof. This connectivity allows the portable communication device 202 to communicate with the server 204. For example, the portable communication device 202 can synchronize counters stored in its memory with the server 204 and send a unique URL received from the smart card 201 to the server 204 (for example, the portable communication device 202 can open the unique URL in a web browser or software application). Upon receiving the unique URL, the server 204 can send financial information or other information to the smart card 201.

[0029] The fixed communication device 203 may include a microprocessor, memory, a contactless communication interface having a communication range (not shown in Figure 2), and a display. The fixed communication device 203 may also include means for receiving user input, such as a keypad, touchscreen, voice command recognition, stylus, and other input / output devices. The display may be any type of display screen, including an LCD display or an LED display. Exemplary fixed communication devices include, but are not limited to, desktop computers, cash registers, kiosks, checkout machines, automated teller machines (ATMs), information stations, booths, order stations, map or general information displays, and countertop computer displays, as well as laptop computers, tablets, and other computing hardware with assigned locations.

[0030] The fixed communication device 203 may include a software application that is associated with or interacts with the smart card 201 and / or a web browser to display data received from the network connection. The software application or web browser may be configured to run on a portable communication device such as the portable communication device 202. Alternatively, the software application or web browser may be configured to run on a device with more system resources. The contactless communication interface may be any short-range wireless communication interface such as near-field communication (NFC) and radio-frequency identification (RFID). In one embodiment, the contactless communication interface may be an NFC interface conforming to the ISO 18092 / ECMA-340 standard. This contactless communication interface may enable data communication with the smart card 201 when the smart card 201 is within the communication field of the interface. When the smart card 201 is within the data communication range of the fixed communication device 203, the smart card 201 can synchronize the value of a counter stored in its memory with a counter stored by the fixed communication device 203. Furthermore, the smart card 201 can transmit a unique URL to the fixed communication device 203. In one embodiment, the fixed communication device 203 can be installed in a commercial facility such as a store, restaurant, office, or other work site.

[0031] The smart card 201 can generate a unique URL by synchronizing the value of a counter stored in its memory with the value of a counter stored in the fixed communication device 203. The smart card 201 can add tags to the unique URL to provide additional information to the communication devices 202, 203 and the server 204. The tags may include customer identifiers, such as the customer identifier 110 discussed with reference to Figure 1.

[0032] In one embodiment, the portable communication device 202 may have a location function that allows the device to determine its current geographical location. For example, the portable communication device 202 may determine its location using the Global Positioning System (GPS) or based on its wireless data connection (e.g., a nearby cellular tower or wireless internet router). The portable communication device 202 may add location information to a URL before sending the URL to the server 204.

[0033] The portable communication device 202 may add information relevant to itself to the unique URL before sending the URL to the server 204. For example, the portable communication device 202 may add information related to the brand or model of the device or its operating system. For example, the portable communication device 202 may add an identifier related to the device's user, an identifier related to the device's registered owner, or information that identifies the device itself, or information related to its operation, such as operating system information. In one embodiment, the portable communication device 202 may be a smartphone including a subscriber identification module (SIM) card. The portable communication device 202 may add an international mobile subscriber identification number to the URL.

[0034] Similarly, a fixed communication device 203 can add information relevant to itself to its unique URL before sending the URL to the server 204. Like a portable communication device 202, a fixed communication device can add information that identifies the device or its operating system. Furthermore, given its stationary nature, a fixed communication device 203 may hold information specific to its location. For example, if the fixed communication device 203 is located in an electronics store, information that identifies the store and its characteristics can be added to its unique URL. In one embodiment, this information and location information can be sent to the server 204 via the unique URL to identify that particular electronics store, available products, or current promotions or rewards. In another embodiment, the fixed communication device 203 can access store records such as loyalty programs or special offers, and this information can be sent to the server 204.

[0035] Server 204 can communicate data with multiple communication devices, including portable communication devices 202 and fixed communication devices 203. This data communication can be achieved through networks such as the Internet, via wireless communication networks, cellular networks, wide area networks, local area networks, wireless personal area networks, wide body area networks, or any combination thereof. This data connectivity allows Server 204 to synchronize the values ​​of counters stored in its memory with counters stored in communication devices 202 and 203, receive unique URLs from communication devices 202 and 203, and transmit information in response to the unique URLs.

[0036] In one embodiment, the server 204 can also receive and interpret identification information of devices 202, 203. For example, the portable communication device 202 may add information that identifies itself or its user to a unique URL. Upon receiving this information, the server 204 can compare the device identification information with records of the smart card 201, or the account or user associated with the smart card 201 (which may be identified by a customer identifier). If the identification information matches account information and records available to the server 204, the server 204 can send financial information or other information to the portable communication device 202. If the identification information does not match, the server 204 may request the user to submit authentication information before sending data in response to the unique URL. The requested authentication may include a password, security questions, swipe patterns, image recognition, driver's license scanning, multi-factor authentication, biometric authentication, or a combination thereof. Examples of biometric authentication are voice recognition, fingerprint scanning, retinal scanning, and facial scanning, if the portable communication device 202 is configured to accept voice recognition, fingerprint scanning, retinal scanning, and facial scanning inputs. For example, multi-factor authentication may involve requiring the user to read and respond to, or obtain a code from, text messages sent to the smart card user or a registered phone number, emails sent to the user's registered email address, or notifications sent to a software application installed by the smart card user. In other examples, the phone number, email address, and software application may be associated with an account linked to the smart card 201, rather than the smart card user. In another example, the server 204 may allow the user to select one or more authentication methods supported by the portable communication device 202. If the requested authentication is not provided, or if the server 204 finds that the entered authentication is incorrect, the server may refuse to provide information to the portable communication device 202.

[0037] For example, the portable communication device 202 may be a smartphone. Information identifying the smartphone user or smartphone device (e.g., phone number, SIM card, or via other means) may be appended to the unique URL sent to the server 204. If the user identification information or device identification information provided by the portable communication device 202 matches the smart card user or smart card account information, the server 204 may send information to the portable communication device 202 in response to the unique URL. If there is no match, the server 204 may refuse to send the response information to the portable communication device 202, or may require the portable communication device 202 to enter additional authentication information before sending the information. In embodiments where the identification information of the portable communication device 202 does not match any records available to the server 204, and incorrect authentication information (or no authentication information) is provided, it is more likely that the smart card 201 is in the possession of an unauthenticated individual. The smart card 201 may be lost or stolen. By refusing to transmit information to the portable communication device 202, server 204 may have prevented the commission of fraud or identity theft.

[0038] In one embodiment, the fixed communication device 203 can support authentication methods similar to those of the portable communication device 202. Furthermore, the fixed communication device 203 may allow other authentication methods. For example, the fixed communication device 203 may be placed in an information kiosk or checkout register in a store or other commercial location supervised by a store employee. In this case, the employee may ask the user to present a photo ID. If a suitable ID is presented, the employee may enter a code, scan a badge, or otherwise indicate to the fixed communication device 203 that a suitable ID has been presented.

[0039] In one embodiment, the confidentiality of the requested information can also determine whether the server requires additional authentication. For example, if a unique URL requests an account balance or credit score, the server may require additional authentication from the user before sending this information to the communication device. In another example, if a unique URL requests information about a rewards or loyalty program, the server may not require any further authentication.

[0040] In one embodiment, the URL may be specific to this information request and may be partially based on the counter value and customer information stored in the smart card's memory. Synchronization of the counter value between the smart card 201, communication devices 202, 203, and server 204 can facilitate the uniqueness of the URL. For example, the URL may include pseudo-random or quasi-random elements, which may be based on the counter value, customer ID (customer identification), or other values ​​known across all devices or in combination thereof. As another example, a unique URL may be formed by cryptographically hashing the customer ID and counter value, with the hash included as part of the unique URL. Server 204 can reconstruct the hash using the expected value of the counter, and if they match, server 204 can determine that authentication was successful and the user may be granted access to the data. Furthermore, this particular URL may only be used for one information request, and different URLs may be generated for subsequent requests. This may also be true if the same information is requested multiple times. Using disposable URLs can improve the security of information requests and reduce the likelihood of unauthorized users successfully requesting data access. In one embodiment, the smart card 201 can generate a series of unique URLs for requesting or communicating subsequent information to communication devices 202, 203 and a server 204.

[0041] In another example, server 204 can access the user's account settings and transaction history. If suspicious activity, potential fraud, or purchases of an unusual frequency or scale are detected, server 204 may request additional authentication before providing further account information. In another embodiment, smart card 201 can determine whether additional authentication is required and generate a unique URL to make that request.

[0042] In one embodiment, the functions of server 204 may be performed by multiple servers connected by a network. These servers can communicate over the Internet or other networks and do not need to be geographically close to the smart card 201 or communication devices 202, 203. Server 204 can also communicate with servers outside the system shown in Figure 2, such as servers belonging to commercial or other entities, to retrieve, provide, or verify information.

[0043] Figure 3 is a flowchart illustrating a method for providing secure data access using a smart card according to an exemplary embodiment. The secure data access method 300 begins in step 305 when the smart card enters the communication range of a portable or stationary communication device. In step 310, upon entering the communication range, the smart card increments the value of a counter stored in its memory, and in step 315, the smart card synchronizes this value with a counter stored in the communication device. Next, in step 320, the smart card can generate a unique URL that may indicate the requested information, along with the counter value and customer identification. In one embodiment, the smart card may add location information, device-specific information, or user-specific information, and other potentially relevant information.

[0044] Once a unique URL is generated, the smart card can send the URL to the communication device in step 325 via its contactless communication interface, and the URL can be stored in the communication device's memory. Upon receiving the unique URL, the communication device can synchronize the value of its counter with the counter stored by the server in step 330, so that the server has the value of the counter used to create the unique URL. Furthermore, the communication device can add additional information to the unique URL, such as information that identifies itself or its location, before sending the URL to the server. Once this is done, the communication device can send the unique URL to the server in step 335.

[0045] Upon receiving a unique URL, in step 340 the server determines whether the requested information is sensitive enough to require additional authentication. If the server determines that no further authentication is required, a "No" selection is made in step 345, and the server sends the requested information to the communication device (step 350) and displays it to the user (step 360).

[0046] Alternatively, if the server determines that additional information is needed, a "Yes" selection is made in step 345, and the communication device prompts the user to provide additional authentication in step 360. If the user fails to provide sufficient authentication, a "No" selection is made in step 365, and the server refuses to send information to the communication device (step 370). If sufficient authentication is provided, a "Yes" selection is made in step 365, and the server sends the requested information to the communication device (step 375) and displays it to the user (step 380).

[0047] Figures 4A, 4B, and 4C show user interfaces for authentication and account information displayed on a software application according to an exemplary embodiment. The software application is designed for use on both portable and fixed communication devices and may be optimized for use on each device. Figures 4A, 4B, and 4C are illustrative and it should be understood that the information that may be displayed is not limited thereto.

[0048] As shown in Figure 4A, an application may display an authentication method selection interface 410. This interface may be displayed when a software application opens a unique URL and the server determines that additional authentication is required to display the requested information. The authentication method selection interface 410 can list authentication methods supported by the application, communication device, and server, including the methods described above, for which authentication information is available. As shown in Figure 4A, these methods include entering a password, receiving a security code, and scanning a fingerprint.

[0049] Figure 4B shows several authentication user interfaces. The password authentication interface 420 requires the user to enter a password before the application can display information. The security code authentication interface 430 requires the user to enter a security code. The request for the security code may be sent via email to the user's registered email address or via text message to the user's registered phone number. The fingerprint authentication interface 440 requires the user to place their finger on a fingerprint scanner (not shown in Figure 4B). With each of these interfaces, the user can select a different authentication method by pressing a button at the bottom of the interface. If pressed, the button may return the user to the authentication method selection interface 410. Authentication information transmitted through these interfaces may be sent to a server for verification. If the user is successfully authenticated, the user can see the account interface 450 shown in Figure 4C. If the user is not successfully authenticated, the software application may ask the user to resend the information or select a different authentication method, notify the user that the information is currently inaccessible, or close the application. Authentication interfaces 420, 430, and 440 are merely illustrative examples, and it should be understood that the information viewable in a web browser is not limited to that shown in Figure 4B.

[0050] Figure 4C shows the account interface 450 that appears when a user is successfully authenticated. The account interface 450 can display information related to the account associated with the smart card. As shown in Figure 4C, the credit card account is displayed, along with information related to this account, such as the name, account number, and outstanding balance. Furthermore, the user can choose to view more detailed information about account activity, rewards, and account options by selecting from the buttons listed at the bottom of the account interface 450. When the user is finished, they can end their browsing session by logging out of the account using the logout button.

[0051] Figure 5 shows a user interface for authentication and account information displayed in a web browser, according to an exemplary embodiment. It should be understood that the interface shown in Figure 5 is illustrative and the information that may be displayed is not limited thereto.

[0052] In one embodiment, the authentication interface 510 may appear in response to a web browser opening a unique URL if the server determines that additional authentication is required to display the requested information. As shown in Figure 5, the authentication interface 510 may accept a username or password as authentication. Alternatively, the authentication interface 510 may require only a password. Furthermore, the authentication interface 510 may give the user the option to select an alternative authentication method. These methods may include other authentication methods supported by the web browser, communication device, and server, including the aforementioned methods where authentication information is available.

[0053] Upon entering this information, the web browser communicates with the server to verify the transmitted information. If the user is successfully authenticated, the account interface 520 may be displayed. The account interface 520 can display information related to the account associated with the smart card. In the embodiment shown in Figure 5, a credit card account is displayed, showing information related to this account, such as the name, account number, and outstanding balance. Furthermore, the user can choose to view more detailed information about account activity, rewards, and account options by selecting from buttons listed at the bottom of the account interface 520. It should be understood that the authentication interface 510 and interface 520 are merely illustrative examples, and the information available for viewing in the web browser is not limited to that shown in Figure 5. When the user is finished, they can end the browsing session by logging out of the account using the logout button. If the user is not successfully authenticated, the web browser may ask the user to resend the information, allow the user to choose an alternative authentication method, notify the user that the information is currently inaccessible, or close the browser.

[0054] The interfaces of the embodiments described above may be formatted as, for example, a web page in a hypertext markup language (HTML), an extensible markup language (XML), or any other suitable format for presentation on a communication device. The forms and formats may depend on the application the user uses to interact with the device and the system resources available on the device. The user may use any device to input information into a communication device available and supported on the device, including a touchscreen, virtual keyboard, cursor control device, stylus, and speech recognition.

[0055] This disclosure is intended to be illustrative of various embodiments and should not be limited to the specific embodiments described in this application. As will be apparent, many modifications and variations are possible without departing from its spirit and scope. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure may be apparent from the above representative description. Such modifications and variations are intended to fall within the scope of the appended representative claims. This disclosure should be limited only by the terms of the appended representative claims and the entire scope of the equivalents to which such representative claims are claimed. It should also be understood that the terms used herein are intended solely to describe specific embodiments and are not intended to limit them.

Claims

1. circuit board and A memory embedded in the aforementioned substrate, including an applet, a counter, and a unique customer identifier, A contactless communication interface embedded in the aforementioned substrate, A microprocessor embedded in the substrate, which communicates data with the memory and the contactless communication interface. Equipped with, When the contactless communication interface enters the communication range of the communication device, the microprocessor increments the counter and synchronizes the value of the counter with a second counter stored in the communication device. The applet generates a unique, one-time URL (Uniform Resource Locator) by encrypting and hashing the counter increment value and a unique customer ID. The aforementioned unique, one-time URL is transmitted to the communication device via the contactless communication interface on a smart card.

2. A system for secure access to information, A server containing financial information, It is a smart card, microprocessor, Contactless communication interface, and Memory that stores applets, counters, and unique customer identifiers Smart cards including, A client application containing instructions to be executed on a communication device with a communication range, Equipped with, When the aforementioned contactless communication interface enters the communication range of the communication device, The microprocessor is configured to increment the value stored in the counter and to synchronize the incremented counter value with the client application. The applet is configured to generate a unique, one-time URL (Uniform Resource Locator) by encrypting and hashing the increment value of the counter and the unique customer ID. The contactless communication interface is configured to transmit the unique, one-time URL to the client application. Upon receiving the unique, one-time URL, the client application opens the unique, one-time URL and displays the financial information received from the server. The server is a system for secure access to information, which regenerates an encrypted hash using the increment value of the counter before the client application displays the financial information.

3. Before sending financial information to the client application, the server requests the client application to enter authentication information. A system for secure access to information as described in claim 1.

4. The server requests the input of authentication information based on the confidentiality of the financial information. A system for secure access to information as described in claim 3.

5. The authentication information is at least one of a password, a fingerprint scan, and a facial scan. A system for secure access to information as described in claim 3.

6. The client application synchronizes the incremented counter value with the server before sending the unique, one-time URL. A system for secure access to information as described in claim 1.

7. The client application adds information that identifies itself to the unique, one-time URL sent to the server. A system for secure access to information as described in claim 1.

8. The server refuses to transmit financial information to the client application based on the identification information attached to the unique, one-time URL by the client application. A system for secure access to information as described in claim 7.

9. The client application adds location information to the unique, one-time URL sent to the server. A system for secure access to information as described in claim 1.

10. The communication device is located in a fixed position, and the client application adds information about its location to the unique, one-time URL sent to the server. A system for secure access to information as described in claim 1.

11. The client application is located in a commercial area, and the client application adds information related to the commercial area to the unique, one-time URL sent to the server. A system for secure access to information as described in claim 1.

12. Upon receiving the unique, one-time URL, the server provides location-specific data to the client application based on the information attached to the unique, one-time URL. A system for secure access to information according to claim 11.

13. The client application displays the financial information received from the server in a browser or one of the second applications. A system for secure access to information as described in claim 1.

14. The contactless communication interface is configured to support at least one of short-range wireless communication and body area networking. A system for secure access to information as described in claim 1.

15. Moving a smart card within the communication range of a communication device, wherein the smart card is Contactless communication interface, Microprocessor, and Memory that stores applets, counters, and unique customer identifiers Including moving and The value stored in the counter is incremented, and the value is synchronized with the counter included in the communication device. By encrypting and hashing the incremented counter value and the unique customer identifier, a unique, one-time URL (Uniform Resource Locator) is generated. Sending the client application a unique, one-time URL containing instructions to be executed on the communication device via the contactless communication interface, Adding location information related to the communication device to the unique URL, Sending the aforementioned unique, one-time URL to a server containing financial information, The server regenerates the encrypted hash using the expected counter value and the unique customer identifier, The encryption hash regenerated by the server is compared with the unique, one-time URL sent to the server. If the regenerated cryptographic hash matches the unique, one-time URL, the server transmits financial information to the client application. A method of accessing information that encompasses it.

16. The communication device is located in a commercial location, and the added information is related to the commercial location. A method for accessing information as described in claim 15.

17. Further encompassing receiving location-specific data from the server in response to the aforementioned added location information, A method for accessing information according to claim 15.

18. This further includes entering at least one of the following before receiving financial information from the server: a password, a fingerprint scan, or a facial scan. A method for accessing information according to claim 15.

19. Further encompasses adding information identifying the communication device to the unique one-time URL before sending the unique one-time URL to the server, A method for accessing information as described in claim 15.

20. The server inspects the information identifying the communication device added to the unique, one-time URL and requests additional authentication information. A method for accessing information according to claim 19.

Images