US20130097047A1 - Authentication server - Google Patents

Authentication server Download PDF

Info

Publication number
US20130097047A1
US20130097047A1 US13/273,969 US201113273969A US2013097047A1 US 20130097047 A1 US20130097047 A1 US 20130097047A1 US 201113273969 A US201113273969 A US 201113273969A US 2013097047 A1 US2013097047 A1 US 2013097047A1
Authority
US
United States
Prior art keywords
user
item
interface
pool
seller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/273,969
Other languages
English (en)
Inventor
Seok Ki Kim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US13/273,969 priority Critical patent/US20130097047A1/en
Priority to PCT/IB2012/002516 priority patent/WO2013054201A2/fr
Publication of US20130097047A1 publication Critical patent/US20130097047A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123Shopping for digital content
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/28Pre-payment schemes, e.g. "pay before"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • G06Q20/40145Biometric identity checks
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3244Payment aspects of a gaming system, e.g. payment schemes, setting payout ratio, bonus or consolation prizes
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326Game play aspects of gaming systems
    • G07F17/3272Games involving multiple players
    • G07F17/3281Games involving multiple players wherein game attributes are transferred between players, e.g. points, weapons, avatars
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/532Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing using secure communication, e.g. by encryption, authentication

Definitions

  • An authentication server can provide security between parties.
  • an authentication server can be used to secure the transfer of property from a first party to a second party.
  • MMORPGs massively multiplayer on-line role playing games
  • potential buyers and sellers meet on-line (e.g., chatting sites); agree on items and price; agree on face-to-face (i.e. within the game) meeting for settlement; and execute the exchange in their on-line games.
  • on-line e.g., chatting sites
  • agree on items and price agree on face-to-face (i.e. within the game) meeting for settlement
  • execute the exchange in their on-line games e.g., chatting sites
  • An apparatus can be for use as an authentication server.
  • the apparatus includes a first interface configured to communicate with a first user.
  • the apparatus also includes a second interface configured to communicate with a second user.
  • the apparatus further includes an authentication controller configured to authenticate the first user based on a first deposit of a first item, authenticate the second user based on a second deposit of a second item, transfer the first deposit to a first pool, wherein the first pool contains a plurality of the first item, transfer the second deposit to a second pool wherein the second pool contains a plurality of the second item, authenticate an exchange transaction between the first user and the second user, transfer a third item from the first pool to the second user, and transfer a fourth item from the second pool to the first user.
  • an apparatus for authenticating a transaction can include an authentication controller configured to broker an exchange between a buyer and a seller.
  • the buyer and the seller are in communication with a persistent world.
  • the authentication controller is configured to generate in-game characters for communicating with the buyer and seller in the persistent world, authenticate the seller based on a first item received from the seller by way of a first generated in-game character configured to communicate with the seller in the persistent world, transfer the first item to a first storage containing a plurality of the first item, transfer virtual currency from a buyer from a first external account outside the persistent world to an escrow account, authenticate an exchange transaction between the buyer and the seller, wherein the exchange transaction is performed based on matching an asking price from the seller with an offer price from the buyer, transfer the first item from the first storage to the buyer by way of a second generated in-game character configured to communicate with the buyer in the persistent world, and transfer virtual currency to a second external account linked to the seller outside the persistent world.
  • FIG. 1 illustrates a system according to certain embodiments.
  • FIG. 2 illustrates a partially integrated system according to certain embodiments.
  • FIG. 3 illustrates a flow diagram of functionality according to certain embodiments.
  • FIG. 4 illustrates automated item transfer according to certain embodiments.
  • FIG. 5 illustrates an automated item deposit according to certain embodiments.
  • FIG. 6 illustrates an apparatus according to certain embodiments.
  • FIG. 7 illustrates a method according to certain embodiments.
  • FIG. 8 illustrates a credit transfer process according to certain embodiments.
  • FIG. 9 illustrates a credit exchange process according to certain embodiments.
  • Various embodiments can provide a security mechanism for protection of parties in a communication or trading transaction.
  • This security mechanism can be implemented using, among other things, an authentication server.
  • the major functionalities of a virtual account, a trading system, and a payment gateway can be integrated. These functionalities can be implemented by a single authentication server or by multiple servers operating in connection with one another.
  • the virtual account functionality can provide an account that includes virtual currencies (a first kind of “item” as described herein) and/or in-game items (another kind of “item” as described here). Both kinds of items can be used in transactions and/or purchases on the overall system.
  • a virtual account can also be termed a pool.
  • the pool can be a pool of an individual user, a pool of the owner or operator of the authentication server or whole system, or an escrow pool possessed by the operator of the authentication server but on behalf of the individual user.
  • “individual user” can also refer to groups of users that form a partnership, association, tribe, guild, co-op, collective, or other agreement for combined action. Thus, “individual user” can even refer to a corporate entity that has an account on the system.
  • character can refer to a virtual representation of an individual user (as defined above) in a gaming environment, e.g., an avatar. Examples of characters include a player character, broker character, delivery character, buyer character, seller character, coordinate character, and so on.
  • the virtual account functionality can include account management and checking balances. Thus, for example, credit or debit of virtual currency, game money or other items can be performed. Likewise, a transaction history can be maintained and provided to the owner of the account or to the owner of the system.
  • the virtual account functionality can also include virtual currency transfer. This currency transfer can be person to person or to a bank account. Likewise, the virtual account functionality can include virtual currency to cash exchange. This exchange can permit the recharging of credit in virtual currency, for example, the purchase of additional virtual currency using real money, or the withdrawal of real money from an account of virtual currency.
  • the trading system functionality can be a system that trades in-game items and other digital contents for virtual currency. This functionality can, in turn, encompass the functionality of auto-matching trades. For example, “buy” prices for items can be matched to “sell” prices for items.
  • the trading system functionality can also include an operations system for instant trade and deposit features.
  • This trading system can be independent and stand/alone from any particular game.
  • This trading system can also or alternatively be integrated with or into a particular game through, for example, an application programming interface (API).
  • API application programming interface
  • the trading system functionality can further include statistical capabilities.
  • the trading system can show the same statistical information as stock trading systems show for the stock market. Examples of such statistics include bid-offer spread (also known as bid-ask or buy-sell spread), sale quotes, order quantity, trading volume, and historical values of the same.
  • bid-offer spread also known as bid-ask or buy-sell spread
  • sale quotes order quantity, trading volume, and historical values of the same.
  • the external payment or payment gateway functionality can provide features that enable other services to make payments using virtual currency.
  • the payment gateway functionality can include a channeling service that permits payment for non-game digital contents provided by the owner of the system or by a partner of the owner of the system. Likewise, the channel service can provide a payment method for game goods in games.
  • the payment gateway functionality can also permit virtual currency to be used as a payment method for other content providers.
  • FIG. 1 provides an illustration of a system according to certain embodiments.
  • an authentication system 100 can include a virtual account module 110 .
  • the virtual account module 110 can implement the virtual account functionality described above.
  • the virtual account module 110 can be configured to maintain accounts, provide transfer of virtual currency between accounts, and provide for conversion between cash and virtual currency.
  • a trading system module 120 can also be included in the authentication system 100 .
  • the trading system module 120 can implement the trading system functionality described above. Accordingly, for example, the trading system module 120 can perform auto-matching of trades, can provide an operations system for instant trade and deposit, and can provide statistics regarding trades.
  • an external payment/payment gateway module 130 can implement the external payment/payment gateway functionality described above.
  • the external payment/payment gateway module 130 can provide channeling service and serve as a payment gateway module for other content sites.
  • FIG. 2 illustrates a partially integrated system according to certain embodiments.
  • a system can include an authentication site 210 , an automatic trade operations system 250 , and a game 260 .
  • there may be full integration between the authentication site 210 and the automatic trade operations system 250 but only limited integration with the game 260 .
  • the buyer 220 can provide virtual currency to the account management system 230 in order to make a trade.
  • the virtual currency can be provided to the seller 240 .
  • the automatic trade operations system 250 can serve as a core system of the infrastructure and can support other functionality, including escrow service and automated transfer processing of an item. More discussions of the automatic trade operations system 250 will be described below.
  • the seller character 290 can provide game money and other items to the authentication system character 280 .
  • This authentication system character 280 can be a single character or a variety of coordinate characters.
  • a broker character can be used to receive the game money or other goods from the seller character 290 .
  • the authentication system character 280 can also deposit the game money or other item in some alternative repository, such as a storage character or in-game safe deposit box, or other inventory security mechanism.
  • the seller character 290 can provide the game money or other items to the authentication system character 280 before the sale transaction occurs.
  • the authentication system character 280 can be configured to escrow the items received from the seller character 290 until the sale transaction clears.
  • the seller 240 can coordinate the actions of the seller character 290 and the buyer 220 can coordinate the actions of the buyer character 270 , while the Automatic trade operations system 250 can coordinate the automatic procedures of the account management system 230 and the authentication system character 280 .
  • the authentication system character 280 (e.g., a delivery character) can provide the game money or other items to the buyer character 270 within the game 260 .
  • the automatic trade operations system 250 can provide automated trade matchmaking between buyer 220 and seller 240 .
  • the automatic trade operations system 250 can permit the transaction to occur automatically, after a deposit of the item in the game 260 and the virtual currency within the authentication site 210 has been performed.
  • the automated trade matchmaking can avoid providing a whole-selling list dealing with the same item. However, the automated trade matchmaking can show market conditions like sales, purchase quotes list, recent deals, and changes of volume and price.
  • the buyer 220 does not need to choose specific deals or contact the seller 240 . Instead, the buyer 220 can purchase the desired amount of a specific item.
  • a buyer 220 that wants a better price than currently offered can submit a bid and wait to be matched to a seller 240 .
  • FIG. 3 illustrates a flow diagram of functionality according to certain embodiments.
  • the functionality can begin at 310 with a desire by a buyer to purchase and/or at 315 with a desire by a seller to sell.
  • the buyer can search using an interface for a desired item and then make a selection.
  • an authentication system can verify whether buyer's credit (calculated in terms of virtual currency, for example) is sufficient to make the desired purchase. If so, a buy order can be created. If not, a purchasing process can be initiated to permit the buyer to obtain more credit.
  • the seller can make a deposit of an item, such as game gold, armor, rings, or other items.
  • An automated item deposit process can transfer that item into a pool.
  • the pool can be an escrow account or simply a collection of like goods. If a mixture of various items is deposited, they can each be placed in different pools or in the same seller escrow pool.
  • the seller can also provide to an interface the asking price for the items, and other information regarding the items, such as information used to confirm that the items are not hacked. The confirming of hacked items may occur when system is being operated in cooperation with a game publisher.
  • a hacked item may be an item that has been altered or created in a way that violates the rules of the game or other program to which the item belongs.
  • a sell order can be created. It is not critical that the asking price be provided prior to depositing the items. Moreover, the seller may retain the ability to change the asking price if a sale transaction remains pending for a period of time. This change in asking price can be configured to occur manually or automatically.
  • the sell order and the buy order can be provided to the automated trade matching, at 320 . There is no requirement that the buy order and the sell order be submitted to the automated trade matching at the same time.
  • the authentication system can check and confirm trade information from a database (DB). Then, the authentication system can perform an automated item transfer process, notify the seller of this trade process, and transfer credits. Finally, at 330 , the trade may be complete.
  • DB database
  • a post-trade credit process can be initiated.
  • the post-trade credit process can involve cashing out of the virtual credit or virtual currency, internal payment, player to player (P2P) credit transfer, or external payment/payment gateway (PG) functionality.
  • This post-trade credit process can be separated from the trading process, such that it is not necessary that trading occur for the credit transactions to occur.
  • FIG. 4 illustrates automated item transfer according to certain embodiments.
  • the automated item transfer can be triggered at 410 when automated trade matching yields a positive (“YES”) outcome.
  • the authentication system can check and confirm trade information from database (DB). Then the authentication system can check the buyer and/or seller character identification (ID), e.g., their account numbers, usernames, locations, description of avatar, or other identification information. Since the item may already be received from the seller, it may not be necessary to check the seller character identification at this stage. The authentication system can then identify storage character information (if the item being exchanged was stored in a storage character) and send that item date to the automated item transfer process.
  • ID buyer and/or seller character identification
  • the automated item transfer process can then auto-login a character (for example, a storage character) and/or contact an in-game delivery system and deliver the item to the buyer's character in the game.
  • a character for example, a storage character
  • the buyer can be notified of the trade process and the functionality can end from the standpoint of the buyer.
  • the buyer it is possible for the buyer to be notified earlier, particularly so as to obtain the buyer's cooperation in locating the buyer's character within the game.
  • the process can continue internally by taking a screenshot of the deposit transaction and performing a comparative check of a change of item storage inventory.
  • the trade date and evidence can be saved to a database, at 435 , and this can conclude the process from an internal standpoint. This evidentiary process may not be necessary, but may help to authenticate the transaction from the standpoint of the owner or operator of the authentication system, as well as to an outside auditor or a complaining customer.
  • Various techniques can be used to automate the delivery of the item to the buyer's character. For example, text and image recognition can be used to permit the authentication system to navigate a game, locate the buyer's character and interact with the buyer's character. From the buyer's side and/or the authentication system's side, a script can be employed to enable the buyer's character to quickly and efficiently connect with the delivery character providing the item. Alternatively, in-game mail delivery can be employed to automatically transmit the item to the buyer's character or to return the item to the seller's character if no purchase transaction is completed.
  • the authentication system can be configured to employ automated game input. Automated game input can be used with respect to various things, such as log-in, choosing characters, mailboxes, and so on. Macros or other scripts can, for example, be used to automate procedures within the game.
  • FIG. 5 illustrates an automated item deposit according to certain embodiments.
  • the automated item deposit process can be triggered at 510 by the attempt of a seller to deposit an item.
  • the authentication system can allocate a broker character to receive the item.
  • the seller can send the item to the broker character via an in-game delivery system, such as a face to face exchange or email. If a broker character is already allocated, that broker character can be auto-logged-in.
  • the authentication system can check for a new delivery from a seller.
  • the authentication system can check each attached item in the delivery.
  • the authentication system can indicate the item as received, and—in parallel—can document the process of receiving the item, which can be known as a receipt of item process.
  • This receipt of item process can be omitted, but may be used for authenticating the delivery transaction for an owner of the authentication system, an auditor, or a complaining customer. That receipt information including the trade date and evidence can be saved to a database (DB) at 525 .
  • DB database
  • an item storage allocation process can be employed to store or escrow the deposited item pending sale and transfer of the item. At this point, the deposit may be finished.
  • a sell order can be generated at 520 .
  • a sell order can be generated automatically, based on current market conditions.
  • the automated item deposit process can employ text and image recognition, automated game input, and exact cognition and input as an automated item transfer process as described above. There is no requirement that the automated item transfer process and the automated item deposit process operate similarly. This is just an example for the purposes of illustration, as are all embodiments set forth herein.
  • FIG. 6 illustrates an apparatus according to certain embodiments.
  • an apparatus for example, an authentication server
  • the first interface 610 can be configured to communicate with a first user, for example, the seller of an item.
  • the first interface 610 can communicate with the first user via a website.
  • the first interface 610 can be configured to query the first user for a username and password.
  • the first interface 610 can be configured to obtain other identification information, such as biometric identification information.
  • the second interface 620 can be configured to communicate with a second user, for example, the buyer of an item.
  • the second interface 620 can communicate with the second user via a website and can be configured to query the second user for a username and password.
  • the second interface 620 can be configured to obtain other identification information, such as biometric identification information, of the second user.
  • the first interface 610 and the second interface 620 can be the same interface or they can be different interfaces.
  • the first interface 610 can be a website belonging to an owner of the authentication server
  • the second interface 620 can be an in-game interface based on, for example, an application programming interface (API) provided by the owner of the authentication server.
  • API application programming interface
  • the authentication controller 630 can be configured to authenticate the first user based on a first deposit of a first item.
  • the first interface 610 can be configured to receive the first deposit from the first user.
  • the first item can be an item being offered for sale.
  • the item can include, for example, game gold or credit, virtual equipment such as swords and armor, or virtual property, such as a house or castle.
  • the first interface 610 can be configured to receive the first deposit by an in-game transfer, by an email transfer, or by any other mechanism.
  • a broker character within a game can be employed to receive the deposit.
  • the broker character can be a user identity within a game and can appear to be another player to players of the game.
  • a sword can be deposited into a pool of like swords.
  • the term “pool” here can refer to a grouping of items.
  • a pool of like swords is a grouping of like swords. This grouping can be maintained via a database or within a game by being stored in a particular character's or store's inventory.
  • the authentication controller 630 can be configured to account for the deposit of the sword and to return a like sword (or even the same sword) to the first user if a transaction fails.
  • the authentication controller 630 can also be configured to authenticate the second user based on a second deposit of a second item.
  • the second interface 620 can be configured to receive the second deposit from the second user.
  • the second item can be an item being offered as a way of buying.
  • the second item can be a virtual currency or a salable item.
  • the deposit of the virtual currency can be accomplished by purchasing virtual currency with real currency, earning virtual currency through performing some task (such as an in-game quest), obtaining virtual currency by a promotion (for example, as a reward for recommending a service to several friends), as proceeds from selling an item, or any other way.
  • the deposit of the virtual currency can be a deposit in an account belonging to the second user, or in a holding account to ensure that sufficient virtual currency is available for a specific transaction.
  • Virtual currency can refer to credits, tokens, or similar countable items that have assigned value within a system, but are not government-issued currency. For example, within a game, game gold or game dollars may be used to purchase items at stores of the game. Such game gold may be one kind of virtual currency. Other kinds of virtual currency are also possible.
  • the authentication system may employ its own virtual currency that is independent of the virtual currency of any particular game. Examples of real currency can include U.S. Dollars, South Korean Won, Euros, Japanese Yen, Swiss Francs, Russian Rubles, and so on.
  • precious metals for example, gold, silver, or platinum
  • other commodities can be substituted.
  • virtual currency can be deposited in the second user's personal account. Then, when the second user wishes to conduct a transaction, an amount of a bid (or other proposed payment amount) of the second user is deposited into an escrow account that holds the amount of the bid until the transaction either succeeds or fails.
  • the authentication controller 630 can be configured to transfer the first deposit to a first pool.
  • the first pool can be a pool of similar goods, or simply a pool of items for sale or other exchange.
  • the first pool can be an escrow pool corresponding to the first user.
  • multiple items from the same user that are being offered for sale or exchange can be pooled in a first pool.
  • the first deposit may be placed into a pool of like goods. For example, gold for a particular game can be placed in a single pool.
  • the first interface 610 can be configured to query the first user regarding the severability of the group of items. For example, the first user can be queried as to whether the items in the group can be sold or exchanged separately or whether they must be sold as a group. In the case of game gold, for example, the selling user may be given the option to sell “all or nothing” to sell sub-units of a group of game gold that is being offered for sale.
  • the authentication controller 630 can maintain the information provided in response to this and other queries from the first interface 610 and second interface 620 .
  • the authentication controller 630 can be configured to transfer the second deposit to a second pool.
  • this second pool may be a user's account of virtual currency, or an escrow account for the user.
  • the authentication controller 630 can be further configured to authenticate an exchange transaction between the first user and the second user.
  • the authentication of the exchange can include automatically matching a first parameter obtained by the first interface 610 from the first user to a second parameter obtained by the second interface 620 from the second user.
  • the first parameter can include one or more item.
  • the first parameter can include an asking price, a sell-by date, an automatic de-escalation amount, a minimum asking price, or any combination thereof.
  • the asking price can be the amount that the first user wishes to receive for the first item.
  • the sell-by date can be the length of time that the first user wants the item to remain available for sale.
  • the automatic de-escalation amount can be an amount of discount to be applied if the first item has not sold within a predetermined period of time.
  • the automatic de-escalation amount can be specified to result in multiple discounts of the same item over time until the item is sold.
  • a minimum asking price can be set to ensure that the asking price does not automatically go too low for the first user.
  • the second parameter can also include one or more item.
  • the second parameter can include an offer price, a duration of the offer, an automatic escalation amount, a maximum offer price, or any combination thereof.
  • the offer price can be the amount that the second user is willing to give for an item to be obtained.
  • the duration of the offer can be the length of time for which this offer is good, and after which the offer is to be withdrawn.
  • the automatic escalation amount is the amount to which the offer or bid should be increased if a sale is not completed within a predetermined period of time.
  • a maximum offer price can be set to avoid the second user automatically overpaying for an item of interest.
  • the matching the first parameter to the second parameter can include matching an ask price to a bid price.
  • the matching can be an exact matching or an inexact matching
  • a bid price can be matched to an ask price that is at most equal to the bid price.
  • the authentication controller 630 can be configured to transfer a third item from the first pool to the second user.
  • the third item can be the same item as the first item or a different item of the same kind.
  • the transfer of the third item can take place in a variety of ways, such as within the gaming environment or a persistent world (in game) or by email.
  • the authentication controller 630 can be configured to transfer a fourth item from the second pool to the first user.
  • the fourth item can be the same item as the second item, or a different item of the same kind.
  • the first pool can be a pool of identical castles and the second pool can be a pool of virtual currency.
  • the first interface 610 can receive the first item with the broker character.
  • the broker character can be present in a game in which the first item is able to be used and exchanged.
  • the broker character can be obtained by registering the broker character with the game as a user of the game.
  • the second interface 6 can use a delivery character to delivery the third item to the second user.
  • the authentication controller 630 can use a storage character to store the first item.
  • multiple broker, delivery, and storage characters can be used within a single game and across multiple games. Like the broker character(s), the delivery and storage character(s) can be generated within the game or within multiple games.
  • the apparatus can further include a payment controller 640 .
  • the payment controller 640 can be configured to perform an exchange between real currency and virtual currency.
  • the second item can be the virtual currency.
  • the payment controller 640 can be configured to verify whether the second user has sufficient virtual currency to perform a transaction and to top up the virtual currency of the second user when the second user does not have sufficient virtual currency.
  • “Topping up” can refer to a procedure of increasing the amount of virtual currency in an account to a predefined “top-to” level, when the level of virtual currency in the account is either below the top-to level, or below some minimum threshold amount.
  • a top-to level can be set to be an initial amount in the account when the account is opened, and a minimum threshold amount can be set to be one-half the top-to level.
  • the payment controller 640 can be configured to convert real currency to virtual currency according to a first rate and can be configured to convert virtual currency to real currency according to a second rate that differs from the first rate. For example, the payment controller 640 can convert from real currency to virtual currency at a 1:1 rate, but can convert from virtual currency to real currency at a 1:0.9 rate.
  • the authentication controller 630 , first interface 610 , and second interface 620 can be configured to conceal all personal information regarding the first user from the second user and all personal information regarding the second user from the first user.
  • the payment controller 640 can be similarly configured with respect to all personal information.
  • the apparatus can additionally include a user interface 650 configured to provide trading information regarding the first pool to the second user.
  • the second interface 630 can be configured to receive a purchase selection from the second user after display of the trading information.
  • the trading information may include the range of asking prices for that pool of armor, volume of trading for that pool of armor, and number of available armor units. For each asking price, the number of available units of armor can be shown.
  • the second user can then select a number of units of armor to purchase and a price that the second user is willing to pay.
  • the authentication controller 630 can automatically authenticate the transaction and move the transaction to settlement.
  • a database 660 can be configured to record, track, and provide the trading information corresponding to the first item, the second item, the first pool, and the second pool.
  • the first interface 610 and the second interface 620 can be placed in communication with a persistent world.
  • the persistent world can be a virtual world in which users' changes to the world's state continue to exist even after the users who made the changes leave the world.
  • the persistent world is the arena of play of a massively multiplayer on-line role playing game.
  • the authentication controller 630 can be configured to generate, in the persistent world, a plurality of in-game characters for communicating with a plurality of users in the persistent world including the first user and the second user and configured to conceal all personal information of the first user from the second user.
  • the plurality of in-game characters include a first in-game character configured to receive the first item from the first user, and a second broker character configured to deliver the fourth item to the second user.
  • the authentication controller 630 is configured to broker an exchange between a buyer and a seller, wherein the buyer and the seller are in communication with a persistent world.
  • the authentication controller 630 is configured to generate in-game characters for communicating with the buyer and seller in the persistent world.
  • the authentication controller 630 is also configured to authenticate the seller based on a first item received from the seller by way of a first generated in-game character configured to communicate with the seller in the persistent world.
  • the authentication controller 630 is further configured to transfer the first item to a first storage containing a plurality of the first item.
  • the authentication controller 630 is additionally configured to transfer virtual currency from a buyer from a first external account outside the persistent world to an escrow account.
  • the authentication controller 630 is also configured to authenticate an exchange transaction between the buyer and the seller, wherein the exchange transaction is performed based on matching an asking price from the seller with an offer price from the buyer.
  • the authentication controller 630 is further configured to transfer the first item from the first storage to the buyer by way of a second generated in-game character configured to communicate with the buyer in the persistent world.
  • the authentication controller 630 is additionally configured to transfer virtual currency to a second external account linked to the seller outside the persistent world.
  • the first interface 610 , second interface 620 , authentication controller 630 , payment controller 640 , user interface 650 , and database 660 are illustrates as separate components connected by a bus connection. However, the components are can be combined, such that, for example, the first interface 610 and the second interface 620 can be the same, or one of those interfaces can be the user interface 650 . Likewise the authentication controller 630 and payment controller 640 can be the same component. Moreover, the interconnection amongst the components can be other than illustrated in FIG. 6 .
  • FIG. 7 illustrates a method according to certain embodiments.
  • a method can be a method of authenticating and brokering an exchange between a buyer and a seller.
  • the buyer and the seller can be in communication with a persistent world.
  • An authentication controller can, at 710 , generate in-game characters for communicating with the buyer and seller in the persistent world.
  • An authentication system can generate a character within a world in a variety of ways. For example, an authentication system can automatically login a previously created character or can register a new character within the world. Alternatively, a new character can be spawned automatically within the world through cooperation with the game provider. The authentication system can provide identifying information about the created character to one or more of the parties of the transaction. Thus, the authentication system can interact with the persistent world via a client like the parties of the transaction. Alternatively, the authentication system can be integrated more or less fully with the game.
  • the authentication controller can also, at 720 , authenticate the seller based on a first item received from the seller by way of a first generated in-game character configured to communicate with the seller in the persistent world.
  • the first item is authenticated to determine whether the first item is hacked.
  • the authentication controller can further, at 730 , transfer the first item to a first storage containing a plurality of the first item.
  • the authentication controller can additionally, at 740 , transfer virtual currency from a buyer from a first external account outside the persistent world to an escrow account.
  • the authentication controller can also, at 750 , authenticate an exchange transaction between the buyer and the seller.
  • the exchange transaction can be performed based on, at 755 , matching an asking price from the seller with an offer price from the buyer.
  • the authentication controller can further, at 760 , transfer the first item from the first storage to the buyer by way of a second generated in-game character configured to communicate with the buyer in the persistent world.
  • the authentication controller can additionally, at 770 , transfer virtual currency to a second external account linked to the seller outside the persistent world.
  • FIG. 8 illustrates a credit transfer process according to certain embodiments.
  • a credit process can begin at 810 with a request to transfer N virtual credits from user A to user B.
  • A knows B's account within the system.
  • A inputs B's account, that account is confirmed, A is identified and the transfer is confirmed with A, then the transfer is completed to B's account, and A is informed about the transfer, for example via email, at 820 .
  • A knows B's bank account.
  • A enters B's bank account.
  • B's bank account is validated by the system.
  • a notice is provided of estimated amount of transfer, enumerated in a real currency.
  • Identification of A and confirmation of the transfer are performed, and then the transfer to B's bank account is completed.
  • A is informed about the transfer via email.
  • A does not know any account information for B.
  • A inputs B's email address or cell phone number.
  • B is notified that A wants to transfer to B's account. This notice can be provided by, for example, email, SMS, or MMS.
  • B is requested to join. When B accepts this offer, B joins and then is offered a way to receive the funds. B can then select a virtual account and the funds can be transferred to B's virtual account.
  • A can be notified about the successful transfer.
  • B can select to deposit in B's bank account.
  • B can input B's bank account number.
  • the bank account can be validated and the transfer can be completed to B's bank account.
  • A can be notified of the successful transfer.
  • B can refuse to join and can select to have the funds transferred to B's bank account.
  • B can input B's bank account information, and the procedure can proceed to 860 , as in the previous option.
  • B can refuse to join and can refuse to provide bank account information.
  • the N credits can be returned to A's account.
  • A can be informed about the failed transfer.
  • FIG. 9 illustrates a credit exchange process according to certain embodiments.
  • an exchanging credit process can be performed.
  • the process can be either an automatic exchange or a manual exchange.
  • An auto-account transfer can be performed in which an option for auto-account transfer has been selected and account data (for example, bank account data) has been entered. Then, the account's validity can be checked and an automated top-up registration can be instituted. In this case, at 920 , automated credit top-up can be performed.
  • a credit card can be used instead of a bank account, and a similar process can proceed to automatic top-up at 920 .
  • manual account transfer can be performed.
  • credit from one virtual account be transferred to another virtual account, and the credit exchange can be finished at 930 .
  • a temporary account can be used in the course of such a transfer.
  • a credit card can be manually used to provide credit.
  • the credit card can either be processed by a one-click exchange or by an external payment gateway (PG), such as PayPal® or the like.
  • PG external payment gateway
  • the credit exchange can be finished at 930 .
  • a mobile phone or an audio response system can be used to make initiate the credit transfer.
  • a password can be provided and entry of the password can be used to authorize the credit exchange.
  • an assigned phone number can be called and customer information and password can be provided to authorize the credit exchange.
  • the credit exchange can be finished at 930 .
  • a final alternative is the use of a gift card or other coupon.
  • the coupon number can be entered. Then, the validity of the coupon number can be checked. If the number is valid, the credit exchange can be finished at 930 .
  • an additional credit exchange process can be used.
  • another virtual currency can be converted into the virtual currency used within the system. The process can proceed similar to that for processing a giftcard or coupon.
  • the credit exchange can be omitted.
  • a dealing process can be initiated directly at 940 .
  • the dealing process can also be initiated after the credit exchange or automatic credit top-up is completed.
  • Embodiments of the present invention may have various features. For example, certain embodiments may permit real-time, on-line trade and settlement during all hours of the day and all days of the year. Certain embodiments may also allow immediate trade and settlement of virtual items. Moreover, there can be, in certain embodiments, a perfect match and settlement between buy & sell (bid & offer). There can be transparency in the process of purchase, as the buyers and sellers may able to make an assessment of the market before asking or bidding. The virtual currency of certain embodiments may be convertibility into real money. Moreover, in certain embodiments, transaction costs may be kept low.
  • certain embodiments may employ matching escrow account(s) at AAA-rated banks.
  • virtual credit/currency to be issued based on cash deposit (into an escrow account).
  • the virtual credit/currency can be the exclusive way by which all trades are settled within the system. This system can avoid default, because any and all virtual credit/currency can be converted unconditionally upon demand into real cash.
  • all items traded within the system can be coded, as in real-world stock-exchanges (e.g., NASDAQ and most of the major securities exchanges around the world).
  • certain embodiments can provide a real-time screen showing all the items with bid & offer; by price and volume; all by computer trading round the clock.
  • all electronic and real-time transfer of items and virtual credit/currency as well as conversion into real money among all the accounts can take place within the system.
  • production of real-time, on-line statements showing all transactions and account balances in items and virtual credit/currency as well as cash can be provided to users.
  • certain embodiments may be capable of sending and receiving items (including virtual credit/currency as a special case), and cash to and from different games, gamers' bank accounts, and credit card accounts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)
