US20130097047A1 - Authentication server - Google Patents
Authentication server Download PDFInfo
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/023—Payment 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
- G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
- G06Q20/123—Shopping for digital content
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/28—Pre-payment schemes, e.g. "pay before"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, 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/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
- G07F17/3244—Payment aspects of a gaming system, e.g. payment schemes, setting payout ratio, bonus or consolation prizes
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
- G07F17/326—Game play aspects of gaming systems
- G07F17/3272—Games involving multiple players
- G07F17/3281—Games involving multiple players wherein game attributes are transferred between players, e.g. points, weapons, avatars
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features 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/50—Features 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/53—Features 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/532—Features 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)
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)
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)
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)
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 |
-
2011
- 2011-10-14 US US13/273,969 patent/US20130097047A1/en not_active Abandoned
-
2012
- 2012-10-11 WO PCT/IB2012/002516 patent/WO2013054201A2/fr active Application Filing
Patent Citations (2)
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)
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 |