US20130139220A1 - Systems and Methods for Using A Domain-Specific Security Sandbox to Facilitate Secure Transactions - Google Patents

Systems and Methods for Using A Domain-Specific Security Sandbox to Facilitate Secure Transactions Download PDF

Info

Publication number
US20130139220A1
US20130139220A1 US13/747,280 US201313747280A US2013139220A1 US 20130139220 A1 US20130139220 A1 US 20130139220A1 US 201313747280 A US201313747280 A US 201313747280A US 2013139220 A1 US2013139220 A1 US 2013139220A1
Authority
US
United States
Prior art keywords
transaction
domain
application
client application
module
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.)
Granted
Application number
US13/747,280
Other versions
US9160717B2 (en
Inventor
Hemant Madhav Bhanoo
Luke Bayes
Allan Stephan Mills
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.)
Google LLC
Original Assignee
Google LLC
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
Priority to US12/788,173 priority Critical patent/US8364959B2/en
Application filed by Google LLC filed Critical Google LLC
Priority to US13/747,280 priority patent/US9160717B2/en
Assigned to GOOGLE INC. reassignment GOOGLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAYES, LUKE, BHANOO, HEMANT MADHAV, MILLS, ALLAN
Publication of US20130139220A1 publication Critical patent/US20130139220A1/en
Publication of US9160717B2 publication Critical patent/US9160717B2/en
Application granted granted Critical
Assigned to GOOGLE LLC reassignment GOOGLE LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: GOOGLE INC.
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356Aspects of software for card payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING 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
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806Details of the card
    • G07F7/0813Specific details related to card security
    • G07F7/0826Embedded security module

Abstract