US13/273,969 2011-10-14 2011-10-14 Authentication server Abandoned US20130097047A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/273,969 US20130097047A1 (en) 2011-10-14 2011-10-14 Authentication server
PCT/IB2012/002516 WO2013054201A2 (fr) 2011-10-14 2012-10-11 Serveur d'authentification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/273,969 US20130097047A1 (en) 2011-10-14 2011-10-14 Authentication server

Publications (1)

Publication Number Publication Date
US20130097047A1 true US20130097047A1 (en) 2013-04-18

Family

ID=48082610

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/273,969 Abandoned US20130097047A1 (en) 2011-10-14 2011-10-14 Authentication server

Country Status (2)

Country Link
US (1) US20130097047A1 (fr)
WO (1) WO2013054201A2 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140164227A1 (en) * 2012-12-06 2014-06-12 Sony Online Entertainment Llc System and method for sharing digital objects
US8777754B1 (en) 2012-07-30 2014-07-15 Zynga Inc. Providing offers for sales of combinations of virtual items at discounted prices
US9257007B2 (en) 2012-07-30 2016-02-09 Zynga Inc. Customizing offers for sales of combinations of virtual items
US20170091721A1 (en) * 2015-09-30 2017-03-30 Bank Of America Corporation Account tokenization for virtual currency resources
US20180049043A1 (en) * 2005-10-04 2018-02-15 Steven M. Hoffberg Multifactorial optimization system and method
US10099115B2 (en) 2012-12-06 2018-10-16 Sony Interactive Entertainment America Llc System and method for user creation of digital objects
US20190188656A1 (en) * 2017-12-18 2019-06-20 Working Dog Ventures Ltd. System and method for exchanging items
US10453059B2 (en) 2015-09-30 2019-10-22 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
US11083970B2 (en) * 2006-11-15 2021-08-10 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US11277265B2 (en) 2020-07-17 2022-03-15 The Government of the United States of America, as represented by the Secretary of Homeland Security Verified base image in photo gallery
US11348093B2 (en) * 2020-07-10 2022-05-31 The Government of the United States of America, as represented by the Secretary of Homeland Security System and method for merchant and personal transactions using mobile identification credential
US11392949B2 (en) 2020-07-10 2022-07-19 The Government of the United States of America, as represented bv the Secretary of Homeland Security Use of mobile identification credential in know your customer assessment
US11405779B2 (en) 2020-07-10 2022-08-02 The Government of the United States of America, as represented by the Secretary of Homeland Security Vehicular communication of emergency information to first responders
US11407528B2 (en) 2020-02-25 2022-08-09 The Government of the United States of America, as represented by the Secretary of Homeland Security Electronic bag locking and unlocking
US11599872B2 (en) 2020-04-13 2023-03-07 The Government of the United States of America, as represented by the Secretary of Homeland Security System and network for access control to real property using mobile identification credential
US11601816B2 (en) 2020-04-13 2023-03-07 The Government of the United States of America, as represented by the Secretary of Homeland Security Permission-based system and network for access control using mobile identification credential including mobile passport
US11711699B2 (en) 2020-04-13 2023-07-25 The Government of the United States of America, as represented by the Secretary of Homeland Security Permission-based system and network for access control using mobile identification credential
US11863994B2 (en) 2020-04-13 2024-01-02 The Government of the United States of America, represented by the Secretary of Homeland Security System and network for access control using mobile identification credential for sign-on authentication

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080004120A1 (en) * 2006-06-30 2008-01-03 Leviathan Entertainment, Llc Management and Protection of Creative Works in a Virtual Environment
US20080220876A1 (en) * 2006-10-17 2008-09-11 Mehta Kaushal N Transaction systems and methods for virtual items of massively multiplayer online games and virtual worlds

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020023903A (ko) * 2001-12-28 2002-03-29 강성훈 가상현실 게임의 온라인 거래중계시스템
KR100456601B1 (ko) * 2004-03-18 2004-11-10 엔에이치엔(주) 게임 아이템 판매 등록 시스템 및 게임 아이템 판매 등록방법
KR20080081212A (ko) * 2007-01-12 2008-09-09 (주)와이앤케이커뮤니케이션즈 게임 캐릭터의 중개를 이용하는 게임 아이템 매매 시스템및 그 게임 아이템 매매 방법
JP2009050602A (ja) * 2007-08-29 2009-03-12 Square Enix Holdings Co Ltd ゲーム提供システム及びゲーム提供管理装置
KR100972428B1 (ko) * 2008-01-15 2010-07-26 주식회사 넥슨 온라인 게임 아이템의 거래 시스템
US8151198B2 (en) * 2009-04-29 2012-04-03 Disney Enterprises, Inc. System and method for item-based economy in a virtual world

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080004120A1 (en) * 2006-06-30 2008-01-03 Leviathan Entertainment, Llc Management and Protection of Creative Works in a Virtual Environment
US20080220876A1 (en) * 2006-10-17 2008-09-11 Mehta Kaushal N Transaction systems and methods for virtual items of massively multiplayer online games and virtual worlds

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180049043A1 (en) * 2005-10-04 2018-02-15 Steven M. Hoffberg Multifactorial optimization system and method
US20210362062A1 (en) * 2006-11-15 2021-11-25 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US11083970B2 (en) * 2006-11-15 2021-08-10 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US11794113B2 (en) * 2006-11-15 2023-10-24 Cfph, Llc Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server
US10369475B2 (en) 2012-07-30 2019-08-06 Zynga Inc. Customizing offers for sales of combinations of virtual items
US8777754B1 (en) 2012-07-30 2014-07-15 Zynga Inc. Providing offers for sales of combinations of virtual items at discounted prices
US9256887B2 (en) 2012-07-30 2016-02-09 Zynga Inc. Providing offers for sales of combinations of virtual items at discounted prices
US9257007B2 (en) 2012-07-30 2016-02-09 Zynga Inc. Customizing offers for sales of combinations of virtual items
US9345974B1 (en) * 2012-07-30 2016-05-24 Zynga Inc. Customizing offers for sales of combinations of virtual items
US20140164227A1 (en) * 2012-12-06 2014-06-12 Sony Online Entertainment Llc System and method for sharing digital objects
US10099115B2 (en) 2012-12-06 2018-10-16 Sony Interactive Entertainment America Llc System and method for user creation of digital objects
US11113773B2 (en) * 2012-12-06 2021-09-07 Sony Interactive Entertainment LLC System and method for sharing digital objects
US10453059B2 (en) 2015-09-30 2019-10-22 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
US10607215B2 (en) * 2015-09-30 2020-03-31 Bank Of America Corporation Account tokenization for virtual currency resources
US10990971B2 (en) 2015-09-30 2021-04-27 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
US11087312B2 (en) 2015-09-30 2021-08-10 Bank Of America Corporation Account tokenization for virtual currency resources
US20170091721A1 (en) * 2015-09-30 2017-03-30 Bank Of America Corporation Account tokenization for virtual currency resources
US20190188656A1 (en) * 2017-12-18 2019-06-20 Working Dog Ventures Ltd. System and method for exchanging items
US11407528B2 (en) 2020-02-25 2022-08-09 The Government of the United States of America, as represented by the Secretary of Homeland Security Electronic bag locking and unlocking
US11655051B2 (en) 2020-02-25 2023-05-23 The Government of the United States of America, as represented by the Secretary of Homeland Security Electronic bag locking and unlocking
US11599872B2 (en) 2020-04-13 2023-03-07 The Government of the United States of America, as represented by the Secretary of Homeland Security System and network for access control to real property using mobile identification credential
US11601816B2 (en) 2020-04-13 2023-03-07 The Government of the United States of America, as represented by the Secretary of Homeland Security Permission-based system and network for access control using mobile identification credential including mobile passport
US11863994B2 (en) 2020-04-13 2024-01-02 The Government of the United States of America, represented by the Secretary of Homeland Security System and network for access control using mobile identification credential for sign-on authentication
US11711699B2 (en) 2020-04-13 2023-07-25 The Government of the United States of America, as represented by the Secretary of Homeland Security Permission-based system and network for access control using mobile identification credential
US11716630B2 (en) 2020-04-13 2023-08-01 The Government of the United States of America, as represented by the Secretary of Homeland Security Biometric verification for access control using mobile identification credential
US11800352B2 (en) 2020-07-10 2023-10-24 The Government of the United States of America, as represented by the Secretary of Homeland Security Remote retrieval of information from vehicles
US11392949B2 (en) 2020-07-10 2022-07-19 The Government of the United States of America, as represented bv the Secretary of Homeland Security Use of mobile identification credential in know your customer assessment
US11405779B2 (en) 2020-07-10 2022-08-02 The Government of the United States of America, as represented by the Secretary of Homeland Security Vehicular communication of emergency information to first responders
US11348093B2 (en) * 2020-07-10 2022-05-31 The Government of the United States of America, as represented by the Secretary of Homeland Security System and method for merchant and personal transactions using mobile identification credential
US11564088B2 (en) 2020-07-10 2023-01-24 The Government of the United States of America, as represented by the Secretary of Homeland Security Vehicular communication of emergency information
US11461450B2 (en) 2020-07-17 2022-10-04 The Government of the United States of America, as represented by the Secretary of Homeland Security Verified hosted information in online galleries
US11277265B2 (en) 2020-07-17 2022-03-15 The Government of the United States of America, as represented by the Secretary of Homeland Security Verified base image in photo gallery
US11675886B2 (en) 2020-07-17 2023-06-13 The Government of the United States of America, as represented by the Secretary of Homeland Security Verified hosted information in online galleries
US11941100B2 (en) 2020-07-17 2024-03-26 The Government of the United States of America, represented by the Secretary of Homeland Security Selective access and verification of user information

