Playing card with electronic authentication means

Abstract

To provide a playing card system, a playing card, a playing card authentication device, a playing card authentication server, a playing card authentication method, and a computer readable medium for making counterfeiting the card harder.SOLUTION: A playing card system (100) comprises a playing card (110), a playing card authentication device (200), and a playing card authentication server (300) to authenticate the playing card for playing a card game. The playing card (110) comprises an electronic memory (120) storing authentication data (122) and a counter (124).SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a playing card system, a playing card, a playing card authentication device, a playing card authentication server, a playing card authentication method, and a computer-readable medium. [Background technology]

[0002] Trading card games (TCGs), also known as collectible card games (CCGs), are games played with tradable and collectible trading cards. Such games are becoming increasingly popular. For example, the game "Magic: the Gathering" (MTG) has a large number of active players. Other examples of trading card games include Pokemon TCG, World of Warcraft TCG, and Hearthstone, among others. Hybrid formats between computer games and card games are also known. For example, in the game "Kantai Collection," players collect cards as in a TCG, but to play the game, the cards are scanned into a gaming machine, such as an arcade machine. Another example of such a computer game that uses tradable cards is "Sengoku Taisen."

[0003] In a TCG, players collect cards that represent game elements, such as characters, abilities, or the like, that can be used during gameplay. Typically, players may obtain a large number of playing cards by buying many small stacks of new cards known as foils or packs, often without knowing which playing cards will be contained within the foils. From the large number of playing cards, players assemble a set of cards known as a deck with which they can play the game. Players whose decks contain better cards enjoy some advantage during gameplay. For example, a pack may contain six more-or-less random cards, while a deck may contain 60 selected cards.

[0004] The manufacturing and buying and selling of cards used in trading card games has grown into a big business. There were an estimated 22 million players in 2014, a 35% increase over the past four years. In addition to the buying and selling of new cards, there is an active secondary market where players can directly obtain the cards they need for their decks.

[0005] Unfortunately, counterfeiting of playing cards is a serious problem in this business. Playing cards are becoming increasingly expensive, and the incentive to counterfeit continues to grow. Counterfeits are very difficult to distinguish from genuine cards. Counterfeits erode consumer confidence. Without confidence in the collectibility of the game, cards revert to their original value. Summary of the Invention [Problem to be solved by the invention]

[0006] Therefore, there is a desire to devise a technological solution to the problem of counterfeiting in the field of playing cards. [Means for solving the problem]

[0007] The problem is addressed by the playing card system, playing cards, playing card authentication device, playing card authentication server, playing card authentication method, and computer readable medium as described herein.

[0008] The playing card may be configured for playing a card game. The playing card may include an electronic memory, an antenna, and a processing circuit. The memory may store authentication data and / or a counter. The antenna may be configured for wireless communication. The processing circuit may include: - wirelessly receiving digital commands over the antenna from an electronic playing card authentication device; - in response to receiving an authentication command, creating an authentication token, the creating including reading authentication data and a counter from memory and applying a cryptographic function to the authentication data and the counter; - wirelessly transmitting an authentication token to the device through the antenna; and - Incrementing a counter stored in memory may be configured for one or more of:

[0009] The authenticity of the card can be verified using an authentication device and an authentication server. For example, the authentication device can interact with the playing card locally and wirelessly. The resulting token can then be verified using the authentication server, for example, using information available at the server, such as corresponding authentication data and / or a corresponding counter. Note that the token can be generated on the playing card such that the authentication data does not need to be available outside the card, or at least not all of the authentication data needs to be available outside the card. This makes it more difficult to counterfeit the card because a counterfeiter would not know what information to include in the counterfeit card.

[0010] A counter stored on the playing card can be incremented after the playing card creates an authentication token. There are at least two different options for doing this. In the first option, the counter on the card is proactive. For example, this counter can be incremented after every action. For example, the playing card can be configured so that it increments the counter as it creates the authentication token. This option has the advantage, for example, that the transaction is not easily interrupted. In particular, it is unlikely on the card's side that an authentication token is successfully created but the counter is not updated. Although it is possible, the counter on the card can be incremented, while the counter on the server is likely not to be incremented, for example, due to a failure in the authentication device. In this option, it is possible that the counter on the card is larger than the counter on the server.

[0011] In the second option, the counter on the server is proactive. For example, the counter is incremented after the playing card receives a command, e.g., a signal, indicating that the counter should be incremented. Both options can be combined with updating the authentication data on the playing card after successful authentication. However, the second option has the advantage that the increment counter command can be combined with a command to update the authentication. For example, after successful authentication, new authentication data is sent from the server to the card, possibly through an authentication device, and the authentication data is written back onto the card. The new authentication data can include a new value for the counter, but can also include a command to update the counter present on the card. The authentication data can include random data. The second option has the disadvantage that the transaction can be more easily interrupted. As a result of this, the counter on the card may not be updated, while the same counter stored on the server may be updated. In this option, it may happen that the counter on the server is larger than the counter on the card.

[0012] The playing cards, the authentication device and the authentication server are electronic devices. In particular, the playing cards and the authentication device may be mobile electronic devices.

[0013] In an embodiment, the authentication server is configured to generate a computer network address through which an information page is accessible on the computer network. The information page includes information indicating the results of the authentication of the playing card. For example, the computer network address may be made available to a playing card authentication device.

[0014] For example, the authentication server may generate a web page containing information about the card. The information may include the authenticity of the card and / or the current owner of the card. The information may also include the date and time when the authenticity of the card was last verified at the authentication server. The information may also include additional information about the card, such as pictures, textual information, and the like. The computer network address may be a URL. The computer network may be the Internet. The computer network address or URL may be referred to as a proof link. The proof link may be valid for a limited duration. For example, in an embodiment, after the validity of the proof link expires, the authentication server may be configured to indicate that the link has expired instead of indicating the authenticity information. This feature further reduces the potential for fraud.

[0015] Another aspect of the present invention involves physical objects that include electronic memory, such as the playing cards described herein. Like playing cards, physical objects can be verified by an authentication device using an online authentication server. This can be applied, for example, to objects such as branded shoes, perfumes, and the like. Method embodiments can be implemented on a computer as a computer-implemented method, or in dedicated hardware, or a combination of both. Executable code for method embodiments can be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, and the like. Preferably, the computer program product includes non-transitory program code stored on a computer-readable medium for performing method embodiments when the program product is executed on a computer.

[0016] In an embodiment, the computer program comprises computer program code configured to perform all or part of the steps of the method embodiments when the computer program is run on a computer. Preferably, the computer program is embodied on a computer-readable medium.

[0017] Another aspect of the present invention provides a method for making a computer program available for downloading, which is used when the computer program is uploaded into, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and when the computer program is made available for downloading from such stores.

[0018] Further details, aspects, and embodiments of the present invention will now be described, by way of example only, with reference to the drawings, in which elements are illustrated for simplicity and clarity and are not necessarily drawn to scale, and in which elements corresponding to elements already described may have the same reference numerals. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 1 is a diagram illustrating an example of an embodiment of a playing card system. [Figure 2] FIG. 1 is a diagram illustrating an example of an embodiment of a playing card system. [Figure 3a] FIG. 1 is a diagram illustrating an example of a blockchain embodiment. [Figure 3b] FIG. 1 is a diagram illustrating an example of an embodiment of a blockchain network. [Figure 4] FIG. 1 illustrates a schematic diagram of an example embodiment of a playing card authentication method. [Figure 5a] 1 is a diagram illustrating a computer-readable medium having a writable portion containing a computer program according to an embodiment; [Figure 5b] FIG. 1 is a diagram that schematically illustrates a representation of a processor system according to an embodiment. [Figure 6] FIG. 1 is a diagram illustrating an example of an embodiment of a playing card system. [Figure 7] FIG. 1 is a diagram illustrating an example of an embodiment of a playing card system. [Figure 8a] FIG. 2 is a diagram illustrating an example of a data model for an embodiment of a marketplace application. [Figure 8b] FIG. 10 is a schematic diagram illustrating an example process diagram for an embodiment of a marketplace application. [Figure 9a] FIG. 1 is a diagram illustrating an example of an embodiment of a playing card. [Figure 9b] 1A-1C are diagrams illustrating an example of an embodiment of a card binder. [Figure 10]1A-1C are schematic diagrams illustrating examples of embodiments of sneakers with tags embedded therein. DETAILED DESCRIPTION OF THE INVENTION

[0020] List of reference numbers in Figures 1, 2, 3a, 3b, 4, 5a, and 5b 100 Playing Card System 110 Playing Cards 120 Electronic Memory 122 Authentication Data 124 counters 130 Antenna 140 Processing Circuit 200 Playing Card Authentication Device 210 Communication Unit 220 Antenna 230 Processing Circuit 240 memory 250 displays 300 Playing Card Authentication Server 310 Electronic Memory 312 Authentication Data 314 Counter 320 Communication Unit 330 Processing Circuit 340 Playing Card Database 400 Playing Card System 410 Playing Cards 411 Printed Information 412 chips 413 Antenna 414 Text 414 Text 415 Additional Text 416 Pictures 450 mobile phones 500 Blockchain 511, 512 transactions 521, 522 transactions Blocks 510 and 520 519, 529 Consensus Proof 530 Blockchain Network 531-533 Blockchain Device 1000 Computer Readable Medium 1010 Writable area 1020 Computer Program 1110 Integrated Circuits 1120 Processing Unit 1122 memory 1124 dedicated integrated circuits 1126 Communication Elements 1130 Interconnect 1140 Processor System

[0021] While the present invention is susceptible to embodiment in many different forms, one or more specific embodiments have been shown in the drawings and will be described in detail herein, with the understanding that the present disclosure is to be considered as illustrative of the principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

[0022] For purposes of understanding, elements of the embodiments are described below in terms of their operation, however it will be apparent that each element is configured to perform the described functions as performed by those elements.

[0023] Furthermore, the invention is not limited to the embodiments, but resides in each and every novel feature or combination of features described herein or recited in mutually different dependent claims.

[0024] As pointed out above, there is a desire for technological measures that would make counterfeiting more difficult. A possible solution to the counterfeiting problem is to embed an RFID tag, such as a near-field communication (NFC) tag, into a playing card. For example, the RFID tag can identify the card. An RFID reader, such as a mobile phone, an NFC reader, or the like, can read the identifying information on the tag. If the identifying information on the tag corresponds to the identifying information visually printed on the card, it can be concluded that the card is authentic. This solution makes card counterfeiting more difficult because it requires the embedding and writing of an RFID tag in addition to an exact visual reproduction of the card. For example, an NFC tag could be used in place of an RFID tag. For example, an MTG playing card could have its unique identifier stored on an RFID chip embedded in the playing card. For example, if one retrieves a unique identifier, say 5d8a7f95-ac4c-4113-8bdd-55336b86b98c, it can be discovered that this identifier corresponds to a card with a so-called multiverseid 193868 and a card type with the name “Lord of the Pit.” It is also possible to store only the card type identifier or multiverseid, but this prevents card-specific information, such as experience points or the card's owner, from being added on the server. The link between a unique physical card and its digital representation using a unique identifier is called a digital twin. If the card in question is found or identified as “Lord of the Pit,” it can be concluded that the card is likely authentic. While this solution is an improvement over cards without an embedded RFID chip, it has been found that the solution is inadequate because RFID tags can be so easily copied.

[0025] Figure 1 shows a schematic example of an embodiment of a playing card system 100 that addresses this problem. The system 100 includes a playing card authentication device 200 and an authentication server 300. The system may also include one or more playing cards. Figure 1 shows one playing card 110, but there may be more playing cards.

[0026] For example, in operation of system 100, playing card authentication device 200 may wirelessly interact with playing card 110. For example, playing card authentication device 200 may receive a cryptographic token derived from authentication information stored on playing card 110. Playing card authentication device 200 and playing card 110 are located near each other so that the two devices can communicate through a direct wireless connection. Playing card authentication device 200 can then authenticate playing card 110 with authentication server 300. For example, server 300 may verify the cryptographic token. The result of the authentication may be displayed as a success or failure signal on authentication device 200. As part of the authentication operation, playing card 110 may be modified; for example, a counter may be incremented and / or authentication data may be modified, e.g., overwritten.

[0027] The playing card 100 includes electronic memory 120, an antenna 130, and processing circuitry 140. For example, the memory 120, the antenna 130, and the circuitry 140 may be implemented as an RFID tag, e.g., an NFC tag. The antenna 130 is configured for wireless communication, e.g., RF communication, e.g., NFC communication. In embodiments, the wireless communication may be of another type, e.g., Bluetooth, ZigBee, Wi-Fi, UHF, etc., but NFC is currently preferred. The playing card may receive commands on the antenna 130, which may be executed by the circuitry 140. The circuitry 140 may be a simple circuit configured only for a specific function of the embodiment, or may be a general-purpose circuit that is programmed accordingly. NFC may be used for wireless communication between the chip in the card 110 and the device 200.

[0028] Playing cards 110 may be paper cards, laminated cards, plastic cards, etc., with circuitry embedded within them.

[0029] Memory 120 is wirelessly readable, for example, by playing card authentication device 200. For example, playing card authentication device 200 may, for example, send a read command to antenna 130. In an embodiment, memory 120 is also writable, for example, by sending a write command to antenna 130. However, writing to memory 120 is optional. For example, memory 120 may be read-only. For example, the contents of memory 120 may be set during the manufacture of playing card 110. For example, memory 120 may be write-once memory. Non-writable memory has the advantage that a counterfeiter cannot change the contents of the memory. However, as described below, some embodiments take advantage of using writable memory. Memory 120 includes at least authentication data 122 and preferably also counter 124. Authentication data 122 may be used in authentication operations to prove the authenticity of the card. For example, authentication data 122 may be a random number chosen randomly, e.g., during manufacturing or during a later operation, e.g., during an authentication operation. For example, a random number is a number that cannot be predicted. For example, authentication data 122 may include a cryptographic key, e.g., a symmetric key, e.g., the private key of a public / private key pair. A counter may be incremented whenever authentication data 122 is involved in an operation, e.g., whenever an authentication operation is performed and / or whenever authentication data is renewed. The initial value of the counter may be a default number, e.g., zero, that may be the same for all playing cards, e.g., all playing cards of this type; the initial value may be a random value. Memory 120 may store additional information such as a unique identifier or a card type, e.g., a multiverse ID for that card type.

[0030] The processing circuitry may be configured to receive digital commands over the antenna from the playing card authentication device 200. For example, the command may be an authentication command instructing the card to authenticate itself to the device 200. In response to receiving the command, the circuitry creates an authentication token. Creating the token involves reading authentication data from memory 120 and a counter from memory 120 and applying a cryptographic function to the authentication data and the counter. There are various ways in which this may be done, some examples of which are described below. After construction of the token, the authentication token is wirelessly transmitted to the authentication device 200, for example, through the antenna 130. After creation or transmission, for example, after a completed or successful transmission, the counter 124 in the memory 120 is incremented. For example, the counter may be incremented immediately after reading the authentication data or after creation of the token. For example, the counter may be incremented after receiving an acknowledgment from the device 200 that the token was successfully received.

[0031] Memory 120 may store additional information associated with playing card 110. For example, memory 120 may store a playing card identifier. The playing card identifier may be included in an authentication token or transmitted with the token. For example, the playing card identifier may be a unique number, such as a UUID. The playing card identifier may or may not be an input in calculating the authentication token.

[0032] The processing circuitry and memory may be integrated into an IC, e.g., an NFC IC. The IC may be embedded within a playing card. The IC may be configured to perform cryptographic operations. The IC may run general-purpose computer instructions, e.g., applications, but this is not required. For example, the IC may be hardwired to perform only a limited set of operations. In embodiments, the memory may be read wirelessly. However, in embodiments, the memory may not be read directly wirelessly but may only be accessed through the processing circuitry. This has the security advantage that if the contents of the memory cannot be obtained, the memory cannot be copied either. For example, the circuitry may be configured to read the memory, e.g., authentication data, but only to transmit the authentication data, e.g., in the form of an authentication token, after a cryptographic function has been applied to the authentication data.

[0033] The authentication device 200 may be configured to verify the authenticity of playing cards, and in particular the playing card 110. The playing card authentication device includes an antenna 220 configured for wireless communication with the playing card. For example, the antenna 220 and the antenna 130 may be configured for the same type of wireless communication, e.g., the same type of RF communication, e.g., the same type of near field communication (NFC).

[0034] In addition to antenna 220, authentication device 200 may also include a communication unit 210 configured to communicate over a computer network to playing card authentication server 300. For example, the communication unit may be configured to communicate over the Internet. Communication unit 210 may also be wireless, for example, configured for Wi-Fi, 3G, 5G, or the like. The wireless communication type of communication unit 210 may be different from the communication type used by antennas 220 and 130.

[0035] The authentication device 200 includes a processing circuit 230 and a memory 240. For example, the memory 240 may store computer instructions executable by the processing circuit 230. For example, the processing circuit 230 may be configured to wirelessly send a digital authentication command over an antenna to the playing card 110. For example, the playing card 110 may be configured to cooperate with the authentication device 200 and to transmit at least an authentication token in response. For example, the processing circuit 230 may be configured to receive an authentication token from the playing card 110 in response to the digital authentication command. The authentication device 200 may be configured to send the authentication token to an authentication server through a communication unit and to receive information regarding the authenticity of the playing card from the authentication server. For example, the authentication device 200 may receive from the server 300 whether the playing card 110 is authentic, e.g., genuine. The device 200 may also receive updated authentication data from the server 300, which will be transferred to the device 110.

[0036] Authentication device 200 may include a display 250 configured to show information of the authentication operation. For example, device 200 may be configured to display information about the type of playing card, such as received from playing cards 110 or from authentication server 300. Display 250 may also be used to display the results of the authentication operation. Before sending the token, authentication device 200 may add or modify information. For example, authentication device 200 may sign the token with a cryptographic key, such as a private key, to indicate to server 300 that authentication device 200 itself is an authentic device.

[0037] The authentication server 300 may be configured to verify the authenticity of playing cards, in particular playing cards 110. The playing card authentication server 300 may include a communication unit 320 configured to communicate over a computer network with the playing card authentication device 200. For example, the communication unit 320 may be configured to use the same computer network as the authentication device 200, e.g., the Internet.

[0038] The authentication server includes a memory 310. The memory 310 may be configured to store computer instructions for execution by the processing circuitry 330. However, the memory 310 may also be configured to store authentication data 312 and a counter 314. For example, the authentication data 312 and the counter 314 may be retrieved from a playing card database 340. The playing card database 340 may be part of the server 300 or may be external to the server 300. For example, the database 340 may be stored on an external server in digital communication with the server 300, for example in the cloud.

[0039] For example, the playing card database 340 may store the authentication data 312 and the counter 314 indexed with a playing card identifier, such as the playing card identifier of the playing card 110 .

[0040] In an embodiment, counter 314 is assumed to be equal to counter 124. After successful authentication of card 110, counter 314 is incremented so that counter 124 and counter 124 remain the same. Counter 314 and counter 124 may differ from each other only if there was a problem or if playing card 110 is not authentic.

[0041] Incrementing counter 124 in card 110 may occur upon command of server 300. In this case, one problem that may arise is that the incrementing of counter 124 fails for some reason, for example because the card is removed from the near field before the operation is completed. In that case, counter 314 may be greater than counter 124. To avoid counter 124 being lower than counter 314 in this scenario, card 110 may be configured to increment counter 124 before calculating the authentication token.

[0042] Accordingly, the counter on the card and the counter on the server may differ. To prevent this problem, a card may be accepted as authentic if counter 314 minus counter 124 is less than a threshold. For example, one may have the formula: counter 124 + #problems = counter 314, such that the card may be accepted if the number of problems, #problems = counter 314 - counter 124, is less than a threshold, e.g., less than 10, less than 100, etc. The threshold may be determined empirically as a compromise between security and user-friendliness.

[0043] On the other hand, for example, in an embodiment, the counter may be incremented whenever authentication data 122 is involved in an operation, e.g., whenever an authentication operation is performed and / or whenever authentication data is updated, regardless of the fact that the resulting token is verified on the authentication device or authentication server. This procedure has the advantage that it reduces communication between the playing card and the authentication device; for example, it is not necessary to give the playing card an additional command to increment its counter, e.g., after waiting for the server's acknowledgment. Reducing communication also reduces the chance of corruption. It is still possible that the counter on the card and the counter on the server differ; for example, if the authentication device fails to forward the token for some reason, the counter may be incremented on the playing card but not on the server. In this situation, the counter on the card may be higher than the counter on the server. To address this issue, the card may be accepted as authentic if counter 124 is higher than counter 314, e.g., if counter 124 minus counter 314 is below a further threshold. Both options can be supported simultaneously. The two thresholds do not need to be the same. If the counters are different, and the token is accepted, the counter on the server can be adjusted so that it is equal to the counter on the card.

[0044] In an embodiment, authentication data 124 and authentication data 314 are equal, e.g., equal numbers, equal cryptographic keys, etc. In an embodiment, authentication data 124 and authentication data 314 are corresponding members of a cryptographic key pair. For example, authentication data 124 may be a signature key and authentication data 314 may be a corresponding verification key. The signature key and verification key may form a cryptographic asymmetric key pair, e.g., an RSA key pair, an ECDSA key pair, etc.

[0045] The authentication server 300, e.g., the processor circuit 330, may be configured to receive an authentication token from the playing card authentication device 200. The authentication token may be created by the playing card 110 from the authentication data 122 and, optionally, the counter 124, etc. The authentication token is verified using the authentication data 312 and the counter 314. If the verification is successful, a success signal may be sent to the authentication device 200. The success signal may indicate to the playing card authentication device 200 the authenticity of the playing card 110. After successful authentication of a playing card, a counter for that card, e.g., the counter 314, and optionally also a counter in a database, is incremented. Not incrementing the counter in the event of a failed authentication prevents an attacker from being able to skew the counter. In an embodiment, the counter may be restored from the authentication token, although this is not necessary.

[0046] To further improve security, the authentication device 200 and the authentication server 300 may authenticate each other. For example, in an embodiment, there may be many authentication devices 200 in the system. For example, the authentication device 200 may be implemented as a smartphone with an appropriate app installed. As such, there is a risk that an attacker may use a fake authentication device. This risk may be reduced by authenticating the authentication device 200 to the server. For example, in an embodiment, the playing card authentication device 200 may be configured to authenticate the playing card authentication server 300, and / or the playing card authentication server 300 may be configured to authenticate the playing card authentication device 200. For example, the device 200 and the server 300 may be configured to perform an SSL handshake.

[0047] Below, some examples of authentication tokens, their creation and authentication are given.

[0048] In an embodiment, the authentication data 122 and 312 are cryptographic keys. For example, the authentication data 122 stored in the playing card may be the private key (Priv) of a public / private key pair, and the authentication data 312 stored in the playing card authentication server may be the public key (Pub) of the public / private key pair. For example, the authentication data 122 stored in the playing card may be a symmetric key (K), and the authentication data 312 stored in the playing card authentication server may be the same key (K).

[0049] The authentication token may be computed by the playing card 110, e.g., the circuit 140, by using the key in a keyed cryptographic operation. For example, the keyed cryptographic operation may be a signature operation, an encryption operation, or a keyed hash operation. For example, the token may be computed by signing a counter. For example, the token may be computed by signing a challenge value received by the playing card 110 from the device 200, e.g., with an authentication command. The challenge value may be a nonce, e.g., a random number. The signature may be performed with a private key and a symmetric key; in the latter case, the operation is sometimes referred to as computing a message authentication code.

[0050] The authentication server 300 may verify that the token was created by applying a keyed cryptographic function to the counter and / or challenge, for example, by recreating the token from the authentication data 312 if the authentication data 312 and the authentication data 122 are equal. For example, the server 300 may apply the same keyed cryptographic function, such as a signature, encryption, or keyed hash operation, to the counter 312 and / or the challenge and verify that the server 300 calculated the same token as received from the playing card 110 by the device 200. Alternatively, if the authentication data 312 and the authentication data 122 are part of a cryptographic key pair, the server may perform the corresponding keyed function using the authentication data 312 as a key. For example, a signature verification to verify whether the token is a valid signature of the counter 312, or a decryption operation using the authentication data 312 as a key and verifying that the result is the counter 312.

[0051] In an embodiment, the device 200 first contacts the server 300 to request a challenge. The server 300 then generates a challenge, e.g., a random number, and sends it to the device 200. The device 200 then sends an authentication command along with the challenge. The playing card 110 then applies a cryptographic function to the challenge, or to the challenge and the counter 124. The server 300 can then verify that the token corresponds to the counter 314 and to the challenge.

[0052] Verifying counter 124 is easiest if counter 124 and counter 314 need only be equal. In practice, differences can be accounted for by verifying the token against counter 314 minus a small decrement, e.g., minus 1, minus 2, etc., up to a threshold. Additionally, or alternatively, increments can be used as needed. This accounts for the fact that authentication may succeed at device 200 and server 300, but incrementing the counter at the card may fail, or if incrementing the counter at the card succeeds, authentication fails at device 200 or server 300. This approach may result in authentication being performed multiple times. In an embodiment, the cryptographic function is a keyed bijective function; for example, encryption or signature with message recovery. This has the advantage that counter 124 can be recovered from the token by applying a keyed inverse function. In this case, counter 124 and counter 314 can be compared unambiguously. This allows more flexibility in allowing authentication to proceed even if counter 124 and counter 314 are not exactly equal. Furthermore, multiple verifications are not required for different values ​​of the counter to cover the eventuality of a difference between the two counters.

[0053] In an embodiment, the token is calculated, for example, as described above, and verified by the server 300, which in turn generates and sends new authentication data 122 and updates authentication data 312. The device 200 receives the new authentication data and sends it to the playing card 110 for writing into memory 120. For example, a new symmetric key or a new private key may be written into memory 120. The new authentication data is also updated in the server 300, e.g., in authentication data 314 and / or database 340. This has the advantage that unauthorized copies of the playing card 110 will have old authentication data. For example, whenever a card is authenticated, the authentication data of that card may be updated, with the effect that all previous copies of the playing card are invalidated. If an attempt is made to authenticate an unauthorized copy, the authentication data of the unauthorized copy may not correspond to the authentication data stored in the server 300, and thus authentication will fail.

[0054] In an embodiment, a random string can be used for the authentication data without applying a cryptographic function so that the token is equal to the authentication data. If the authentication data is constantly updated, this can be a particularly low-cost solution for authenticating playing cards. To verify the token, the server 300 compares the token with stored authentication data.

[0055] An advantage of updating the authentication data is that duplicates of the card are automatically invalidated. If a user makes an unauthorized copy of the card, the first card verified by server 300 is the valid card, at least as far as the server can determine. This is an incentive to not allow one's card to be copied, because if a copy is verified first, the original will be automatically invalidated.

[0056] For example, the playing card authentication server may be configured to generate new authentication data and, if verification is successful, send the new authentication data to the playing card authentication device. The new authentication data may be a new key or a new random string. The playing card authentication device may be configured to receive the new authentication data over the communication unit and send the new authentication data to the playing card over the antenna. The playing card may be configured to receive the new authentication data over the antenna and write the new authentication data to its memory.

[0057] In an embodiment, memory 120 may store a key. Processing circuit 140 may be configured to encrypt a counter using the key. The token may include the encrypted counter. Processing circuit 140 may receive a challenge from authentication device 200. The challenge may also be encrypted. Instead of encryption, a signature may be calculated and included in the token. The signature may be an asymmetric or symmetric signature, e.g., a MAC, a keyed hash, etc. The key may be a private key.

[0058] In an embodiment, memory 120 stores a private key and a corresponding public key. The public key may be retrieved from the chip by device 200. The counter may also be retrieved. The token may include a signature for the counter and / or challenge, or may be a signature of the counter and / or challenge. Authentication device 200 may use the public key to verify the signature. For example, the signature may be verified against the counter and / or challenge. The public key may be protected using conventional means, for example, by a signature certificate, such as an X.509 certificate. Interestingly, this allows the token to be verified locally, for example, using a key retrieved from the playing card, and non-locally at server 300, for example, using a public key stored at server 300. In an embodiment, the authentication data on playing card 110 is updated only when the token is verified through server 300, but not when the token is verified locally. Note that updating the authentication data is optional.

[0059] In an embodiment, before authenticating playing card 110, authentication device 200 requests a challenge from server 300. Server 300 generates the challenge and sends it to authentication device 200. Authentication device 200 then requests a token from playing card 110. Playing card 110 may process the challenge, e.g., with a counter, with a key, encrypt the challenge, or sign the challenge. The token may also include an identifier for playing card 110. Authentication device 200 may then forward the token to server 300 for verification.

[0060] The system may be used to store one or more game parameters. For example, the game parameters may be stored on the card 110 and / or on the server 300. When the game parameters are needed, for example, in game play, the parameters may be retrieved from the card 110 and / or on the server 300, for example, by an authentication device, such as a mobile phone.

[0061] For example, memory 120 may contain game parameters that can enhance game play in various ways. For example, game parameters may be modified when the authenticity of a playing card is verified. For example, modified game parameters may be provided if an authentication token is submitted with a correctly verifying playing card. For example, modified game parameters may be provided to and stored on a playing card. For example, modified game parameters may be shown on a display of an authentication device. Game parameters may alternatively or additionally be stored on server 300.

[0062] For example, the game parameters may represent so-called experience points. For example, cards may earn experience points, which may be stored, for example, in a database on server 300 and / or within card 110. Experience points may be earned by playing with cards in tournaments. Cards may become better over time by earning experience points. This may motivate players to participate in tournaments by increasing the level of their cards. Furthermore, the monetary value of the cards comes from playing the game, not from using the cards as a proxy stock market.

[0063] Figure 2 schematically illustrates an example embodiment of a playing card system 400. Figure 2 shows a playing card 410. The playing card 410 has printed information 411 visible thereon. The printed information 411 may include a picture 416 and text 414. For example, the picture may indicate a game character, and the text may indicate a game parameter, such as an ability, or the like.

[0064] The playing card 410 may include a chip 412 and an antenna 413. The chip and antenna may be configured as described herein. For example, the antenna 413 may be configured for wireless communication with, for example, an authentication device. The chip 412 may include: - Receives digital commands wirelessly over an antenna from an electronic playing card authentication device; - creating an authentication token in response to receiving an authentication command, the creating including reading authentication data and a counter from a memory and applying a cryptographic function to the authentication data and the counter; - Wirelessly transmits an authentication token to the device through an antenna; - Increment a counter stored in memory It can be configured as follows.

[0065] 2 further illustrates a mobile phone 450. The mobile phone 450 may be configured as an authentication device. The mobile phone 450 may include a communication unit configured to communicate over a computer network with a playing card authentication server and an antenna configured for wireless communication with a playing card, such as playing card 410.

[0066] The mobile phone 450, e.g., an app installed on the mobile phone, may be configured to communicate with the chip 412 and receive information. The information may include an ID that identifies the card 410. The mobile phone 450 may obtain information about this playing card and / or this type of playing card. For example, the phone 450 may obtain the information from the chip 412 or from a server, e.g., the server 300. For example, the playing card authentication server may be configured to send information about the playing card for display on the playing card authentication device. For example, the information may be requested from the server 300 using the ID. The mobile phone 450 may be configured to display the information. For example, in this case, the phone 450 displays a picture, e.g., the picture 416, text, e.g., the text 414, and the additional text 415. For example, the additional text 415 may include additional game parameters. The phone 450 may - Wirelessly transmits digital authentication commands over the antenna to the playing card, - receiving an authentication token from the playing card in response to the digital authentication command; - sending the authentication token to the authentication server through the communication unit; - receiving information about the authenticity of the playing cards from the authentication server; It can be configured as follows.

[0067] When a playing card such as card 410 or 110 is first used, the card may be claimed by a user. For example, an authentication device, such as 200 or 450, may include a user identifier that identifies the user to further services of the playing card authentication server. The playing card authentication device may be configured to send the user identifier along with an authentication token. The playing card authentication server is configured to associate the user identifier with the playing card identifier in its memory, and the playing card authentication server is configured to provide access to the playing card in the further services. For example, after manufacture of card 110 or 410, the card's ID may be registered with the server. The card may initially be registered as unclaimed. When a token for the card is first received and validated, the user ID received with the token may be stored by the server as the owner, or claimant, of the playing card. For example, a playing card may be scanned by a consumer after opening a pack, for example, using their smartphone, to claim ownership. An initial seller, such as a manufacturer or retailer, may be the card's original owner. In this case, the seller needs to transfer ownership of the card to the buyer. This can be linked to a cash register or an online e-commerce store. The store can be the current owner; upon payment, ownership will be transferred or the owner lock status will be released so that someone, e.g., the buyer, can claim ownership.

[0068] When a user acquires a card from a previous owner, they can submit a token along with a new user ID to register a new owner or claimant of the card. This allows users to manage their card collection online, for example, through a website maintained by server 300. It also allows the system to track theft, mark cards as lost, or set a transfer lock on cards. For example, a transfer lock can be implemented by storing, for example, a blacklist of card IDs that cannot be transferred on server 300. For example, if a card is stolen, it can be reported as such to an online collection, for example, through a website. If a claim on the card is received, a signal can be generated so that appropriate follow-up action can be taken, for example, asking the new owner to legally identify themselves. Depending on the configuration, there can be different requirements for transferring digital ownership of a card. One example is that physical access to the card leads to the transfer of ownership, and an authentication token can be used to validate the action. Another example is that only digital ownership is required to transfer ownership. A final example is that both physical and digital ownership is required to transfer ownership.

[0069] Interestingly, this allows a user to link his physical card collection, also called a "digital twin," to his online card collection. For example, scanning an NFC card and transferring ownership adds the card to the online collection. This may enable playing games both online and offline using proprietary playing cards. For example, server 300 may be configured for online gameplay between two or more players using their online card collection. Offline, the same or different users may use their physical cards to play the same or different games. Interestingly, online gameplay may allow game parameters to be modified. When a playing card is verified, modified game parameters may be downloaded onto the card. An authentication device, such as a mobile phone, may be used to write and / or read game parameters. This enables offline play using modified game parameters that were modified through online play. For example, cards may level up online, which may provide benefits to users offline when using physical, e.g., paper, cards.

[0070] For example, a playing card authentication server may maintain collections of cards for multiple users, e.g., players, in a database that stores cards that have been authenticated for the users. The server may provide additional services in various forms, such as providing a digital gameplay interface configured to receive gameplay instructions that reference the user's cards. For example, the instructions may be gameplay moves received from the user or from other users. The instructions may reference the user's cards for some game-related purpose. For example, before allowing an instruction to be completed to perform some game-related purpose, the playing card authentication server may verify, for example, by referencing a database, that the referenced cards are authenticated for the user. For example, if the server is also configured as a game server, the server may operate this interface for its own purposes; however, the server may also or instead perform this service for third-party game servers. This feature allows online games to mirror games that may be played in real life, for example, with the same cards.

[0071] A potential problem with wirelessly updating playing cards, especially when the playing card does not have its own power source, is corruption of the playing card date. This problem can be addressed by a card memory including at least two areas for storing authentication data. The card's processor is configured to write authentication data to memory in an area different from the area that stores authentication data used to generate the authentication token. This ensures that the authentication data used to validly create the token, and therefore uncorrupted, remains valid and on the card. The next time a token is needed, the updated data is used, overwriting the old authentication data. For example, the area could include a counter; initially, the highest counter is used to generate the token; only if the data is corrupted or the token is found to be invalid is a token created using older data.

[0072] Another potential problem is that someone could attempt to claim a card without purchasing it, e.g., while the card is in the store, e.g., to claim the card as the original owner. They could do this, for example, to aid in online gameplay, or perhaps, as a nuisance, to add the card to their online collection without having to purchase it. There are various ways in which this problem could be addressed.

[0073] For example, the playing cards may be wrapped in foil, e.g., as part of a pack, which may be a metal foil or may be lined with a metal material to attenuate wireless signals to and from the playing card antenna.

[0074] For example, a playing card pack may include, in addition to one or more playing cards, a further card that includes an antenna configured for wireless communication and processing circuitry configured to distort the wireless signal of the one or more playing cards.

[0075] For example, a playing card may have its owner assigned to the retailer selling the card. At the time of purchase, the retailer may need to unassign the card's owner so that the card's buyer can claim the card, since the card is not protected by any ownership rights, or the retailer may need to digitally transfer card ownership to the card's buyer. The buyer would communicate the buyer's player ID to the retailer, for example, by typing a code, scanning a QR code, or wirelessly transferring using 3G, WiFi, or NFC. The code is then used to send a request to server 300, which would update the card's owner.

[0076] Alternatively, a unique code printed on the inside of the pack or on a card contained within the pack may be used to establish the cardholder.

[0077] FIG. 3a schematically illustrates an example embodiment of a blockchain 500. Shown are two blocks of the blockchain: block 510 and block 520. A block includes one or more transactions. Shown are transactions 511, 512, 521, and 522 within blocks 510 and 520, respectively. The blocks also include consensus proofs 519 and 529, respectively. Consensus proofs are computed by a blockchain device and may be, for example, proof-of-work, proof-of-stake, or the like. A transaction may represent a claim and / or transfer of playing cards. A transaction may represent an authentication of playing cards.

[0078] FIG. 3b schematically illustrates an example embodiment of a blockchain network 530. The blockchain network 530 includes blockchain devices, shown are blockchain devices 531, 532, and 533. For example, the blockchain network 530 may be a peer-to-peer network over which blockchain blocks, transactions, etc. are communicated. For example, an authentication device, such as device 200, 450, etc., or a server, may generate a blockchain transaction including a playing card identifier and submit the blockchain transaction to the blockchain network so that the transaction can be processed by a blockchain management device for inclusion in a block on the blockchain. The transaction may include an authentication token. Blockchain devices are sometimes referred to as miners.

[0079] In embodiments, the card's public key may be stored in the blockchain, while the private key is uploaded to the chip. This may be done when the card is manufactured, when the card is first claimed, etc. The blockchain may replace database 340.

[0080] Storing cards or card transactions on the blockchain prevents server-side hacks. For example, transaction lineage can be checked for transactions. Furthermore, transferring a card twice becomes much more difficult because who the card owner is can be verified on the blockchain. The costs of hosting blockchain devices can ultimately be covered by players. For example, blockchain miners can be rewarded with points that can be exchanged for mining foils that cannot be obtained anywhere else.

[0081] In embodiments of the card system or method, one or more of the following may occur: 1. Create a print command. a. Create a new key pair, e.g., public key, private key pair. Create a Card ID. The Card ID can be a hash of the public key. Sign the new Card ID with the card authority's private key. Instead of a key pair, a symmetric key can be used. For example, the private key, Card ID can be stored on the card. The public key can also be stored on the card to allow local verification. The public key and Card ID can be stored in a database. b. The card is printed with an embedded NFC chip. c. The public key may be stored in a blockchain or a database, etc. For example, each unique key can be stored in a database enriched with card data. 2. The print command and key are sent to the printer 3. Upload the private key to a chip embedded in the physical card, e.g., an NFC chip. The finished card may include an NFC chip with a unique private key stored on the card and a corresponding public key stored on a database. 4. Packaging, distributing, and / or selling cards to consumers 5. Claim an unclaimed card, e.g., send a command to the card to obtain a digital signature, e.g., Sig=sign(secret key, message). The message may include a counter and / or a challenge. 6. Verify the digital signature using the corresponding blockchain. The public key can be obtained locally from the card, from the server, and from the blockchain. verify(publickey, message, sig) to verify authenticity. If successful, the card can be claimed. Verification can be done on the server or on the authentication device. 7. Send a success response to the app. The transaction may be stored in the blockchain. New private and public keys may be generated and uploaded (this is optional). For example, the existing private key on the chip may be overwritten by the new private key. Transferring the card may follow the same procedure.

[0082] Typically, the playing cards, authentication devices, and servers each include a microprocessor that executes appropriate software stored on the device; for example, the software may be downloaded and / or stored in corresponding memory, e.g., volatile memory such as RAM, or non-volatile memory such as Flash. Alternatively, the devices, and particularly the playing cards, may be implemented in whole or in part as so-called application-specific integrated circuits (ASICs), e.g., integrated circuits (ICs) customized for the particular use of the devices. For example, the circuits may be implemented in CMOS using hardware description languages ​​such as Verilog, VHDL, etc.

[0083] In embodiments, the playing cards, authentication device, and / or server may include one or more processing circuits to implement their functionality, which may be processor circuits and memory circuits, where the processor circuit executes instructions electronically represented in the memory circuit.

[0084] The processor circuitry may be implemented in a distributed manner, for example, as multiple sub-processor circuits. The storage device may be distributed over multiple distributed sub-storage devices. Some or all of the memory may be electronic memory, magnetic memory, etc. For example, the storage device may have volatile and non-volatile portions. A portion of the storage device may be read-only. The circuitry may also be an FPGA, an ASIC, or the like.

[0085] Figure 4 illustrates generally an example embodiment of a playing card authentication method 600. Method 600 comprises: - wirelessly transmitting (610) a digital command over the antenna to a playing card authentication device to cause the playing card to create an authentication token, the playing card including an electronic memory (120) storing authentication data (122) and a counter (124), and generating the authentication token includes applying a cryptographic function to the authentication data and the counter; - wirelessly receiving an authentication token from the device via the antenna (620); - the authentication token is verified using the counter and authentication data stored in the memory of the playing card authentication server (630); Includes:

[0086] Many different ways of performing the method are possible, as will be apparent to those skilled in the art. For example, while the order of steps may be performed in the order shown, the order of steps may be changed or some steps may be performed in parallel. Furthermore, other method steps may be inserted between steps. The inserted steps may represent elaborations of the method as described herein or may be unrelated to the method.

[0087] Method embodiments may be implemented using software including instructions for causing a processor system to perform method 600. The software may only include steps used by a particular sub-entity of the system. The software may be stored in a suitable storage medium such as a hard disk, floppy, memory, optical disk, etc. The software may be transmitted as a wired or wireless signal or using a data network, e.g., the Internet. The software may be made available for download and / or for remote use on a server. Method embodiments may be implemented using a bitstream configured to configure programmable logic, e.g., a field programmable gate array (FPGA), to perform the method.

[0088] It will be understood that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for practicing the invention. The program may be in the form of object code, such as source code, object code, code intermediate source, and partially compiled form, or any other form suitable for use in implementing the method embodiments. An embodiment relating to a computer program product comprises computer-executable instructions corresponding to each of the processing steps of at least one of the methods discussed. These instructions may be subdivided into subroutines and / or stored in one or more files, which may be statically or dynamically linked. Another embodiment relating to a computer program product comprises computer-executable instructions corresponding to each of the means of at least one of the systems and / or products discussed.

[0089] 5a shows a computer-readable medium 1000 having a writable portion 1010 including a computer program 1020, the computer program 1020 including instructions for implementing a playing card, authentication device, and / or server on a processor system according to an embodiment. The computer program 1020 may be embodied on the computer-readable medium 1000 as a physical marking or by means of magnetization on the computer-readable medium 1000. However, any other suitable embodiment is also conceivable. Furthermore, while the computer-readable medium 1000 is shown here as an optical disk, it will be understood that the computer-readable medium 1000 may be any suitable computer-readable medium, such as a hard disk, solid-state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing the processor system to perform as a playing card, authentication device, and / or server.

[0090] FIG. 5b shows a schematic representation of a processor system 1140 according to an embodiment of a playing card, authentication device, and / or server. The processor system includes one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is shown schematically in FIG. 5b. The circuit 1110 includes a processing unit 1120, e.g., a CPU, for executing a method according to an embodiment and / or running computer program components to realize a module or unit thereof. The circuit 1110 includes a memory 1122 for storing programming code, data, etc. A portion of the memory 1122 may be read-only. The circuit 1110 may include a communication element 1126, e.g., an antenna, a connector, or both, and the like. The circuit 1110 may include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, memory 1122, dedicated ICs 1124, and communication elements 1126 may be connected to each other via an interconnect 1130, such as a bus. The processor system 1110 may be configured for contact and / or contactless communication, using antennas and / or connectors, respectively.

[0091] For example, in an embodiment, the processor system 1140, e.g., a playing card, authentication device, or authentication server, may include a processor circuit and a memory circuit, where the processor is configured to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, an ARM Cortex-R8, or the like. In an embodiment, the processor circuit may be an ARM Cortex M0. The memory circuit may be a ROM circuit or a non-volatile memory, e.g., flash memory. The memory circuit may be a volatile memory, e.g., SRAM memory. In the latter case, the device may include a non-volatile software interface, e.g., a hard drive, a network interface, or the like, configured to provide the software.

[0092] Figure 6 illustrates a schematic example of an embodiment of a playing card system 600. Figure 6 further visualizes item staking, e.g., staking ownership of an item.

[0093] System 600 includes a number of playing cards; shown is playing card 610. Playing card 610 may have various information printed on it; shown is the card name "Card Name 1" and a picture. Playing card 610 includes an electronic tag 612. Tag 612 may store a playing card identifier, such as a number or the like. In an alternative embodiment, a computer-readable identifier, such as a QR code or the like, may be used. However, QR codes can be easily reused, which is why the latter is not preferred.

[0094] System 600 includes a mobile scanning device 620, e.g., a playing card authentication device. System 600 includes an authentication platform 630, e.g., a playing card authentication server. Mobile scanning device 620 is configured to read tag 612 and to communicate with authentication platform 630. For example, authentication platform 630 may be configured to store information about a playing card, e.g., playing card 610. For example, authentication platform 630 may store item and identifier records. Authentication platform 630 may also store ownership information, e.g., an identifier of the user who currently owns a particular playing card, e.g., who most recently claimed the card.

[0095] 6 shows that the mobile scanning device 620 and authentication platform 630 are configured for two protocols: a protocol for verifying the authenticity of the playing card 610, and a protocol for asserting ownership of the playing card 610.

[0096] 7 illustrates in further detail an example embodiment of a playing card system 600, and in particular an example embodiment of a protocol for verifying the authenticity of a playing card 610. In response to a request from a mobile scanning device 620 to verify the authenticity of a playing card 610, the authentication platform 630 may generate a web page that can be downloaded from the authentication platform 630 by requesting a particular computer network address, e.g., a web address, e.g., a URL. For example, in response to the request, a proof URL may be generated. When the URL is visited, e.g., using a web browser, the status of the card may be obtained.

[0097] Three possible responses are shown in Figure 7. For example, according to web page 641, the page includes information that the card is authentic, e.g., that the card is accounted for in the database of server 630. Additional information could be when the card was activated.

[0098] Optionally, a proof link, such as a URL, to web page 641 may be valid for a limited amount of time. Page 641 indicates when authenticity was last checked, but this may be overlooked by some consumers, thus creating an opportunity for fraudulent transactions. The proof link with this option is only valid for a limited amount of time. For example, web page 642 indicates that the proof link has expired. For example, according to web page 643, the link may be invalid. For example, this page may be shown when the card cannot be authenticated.

[0099] Thus, in this embodiment, a proof link may be generated, for example, a possibly temporary link, e.g., a URL, based on a scan of the playing card, which may prove not only authenticity but also physical access.

[0100] For example, in an embodiment, a user may scan his card with his mobile phone and receive a proof link in return. The proof link, e.g., a URL, may then be forwarded to others, e.g., through a chat app, marketplace, or email, or the like. For example, the link may be included when mentioning the card online, such as on a web page; for example, the link may be included when the card is listed for sale on eBay or the like.

[0101] Other users may then verify for themselves the authenticity of information, e.g., cards, which may be used, for example, during negotiation of a sale or during game play, or the like.

[0102] In an embodiment, the system is configured for a method for remotely verifying physical possession of a physical item, such as a playing card. For example, the card is scanned to obtain a unique code from an authentication server. The code may be verified on the server. The unique code may include a computer network address, such as a URL, although this is not required. The unique code or URL may be sent to another party, such as a counterparty, another device, or an online marketplace. This token may be checked to prove whether and, optionally, when someone physically transported the product.

[0103] The marketplace is based on ownership registration of authenticated physical items, such as playing cards. The marketplace may be realized as an entity that can send messages to and from entities over a computer network, such as a server or cloud instance, etc. For example, the marketplace may include a computer. For example, the marketplace may include a web server. The marketplace may be integrated within, e.g., included in, an authentication server.

[0104] In an embodiment, an online system is provided in which people register items they possess, which can be verified using authentication methods. In the marketplace, owners can be considered potential sellers because they have items they could sell if the price or circumstances are favorable. For example, each time an owner scans or verifies an item, a field can be updated with the last time someone interacted with the item, at which time the current owner interacted with the item.

[0105] A buyer looking to buy a certain type of product can query a server that holds all registered items. The buyer can place a price range and distance on the marketplace, which will then locate potential sellers. Results from the query can be scored based on one or more of the following: - Proximity / distance of buyers and potential sellers, - The time since the last time a potential seller interacted with the item, - The time from the first time a potential seller interacts with the item, - the time since the potential seller first became the registered owner of the item; - the number of times potential sellers responded to offers on the item; - the number of times potential sellers have accepted offers on the item; - the percentage of offers accepted by potential sellers; - The last time the potential seller was active on the marketplace, for example by using the app or website; - the price paid by the potential seller for the item, if known by the system; - The item's historical retail price, if known by the system; - the current retail price of the item, if known by the system, - the current market price of the item, if known by the system; - The selling price the potential seller has set for the item, if set.

[0106] The marketplace may add potential sellers to a list. New potential sellers may be added to this list periodically as long as the query remains active. Buyers can manually indicate interest in a particular seller from those presented in the potential seller list. Sellers may then get notifications from the marketplace, e.g., push notifications, emails, etc., that someone is interested in buying an item they own. If the seller states that he / she is also interested in selling, the buyer and seller: - Manually initiate negotiation to discuss the item's condition and terms of the deal, or: - Accept trades and receive delivery / shipping and payment information You can do either of the following.

[0107] The marketplace may be configured to automatically seek out the highest-scored potential sellers in parallel and notify them of interest. For example, there may be a maximum number of simultaneous outstanding offers configured for parallelism. The list of outstanding offers may be periodically checked for expired offers. If the maximum parallelism has not yet been reached, the marketplace will add the next highest-scored offer to the current list.

[0108] When accepting the trade, the system may update the owner field of the item, with the buyer being considered the registered owner of the item from that point on.

[0109] The marketplace can be configured with a recommender system for digital twins, collectibles, and the like. For example, the marketplace can be configured with a computer algorithm that analyzes user-registered digital twins from owners of physical items from a database, or a subset of the digital twins and owners, to detect latent or non-latent class membership of objects or latent classes, such as synergistic cards that are frequently associated with each other, in order to recommend manifest sets of objects, such as decklists, or other objects, such as playing cards that must be acquired to complete a game expansion set. An example of a latent class would be "Brainstorm" and "Fetchlands," which are not directly related to each other, but the owner of "Fetchlands" would benefit from obtaining "Brainstorm," a well-known synergy in the card game Magic: The Gathering. The recommender system quantifies other non-obvious synergies. The detected item associations are mapped to related items in the database and recommended to the user if he / she already owns part of the set. The greater the ownership share of the set, the higher the card will be ranked in the order of recommendation.

[0110] Figure 8a illustrates a schematic example of a data model for an embodiment of the marketplace application. Figure 8b illustrates a schematic example of a process diagram for an embodiment of the marketplace application. Interestingly, since items have owners, the marketplace application has information indicating who owns a particular card. The marketplace allows prospective buyers of a card to ask the owner if they would like to sell the card.

[0111] For example, scoring may be based on the information shown in FIG. 8a, as well as location, e.g., GPS location, e.g., distance, and user ratings as a buyer and / or seller. A list of available items with their scores may be saved. Potential sellers may be notified in parallel, e.g., up to a maximum of five at a time. These offerings may be accepted, rejected, negotiations may be initiated, they may expire, etc. The list of active orders may be updated each time the list does not reach maximum parallelism.

[0112] FIG. 8b illustrates an example process for searching, matching, and executing trades in an embodiment of a marketplace application. In an embodiment, the marketplace application maintains an active query queue. For example, a buyer may initiate a query on the marketplace. The query may be added to a list of active queries in the marketplace, e.g., the active query queue. The active query queue may be executed periodically and / or in response to adding a query to the queue and / or using a job queue runner. Active queries may be executed against the system using parameters that may be set by the user, e.g., based on card, distance, price, etc. For example, each result may receive a score and may be added as an offer linked to the query.

[0113] The offer with the highest score that is added to the query may be activated and presented to the owner of the item associated with the offer. This person or entity is called a potential seller. For example, this may be done in advance by different processes, which may be performed periodically, as a response to adding an offer to the query, as a response to declining another offer, and / or using a job queue runner, etc. In embodiments, the maximum number of simultaneously active offers may be limited, for example, to reduce the number of fulfilled / accepted orders that are still presented to the potential seller. If a potential seller receives too many offers that he cannot accept due to the fact that the offer has already been accepted by someone else, the potential seller will likely find the notifications less valuable and may even not respond to the offers at all, due to disappointment.

[0114] When an offer is activated, a notification is sent to the potential seller. This notification can be in the form of a push notification, email, SMS, or other format. The potential seller can use an app or web application to open an offer in the marketplace. The potential seller may have various options for responding to this offer. For example, his options may include one or more of the following:

[0115] - The potential seller can accept the offer. Ownership of the item can be transferred immediately or when payment is confirmed, depending on the terms used for the transaction. Payment confirmation can occur immediately if the buyer has prepaid for the item, when the buyer's payment details are known, or when the buyer has sufficient funds in the account.

[0116] - A potential seller may decline an offer and set conditions as to when he would be interested in selling. This could be a minimum price, distance, or not for sale at all. This information would then be used in future queries.

[0117] - Potential sellers can open negotiations, which will not result in a permanent outcome but will allow both parties to establish terms and conditions and then either accept or reject the offer.

[0118] If a potential seller does not respond within a set amount of time, the offer may be marked as "expired." The rate or number of expired offers may be used for better matching in the future. If another potential seller accepts an offer for a query, all other offers for that query may be marked as "taken." This status does not penalize the potential seller in the matching and scoring algorithms.

[0119] If a buyer decides to cancel his query, all open offers will be marked as "canceled." This status can penalize the buyer in the matching and scoring algorithm, rather than penalizing potential sellers. An example could be to limit the number of simultaneous open offers for a query.

[0120] Figure 9a shows a schematic example of an embodiment of a playing card, for example, a tag may be embedded within the card.

[0121] The techniques described herein for playing cards can also be applied to other physical objects. Figure 9b shows a schematic example of a card binder embodiment. For example, tags similar to those used in playing cards can be embedded in a cover, such as the front cover or inner cover, allowing for verification or transfer of the card binder. The same techniques can be used to scan folders. Figure 10 shows a schematic example of a shoe, in this case a sneaker, embodiment with a tag embedded therein. All of the embodiments discussed for playing cards can be modified for sneakers or binders.

[0122] It should be noted that the above-described embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments.

[0123] In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those explicitly stated in a claim. The article "a" or "an" before an element does not exclude the presence of a plurality of such elements. When preceding a list of elements, phrases such as "at least one of" denote the selection of all or any subset of the elements from the list. For example, the phrase "at least one of A, B, and C" should be understood to include A only, B only, C only, both A and B, both A and C, both B and C, or all of A, B, and C. The invention can be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In a device claim listing several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0124] In the claims, references in parentheses refer to reference signs in the drawings of exemplary embodiments or to mathematical formulas of embodiments, thus increasing the clarity of the claims. These references shall not be construed as limiting the claims.

Claims

1. A playing card system (100) configured to authenticate playing cards for playing a card game, comprising: playing cards (110), a playing card authentication device (200), and a playing card authentication server (300); A: The playing card (110) is an electronic memory (120) storing authentication data (122) and a counter (124); an antenna (130) configured for wireless communication; a processing circuit (140), - wirelessly receiving digital commands over an antenna from an electronic playing card authentication device; - creating an authentication token in response to receiving an authentication command, the creating including reading authentication data and a counter from memory and applying a cryptographic function to the authentication data and the counter; - Wirelessly transmits an authentication token to the device through an antenna; - Increment a counter stored in memory A processing circuit (140) configured to Including, B: A playing card authentication device (200) is configured to verify the authenticity of a playing card, the playing card authentication device comprising: a communication unit (210) adapted to communicate over a computer network with a playing card authentication server; an antenna (220) configured for wireless communication with the playing cards; a processing circuit (230), - Wirelessly transmits digital authentication commands over the antenna to the playing card, receiving an authentication token from the playing card in response to the digital authentication command; - sending the authentication token to the authentication server through the communication unit; - receiving information about the authenticity of the playing cards from the authentication server; A processing circuit (230) configured to Including, C: A playing card authentication server (300) is configured to verify the authenticity of playing cards, the playing card authentication server comprising: an electronic memory (310) for storing authentication data and counters; a communication unit (320) adapted to communicate over a computer network with a playing card authentication device; a processing circuit (330), receiving an authentication token from the playing card authentication device; - verifying the authentication token using the counter and authentication data stored in the memory of the playing card authentication server; If the verification is successful, it sends an indication of authenticity to the playing card authentication device and increments a counter in the memory of the playing card authentication server. A processing circuit (330) configured to A playing card system (100) comprising:

2. A playing card configured for playing a card game, comprising: an electronic memory for storing authentication data and a counter; an antenna configured for wireless communication; a processing circuit, - wirelessly receiving digital commands over an antenna from an electronic playing card authentication device; - creating an authentication token in response to receiving an authentication command, the creating including reading authentication data and a counter from memory and applying a cryptographic function to the authentication data and the counter; - Wirelessly transmits an authentication token to the device through an antenna; - Increment a counter stored in memory A processing circuit configured to Including playing cards.

3. 1. A playing card authentication device for verifying the authenticity of playing cards, comprising: a communication unit adapted to communicate over a computer network with a playing card authentication server; an antenna configured for wireless communication with the playing cards; a processing circuit, - Wirelessly transmits digital authentication commands over the antenna to the playing card, receiving an authentication token from the playing card in response to the digital authentication command; - sending the authentication token to the authentication server through the communication unit; - receiving information about the authenticity of the playing cards from the authentication server; A processing circuit configured to a playing card authentication device,

4. A playing card authentication server for verifying the authenticity of playing cards, comprising: an electronic memory for storing authentication data and a counter; a communication unit configured to communicate over a computer network with the playing card authentication device; a processing circuit, receiving an authentication token from the playing card authentication device; - verifying the authentication token using the counter and authentication data stored in the memory of the playing card authentication server; If the verification is successful, it sends an indication of authenticity to the playing card authentication device and increments a counter in the memory of the playing card authentication server. A processing circuit configured to a playing card authentication server,

5. the authentication data stored in the playing card is the private key of a public / private key pair and the authentication data stored in the playing card authentication server is the public key of the public / private key pair, or the authentication data stored in the playing card is a symmetric key and the authentication data stored in the playing card authentication server is the same symmetric key, A playing card, a playing card authentication device, and / or a playing card authentication server according to any one of claims 1 to 4.

6. 6. A playing card authentication device and / or playing card authentication server according to any one of claims 1 to 5, wherein the playing card authentication device is configured to authenticate the playing card authentication server.

7. The processing circuit - generating an information page, e.g., a web page, containing the results of verifying the authentication token; - generating an identifier, for example a computer network address, through which the information page is accessible on the computer network; - Making the identifier available to playing card authentication devices 7. A playing card authentication server according to claim 4, configured to:

8. - a processor circuit of the playing card authentication server, - generate new authentication data, - If the verification is successful, send new authentication data to the playing card authentication device. It is configured as follows: - a processor circuit of the playing card authentication device - receiving new authentication data on the communication unit and transmitting new authentication data to the playing card on the antenna; It is configured as follows: - The processor circuit of the playing card - Receive new authentication data on the antenna and write the new authentication data to memory 8. A playing card, a playing card authentication device, and / or a playing card authentication server according to any one of claims 1 to 7, configured to:

9. 9. A playing card according to claim 8, wherein the memory includes at least two areas for storing authentication data, and wherein the processor of the card is configured to write the authentication data to the memory in an area different from the area storing the authentication data used to generate the authentication token.

10. 10. A playing card, playing card authentication device and / or playing card authentication server according to any one of claims 1 to 9, wherein the memory of the playing card includes a playing card identifier and the authentication token includes a playing card identifier.

11. 11. A playing card authentication device and / or playing card authentication server according to any one of claims 1 to 10, wherein the playing card authentication server is configured to send information about the playing cards for display on the playing card authentication device.

12. 12. A playing card according to any one of claims 1 to 11, wherein the antenna is configured for NFC communication.

13. 13. A playing card according to any one of claims 1 to 12, wrapped in foil, the foil being a metal foil or backed with a metal material to attenuate wireless signals to and from the antenna.

14. 14. A playing card authentication device and / or playing card authentication server according to any one of claims 1 to 13, wherein the memory contains game parameters for playing cards, the game parameters being modified upon receipt of a correctly validating authentication token, and the game parameters being sent together with information indicating authenticity.

15. the memory includes a user identifier identifying a user of a further service of the playing card authentication server; - the playing card authentication device sends the user identifier together with the authentication token; 15. A playing card authentication server according to any one of claims 1 to 14, wherein the playing card authentication server is configured to associate a user identifier with a playing card identifier in a memory of the playing card authentication server, and wherein the playing card authentication server is configured to provide access to the playing card in a further service.

16. - generating a blockchain transaction that includes the playing card identifier; - Submitting a blockchain transaction to a blockchain network so that the transaction can be processed by a blockchain management device for inclusion in a block on the blockchain.

16. A playing card authentication server according to any one of claims 1 to 15, configured to:

17. 17. A playing card pack comprising one or more playing cards according to any one of claims 1 to 16, the playing card pack including a further card, the further card comprising an antenna configured for wireless communication and processing circuitry configured to distort the wireless signal of the one or more playing cards.

18. a database storing the cards that have been authenticated to the user; a digital game play interface configured to receive game play instructions that refer to a user's cards, the playing card authentication server including: - Verify that the referenced card is authorized for the user before allowing gameplay commands to be processed a digital gameplay interface configured to 18. A playing card authentication server according to any preceding claim, comprising:

19. A playing card authentication method (600) for authenticating electronic playing cards, comprising: - wirelessly transmitting (610) a digital command over an antenna to a playing card authentication device to cause the playing card to create an authentication token, the playing card including an electronic memory (120) storing authentication data (122) and a counter (124), and creating the authentication token including applying a cryptographic function to the authentication data and the counter; - wirelessly receiving an authentication token from the device through an antenna (620); - The authentication token is verified (630) using the counter and authentication data stored in the memory of the playing card authentication server. A playing card authentication method (600) comprising:

20. 20. A computer-readable medium (1000) comprising transitory or non-transitory data (1020) representing instructions for causing a processor system to perform the method of claim 19.

21. An authentication system (100) configured to authenticate a physical object for playing a card game, the authentication system (100) comprising: a physical object (110); a physical object authentication device (200); and a physical object authentication server (300); A: The physical object (110) is an electronic memory (120) storing authentication data (122) and a counter (124); an antenna (130) configured for wireless communication; a processing circuit (140), - wirelessly receiving a digital command on the antenna from an electronic physical object authentication device; - creating an authentication token in response to receiving an authentication command, the creating including reading authentication data and a counter from memory and applying a cryptographic function to the authentication data and the counter; - Wirelessly transmits an authentication token to the device through an antenna; - Increment a counter stored in memory A processing circuit (140) configured to Including, B: A physical object authentication device (200) configured to verify the authenticity of a physical object, the physical object authentication device comprising: a communication unit (210) adapted to communicate over a computer network to a physical object authentication server; an antenna (220) configured for wireless communication with a physical object; a processing circuit (230), - Wirelessly transmit digital authentication commands over an antenna to a physical object; receiving an authentication token from the physical object in response to a digital authentication command; - sending the authentication token to the authentication server through the communication unit; - receiving information about the authenticity of the physical object from an authentication server; A processing circuit (230) configured to Including, C: A physical object authentication server (300) is configured to verify the authenticity of a physical object, the physical object authentication server comprising: an electronic memory (310) for storing authentication data and counters; a communication unit (320) adapted to communicate over a computer network with a physical object authentication device; a processing circuit (330), receiving an authentication token from a physical object authentication device; - verifying the authentication token using the counter and authentication data stored in the memory of the physical object authentication server; If the verification is successful, it sends an indication of authenticity to the physical object authentication device and increments a counter in the memory of the physical object authentication server. A processing circuit (330) configured to An authentication system (100) comprising:

Images