Computer systems, methods, and computer readable media for facilitating a secure transaction are provided in which a client application is executed on a client computer. The client application initiates a request to a first domain comprising (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. Responsive to this request, the client receives a validated transaction module from the first domain. The client application loads the validated transaction module into a separate domain security sandbox that is segregated from memory space in which the client application is run. The validated transaction module conducts a validated transaction between the second domain and the validated transaction module. Separately, through the client application, a determination is made as to whether the transaction is complete by querying the first domain.

Description

    1. FIELD OF THE INVENTION
  • The present application relates generally to systems and methods for using a domain-specific security sandbox to facilitate secure transactions.
  • 2. BACKGROUND
  • The number of potentially insecure applications running on client computers that, nevertheless, require secure real time transaction services, continues to grow. One non-limiting example of such applications are FLASH-based gaming applications that require replenishment of virtual currency in order to buy in-game upgrades like level unlocks, virtual equipment, virtual special weapons and cheats directly to gamers. Securing such real time transactions is needed in the art to protect users and application developers from fraudulent acquisition of account information, identity theft, and other forms of fraud.
  • One known method for securing such transactions is the concept of using a shared secret (secret key cryptography). Secret key cryptography involves the use of a single key. Given a message and the key, encryption produces unintelligible data which requires the key to decrypt. See, for example, Section 2.4 of Kaufman, Network Security, Prentice-Hall, Inc., Upper Saddle River, N.J., which is hereby incorporated by reference. However, the shared secret method does not work in instances where one of the applications is not secure. For example, many popular programming applications are executed by FLASH players and are not secure. Typically, when a shared secret algorithm is used, there is a remote web server calling a local web server. The secret is safe on the remote web server and the local web server and is not communicated between the two servers. This fails when the application is written in FLASH or other programs that are downloaded to a client computer and run, for example, within the client's browser. In the case of FLASH, when a user requests a FLASH application, a SWF file that contains bytecode that is interpreted by a FLASH player is down-loaded to the client computer and run (interpreted) by a FLASH player within the client's browser. The bytecode in the SWF file can be inspected at the client computer to determine the secret. Thus, secrets cannot be contained within a FLASH SWF file.
  • Given the above background, what is needed in the art are improved systems and methods for authenticating electronic transactions originated from applications that may not be secure.
  • 3. SUMMARY
  • The present disclosure addresses the needs in the art by making novel use of server cross-domain policies as well as domain-specific security sandboxes. There are two embodiments disclosed. In the first embodiment, a client application makes a request for a transaction module from a first domain that has an unrestrictive cross-domain policy. Once the client application receives the transaction module, it is executed in its own domain-specific security sandbox such that the source URL of the transaction module, the URL of the first domain, is preserved. The transaction module completes the transaction by interacting with a second domain that has a cross-domain policy that restricts interaction to those programs and processes whose source URL is the first domain.
  • The second embodiment takes the process a step further. In the second embodiment, responsive to a need to make an in-application secure transaction, a client application makes a first request associated with an in-application secure transaction. The first request is sent over the Internet or a computer network to a first domain that has an unrestrictive cross-domain policy. Responsive to this request, the first domain sends the client application a request module. Once the client application receives the request module, it is executed in its own domain-specific security sandbox (first sandbox) such that the source URL of the request module, the URL of the first domain, is preserved. The request module, operating in the first sandbox, makes a request for a transaction module from a second domain that has a cross-domain policy that restricts interaction to those programs and processes whose source URL is the first domain. The second domain sends the client application the transaction module. Once the client application receives the transaction module, the transaction module is executed in its own domain-specific security sandbox (second sandbox) such that the source URL of the transaction module, the URL of the second domain, is preserved. The transaction module completes the transaction by interacting with a third domain that has a cross-domain policy that restricts interaction to those programs and processes whose source URL is the second domain.
  • By exploiting cross-domain policies and the natural ability to run programs in their own domain-specific security sandboxes without the power for calling applications to introspect, the present disclosure provides highly secure systems, methods, and computer readable media for facilitating a secure in-application transaction.
  • First Embodiment from a Client Perspective
  • One implementation of the first embodiment of the present disclosure, from a client perspective, comprises a computer system for facilitating a secure transaction. The computer system comprises one or more processing units and a memory, coupled to at least one of the one or more processing units. The memory stores instructions that are executed by at least one of the one or more processing units. For purposes of illustration, this computer system may be regarded as a client computer in which a client application is executed directly from a local data store associated with the computer system or that is executed from a remote client application server. In the embodiment, a request associated with a secure in-application transaction is generated through the client application, at a time when the client application is executing. The request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. The request for the secure in-application transaction is submitted over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy. Responsive to this submission, a validated transaction module is received from the first domain. Accordingly, the source URL of the transaction module is identified as the first domain.
  • The client application executes the validated transaction module such that the validated transaction module is loaded into a separate domain-specific security sandbox within the memory of the computer system. The separate domain-specific security sandbox is segregated from memory space in the memory in which the client application is run. The separate domain-specific security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain. The validated transaction module is executed such that the identity of the source URL of the validated transaction module is not altered or destroyed. Moreover, the validated transaction module does not grant the client application the power to introspect the validated transaction module.
  • The validated transaction module, while it is executing in the separate domain-specific security sandbox, issues a transaction call to a second domain. The second domain has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain. A validated transaction is conducted between the second domain and the validated transaction module.
  • The instructions further include instructions that are run concurrently with any or all of the above-identified processes, or after all of the above-identified processes have been run. Such instructions include instructions for determining, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.
  • In some instances, the computer system further comprises a display having a screen real estate. In some such instances, the client application is manifested on a portion of the screen real estate and the validated transaction module is manifested on a subset of the portion of the screen real estate. This advantageously gives the user of the client application the impression that the in-application transaction is a seamless transaction that is being run from within the client application.
  • In some instances, the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. In some instances, the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency. In some instances, the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
  • In some instances, the first domain and the second domain are hosted by the same server that is accessible to the computer system over the Internet or the computer network. In other instances, the first domain and the second domain are each hosted by a separate server and are each accessible to the computer system over the Internet or the computer network.
  • In some instances, the client application is a FLASH application and the validated transaction module is a FLASH SWF application that is loaded by the client application.
  • First Embodiment from a Server Perspective
  • The present disclosure also contemplates the above-identified first embodiment from the perspective of one or more servers that service a client. For instance, one such implementation of this server perspective provides a computer system comprising one or more processing units and a memory, coupled to at least one of the one or more processing units. The memory stores instructions that are executed by at least one of the one or more processing units. The memory comprises a first domain characterized by a first cross-domain policy that is unrestrictive, a second domain characterized by a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain, a database of valid application credentials, a transaction database that is readable from the first domain and the second domain, and an unbranded transaction module.
  • In some instances, the computer system comprises a first computer and a second computer and the above-identified memory comprises memory resident in the first computer and memory resident in the second computer. In such instances, the first cross-domain policy, the database of valid application credentials, and the unbranded transaction module may be resident in the memory of the first computer while the second cross-domain policy may be resident in the memory of the second computer. Further, in such embodiments, access to the transaction database is possible from the first computer and the second computer. In some alternative instances, the computer system is a single computer.
  • The memory comprises instructions for receiving, at the first domain, over the Internet or a computer network, a request from a client application running on a client computer. The request is associated with a secure in-application transaction. The request comprises (i) a credential for the client application, (ii) an identification of a user of the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. The memory comprises instructions for verifying the credential for the client application against the database of valid application credentials. The memory further comprises instructions for keying the request into the transaction database. The memory further comprises instructions for dynamically generating a validated transaction module. In one embodiment, one or more credentials are injected into the unbranded transaction module. Examples of such injection (security) methods are found in, for example, U.S. patent application Ser. No. 12/607,005, entitled “Systems and Methods for Authenticating an Electronic Transaction,” filed Oct. 27, 2009, which is hereby incorporated by reference herein in its entirety. In other embodiments, disclosed herein, other methods are used to obtain parameters from the domain that provides the transaction module and these parameters serve to validate the transaction module.
  • The memory further comprises instructions for providing, from the first domain, the validated transaction module to the client computer. The memory further comprises instructions for receiving, at the second domain, a transaction call that originates from the validated transaction module executing on the client computer, where the source URL of the validated transaction module complies with the second cross-domain policy. The memory further comprises instructions for conducting a validated transaction between the second domain and the validated transaction module running on the client computer. The memory further comprises instructions for storing, at the second domain, a record of the completed transaction in the transaction database.
  • Concurrent to some or all of the above-mentioned processes, or after all of the above-mentioned processes are completed, additional processes are run. These processes include receiving, at the first domain, a query from the client application running on the client computer as to whether the transaction has been completed. The query includes the transaction identifier that uniquely identifies the request. These processes further include determining, at the first domain, by looking up the transaction identifier in the transaction database, whether the transaction has been completed. These processes further include notifying, responsive to the receiving and the determining, the client application running on the client computer of the status of the transaction.
  • In embodiments in which the computer system is divided into a first server and second server, the above-identified processes that are performed at or by the first domain are completed by the first server while the above-identified processes that are performed at or by the second domain are completed by the second server. One of skill in the art will appreciate that the first domain may comprise a first plurality of computers and the second domain may comprises a second plurality of computers. For instance, one server may be a mirror site to another server within a domain. In another example, one server may be a backup server to another server within a domain. In still another example, one domain may comprise a plurality of servers that handle a common load through conventional load balancing techniques. Those of skill in the art will appreciate that the present disclosure fully contemplates all of these different scenarios.
  • Second Embodiment from a Client Perspective
  • One implementation of the second embodiment of the present disclosure, from a client perspective, comprises a computer system comprising one or more processing units and a memory coupled to at least one of the one or more processing units. The memory stores instructions that are executed by at least one of the one or more processing units. The instructions include instructions for executing a client application, where the client application is executed directly from a local data store or is executed from a remote client application server. The instructions include instructions for generating, through the client application, at a time when the client application is executing, a first request associated with a secure in-application transaction. The instructions include instructions for submitting the first request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy. The instructions further include instructions for receiving, responsive to the submitting, a request module, where the source URL of the request module is identified as the first domain.
  • The instructions further include instructions for causing the client application to execute the request module such that the request module is loaded into a first domain-specific security sandbox within the memory. The first domain-specific security sandbox is segregated from memory space in the memory in which the client application is run. The first domain-specific security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain. The request module is executed such that the identity of the source URL of the request module is not altered or destroyed. The request module does not grant the client application the power to introspect the request module.
  • The instructions include instructions for generating, through the request module, at a time when the request application is executing, a second request associated with the secure in-application transaction. The second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the second request, and (iii) optionally, an identification of a user of the client application. The instructions further include instructions for submitting the second request for the secure in-application transaction over the Internet or computer network to a second domain that has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain. The instructions further include instructions for receiving, responsive to the submitting, a transaction module from the second domain in which the source URL of the transaction module is identified as the second domain;
  • The instructions further include instructions for causing the client application to execute the transaction module such that the transaction module is loaded into a second domain-specific security sandbox within said memory. The second domain-specific security sandbox is segregated from memory space in the memory in which the client application is run, the second domain-specific security sandbox is associated with, and limited to, programs that identify their source URL as being the second domain. The transaction module is executed by the causing such that the identity of the source URL of the transaction module is not altered or destroyed. The transaction module does not grant the client application the power to introspect the validated transaction module;
  • The instructions further include instructions for issuing, from the transaction module while it is executing in the second domain-specific security sandbox, a transaction call to a third domain. The third domain has a cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain. The instructions include instructions for conducting a validated transaction between the third domain and the transaction module.
  • The instructions further include instructions that are run concurrently with any or all of the above-identified processes, or after all of the above-identified processes have been run. Such instructions include instructions for determining, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.
  • In some instances, the computer system further comprises a display having a screen real estate, where, upon execution of the client application, the client application is manifested on a portion of the screen real estate. In such instances, the validated transaction module is manifested on a subset of the portion of the screen real estate.
  • In some instances, the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. In some instances, the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency. In some instances, the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
  • In some instances, the first, second and third domain are each hosted by the same server that is accessible to the computer system over the Internet or the computer network. In some instances, the first, second, and third domain are each hosted by a separate server and are each accessible to the computer system over the Internet or the computer network. In some instances, the client application is a FLASH application and the validated transaction module is a FLASH SWF application that is loaded by the client application.
  • Second Embodiment from a Server Perspective
  • The present disclosure also contemplates the above-identified second embodiment from the perspective of one or more servers that service a client. For instance, one such implementation of this server perspective provides a computer system for facilitating a secure transaction. The computer system comprises one or more processing units and a memory, coupled to at least one of the one or more processing units. The memory stores instructions that are executed by at least one of the one or more processing units.
  • The memory comprises a first domain characterized by a first cross-domain policy that is unrestrictive, a second domain characterized by a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain, and a third domain characterized by a third cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain. The memory further comprises a database of valid application credentials, a transaction database that is readable from the first domain, second and third domain, an unbranded transaction module, and a request module.
  • In some instances, the computer system comprises a first, second, and third computer and the above-identified memory comprises memory resident in the first computer, memory resident in the second computer, and memory resident in the third computer. In such instances, the first cross-domain policy and the request module may be resident in the memory of the first computer. The second cross-domain policy, the database of valid application credentials, and the unbranded transaction module may be resident in the memory of the second computer. The third cross-domain policy may be resident in the memory of the second computer. Further, in such embodiments, access to the transaction database is possible from the first computer, the second computer, and the third computer. In some alternative instances, the computer system is a single computer.
  • The memory comprises instructions for receiving, at the first domain, over the Internet or a computer network, a first request from a client application running on a client computer, where the first request is associated with a secure in-application transaction. The memory further comprises instructions for providing, from the first domain, the request module to the client computer. The memory comprises instructions for receiving, at the second domain, over the Internet or the computer network, a second request from the request module running on the client computer, where the second request is associated with the secure in-application transaction and where the second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. In such instances, the source URL of the request module complies with the second cross-domain policy.
  • The memory further comprises instructions for verifying the credential for the client application against the database of valid application credentials. The memory further comprises instructions for keying the second request into the transaction database. The memory further comprises instructions for dynamically generating a validated transaction module. For instance, in some embodiments, the validated transaction is generated by injecting one or more credentials into the unbranded transaction module. Examples of such injection (security) methods are found in, for example, U.S. patent application Ser. No. 12/607,005, entitled “Systems and Methods for Authenticating an Electronic Transaction,” filed Oct. 27, 2009, which is hereby incorporated by reference herein in its entirety. In other embodiments, disclosed herein, other methods are used to obtain parameters from the domain that provides the transaction module and these parameters serve to validate the transaction module. The memory further comprises instructions for providing, from the second domain, the validated transaction module to the client computer. The memory further comprises instructions for receiving, at the third domain, a transaction call that originates from the validated transaction module executing on the client computer, where the source URL of the validated transaction module complies with the third cross-domain policy. The memory further comprises instructions for conducting a validated transaction between the third domain and the validated transaction module running on the client computer. The memory further comprises instructions for storing, at the third domain, a record of the completed transaction in the transaction database.
  • Concurrent to some or all of the above-mentioned processes, or after all of the above-mentioned processes are completed, additional processes are run. These processes include receiving, at the first domain, a query from the client application running on the client computer as to whether the transaction has been completed. The query includes the transaction identifier that uniquely identifies the request. These processes further include determining, at the first domain, by looking up the transaction identifier in the transaction database, whether the transaction has been completed. These processes further include notifying, responsive to the receiving and the determining, the client application running on the client computer of the status of the transaction.
  • In some instances, the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. In some instances, the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency. In some instances, the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
  • In some instances, the first, second and third domain are hosted by the same server that is accessible to the client computer over the Internet or the computer network.
  • In some instances, the first domain is hosted by a first server, the second domain is hosted by a second server, and the third domain is hosted by a third server. The first, second and third server are each accessible to the client computer over the Internet or the computer network. In some such instances, the above-identified memory comprises a first memory resident in the first server, a second memory resident in the second server, and a third memory resident in the third server. In some such instances, the first cross-domain policy and the request module are resident in the first memory of the first server. In some such instances, the second cross-domain policy, the database of valid application credentials, and the unbranded transaction module are resident in the second memory of the second server. In some such instances, the third cross-domain policy is resident in the memory of the third server.
  • In some embodiments, the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application.
  • In embodiments in which the computer system is divided into a first, second, and third server, the above-identified processes that are performed at or by the first domain are completed by the first server, the above-identified processes that are performed at or by the second domain are completed by the second server, and the above-identified processes that are performed at or by the third domain are completed by the third server. One of skill in the art will appreciate that the first domain may comprise a first plurality of computers, the second domain may comprises a second plurality of computers, and the third domain may comprises a third plurality of computers. For instance, one server may be a mirror site to another server within a domain. In another example, one server may be a backup server to another server within a domain. In still another example, one domain may comprise a plurality of servers that handle a common load through conventional load balancing techniques. Those of skill in the art will appreciate that the present disclosure fully contemplates all of these different scenarios.
  • 4. BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates a system in accordance with a first embodiment of the present disclosure.
  • FIGS. 2A and 2B illustrate a method in accordance with the first embodiment of the present disclosure.
  • FIGS. 3A and 3B illustrate a system in accordance with a second embodiment of the present disclosure.
  • FIGS. 4A and 4B illustrate a method in accordance with the second embodiment of the present disclosure.
  • Like reference numerals refer to corresponding parts throughout the several views of the drawings.
  • 5. DETAILED DESCRIPTION
  • The present disclosure details novel advances over known systems and methods for authenticating an electronic transaction that is communicated by application that is potentially not secure. The present disclosure makes use of server cross-domain policies as well as domain-specific security sandboxes. There are two embodiments disclosed. In the first embodiment, illustrated in FIGS. 1 and 2, a client application 34 makes a request for a transaction module 38 from a first domain 180 that has an unrestrictive cross-domain policy 138. Once the client application 34 receives the transaction module 38, it is executed in its own domain-specific security sandbox such that the source URL of the transaction module, the URL of the first domain 180, is preserved. The transaction module 38 completes the transaction by interacting with a second domain 200 that has a cross-domain policy 236 that restricts interaction to those programs and processes whose source URL is the first domain 180.
  • The second embodiment, illustrated in FIGS. 3 and 4, takes the process a step further. In the second embodiment, responsive to a need to make an in-application secure transaction, a client application 34B makes a first request that is associated with an in-application secure transaction. The first request is sent over the Internet or a computer network 302 to a first domain 300 (FIG. 3B) that has an unrestrictive cross-domain policy 336. Responsive to this request, the first domain 300 sends the client application 34B a request module 36. Once the client application 34B receives the request module 36, the request module 36 is executed in its own domain-specific security sandbox (first sandbox) such that the source URL of the request module 36, the URL of the first domain 300, is preserved. The request module 36, operating in the first sandbox, makes a request for a transaction module 38 from a second domain 180B that has a cross-domain policy 138B that restricts interaction to those programs and processes whose source URL is the first domain 300.
  • In some embodiments, upon receipt of the request for the transaction module from the client application 34B, the second domain 180B injects security information into an unbranded version of the transaction module 136, thereby forming secure transaction module 38, and sends the client application 34B the secure transaction module 38. Once the client application 34B receives the secure transaction module 38, the transaction module 38 is executed in its own domain-specific security sandbox (second sandbox) such that the source URL of the secure transaction module 38, the URL of the second domain 180, is preserved. The transaction module 38 completes the transaction by interacting with a third domain 200 that has a cross-domain policy 236 that restricts interaction to those programs and processes whose source URL is the second domain 180.
  • In some embodiments, the second domain 180B provides an unbranded version of transaction module 136 without modifying the content of the transaction module 136. In other words, in some embodiments, credentials are not necessarily injected into an unbranded version of the transaction module 136 to thereby form secure transaction module 38. In such embodiments, once the request module 36 receives the unbranded transaction module 136, it is able to validate the transaction module 136 with parameters provided by the second domain 180B. In this way, the request module 36 is able to validate the transaction module 136 (thereby allowing the transaction module 136 to be deemed transaction module 38 without injecting parameters into transaction module 136). Then, the transaction module 38 is executed in its own domain-specific security sandbox (second sandbox) such that the source URL of the secure transaction module 38, the URL of the second domain 180B, is preserved. The transaction module 38 completes the transaction by interacting with a third domain 200 that has a cross-domain policy 236 that restricts interaction to those programs and processes whose source URL is the second domain 180B.
  • By exploiting cross-domain policies and the natural ability to run programs in their own domain-specific security sandboxes without the power for calling applications to introspect, the present disclosure provides highly secure systems, methods, and computer readable media for facilitating a secure in-application transaction.
  • Now that an overview of the novel systems and methods for conducting secure in-application transactions have been disclosed, a more detailed description of a system in accordance with the first embodiment of the present disclosure is described in conjunction with FIG. 1. As such, FIG. 1 illustrates the topology of an environment in accordance with the present disclosure.
  • In the topology, there is a secure interface server 180, a client device 100, and a transaction server 200. Of course, other topologies are possible, for instance, the secure interface server 180 can in fact comprise several servers. Moreover, typically, there are hundreds, thousands, hundreds of thousands of client devices 100 or more. The exemplary topology shown in FIG. 1 merely serves to describe the features of the first embodiment of the present disclosure in a manner that will be readily understood to one of skill in the art.
  • The secure interface server 180 will typically have one or more processing units (CPU's) 102, a network or other communications interface 110, a memory 114, one or more magnetic disk storage and/or persistent devices 120 optionally accessed by one or more controllers 118, one or more communication busses 112 for interconnecting the aforementioned components, and a power supply 124 for powering the aforementioned components. Data in memory 114 can be seamlessly shared with non-volatile memory 120 using known computing techniques such as caching Memory 114 and/or memory 120 can include mass storage that is remotely located with respect to the central processing unit(s) 102. In other words, some data stored in memory 114 and/or memory 120 may in fact be hosted on computers that are external to the secure interface server 180 but that can be electronically accessed by the secure interface server 180 over an Internet, intranet, or other form of network or electronic cable (illustrated as element 126 in FIG. 1) using network interface 110.
  • Memory 114 preferably stores:
      • an operating system 130 that includes procedures for handling various basic system services and for performing hardware dependent tasks;
      • a network communications module 132 that is used for connecting the secure interface server 180 to various client computers such as client devices 100 (FIG. 1) and possibly to other servers or computers (such as the transaction server 200) via one or more communication networks, such as the Internet, other wide area networks, local area networks (e.g., a local wireless network can connect the client devices 100 to the secure interface server 180), metropolitan area networks, and so on;
      • a transaction module serving application 134 for receiving requests from client computers;
      • an unbranded transaction module 136 for distribution, upon user request, to a client device 100;
      • a cross-domain policy 138 that specifies which computers/domains that the secure interface server 180 may interact with;
      • a transaction database 140/240 for storing a record of secure in-application transactions; and
      • a database of valid application credentials 142.
  • The secure interface server 180 is connected via Internet/network 126 to one or more client devices 100. FIG. 1 illustrates the connection to only one such the client device 100. It is possible for the client device 100 to be a personal computer (e.g., desktop or laptop computer) or any form of mobile computing device (e.g., an I-phone, Blackberry, and the like).
  • In typical embodiments, a client device 100 comprises:
      • one or more processing units (CPU's) 2;
      • a network or other communications interface 10;
      • a memory 14;
      • optionally, one or more magnetic disk storage and/or persistent storage devices 20 accessed by one or more optional controllers 18;
      • a user interface 4, the user interface 4 including a display 6 and a keyboard or keypad 8;
      • one or more communication busses 12 for interconnecting the aforementioned components; and
      • a power supply 24 for powering the aforementioned components, which power supply can be, for example, batteries.
  • In some embodiments, data in memory 14 can be seamlessly shared with optional non-volatile memory 20 using known computing techniques such as caching. In some embodiments the client device 100 does not have a magnetic disk storage device. For instance, in some embodiments, the client device 100 is a portable handheld computing device and the network interface 10 communicates with the Internet/network 126 by wireless means.
  • The memory 14 preferably stores:
      • an operating system 30 that includes procedures for handling various basic system services and for performing hardware dependent tasks;
      • a network communication module 32 that is used for connecting client device 100 to other computers such as the secure interface server 180 and the transaction server 200, in some embodiments the network communication module 32 includes an optional web browser, such as Microsoft Internet Explorer versions 6.0 or later, Firefox 2.x, Firefox 3.x, AOL 9, Opera 9.5 or later, Safari 3.x, Chrome 2.0 or higher, and, in some embodiments, the optional web browser includes a module such as a FLASH player; a client application 36 that can request an in-application transaction and that can verify that the in-application transaction was completed;
      • a request module 36 for initiating an in-application transaction; and
      • a transaction module 38 for conducting an in-application transaction.
  • The transaction server 200 will typically have one or more processing units (CPU's) 202, a network or other communications interface 210, a memory 214, one or more magnetic disk storage and/or nonvolatile devices 220 optionally accessed by one or more optional controllers 218, one or more communication busses 212 for interconnecting the aforementioned components, and a power supply 224 for powering the aforementioned components. Data in memory 214 can be seamlessly shared with non-volatile memory 220 using known computing techniques such as caching Memory 214 and/or memory 220 can include mass storage that is remotely located with respect to the central processing unit(s) 202. In other words, some data stored in memory 214 and/or memory 220 may in fact be hosted on computers that are external to the transaction server 200 but that can be electronically accessed by the transaction server 200 over an Internet, intranet, or other form of network or electronic cable (illustrated as element 126 in FIG. 1) using network interface 210.
  • The memory 214 preferably stores:
      • an operating system 230 that includes procedures for handling various basic system services and for performing hardware dependent tasks;
      • a network communications module 232 that is used for connecting the transaction server 200 to various client computers such as client devices 100 (FIG. 1) and possibly to other servers or computers (such as the secure interface server 180) via one or more communication networks, such as the Internet, other wide area networks, local area networks (e.g., a local wireless network can connect the client devices 100 to the secure interface server 180), metropolitan area networks, and so on;
      • transaction module 234 for verifying the validity of a request from a transaction module 38 operating on a client device 100;
      • a cross-domain policy 236 that specifies which computers/domains that the transaction server 200 may interact with;
      • an application programming interface “API” 238 for performing an in-application transaction with a transaction module 38 running on a client device 100; and
      • a transaction database 140/240 for storing a status of a secure in-application transaction.
  • Referring to FIG. 2, an exemplary method in accordance with a first embodiment of the present disclosure is described. The method details the steps taken by a secure interface server 180, a client device 100, and a transaction server 200 to interactively service a transaction in accordance with the present disclosure.
  • Step 202.
  • In step 202, a client device 100 runs a client application 34 from a local data store (e.g., memory 14 or memory 20 of FIG. 1) or obtains and runs the client application 34 from a remote application server (not shown) over the Internet or computer network. In some instances, the client application 34 is a social networking application (e.g., FACEBOOK, MYSPACE), a financial services application, an accounting application, or a tax preparation application.
  • Step 204.
  • At some point while the client application 34 is running on the client device 100, the client application 34 invokes request module 36 to make a request for a secure in-application transaction. In some instances, the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of a user of the client application. Examples of in-game upgrades include, but are not limited to, a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.
  • Typically, the secure in-application request includes an application credential, information identifying a client application 34 user, and a unique transaction identifier. The application credential is a credential associated with the client application 34 that identifies the application developer. For instance, in some embodiments, the client application 34 is a game application and the application credential identifies the game application developer. The application credential can be used to determine who to credit an in-application transaction. For example, if the in-application transaction involves payment of funds by a user of the client application 34, the application credential is used to identify who is to be credited these funds. In general, the application credential is used to identify a first party to the in-application transaction. Similarly, information identifying the client application 34 user can be used to determine the second party to the in-application transaction. For example, typically, the second party is the user of the client application 34 who wishes to perform a secure in-application transaction mandated by the client application 34 in order to further a goal (e.g., an additional game level, more user features, etc.) that is made possible if the in-application transaction is completed. The unique transaction identifier is used to track the status of the in-application transaction. In typical embodiments, the format of the application credential, information identifying a client application 34 user, and a unique transaction identifier is predetermined in accordance with the requirements of the secure interface server 180 and/or the transaction server 200. For instance, the application credential may be a serial number provided to the application developer for use in all in-application transaction. Furthermore, the information identifying a client application 34 user may be registration information uniquely associated with the user that was created when the user created an account with the application developer and/or when the user created an account with the secure interface server 180 or the transaction server 200 and/or when the application developer registered the user with the secure interface server 180 or the transaction server 200. Regardless of implementation, the information identifying a client application 34 user uniquely identifies a user to the secure interface server 180 and/or the transaction server 200. Similarly, in preferred embodiments, the unique transaction identifier uniquely identifies a single in-application transaction conducted by a user of the client application 34.
  • Thus, in summary, upon completion of step 204, there is generated, through the client application 34 and the associated request module 36, at a time when the client application 34 is executing on the client device 100, a request associated with a secure in-application transaction, where the request comprises (i) a credential for the client application, (ii) an identification of a user of the client application, and (iii) a transaction identifier that uniquely identifies the request. The request for the secure in-application transaction is submitted over the Internet or a computer network to the secure interface server 180 (first domain) which has an unrestrictive first cross-domain policy 138.
  • Step 206.
  • In step 206, the request for the secure in-application transaction is received over the Internet or computer network by transaction module serving application 134, running on the secure interface server 180, with information identifying the application user, a unique transaction identifier, and the application credential. In some embodiments, the request received at step 206 does not include the identity of the user. In such embodiments, the identity of the user is only communicated by transaction module 38 to transaction server module 234 of the transaction server 200.
  • Step 208.
  • In step 208, the application credential for the client application 34 is verified against a database of valid application credentials 142. In some embodiments, the database of valid application credentials 142 comprises an identification of each legitimate application developer that may use the secure interface server 180 and the transaction server 200 to conduct secure transactions.
  • Step 210.
  • If the application credential provided with the application request received in step 206 is not verified 210—No, meaning that the application credential is not present in the database of valid application credentials 142 or the database indicates that the credential is invalid or inactivated, then the transaction ends 212. In some embodiments, not shown, the client application 34 is notified of this failure. In some embodiments, not shown, the application developer is notified of this failure. If the application credential provided with the application request received in step 206 is verified 210—Yes, meaning that the application credential is present in the database of valid application credentials 142, process control passes on to step 214.
  • Step 214.
  • In step 214, the request is keyed into the transaction database 140/240. In some embodiments, this involves adding a unique entry into the transaction database 140/240 for the disclosed single transaction. In some embodiments in which the request includes an identity of the user of the client application 34, the transaction entry is added to an account associated with this user. The transaction is not performed in step 214. For example, no sum of money is credited or debited to the user identified in the transaction during step 214. Such debiting or crediting, if it is to occur at all, occurs at later stages in the disclosed method. Transaction database 140/240 is accessible by both the secure interface server 180 and the transaction server 200. In some embodiments, the secure interface server 180 and the transaction server 200 are different servers. In some embodiments the secure interface server 180 and the transaction server 200 is the same server with separate cross-domain policies and domains.
  • Step 216.
  • In step 216, the transaction module serving application 134 dynamically brands the unbranded transaction module (e.g., in SWF file format) 136 with sufficient information to establish the validity of the transaction module for the requested transaction and sends the branded transaction module to client device 100 as transaction module 38. In some embodiments, this is accomplished by having the transaction module serving application 134 dynamically generate a validated transaction module 38 by injecting one or more credentials into the unbranded transaction module 136. Examples of such injection (security) methods are found in, for example, U.S. patent application Ser. No. 12/607,005, entitled “Systems and Methods for Authenticating an Electronic Transaction,” filed Oct. 27, 2009, which is hereby incorporated by reference herein in its entirety.
  • In some embodiments, the second domain 180 provides a secure transaction module 38 to the request module 36 and/or client application 34 on client device 100 without modifying the content of the unbranded transaction module 136. In some such embodiments, the request for the transaction module that is sent to the secure interface server 180 from the client device 100 is serviced by providing an unbranded transaction module 136 along with parameters, external to the unbranded transaction module 136, that serve to validate the transaction module. The request module 36 is able to validate the transaction module 136 (thereby allowing the transaction module 136 to be deemed transaction module 38 without injecting parameters into transaction module 136). In some embodiments, a credential that is either injected into the transaction module 38 or that is provided as one or more parameters external to the transaction module is a user identifier key. In some embodiments, the application user identifier key is provided with the request received in step 206 originating from the client device 100. In some embodiments, the application user identifier key is associated with an account that the user has with the application developer and this account is serviced by the secure interface server 180 and the transaction server 200. In some embodiments, the application user identifier key is provided by a third party, such as FACEBOOK or MYSPACE.
  • In some embodiments, a credential that is injected into the transaction module 38 or that is provided as one or more parameters external to the transaction module is a salting value 146 based on a reference time. In some embodiments, this salting value is a Coordinated Universal Time (UTC) associated with request. For example, the salting value 146 may be UTC at a time during (e.g., at the beginning of, at the end of, at a time during) the exercise of step 202, step 204, step 206, step 208, step 210, step 214, or step 216 or some other predetermined function of the time when the request was either originated by client device 100 or received by the secure interface server 180. UTC is a time standard based on International Atomic Time (TAI) with leap seconds added at irregular intervals to compensate for the Earth's slowing rotation. Leap seconds are used to allow UTC to closely track UT1, which is mean solar time at the Royal Observatory, Greenwich. In some embodiments, the salting value 146 is the integer divide of UTC and some time increment, such as one hour, eight hours, twelve hours, or the like.
  • In some embodiments, a credential that is injected into the transaction module 38 or that is provided as one or more parameters external to the transaction module is a secret key that is shared by the secure interface server 180 and the transaction server 200. A feature of the secret key 148 is that it is not communicated across Internet/network 126 and only the application developer, the host of the transaction server 200, and the host of the secure interface server 180 know its identity. See, for example, Section 2.4 of Kaufman, Network Security, Prentice-Hall, Inc., Upper Saddle River, N.J., which is hereby incorporated by reference.
  • In some embodiments, a credential that is injected into the transaction module 38 or that is provided as one or more parameters external to the transaction module is the application user identifier provided with the request received in step 206. In some embodiments, any combination of the foregoing credentials is injected into the transaction module 38 prior to sending it to the client application 34 or that is provided as one or more parameters external to the transaction module. In some embodiments, any combination of the foregoing credentials are used to a generate the temporary signing key. For example, in some embodiments these credential are truncated together, or otherwise combined, and then one-way hashed to generate a signing key that is injected into the transaction module 38 rather than, or in addition to, injecting the foregoing credentials and/or providing them external to the transaction module. In some embodiments, other credentials, in addition to, or instead of the foregoing, are injected into the transaction module 38.
  • Step 218.
  • In step 218, the client application 34 executes the transaction module 38 in a separate domain-specific security sandbox associated with, and limited to, programs identifying the secure interface server 180 as their source URL. For example, in some embodiments, the client application 34 is a FLASH program and the transaction module 38 is in the form of a SWF file that is loaded and executed by the client application 34 during step 218. In such embodiments, the client application 34 interrogates the transaction module 38 to determine its source URL. In this instance, the source URL of transaction module 38 is the URL of the secure interface server 180. Thus, the client application 34 loads and executes the transaction module 38 in a domain-specific security sandbox that is dedicated to programs from the domain of secure interface server 180. In other words, during step 218, the client application 34 executes the validated transaction module 38 such that the validated transaction module is loaded into a separate domain-specific security sandbox within memory, where (i) the separate domain-specific security sandbox is segregated from memory space in said memory in which the client application is run, (ii) the separate domain-specific security sandbox is associated with, and limited to, programs that identify their source URL as being the domain of the secure interface server 180, (iii) the validated transaction module 38 is executed by the client application 34 such that the identity of the source URL of the validated transaction module 38 is not altered or destroyed, and (iv) the validated transaction module 38 does not grant the client application 34 the power to introspect the validated transaction module 38. Thus, advantageously, transaction module 38 is able to run in a secure manner on client device 100 even though it was loaded by client application 34. The client application 34 cannot introspect the transaction module 38. In other words, the client application 34 cannot read any values stored by the transaction module 38. This is highly advantageous because the user of the client application can enter sensitive information into the transaction module 38 without any risk of having the client application 34 obtain such sensitive information.
  • Step 220.
  • In step 220, transaction module 38 issues a transaction call while the module 38 is executing in the separate domain-specific security sandbox. The transaction call is issued to a second domain, that of the transaction server 200. The transaction server 200 has a second cross-domain policy 236 that limits interaction between the transaction server 200 and programs external to the transaction server 200 (second domain) to those external programs whose source URL is that of the secure interface server 180 (first domain).
  • Steps 222 and 224.
  • In step 222, a determination is made as to whether the calling transaction module 38 names the secure interface server 180 as its source URL. As described above in step 220, this is a necessary condition for interacting with the transaction server 200 because the cross-domain policy 236 of the transaction server 200 limits external interaction to only those programs whose source URL is that of the secure interface server 180. Because transaction module 38 was served by the secure interface server 180 to the client device 100, and loaded by the client application 34 in such a manner that the source URL of the transaction module 38 was preserved, the transaction module 38 should satisfy condition 222 (222—Yes) and thus process control should move to step 226. If the client application 34 attempted to load transaction module 38 in such a manner that the source URL of the transaction module 38 was not preserved (e.g., by using FLASH a loadBytes call) then, condition 222 will not be satisfied (222—No) and process control will pass to step 224 where the transaction will fail. In such instances, the record of the transaction will be removed from the transaction database 140/240.
  • Step 226. If process control reaches step 226, the transaction server module 234 operating on the transaction server 200 permits API 238 to interact with the transaction module 38 in order to perform the requested transaction. In some embodiments, additional security measures are taken before the transaction commences. Examples of such security measures are disclosed in U.S. patent application Ser. No. 12/607,005, entitled “Systems and Methods for Authenticating an Electronic Transaction,” filed Oct. 27, 2009, which is hereby incorporated by reference herein in its entirety. See, for example, steps 214 through 218 disclosed in U.S. patent application Ser. No. 12/607,005.
  • Step 228.
  • In step 228, a user conducts the transaction using transaction module 38 and API 238. During this transaction, the user may enter financial information or other forms of information such as credit card information, debit card information, ATM information (e.g., personal identification number), PAYPAL account information, automatic clearing house (ACH) transfer information, banking information, billing address information, mailing address information, personal information (e.g., social security number, date of birth, answers to personal questions, etc.), coupon information, rebate information, membership information, subscription information, login information, password information, security tokens (e.g., RSA challenge numbers) and the like. Advantageously, because transaction module 38 is operating in its own domain-specific security sandbox on the client device 100, the client application 34 and request module 36 cannot obtain the information entered by the user in step 228.
  • Step 230.
  • The information entered by the user in step 228 is processed by API 238 to thereby credit or debit the user. It will be appreciated that steps 228 and 230 may be repeated a number of times in order to complete the transaction. For example, API 238 may issue one or more challenges or requests from the user. The user, using transaction module 38, enters this information. If the user enters the correct challenge information, API 238 proceeds to later stages of the transaction by requesting more information from the user. Further, the status of the transaction is stored in transaction database 140/240 using the unique transaction identifier assigned to the transaction. It is to be noted that, in typical embodiments, both the transaction server 200 and the secure interface server 180 have access to transaction database 140/240. The secure interface server 180 creates an entry for the transaction in step 214 using the unique transaction identifier assigned to the transaction while the transaction server 200 records the status of the transaction (e.g., completed, failed, amount credited, amount debited etc.) during step 230.
  • Steps 232-234.
  • In preferred embodiments, the instance of API 238 is used for a single transaction. Thus, in such preferred embodiments, the instance of API 238 that was used to facilitate the transaction terminates. In other embodiments, API 238 is persistent across multiple transactions. Regardless of which form of embodiment is used, transaction server module 234 ceases deeming the instance of the transaction module 38 that it was interacting with in steps 226 and 230 as valid. This advantageously enhances the security of the discloses systems and methods since, in a worse case scenario, the transaction module 38 can only be used with a single user for a single, unique transaction. In step 234, the transaction module 38 is terminated.
  • Steps 236-242.
  • As noted above, the transaction module 38 operates in its own domain-specific security sandbox on the client device 100 and the transaction module 38 does not grant the client application 34 the power to introspect. Therefore, the client application 34 does not ascertain directly from the transaction module 38 whether the in-application transaction was completed, much less whether the in-application transaction was successfully completed such that the user is to be granted whatever privilege was associated with the in-application transaction (e.g., more game points, etc.). Therefore, concurrently with some or all of the aforementioned steps, or after all of the aforementioned steps have been completed, the client application 34 polls the transaction database 140/204 using the secure interface server 180 to determine the status of the transaction. It is to be appreciated that, while both the secure interface server 180 and the transaction server 200 have access to the transaction database 140/240, the secure interface server 180 has a permissive cross-domain policy 138 while the transaction server 200 has a restrictive cross-domain policy 236. Thus, unless the source URL of the client application 34 is the URL of the secure interface server 180, the client application 34 will be unable to interact directly with the transaction server 200. Thus, the client application 34 would be unable to poll the transaction database 140/240 using the transaction server 200.
  • In typical embodiments, the client application 34 polls the transaction database 140/240 on the secure interface server 180 on a periodic basis (e.g., every minute, every five minutes, every half hour, etc.) until the transaction database 140/240 indicates that the transaction is completed. In typical embodiments, this query is very limited. In typical embodiments, the client application 34 provides the unique transaction identifier and the application credential. If the application credential is valid against the database of valid application credentials 142, the status of the transaction uniquely associated with the transaction identifier provided by the client application 34 is sent back to the client application 34 running on the client over the Internet or computer network. In typical embodiments, the client application 34 is not permitted to obtain personal information from the transaction database 140/240.
  • Now that the details of the processing steps associated with an instance of the first embodiment have been disclosed, the advantages of the present application may be emphasized. A secure transaction may be performed using a client application in which the client application cannot gain knowledge of secure information needed to conduct the transaction. Nevertheless, using a unique transaction identifier for the transaction, the client application can determine whether the transaction was successful. Thus, using the disclosed system, the client application can support in-application transactions in a secure manner without having to set up the disclosed secure platform (e.g., secure internet server 180 and the transaction server 200). For example, the secure platform can be run by a separate entity. This reduces the costs for developing the client application.
  • In-Transaction User Interface.
  • In some embodiments, the look and feel of the in-application transaction is enhanced by creating the appearance that the transaction module 38 is controlled by the client application 34. In some embodiments, this is done through an application programming interface associated with the request module 36. The client application 34 uses the application programming interface to allocate a portion of the screen real estate being used by the client application 34 to open up the transaction module 38. In one example, the transaction module 38 is a 300 by 400 pixel interface and the client application 34, when making the transaction request, specifies the coordinates on the screen where this 300 by 400 pixel interface may open. Thus, advantageously, in such embodiments, even though the transaction module 38 is running in its own domain-specific security sandbox, the client application 34 and the transaction module 38 appear to be the same application. In some embodiments, the API interface associated with the request module 36 further includes parameters for specifying the fonts and colors used in the transaction module 38. Such parameters further the appearance that the client application and the transaction module 38 are the same application. In typical embodiments, client application 34 runs in its own window and all pixel coordinates provided to the transaction module 38 through the API of request module 36 are in reference to this window.
  • Secure Interface Server 180/Transaction Server 200.
  • In typical embodiments, as depicted in FIG. 1, the secure interface server 180 and the transaction server 200 are each a separate physical server. In some alternative embodiments, the secure interface server 180 and the transaction server 200 are hosted by the same physical server. In such embodiments, this physical server is accessible to the client device 100 over the Internet or a computer network 126.
  • Second Embodiment
  • A second embodiment of the present disclosure is illustrated in FIGS. 3 and 4. In more detail, a system in accordance with the second embodiment of the present disclosure is described in conjunction with FIG. 3. As such, FIG. 3 illustrates the topology of an environment in accordance with the present disclosure. In the topology, there is a secure interface server 180B, a client device 100B, a transaction server 200, and a request module server 300. Of course, other topologies are possible, for instance, the secure interface server 180B can in fact comprise several servers. Moreover, typically, there are hundreds, thousands, hundreds of thousands of client devices 100B or more. The exemplary topology shown in FIG. 3 merely serves to describe the features of the second embodiment of the present disclosure in a manner that will be readily understood to one of skill in the art.
  • The client device 100B of FIG. 3A, and each of the modules hosted by the client device 100B are identical to their like-named counterparts in the client device 100 of FIG. 1A with the exception that, at the time the client application 34B of the client device 100B is invoked by the client device 100B, the client application 34B does not include the entirety of the request module 36.
  • The transaction server 200 of FIG. 3A, and each of the modules hosted by the transaction server 200 of FIG. 3A, are identical to their like-named counterparts in the transaction server 200 of FIG. 1A.
  • The secure interface server 180B of FIG. 3B, and each of the modules hosted by the secure interface server 180B are identical to their like-named counterparts in the secure interface server 180 of FIG. 1A with the exception that the cross-domain policy 138B of the secure interface server 180B (FIG. 3B) restricts interaction between the secure interface server 180B and those programs whose source URL is the domain of the request module server 300.
  • As illustrated in FIG. 3B, request module server 300 will typically have one or more processing units (CPU's) 302, a network or other communications interface 310, a memory 314, one or more magnetic disk storage and/or persistent devices 320 optionally accessed by one or more controllers 318, one or more communication busses 312 for interconnecting the aforementioned components, and a power supply 324 for powering the aforementioned components. Data in memory 314 can be seamlessly shared with non-volatile memory 320 using known computing techniques such as caching Memory 314 and/or memory 320 can include mass storage that is remotely located with respect to the central processing unit(s) 302. In other words, some data stored in memory 314 and/or memory 320 may in fact be hosted on computers that are external to the request module server 300 but that can be electronically accessed by the request module server 300 over an Internet, intranet, or other form of network or electronic cable (illustrated as element 126 in FIG. 3B) using network interface 310.
  • Memory 314 preferably stores:
      • an operating system 330 that includes procedures for handling various basic system services and for performing hardware dependent tasks;
      • a network communications module 332 that is used for connecting the request module server 300 to various client computers such as the client devices 100 (FIG. 3A) and possibly to other servers or computers (such as the transaction server 200 and the secure interface server 180) via one or more communication networks, such as the Internet, other wide area networks, local area networks (e.g., a local wireless network can connect the client device 100 to the request module server 300), metropolitan area networks, and so on;
      • a transaction request module serving application 334 for receiving requests from client device 100 and provided a request module 36 in response thereto;
      • a cross-domain policy 336 that specifies which computers/domains that the request module server 300 may interact with;
      • a transaction database 140/240 for storing a record of secure in-application transactions; and
      • a database of valid application credentials 142.
  • Referring to FIG. 4, an exemplary method in accordance with the second embodiment of the present disclosure is described. The method details the steps taken by a secure interface server 180B, a client device 100, a transaction server 200, and a request module server 300 to interactively service a transaction in accordance with the second embodiment of the present disclosure.
  • Steps 402-406.
  • The method disclosed in FIG. 4 (embodiment 2) takes the method of FIG. 2 (embodiment 1) a step further by requiring that the client application 34B obtain the request module 36 from request module server 300 when the client application 34B is invoked. In the embodiment disclosed in FIG. 1, the client application 34B already had a copy of this request module 36. In some embodiments in which client application 34/34B is a FLASH application, the request module 36 is a compiled SWC file in embodiment 1 (FIG. 1) whereas in embodiment 2, the request module 36 is a SWF file.
  • In step 402, client device 100B invokes the client application 34B from local data store or from a remote application server. At the time client application 34B is invoked, the client application 34B does not include a request module 36 for facilitating in-application secure transactions. In step 404, the client application 34B initiates a transaction by asking for request module 36 from request module server 300. In step 406, responsive to the request of step 404, transaction request module serving application 334 processes the request and sends request module 36 to client device 100. In some embodiments of step 406, transaction request module serving application 334 only provides the request module 36 to the client application 34B if the client application 34B provides an application credential that the transaction request module serving application 334 verifies against the database of valid application credentials 142.
  • Step 408.
  • In step 408, the client application 34B executes the request module 36 in a separate domain-specific security sandbox (first sandbox) associated with, and limited to, programs identifying the request module server 300 as their source URL. For example, in some embodiments, the client application 34B is a FLASH program and the request module 36 is in the form of a SWF file that is loaded and executed by the client application 34B during step 408. In such embodiments, the client application 34B interrogates the request module 36 to determine its source URL. In this instance, the source URL of the request module 36 is the URL of the request module server 300. Thus, the client application 34B loads and executes the request module 36 in a domain-specific security sandbox that is dedicated to programs from the domain of the request module server 300. In other words, during step 408, the client application 34B executes the request module 36 such that the request module 36 is loaded into a separate domain-specific security sandbox within memory, where (i) the separate domain-specific security sandbox is segregated from memory space in the memory in which the client application 34B is run, (ii) the separate domain-specific security sandbox is associated with, and limited to, programs that identify their source URL as being the domain of the request module server 300, (iii) the request module 36 is executed by the client application 34B such that the identity of the source URL of the request module 36 is not altered or destroyed, and (iv) the request module does not grant the client application 34B the power to introspect the request module 36. Thus, advantageously, the request module 36 is able to run in a secure manner on the client device 100B even though it was loaded by the client application 34B. The client application 34B cannot introspect the request module 36. In other words, the client application 34B cannot read any values stored by the request module 36.
  • Step 410.
  • At some point while the client application 34B is running on the client device 100B, the client application 34B invokes request module 36 to make a request for a secure in-application transaction. Typically, the secure in-application request includes an application credential, information identifying a client application 34B user, and a unique transaction identifier. In typical embodiments, the format of the application credential, information identifying a client application 34B user, and a unique transaction identifier is predetermined in accordance with the requirements of the secure interface server 180B and/or the transaction server 200. Regardless of implementation, the information identifying a client application 34B user uniquely identifies a user to the secure interface server 180B and/or the transaction server 200 and/or request module server 300. Similarly, in preferred embodiments, the unique transaction identifier uniquely identifies a single in-application transaction conducted by a user of the client application 34B.
  • Thus, in summary, upon completion of step 410, there is generated, through the client application 34B and the associated request module 36, at a time when the client application 34B is executing on the client device 100B, a request associated with a secure in-application transaction, where the request comprises (i) a credential for the client application 34B, (ii) an identification of a user of the client application 34B, and (iii) a transaction identifier that uniquely identifies the request. The request for the secure in-application transaction is submitted over the Internet or a computer network to the secure interface server 180B. Here, unlike the first embodiment, the secure interface server 180B has a restrictive cross-domain policy 138B that requires applications that interact with the secure interface server 180B to have a source URL that is the domain of the request module server 300. In some embodiments, particularly those where the application credential was already presented to the request module server 300 in step 404, the request sent in step 410 and processed in step 412 may not have the application credential. In some embodiments, the request sent in step 410 and processed in step 412 may not have the identity of the user of the client application 34B.
  • Step 412.
  • As discussed above with reference to step 410, the request for the secure in-application transaction is received over the Internet or computer network by transaction module serving application 134, running on the secure interface server 180B, with information identifying the application user (optionally), a unique transaction identifier, and the application credential (optionally). In some embodiments, the request received at step 412 does not include the identity of the user. In such embodiments, the identity of the user is only communicated by transaction module 38B to the transaction server module 234 of the transaction server 200.
  • Step 414.
  • In some embodiments of step 414, the application credential for the client application 34B is verified against a database of valid application credentials 142. In some embodiments, this verification was already done in step 406. In some embodiments, this verification is done in both steps 414 and 406. In some embodiments, the database of valid application credentials 142 comprises an identification of each legitimate application developer that may use the secure interface server 180B and the transaction server 200 to conduct secure transactions. In step 414, an additional check is made to ensure that the source URL of the request module 36 is verified against the cross domain policy 138B of the secure interface server 180B.
  • Step 416.
  • If the application credential provided with the application request received in step 412 is not verified and/or the source URL of the request module 36 is not that of the domain of the request module server 300 (416—No), the transaction ends 418 in failure. In some embodiments, not shown, the client application 34B is notified of this failure. In some embodiments, not shown, the application developer is notified of this failure. If the application credential provided with the application request received in step 412 is verified and the source URL of the request application 36 is that of the domain of the request module server 300 (416—Yes), process control passes on to step 214 of FIG. 2A. In other words, the second embodiment includes steps 214 through 234 of the first embodiment.
  • Steps 460 Through 466.
  • The transaction module 38 operates in its own domain-specific security sandbox on the client device 100B and the transaction module 38 does not grant the client application 34B the power to introspect. Therefore, the client application 34B does not ascertain directly from the transaction module 38 whether the in-application transaction was completed, much less whether the in-application transaction was successfully completed such that the user is to be granted whatever privilege was associated with the in-application transaction (e.g., more game points, etc.). Therefore, concurrently with some or all of the aforementioned steps, or after all of the aforementioned steps have been completed, the client application 34B polls the transaction database 140/204 using the request module server 300 to determine the status of the transaction.
  • It is to be appreciated that, while the secure interface server 180B, the transaction server 200, and the request module server 300 each have access to the transaction database 140/240, the request module server 300 has a permissive cross-domain policy 336 in embodiment 2 while the transaction server 200 has a restrictive cross-domain policy 236 and the secure interface server 180B has a restrictive cross-domain policy 138B. Thus, unless the source URL of the client application 34 is the URL of the secure interface server 180B, the client application 34B will be unable to interact directly with the transaction server 200. Moreover, unless the source URL of the client application 34 is the URL of the request module server 300, the client application 34B will be unable to interact directly with the secure interface server 180B. Thus, in such instances, the client application 34B would be unable to poll the transaction database 140/240 using the transaction server 200 or the secure interface server 180B
  • In typical embodiments, the client application 34B poles the transaction database 140/240 on the request module server 300 on a periodic basis (e.g., every minute, every five minutes, every half hour, etc.) until the transaction database 140/240 indicates that the transaction is completed. In typical embodiments, this query is very limited. In typical embodiments, the client application 34B provides the unique transaction identifier and the application credential. If the application credential is valid against the database of valid application credentials 142, the status of the transaction uniquely associated with the transaction identifier provided by the client application 34B is sent back to the client application 34B running on the client device 100B over the Internet or computer network. In typical embodiments, the client application 34B is not permitted to obtain personal information from the transaction database 140/240.
  • REFERENCES CITED AND ALTERNATIVE EMBODIMENTS
  • All references cited herein are incorporated herein by reference in their entirety and for all purposes to the same extent as if each individual publication or patent or patent application was specifically and individually indicated to be incorporated by reference in its entirety for all purposes.
  • The present invention can be implemented as a computer program product that comprises a computer program mechanism embedded in a computer readable storage medium. For instance, the computer program product could contain the program modules shown in FIGS. 1 and/or 3. These program modules can be stored on a CD-ROM, DVD, magnetic disk storage product, or any other tangible computer readable data or program storage product.
  • Many modifications and variations of this invention can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. The specific embodiments described herein are offered by way of example only. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. The invention is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (37)

1. A system for facilitating secure transactions, comprising:
one or more processing units;
a memory, coupled to at least one of the one or more processing units, the memory storing instructions that are executed by at least one of the one or more processing units and that when executed by the one or more processing units cause the system to:
execute a client application;
generate, through the client application, a request associated with a secure in-application transaction;
submit the request for the secure in-application transaction to a first domain;
receive a validated transaction module from the first domain wherein a source URL of the transaction module is identified as the first domain;
cause the client application to execute the validated transaction module such that the validated transaction module is loaded into a separate secure memory space within said memory, wherein
the separate secure memory space is segregated from memory space in said memory in which the client application is run,
the separate secure memory space is associated with, and limited to, programs that identify their source URL as being the first domain,
the validated transaction module is executed such that the identity of the source URL of the validated transaction module is not altered or destroyed, and
the validated transaction module does not grant the client application power to introspect the validated transaction module;
issue a transaction call to a second domain; and
conduct a validated transaction between the second domain and the validated transaction module.
2. The system of claim 1, further comprising a display having a screen real estate, wherein, upon executing the client application, the client application is manifested on a portion of the screen real estate and wherein the validated transaction module is manifested on a subset of the portion of the screen real estate.
3. The system of claim 1, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with an identity of a user of the client application.
4. The system of claim 3, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.
5. The system of claim 1, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
6. The system of claim 1, wherein the first domain and the second domain are hosted by the same server.
7. The system of claim 1, wherein the first domain and the second domain are each hosted by a separate server.
8. The system of claim 1, wherein the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application that is loaded by the client application during execution of the validated transaction module.
9. A method for facilitating secure transactions, comprising:
executing a client application on one or more computing devices;
generating by the one or more computing devices, and through the client application, a request for a secure in-application transaction;
submitting, by the one or more computing devices, the request for the secure in-application transaction to a first domain that has an unrestrictive first cross-domain policy;
receiving, by the one or more computing devices, a validated transaction module from the first domain, wherein a source URL of the transaction module is identified as the first domain;
causing, by the one or more computing devices, the client application to execute the validated transaction module such that the validated transaction module is executed in a separate secure memory space;
issuing, from the validated transaction module while it is executing in the separate secure memory space of the one or more computing devices, a transaction call to a second domain, wherein the second domain has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;
conducting, by the one ore more computing devices, a validated transaction between the second domain and the validated transaction module; and
determining, by one or more computing devices, that the transaction was completed.
10. The method of claim 9, wherein, upon executing the client application, the client application is manifested on a portion of a screen real estate and wherein the validated transaction module is manifested on a subset of the portion of the screen real estate.
11. The method of claim 9, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with an identity of a user of the client application.
12. The method of claim 11, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.
13. The method of claim 9, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
14. The method of claim 9, wherein the first domain and the second domain are hosted by the same server.
15. The method of claim 9, wherein the first domain and the second domain are each hosted by a separate server.
16. The method of claim 9, wherein the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application that is loaded by the client application during the execution of the validated transaction module such that the validated transaction module is executed in the separate secure memory space.
17. A computer program product, comprising:
a non-transitory computer readable medium having computer-readable program instructions embedded therein that when executed by a computer perform a method for facilitating secure transactions comprising:
generating by a computer system and through a client application, a request for a secure in-application transaction;
submitting, by the computer system, the request for the secure in-application transaction to a first domain;
receiving, by the computer system, a validated transaction module from the first domain;
causing, by the computer system, the client application to execute the validated transaction module such that the validated transaction module is loaded into a separate secure memory space;
issuing, by the computer system, a transaction call to a second domain; and
conducting, by the computer system, a validated transaction between the second domain and the validated transaction module.
18-34. (canceled)
35. A method for facilitating secure transactions, comprising:
generating, by one or more computing devices and through a client application a first request associated with a secure in-application transaction;
submitting, by the one or more computing devices, the first request for the secure in-application transaction to a first domain that has an unrestrictive first cross-domain policy;
receiving, by the one or more computing devices, a request module;
causing, by the one or more computing devices, the client application to execute the request module such that the request module is loaded into a first secure memory space;
generating, by one or more computing devices, a second request associated with the secure in-application transaction;
submitting, by the one or more computing devices, the second request for the secure in-application transaction to a second domain;
receiving, by the one or more computing devices, a transaction module from the second domain wherein a source URL of the transaction module is identified as the second domain;
causing, by the one or more computing devices, the client application to execute the transaction module such that the transaction module is loaded into a second secure memory space;
issuing, by the one or more computing devices, from the transaction module while it is executing in the second secure memory space, a transaction call to a third domain; and
conducting, by the one or more computing devices, a validated transaction between the third domain and the transaction module.
36. The method of claim 35, further comprising executing, the one or more computing devices, the client application.
37. The method of claim 35, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.
38. The method of claim 37, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.
39. The method of claim 35, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
40. The method of claim 35, wherein the first domain, the second domain, and the third domain are hosted by the same server.
41. The method of claim 37, wherein the first domain and the second domain are each hosted by a separate server.
42. The method of claim 37, wherein the client application is a FLASH application and wherein the transaction module is a FLASH SWF application that is loaded by the client application during the execution of the transaction module.
43-53. (canceled)
54. The computer program product of claim 17, wherein, upon the executing of the client application, the client application is manifested on a portion of a screen real estate and wherein the validated transaction module is manifested on a subset of the portion of the screen real estate.
55. The computer program product of claim 17, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with an identity of a user.
56. The computer program product of claim 55, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.
57. The computer program product of claim 17, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.
58. The computer program product of claim 17, wherein the request for a secure in-application transaction comprises:
(i) a credential for the client application, and
(ii) a transaction identifier that uniquely identifies the request.
59. The computer program product of claim 17, wherein the first domain and the second domain are hosted by the same server.
60. The computer program product of claim 17, wherein the first domain and the second domain are each hosted by a separate server.
61. The computer program product of claim 17, wherein the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application that is loaded by the client application during execution of the validated transaction module such that the validated transaction module is loaded into the separate secure memory space.
62. The system of claim 1, wherein the request for a secure in-application transaction comprises:
(i) a credential for the client application, and
(ii) a transaction identifier that uniquely identifies the request.
63. The method of claim 9, wherein the request for a secure in-application transaction comprises:
(i) a credential for the client application, and
(ii) a transaction identifier that uniquely identifies the request.
US13/747,280 2010-05-26 2013-01-22 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions Active 2030-11-12 US9160717B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/788,173 US8364959B2 (en) 2010-05-26 2010-05-26 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions
US13/747,280 US9160717B2 (en) 2010-05-26 2013-01-22 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/747,280 US9160717B2 (en) 2010-05-26 2013-01-22 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/788,173 Continuation US8364959B2 (en) 2010-05-26 2010-05-26 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

Publications (2)

Publication Number Publication Date
US20130139220A1 true US20130139220A1 (en) 2013-05-30
US9160717B2 US9160717B2 (en) 2015-10-13

Family

ID=45004818

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/788,173 Active 2031-07-22 US8364959B2 (en) 2010-05-26 2010-05-26 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions
US13/747,280 Active 2030-11-12 US9160717B2 (en) 2010-05-26 2013-01-22 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/788,173 Active 2031-07-22 US8364959B2 (en) 2010-05-26 2010-05-26 Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

Country Status (8)

Country Link
US (2) US8364959B2 (en)
EP (1) EP2577550A4 (en)
JP (1) JP5373997B2 (en)
KR (1) KR101370020B1 (en)
CN (2) CN102947847B (en)
AU (1) AU2011258191B2 (en)
CA (1) CA2800657C (en)
WO (1) WO2011150204A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015126133A1 (en) * 2014-02-21 2015-08-27 Samsung Electronics Co., Ltd. Method and apparatus to sandbox run-time android applications with lightweight container
US10181028B2 (en) 2014-02-21 2019-01-15 Samsung Electronics Co., Ltd. Method and apparatus to sandbox run-time android applications with lightweight container

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8359278B2 (en) 2006-10-25 2013-01-22 IndentityTruth, Inc. Identity protection
US9961388B2 (en) 2008-11-26 2018-05-01 David Harrison Exposure of public internet protocol addresses in an advertising exchange server to improve relevancy of advertisements
US9519772B2 (en) 2008-11-26 2016-12-13 Free Stream Media Corp. Relevancy improvement through targeting of information based on data gathered from a networked device associated with a security sandbox of a client device
US9986279B2 (en) 2008-11-26 2018-05-29 Free Stream Media Corp. Discovery, access control, and communication with networked services
US8180891B1 (en) 2008-11-26 2012-05-15 Free Stream Media Corp. Discovery, access control, and communication with networked services from within a security sandbox
US9386356B2 (en) 2008-11-26 2016-07-05 Free Stream Media Corp. Targeting with television audience data across multiple screens
US9154942B2 (en) 2008-11-26 2015-10-06 Free Stream Media Corp. Zero configuration communication between a browser and a networked media device
US10419541B2 (en) 2008-11-26 2019-09-17 Free Stream Media Corp. Remotely control devices over a network without authentication or registration
US10334324B2 (en) 2008-11-26 2019-06-25 Free Stream Media Corp. Relevant advertisement generation based on a user operating a client device communicatively coupled with a networked media device
US8627451B2 (en) * 2009-08-21 2014-01-07 Red Hat, Inc. Systems and methods for providing an isolated execution environment for accessing untrusted content
US8296568B2 (en) 2009-10-27 2012-10-23 Google Inc. Systems and methods for authenticating an electronic transaction
US9684785B2 (en) 2009-12-17 2017-06-20 Red Hat, Inc. Providing multiple isolated execution environments for securely accessing untrusted content
CN102754462B (en) * 2010-05-12 2016-05-11 中兴通讯股份有限公司 A kind ofly realize method and the business platform that mobile terminal is transferred accounts
US8364959B2 (en) 2010-05-26 2013-01-29 Google Inc. Systems and methods for using a domain-specific security sandbox to facilitate secure transactions
US10511630B1 (en) 2010-12-10 2019-12-17 CellSec, Inc. Dividing a data processing device into separate security domains
US8931042B1 (en) * 2010-12-10 2015-01-06 CellSec, Inc. Dividing a data processing device into separate security domains
US10305937B2 (en) 2012-08-02 2019-05-28 CellSec, Inc. Dividing a data processing device into separate security domains
US8863256B1 (en) 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
US9027151B2 (en) * 2011-02-17 2015-05-05 Red Hat, Inc. Inhibiting denial-of-service attacks using group controls
AU2012217565B2 (en) 2011-02-18 2017-05-25 Csidentity Corporation System and methods for identifying compromised personally identifiable information on the internet
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
US9707486B1 (en) * 2011-02-25 2017-07-18 Zynga Inc. Apparatus, method and system for crew mechanics in multiplayer games
JP5329589B2 (en) * 2011-03-17 2013-10-30 株式会社三菱東京Ufj銀行 Transaction processing system and operation method of transaction processing system
US20120291089A1 (en) * 2011-05-13 2012-11-15 Raytheon Company Method and system for cross-domain data security
US8561208B2 (en) * 2011-05-20 2013-10-15 Adobe Systems Incorporated Secure user interface content
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US8819793B2 (en) 2011-09-20 2014-08-26 Csidentity Corporation Systems and methods for secure and efficient enrollment into a federation which utilizes a biometric repository
CN103309861B (en) * 2012-03-07 2018-04-10 阿里巴巴集团控股有限公司 The method and apparatus that cross-domain data obtains
US9026668B2 (en) 2012-05-26 2015-05-05 Free Stream Media Corp. Real-time and retargeted advertising on multiple screens of a user watching television
US20130332284A1 (en) * 2012-06-11 2013-12-12 Retailmenot, Inc. Cross-device offers platform
US9294508B2 (en) 2012-08-02 2016-03-22 Cellsec Inc. Automated multi-level federation and enforcement of information management policies in a device network
EP2973276A4 (en) * 2013-03-15 2016-09-14 Visa Int Service Ass Snap mobile security apparatuses, methods and systems
US9313203B2 (en) * 2013-03-15 2016-04-12 Symantec Corporation Systems and methods for identifying a secure application when connecting to a network
US9424421B2 (en) 2013-05-03 2016-08-23 Visa International Service Association Security engine for a secure operating environment
US9292525B2 (en) * 2013-06-19 2016-03-22 BlackBerry Limited; 2236008 Ontario Inc. Searching data using pre-prepared search data
EP2819370B1 (en) * 2013-06-24 2018-09-19 Telefonica Digital España, S.L.U. A computer implemented method to prevent attacks against user authentication and computer programs products thereof
CN103607426B (en) * 2013-10-25 2019-04-09 中兴通讯股份有限公司 Security service customization method and device
US9195833B2 (en) * 2013-11-19 2015-11-24 Veracode, Inc. System and method for implementing application policies among development environments
US10339527B1 (en) 2014-10-31 2019-07-02 Experian Information Solutions, Inc. System and architecture for electronic fraud detection
KR101660627B1 (en) * 2015-02-03 2016-09-28 한양대학교 에리카산학협력단 Method and apparatus for protecting transasction of encrypted currency
US10339523B2 (en) 2015-07-14 2019-07-02 Fmr Llc Point-to-point transaction guidance apparatuses, methods and systems
RU2606877C1 (en) 2015-09-28 2017-01-10 Общество С Ограниченной Ответственностью "Яндекс" System and method of processing data in executed on computer system
US10504179B1 (en) 2015-12-08 2019-12-10 Fmr Llc Social aggregated fractional equity transaction partitioned acquisition apparatuses, methods and systems
CN106682499A (en) * 2016-11-16 2017-05-17 无锡港湾网络科技有限公司 Disaster prevention system data secure-storage method
KR102003731B1 (en) 2018-04-20 2019-08-28 주식회사 클라우드퓨전 System and method for protecting crypto currency using virtual machine
KR101923943B1 (en) 2018-04-20 2019-02-22 주식회사 클라우드퓨전 System and method for remitting crypto currency with enhanced security
KR102003733B1 (en) 2018-04-20 2019-08-28 주식회사 클라우드퓨전 System for protecting crypto currency using separating network
KR102005974B1 (en) 2018-04-20 2019-10-21 주식회사 클라우드퓨전 System and method for protecting electronic contents using virtual machine

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080208749A1 (en) * 2007-02-20 2008-08-28 Andrew Wallace Method and system for enabling commerce using bridge between real world and proprietary environments
US20080313648A1 (en) * 2007-06-14 2008-12-18 Microsoft Corporation Protection and communication abstractions for web browsers
US8635535B2 (en) * 2007-10-16 2014-01-21 D&B Business Information Solutions Limited Third-party-secured zones on web pages
US20140033086A1 (en) * 2008-01-29 2014-01-30 Adobe Systems Incorporated Secure content-specific application user interface components

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038551A (en) 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US5864620A (en) 1996-04-24 1999-01-26 Cybersource Corporation Method and system for controlling distribution of software in a multitiered distribution chain
US6256393B1 (en) * 1998-06-23 2001-07-03 General Instrument Corporation Authorization and access control of software object residing in set-top terminals
US6990470B2 (en) 2000-04-11 2006-01-24 Mastercard International Incorporated Method and system for conducting secure payments over a computer network
US7076445B1 (en) 2000-06-20 2006-07-11 Cartwright Shawn D System and methods for obtaining advantages and transacting the same in a computer gaming environment
US7069271B1 (en) * 2000-11-03 2006-06-27 Oracle International Corp. Methods and apparatus for implementing internet storefronts to provide integrated functions
EP1233333A1 (en) * 2001-02-19 2002-08-21 Hewlett-Packard Company Process for executing a downloadable service receiving restrictive access rights to al least one profile file
JP2003005857A (en) * 2001-06-21 2003-01-08 Toshiba Corp Server computer provided with web server operatable of web application, and method for measuring use time of web application
US7509687B2 (en) 2002-03-16 2009-03-24 Trustedflow Systems, Inc. Remotely authenticated operation method
US20100017627A1 (en) 2003-02-07 2010-01-21 Broadon Communications Corp. Ensuring authenticity in a closed content distribution system
ITRM20030100A1 (en) 2003-03-06 2004-09-07 Telecom Italia Mobile Spa multiple access technique to the network, by the user terminal interconnected to a LAN and relative reference architecture.
JP2004272669A (en) * 2003-03-10 2004-09-30 Hitachi Ltd Method and device for charging management for grid computing
US7444678B2 (en) * 2003-10-28 2008-10-28 Aol Llc Securing resources from untrusted scripts behind firewalls
JP2005332208A (en) * 2004-05-20 2005-12-02 Okuto:Kk Charging management system
US20060056281A1 (en) * 2004-09-10 2006-03-16 Samsung Electronics Co., Ltd. Method and system for time-domain transmission diversity in orthogonal frequency division multiplexing
US7886344B2 (en) 2004-09-13 2011-02-08 Cisco Technology, Inc. Secure fallback network device
EP1659473A1 (en) 2004-11-22 2006-05-24 Swisscom Mobile AG Method and user device for the reproduction of a file
US8135954B2 (en) 2004-12-20 2012-03-13 Motorola Mobility, Inc. Distributed digital signature generation
US7624111B2 (en) 2005-06-27 2009-11-24 Microsoft Corporation Active content trust model
CN101025802A (en) 2006-02-17 2007-08-29 鸿富锦精密工业(深圳)有限公司 Working log electronic system and method
US20080034216A1 (en) 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
US7809525B2 (en) * 2007-07-31 2010-10-05 International Business Machines Corporation Automatic configuration of robotic transaction playback through analysis of previously collected traffic patterns
CN101364869B (en) 2007-08-09 2012-03-28 鸿富锦精密工业(深圳)有限公司 Electronic document digital checking system and method
US8341104B2 (en) 2007-08-16 2012-12-25 Verizon Patent And Licensing Inc. Method and apparatus for rule-based masking of data
US8806565B2 (en) 2007-09-12 2014-08-12 Microsoft Corporation Secure network location awareness
JP5145949B2 (en) * 2008-01-08 2013-02-20 富士通株式会社 Campaign system, campaign method, and campaign service program
EP2728528A1 (en) * 2008-05-30 2014-05-07 MR.QR10 GmbH & Co. KG Server device for controlling a transaction, first entity and second entity
US20100023757A1 (en) 2008-07-22 2010-01-28 Winmagic Data Security Methods and systems for sending secure electronic data
US8296568B2 (en) 2009-10-27 2012-10-23 Google Inc. Systems and methods for authenticating an electronic transaction
US20110214115A1 (en) * 2010-02-26 2011-09-01 Nokia Corporation Method and appartus for providing a high level mobile virtual machine
US9922354B2 (en) * 2010-04-02 2018-03-20 Apple Inc. In application purchasing
US8364959B2 (en) 2010-05-26 2013-01-29 Google Inc. Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080208749A1 (en) * 2007-02-20 2008-08-28 Andrew Wallace Method and system for enabling commerce using bridge between real world and proprietary environments
US20080313648A1 (en) * 2007-06-14 2008-12-18 Microsoft Corporation Protection and communication abstractions for web browsers
US8635535B2 (en) * 2007-10-16 2014-01-21 D&B Business Information Solutions Limited Third-party-secured zones on web pages
US20140033086A1 (en) * 2008-01-29 2014-01-30 Adobe Systems Incorporated Secure content-specific application user interface components

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015126133A1 (en) * 2014-02-21 2015-08-27 Samsung Electronics Co., Ltd. Method and apparatus to sandbox run-time android applications with lightweight container
US10181028B2 (en) 2014-02-21 2019-01-15 Samsung Electronics Co., Ltd. Method and apparatus to sandbox run-time android applications with lightweight container

Also Published As

Publication number Publication date
CA2800657C (en) 2014-03-04
US8364959B2 (en) 2013-01-29
CN102947847A (en) 2013-02-27
KR101370020B1 (en) 2014-03-05
JP2013533994A (en) 2013-08-29
JP5373997B2 (en) 2013-12-18
KR20130033385A (en) 2013-04-03
EP2577550A2 (en) 2013-04-10
WO2011150204A2 (en) 2011-12-01
WO2011150204A3 (en) 2012-04-05
AU2011258191A1 (en) 2012-12-13
US9160717B2 (en) 2015-10-13
CN102947847B (en) 2014-10-29
EP2577550A4 (en) 2013-06-19
CN104281947A (en) 2015-01-14
US20110296529A1 (en) 2011-12-01
CN104281947B (en) 2017-09-08
CA2800657A1 (en) 2011-12-01
AU2011258191B2 (en) 2013-04-11

Similar Documents

Publication Publication Date Title
US9117324B2 (en) System and method for binding a smartcard and a smartcard reader
US9123044B2 (en) Generation systems and methods for transaction identifiers having biometric keys associated therewith
US9972005B2 (en) Cloud-based transactions methods and systems
US9596237B2 (en) System and method for initiating transactions on a mobile device
US9325708B2 (en) Secure access to data in a device
ES2599985T3 (en) Validation at any time for verification tokens
JP5184627B2 (en) Communication device, authentication system and method, and carrier medium
CN1266560C (en) Enhanced quality of identification in a data communications network
RU2263961C2 (en) Method for playing without using cash
CA2748481C (en) System and method for initiating transactions on a mobile device
ES2732564T3 (en) Remote server encrypted data provisioning system and procedures
US6895391B1 (en) Method and system for secure authenticated payment on a computer network
CN102792630B (en) Systems and methods for authenticating an electronic transaction
EP2873192B1 (en) Methods and systems for using derived credentials to authenticate a device across multiple platforms
US20110302646A1 (en) System and methods for online authentication
TWI274500B (en) User authentication system
US7512802B2 (en) Application authentication system, secure device, and terminal device
US20040030901A1 (en) Linking public key of device to information during manufacture
US20060123117A1 (en) Trial-before-purchase subscription game infrastructure for peer-peer networks
US20100023450A1 (en) System and methods for facilitating fund transfers over a network
JP2009534739A (en) Authentication for commerce using mobile modules
US5883810A (en) Electronic online commerce card with transactionproxy number for online transactions
US20070088952A1 (en) Authentication device and/or method
US7596530B1 (en) Method for internet payments for content
US10049353B2 (en) Embedding cloud-based functionalities in a communication device

Legal Events

Date Code Title Description
AS Assignment

Owner name: GOOGLE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BHANOO, HEMANT MADHAV;BAYES, LUKE;MILLS, ALLAN;REEL/FRAME:029713/0940

Effective date: 20101029

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: GOOGLE LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044334/0466

Effective date: 20170929

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4