Also Published As

Publication number Publication date
WO2013054201A3 (fr) 2013-08-01
WO2013054201A2 (fr) 2013-04-18

Similar Documents

Publication Publication Date Title
US20130097047A1 (en) Authentication server
US11741540B2 (en) Alternative value exchange systems and methods
US20220327590A1 (en) Secure execution of an exchange item acquisition request
US9785988B2 (en) In-application commerce system and method with fraud prevention, management and control
US20130041773A1 (en) Systems and methods to process online monetary payments dependent on conditional triggers involving future events
US8751294B2 (en) Processing value-ascertainable items
US20140304102A1 (en) Secure transfer of online privileges including non-financial options
US20110131128A1 (en) Method and means for controlling payment setup
KR100434850B1 (ko) 머드 게임을 위한 전자 상거래 서비스 방법 및 장치
US20220261790A1 (en) Electronic financial transaction system employing cryptocurrency and payment method using same
WO2008130748A2 (fr) Transfert sécurisé de privilèges en ligne comprenant des options non financières
KR20170142374A (ko) 가상화폐를 이용한 송금 시스템 및 방법
KR20150086360A (ko) 교환 가능한 홍보 가치 크레디트를 제공하는 컴퓨터 프로그램, 방법, 및 시스템
EP1837821A1 (fr) Système et procédé de commerce électronique
US20220084015A1 (en) Methods and systems for ethical cryptocurrency management
CN107358428B (zh) 一种多终端撮合交易系统
US20190080394A1 (en) Method and system for online auctions
US20180047098A1 (en) Computer implemented method and computer system for auctioning or trading bets
US20150213531A1 (en) Computer-Assisted Interactive Reverse Auctions
US20230108958A1 (en) Computer implemented techniques and graphical user interfaces for facilitating online sale, transfer, and/or exchange of whole or fractional ownership interests of electronic sports wager transactions
US20210097819A1 (en) Wagering Services Systems and Methods
KR20120009569A (ko) 배팅 게임과 연계된 전자 상거래 시스템 및 방법
KR20020073887A (ko) 선결제 방식에 의한 인터넷 상에서의 상품 구매방법
US20230368283A1 (en) Method and system for online auctions
US20220327591A1 (en) Automatically determining an acquisition threshold for an exchange item

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION