Patent Application
20170352019
Embodiments of the invention are directed to systems and methods related to conducting a group transaction.
The Internet has made it increasingly easy for consumers to conduct electronic transactions using computing devices such as mobile devices (e.g., mobile phones, tablet computers, etc.). However, transactions conducted over the Internet using mobile applications are usually conducted by a single user and not a group of users.
Current techniques for enabling multiple users (e.g., a group) to share in a group transaction include a single user conducting a single transaction on behalf of one or more other users. Alternatively, each person may manually conduct a separate transaction related to the group resulting in multiple messages being sent to a processing system. These approaches are inconvenient for the user and/or a waste of computing resources and network bandwidth. Although various approaches have attempted to address these drawbacks, these approaches include clear disadvantages. For example, some approaches require users who are sharing a transaction to share a common attribute. Other approaches provided by third-parties may not have the flexibility to optimize the transaction procedure, which can lead to an unfortunate user experience.
Thus, there is a need for new and enhanced methods for enabling a group of users to conduct a group transaction that optimizes computing resources and conserves network bandwidth while providing a positive user experience to the user.
Embodiments of the invention address these and other problems, individually and collectively.
One embodiment of the invention is directed to a method comprising, receiving, by a server computer, a request to establish a group identifier for a group. The method further comprises generating, by the server computer, the group identifier for the group. The method further comprises transmitting, by the server computer to a plurality of user devices operated by a plurality of users, group invitations to join the group. The method further comprises receiving, by the server computer from at least a subset of the plurality of user devices, group invitation responses. The method further comprises receiving, by the server computer from the at least the subset of the plurality of user devices, confirmations to share a group transaction. The method further comprises initiating a plurality of messages corresponding to the plurality of confirmations, wherein the plurality of messages result in an initiation of a single message to a third-party computer, the third-party computer being configured to conduct the group transaction according to the single message.
Another embodiment of the invention is directed to a server computer comprising a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor, for implementing a method. The method comprises receiving a request to establish a group identifier for a group. The method further comprises generating the group identifier for the group. The method further comprises transmitting, to a plurality of user devices operated by a plurality of users, group invitations to join the group. The method further comprises receiving, from at least a subset of the plurality of user devices, group invitation responses. The method further comprises receiving, from the at least the subset of the plurality of user devices, confirmations to share a group transaction. The method further comprises initiating a plurality of messages corresponding to the plurality of confirmations, wherein the plurality of messages result in an initiation of a single message to a third-party computer, the third-party computer being configured to conduct the group transaction according to the single message.
These and other embodiments of the invention are described in further detail below.
Embodiments of the present invention may be directed at utilizing the infrastructure of an application server computer to perform group transactions. Any functions of the application server computer described herein may be instead provided by a sharing application operating on a user computing device. Similarly, any functions and/or features provided by a sharing application described herein may alternatively be provided by an application server computer.
In some embodiments of the present invention, an interface (e.g., provided by an application server computer) may be utilized to create a group. The record corresponding to the group may be stored in the system and associated with, for example, a group identifier. A number of individuals may be identified by the application server computer and these individuals may be sent electronic group invitations to join the group. Such invitations may be sent via email(s), Short Message Service (SMS) text message(s), Multimedia Messaging Service (MMS) text message(s), or any suitable form of electronic communication. Additionally, or alternatively, an interface provided by the application server computer may enable one or more individuals to search for a pre-existing group and request to join the group. Receipt of a request to join the group and/or a group invitation response indicating a desire by an individual to join the group, may cause the application server computer to associate the requestor with the stored group identifier (e.g., a part of a stored record associated with the group). In at least one example, there may be some individuals that decline to join a group, in which case, the application server computer may only receive responses from a subset of the individuals that were invited to join the group. In examples in which only a subset of the invited individuals respond, group membership may be determined after, for example, a threshold period of time after receipt of a last group invitation response. As a non-limiting example, if five group invitations were sent, and four group invitation responses received, the group membership may be determined to be the four individuals for which responses were received, the determination occurring, for example, 30 seconds after the receipt of the fourth group invitation response. In general, the application server computer may be responsible for maintaining group membership status.
In at least one embodiment, an interface may be provided by the application server computer to enable a user to create a group transaction. The group transaction may include any suitable group transaction data that enables the group transaction to be conducted on behalf of multiple group members. As a non-limiting example, multiple individuals may desire to join a charitable 5K race. In order to register as a group for the race, each person of the group must submit registration information including, but not limited to his or her name, address, and phone number. Accordingly, the application server computer may provide an interface via a sharing application operating on each user's device. The interface may be utilized to enable each user to enter his or her registration information. Upon receiving registration information from each group member, the application server computer may forward the registration information to a processing network computer. The processing network computer, on receipt of the registration information may (or may not) perform one or more validation operations before forwarding the registration information along as a single group transaction. The single group transaction may be utilized to enable each member of the group to be registered as a group, alleviating the need for separate transactions to be utilized for each group member.
Embodiments of the present invention may be used in transaction processing systems or may use data generated during transaction processing through a transaction processing system. Such embodiments may involve transactions between consumers and merchants.
Before discussing detailed embodiments of the invention, some descriptions of certain terms may be useful.
A “computing device” may be any suitable device that can perform computations, and that can communicate with other devices. A mobile device is an example of a computing device. Other types of computing devices may not be mobile.
A “mobile device” may comprise any suitable device can be easily carried by a user. In some embodiments, it may be an electronic device that may be transported and operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, personal music players, hand-held specialized readers, wearable devices (e.g., watches), vehicles (e.g., cars), etc. A mobile device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device—i.e., using the other device as a relay—both devices taken together may be considered a single mobile device).
“Registration information” may include data associated with a user enabling the user to register with a service provider. For example, registration information may include any suitable combination of a name, a shipping address, a phone number, an email address, one or more user preferences, a payment method, a billing address, or any suitable information enabling the service provider to provide a service to the user.
A “group identifier” may include a string of characters, a number, an alphanumeric identifier, or any suitable mechanism for identifying a group (e.g., two or more) of individual people.
A “group invitation” may include one or more electronic communications for eliciting one or more responses from a user with respect to a group. In at least one example, an application server computer may provide an invitation to join a group to a user device of an individual. In some examples, the invitation may include a group identifier associated with the group pertaining to the invitation.
A “group invitation response” may include one or more communications for providing feedback from a user with respect to a group. In at least one example, an application server computer may receive a group invitation response indicating that the invited individual wishes to join a particular group. In some examples, the group invitation response may include additional data such as a payment amount, a share, a portion, a percentage, or any suitable data indicating a sub-portion of a group transaction for which the individual claims ownership.
“Group transaction information” may include any suitable information that enables a group transaction to be conducted. For example, group transaction information may include, but is not limited to, a transaction identifier, a merchant account identifier, an amount, a name, an address, a phone number, payment information, a height, a weight, a body type and/or build, or any suitable information needed to conduct a group transaction.
A “confirmation message” may be an electronic message that confirms an event. In some embodiments, it may be an electronic message that is sent from a user device, and that confirms group membership of an individual operating the user device. In some examples, the confirmation message may include data such as a payment amount, a share, a portion, a percentage, or any suitable data indicating a sub-portion of a group transaction for which the individual claims ownership.
A “transaction request message” may be an electronic message that includes information related to a group transaction. As a non-limiting example, in a group purchase transaction (e.g., splitting of a restaurant bill), the transaction request message may include a total bill amount, a subtotal, a taxes amount, a merchant identifier, or the like.
A “payment account attribute inquiry message” may be an electronic message that enables an inquiry corresponding to a particular account. In at least one example, the account may be managed by a financial institution. In at least one example, the payment account attribute inquiry message may include an account number (e.g., a primary account number (PAN)).
A “payment account attribute inquiry response message” may be an electronic message that provides account information corresponding to a particular account. In at least one example, the account information pertains to an account managed by a financial institution. In at least one example, the payment account attribute inquiry response message may include a product identification code, a product name, a product sub-type code, a product sub-type name, a card type code, a card sub-type code, a product platform code, issuer information (e.g., an issuer name and/or country code), a billing currency code, a decimal position indicator, a fast funds indicator, a push payment indicator, an online gambling block indicator, or any suitable combination of the above. In at least one example, the fast funds indicator indicates whether or not the issuer of a recipient account is enabled to make transferred funds available within 30 minutes of authorizing a transfer.
A “push funds transaction” may be an electronic message that adheres to an application programming interface for providing functionality to push funds to a recipient account (e.g., an account operated by a financial institution). In at least one examples, an Original Credit Transaction (OCT) can operate using an application interface for providing the functionality of a push funds transaction. A push funds transaction may include information such as recipient information, transaction amount, sender information, transaction identifier, etc.
A “multi-push funds transaction” may be an electronic message that adheres to an application programming interface for providing functionality to push funds to multiple recipient accounts (e.g., each account operated by a common or different financial institution). In at least one embodiment, the multi-push funds transaction may include information pertaining to multiple push funds transactions.
A “pull funds transaction” may be an electronic message that adheres to an application programming interface for providing functionality to pull funds from a sender's account (e.g., an account operated by a financial institution). In at least one examples, an Account Funding Transaction (AFT) may operate using an application interface for providing the functionality of a pull funds transaction. A pull funds transaction may include information such as sender information, transaction amount and fees (if applicable), point of sale information, etc.
A “multi-pull funds transaction” may be an electronic message that adheres to an application programming interface for providing functionality to pull funds from multiple senders' accounts (e.g., each account operated by a common or different financial institution). In at least one embodiment, the multi-push funds transaction may include information pertaining to multiple pull funds transactions.
A “processing network computer” may be one or more computers that provide one or more operations for processing a transaction. As a non-limiting example, a processing network computer may provide one or more application programming interfaces (e.g., APIs for providing push funds transactions, pull funds transactions, multi-push funds transactions, multi-pull funds transactions, and the like).
A “sharing application” may be a software application that is provided by an application server computer for a specific purpose. In at least some examples, a sharing application may be a software application that is provided to perform a variety of group transactions. Group transactions may relate to, for example, eCommerce, social networks, money transfer/personal payments, mobile commerce, proximity payments, gaming, and/or the like for retail purchases, digital goods purchases, utility payments, purchasing games or gaming credits from gaming websites, transferring funds between users, although this is not an exhaustive list.
An “authorization request message” may be an electronic message that is used to authorize a payment for a financial transaction. In some examples, an authorization request message is sent to a payment processing network and/or an authorizing computer to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current group transaction, such as the transaction amount assigned to the individual, a merchant identifier, a merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
An “authorization response message” may be an electronic message reply to an authorization request message generated by an issuing financial institution or a payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g. POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a payment processing network may generate or forward the authorization response message to the merchant.
A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.
An “acquirer” may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer”.
An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.
An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.
“User account information” may include data associated with a user. As a non-limiting example, user account information may include a user name, a user password, an address, a phone number, an email address, a shipping address, a billing address, a number of user preferences, payment information, or the like.
A “server computer” is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server.
A “processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).
A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.
The user computing device(s) 106 may have any suitable characteristics. The user computing device(s) 106 may individually include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described herein. The user computing device(s) 106 may be communicatively coupled to the application server computer 108 via a communications medium in order to conduct a group transaction with a resource provider (e.g., a merchant) associated with the resource provider computer 116. In some embodiments, the user computing device(s) 106 may be in communications with a resource provider computer 116 through the application server computer 108, the processing network computer 110, and the transport computer 114.
The user computing device(s) 106 may be in any suitable form. Example of user computing device(s) 106 includes any device capable of accessing the Internet, such as a personal computer, cellular or wireless phones, personal digital assistants (PDAs), tablet computers, laptop computers, and handheld specialized readers. The user computing device(s) 106 may transmit data through the communications medium to the application server computer 108.
In at least one embodiment, user computing device(s) 106 may be operated by individual users (e.g., a group creator 102, a group participant 104, or the like). In at least one embodiment, one or more interfaces may be provided by the application server computer 108 to a user of a user computing device via a sharing application operating on the user computing device. A user may interact with the application server computer 108 utilizing the sharing application in order to receive and transmit information related to a group and/or a group transaction.
The application server computer 108 may be one or more computers provided by a service provider. In some embodiments, application server computer 108 may manage and provide services to a user via a user computer device. The services may be provided to the user via a sharing application stored a user's computer device. The application server computer 108 may send over-the-air (OTA) messages to the sharing application. In at least one example, the application server computer 108 may be responsible for providing one or more network pages associated with the processing network. The application server computer 108 may be accessed via a website accessible to the user computing device(s) 106 and operated by the processing network computer 110. This website may be configured to be accessible from an application (e.g., a browser application, the sharing application, etc.) operating on the user computing device(s) 106. The sharing application may be configured to receive and transmit group information and/or group transaction information using one or more service calls. For example, the application server computer 108 may be configured to handle service call requests from the sharing application. The application server computer 108 may serve, in response to received requests, various user interfaces that may be rendered at the user computing device(s) 106.
As a non-limiting example, the application server computer 108 may provide one or more interfaces (directly, or via the sharing applications 106A-1 to 106A-N) to a group creator 102. In a non-limiting example, the group creator 102 may utilize such interfaces to input various information (e.g., a name, a location, etc.) to define a group. In some cases, the group creator 102 may utilize the provided interfaces to input one or more identifiers (e.g., a phone number, an email address, or the like) that individually identify a potential group member. Group defining information and/or group identifiers may be communicated to the application server computer 108 by the sharing application operating on a corresponding user device.
In at least one embodiment, one or more interfaces may be provided by the application server computer 108 (directly, or via the sharing applications 106A-1 to 106A-N) to a user (e.g., the group creator 102, and/or the group participant 104) to view/create a group transaction. As a non-limiting example, the group creator 102 may utilize the one or more interfaces to input group transaction information. Such information may be communicated to the application server computer 108 (e.g., by the sharing application operating on a corresponding user device).
In at least one embodiment, one or more interfaces may be provided by the application server computer 108 (directly, or via the sharing applications 106A-1 to 106A-N) to the group participant 104 (e.g., via a sharing application 106A-N operating on the user computing device 106-N). In a non-limiting example, the one or more interfaces may be utilized by the group participant 104 to input various identifying information (e.g., a name, a location, etc.) for a group. In some examples, the group participant 104 may utilize the one or more interfaces to search for a group (e.g., by group identifier, by location, or the like). The group participant 104 may utilize an interface provided by the application server computer 108 to indicate a desire to join an identified group. Such information may be communicated to the application server computer 108 (e.g., in a group invitation response) via the sharing application 106A-N.
In at least one embodiment, one or more interfaces may be provided by the application server computer 108 (directly, or via the sharing applications 106A-1 to 106A-N) to one or more users (e.g., the group creator 102 and/or the group participant 104) to provide information related to a group and/or a group transaction. For example, such interfaces may be utilized to communicate a transaction amount associated with a user (e.g., the group participant 104). A same or additional interface may be utilized to enable to the user to confirm and/or edit transaction information (e.g., the transaction amount). Confirmed and/or edited transaction information may be communicated to the application server computer 108 via, for example, a sharing application operating on the corresponding user computing device.
The application server computer 108 may be configured to maintain group membership information associated with a number of groups. For example, the application server computer 108 can receive a group identifier for a group. On receipt of a group identifier, or at another suitable time, the application server computer 108 may create and store a record that is associated with a particular group. The record, in some examples, may be used by the application server computer 108 to maintain information related to group membership such as indicators and/or identifier of members of the group. The record may further store a group identifier associated with a particular group. In some examples, the application server computer 108 may utilize the group identifier as a lookup for the record.
In at least one embodiment, the application server computer 108 may be configured to maintain group transaction information for a number of group transactions. Group transaction information may be associated with a particular group transaction. For example, the application server computer 108 can store a record for each group transaction or a record for more than one group transaction. The record, in some examples, may maintain group transaction information such as, but not limited to, a transaction amount, one or more shares of the transaction amount. The record may further store a group identifier for a particular group associated with the group transaction. In some cases, group membership information and group transaction information may be stored in a common record maintained by the application server computer 108.
In at least one embodiment, the application server computer 108 may be configured to provide a number of interfaces discussed above with respect to the user computing device(s) 106 via a corresponding sharing application operating on a user computer device. For example, the application server computer 108 may provide one or more interfaces via the sharing application to enable a user to create a group, join a group, search for a group, create a group transaction, confirm/edit transaction information related to a group transaction, or the like.
The processing network computer 110 may be configured to provide authorization services, and clearing and settlement services for payment transactions. A processing network computer 110 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary processing network computer may be included in a processing network such as VisaNet™. The processing network computer 110 may expose one or more application programming interfaces associated with a service such as VisaDirect™. In at least one example, the service may provide push and pull fund capabilities by providing one or more APIs, such as an API for pushing funds, an API for pulling funds, an API for pushing funds to multiple accounts, and an API for pulling funds from multiple accounts. In at least some examples, processing network computers are able to process credit card transactions, debit card transactions, and other types of commercial transactions. Processing network computers operating in VisaNet™, in particular, may include a Visa Integrated Payments (VIP) system which processes authorization requests and a Base II system which performs clearing and settlement services. Furthermore, the processing network computer 110 may include a server computer and may use any suitable wired or wireless telecommunications network, including the Internet. In some embodiments, the processing network computer 110 may forward an authorization request received from the transport computer 114 to the authorizing computer(s) 112 via a communication channel. The processing network computer 110 may further forward an authorization response message received from the authorizing computer(s) 112 to the transport computer 114.
The authorizing computer(s) 112 may individually be operated by a corresponding account issuer. Typically an issuer is an entity (e.g., a bank) that issues and maintains an account of a user (e.g., the group participant 104). The account may be a credit, debit, prepaid, or any other type of account. The authorizing computer(s) 112 may each be a stand-alone entity or may be coupled to, integrated into, and/or operated or managed by any of the entities shown in
The transport computer 114 may be operated by an acquirer. An acquirer is typically a system for an entity (e.g., a bank) that has a business relationship with a particular resource provider (e.g., a merchant) or another entity. The transport computer 114 may be communicatively coupled to the resource provider computer 116 and the processing network computer 110 and may issue and manage an account of the resource provider. In some embodiments, the transport computer 114 may forward an authorization request message to the processing network computer 110 and an authorization response message to the resource provider computer 116 during a transaction to confirm processing of a payment transaction.
The resource provider computer 116 may be associated with any suitable resource provider. In some examples, the resource provider may be a merchant. The resource provider computer 116 may be, for example, an access device such as a POS terminal at a location, a computer coupled with an access device of a merchant, or a remote server computer that operates a web site operated by the merchant. In some embodiments, the merchant operating the resource provider computer 116 may be a card-on-file (COF) merchant. The card-on-file merchant may store consumer account information in a remote database for future payments (e.g., recurring or periodic payments). The resource provider computer 116 may be configured to generate an authorization request message for a transaction. In some embodiments, the resource provider computer 116 may generate multiple authorization request messages if the transaction involves multiple authorizations.
The resource provider computer 116 may include any suitable computational apparatus operated by a resource provider (e.g., a merchant). The resource provider computer 116 may include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described herein. Examples of resource provider computer 116 may include an access device or a point of sale device. In some embodiments, the resource provider computer 116 may include a web server computer that may host one or more websites associated with the merchant. In some embodiments, the resource provider computer 116 may be configured to send and receive data to/from the transport computer 114 as part of a transaction procedure (e.g., payment verification and authentication process) between the user (e.g., consumer) and the resource provider (e.g., the merchant).
Messages between the computers, networks, and devices in
Each of the entities in
The data store 202 (as well as any other database described herein) may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle™ or Sybase™. The data store 202 may be implemented using various standard data-structures, such as an array, hash, (linked) list, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files.
The application server computer 108 may comprise a processor 204, which may be coupled to a system memory 206 and an external communication interface 208. A computer readable medium 210 may also be operatively coupled to the processor 204.
The computer readable medium 210 may comprise a number of software modules including a registration module 212, a group manager module 214, a group search module 216, a transaction module 218, a confirmation module 220, and a display manager module 222.
The registration module 212 may comprise code that, when executed, causes the processor 204 to transmit, receive, and/or store user account information. For example, the registration module 212 may receive user account information from a user. Such user account information may be collected by an interface provided by a component of the computer readable medium 210 (e.g., display manager module 222). In at least one example, the registration module 212 may transmit user account information to the data store 202 for storage as part of a user account associated with the user. In other examples, the registration module 212 may store user account information as part of a user account associated with the user.
The group manager module 214 may comprise code that, when executed, causes the processor 204 to transmit, receive, and/or store group information. For example, the group manager module 214 may receive a request to establish a group identifier. Such a request may be initiated by an interface provided by a component of the computer readable medium 210 (e.g., display manager module 222). The group manager module 214, upon receipt of such a request, may generate a group identifier for a group. In some example, the received request may include a group identifier to be used for a group. The group manager module 214 may cause the processor to execute instructions to store the group identifier (e.g., in the data store 202, or another suitable storage location) as part of a record associated with the group. In at least one embodiment, the group manager module 214 may cause the processor to transmit group invitations to join a group to one or more users. Such invitations may be included in any suitable electronic communication, including, but not limited to, an interface provided by a component of the computer readable medium 210 (e.g., display manager module 222).
In at least one embodiment, the group manager module 214 may cause the processor receive group invitation responses in response to the group invitations transmitted. Upon receipt of a group invitation response, the group manager module 214 may cause the processor to execute instructions to store data associated with the group invitation response identifier (e.g., in the data store 202, or another suitable storage location) as part of a record associated with the group. In at least one example, the group manager module 214 may cause both the group identifier and group invitation response information to be stored in a single record associated with the group. In at least one embodiment group manager module 214 may interact with the display manager module 222 to provide group information to a user (e.g., via a sharing application operating on a computing device of the user).
The group search module 216 may comprise code that, when executed causes the processor 204 to receive search parameters corresponding to a group search. In at least one example, such search parameters may include a location, one or more characters, one or more numbers, one or more symbols, or any suitable combination of the above. The group search module 216 may comprise additional code that causes the processor 204 to execute a search query (e.g., including one or more received search parameters) on the data store 202 or another suitable storage location that includes one or more group records. The group search module 216 may receive search results corresponding to the query and may include instructions that, when executed, causes a component of the computer readable medium 210 (e.g., the display manager module 222) to cause the processor 204 to provide such search results to a user (e.g., rendered via the sharing applications operating on the user computing device(s) 106 of
The transaction module 218 may comprise code that, when executed, causes the processor 204 to transmit, receive, and/or store group transaction information. For example, the transaction module 218 may receive a request to create and/or modify a group transaction. Such a request may be initiated by an interface provided by a component of the computer readable medium 210 (e.g., display manager module 222). The transaction module 218, upon receipt of such a request, may generate a group transaction for a group. In some examples, the received request may include a group identifier to identify a group associated with the group transaction. The transaction module 218 may cause the processor to execute instructions to store the group transaction information (e.g., in the data store 202, or another suitable storage location) as part of a record associated with the group. In at least one embodiment, the transaction module 218 may comprise code that, when executed, causes the processor 204 to store the group transaction information in a common record with respect to the group identifier and/or group invitation response information. In at least one embodiment the transaction module 218 may interact with the display manager module 222 to provide group transaction information to a user (e.g., via a sharing application operating on a computing device of the user).
The confirmation module 220 may comprise code that, when executed, causes the processor 204 to transmit, receive, and/or store one or more confirmations to share a group transaction. For example, the confirmation module 220 may receive a confirmation initiated by a particular user that indicates that the user desires to take part in the group transaction. A confirmation, in this context, can be initiated by an interface provided by a component of the computer readable medium 210 (e.g., display manager module 222). In at least some examples, the confirmation may include a portion of an overall transaction amount. In at least one embodiment, the confirmation module 220 may comprise code that, when executed, causes the processor 204 to allocate a share of the group transaction to individual users of a group. In at least one embodiment the confirmation module 220 may interact with the display manager module 222 to provide information related to a confirmation and/or a transaction share to a user (e.g., via a sharing application operating on a computing device of the user).
In at least one embodiment, the confirmation module 220 may comprise code that, when executed, causes the processor 204 to determine whether or not a confirmation has been received for every member of a group. If confirmations have been received for each group member, the confirmation module 220 may comprise further code for providing a group transaction a utilizing a multi-push transaction and/or a multi-pull transaction. As a non-limiting example, the confirmation module 220 may comprise code that, when executed, causes the processor 204 to initiate (or cause initiation of) a single message (e.g., a multi-push transaction or a multi-pull transaction), the single message including transaction information corresponding to each confirmation into a single message to a third party (e.g., the processing network computer 110). The confirmation module 220 may further comprise code that transmits the single message to a third-party computer (e.g., the processing network computer 110).
The display manager module 222 may comprise code, which causes the processor 204 to provide one or more interfaces to a user. In at least one embodiment, the one or more interfaces may be provided via an application (e.g., a sharing application such as the sharing application 106A-1 of
The computer readable medium 210 may comprise code, executable by the processor to implement a method comprising: receiving, by a server computer, a request to establish a group identifier for a group; generating, by the server computer, the group identifier for the group; transmitting, by the server computer, to a plurality of user devices operated by a plurality of users, group invitations to join the group; receiving, by the server computer from a subset of the plurality of user devices, group invitation responses; receiving, by the server computer from the subset of the plurality of user devices, confirmations to share a group transaction; and initiating a plurality of messages corresponding to the plurality of confirmations, wherein the plurality of messages result in an initiation of a single message to a third-party computer, the third-party computer being configured to conduct the group transaction according to the single message.
A. Conducting a Group Transaction
At step 302, a user may provide login information pertaining to a user account utilizing an interface provided by the application server computer 108 of
At step 304, a determination may be made by the application server computer 108 as to whether or not the user has previously registered with the login information. If the user has not previously registered with the application server computer 108 of
At step 312, the application server computer 108 may provide the user with two options. For example, a component of the application server computer 108 (e.g., the display manager module 222 of
Upon selecting the “create group” option at step 314, a component of the application server computer 108 (e.g., the display manager module 222) provides the user an interface to enable the user to provide group information (e.g., a group identifier) for the group. Upon receipt of the group information, a component of the application server computer 108 (e.g., the group manager module 214) may create record for the group and associate the record with the group information.
The flow may proceed to step 318, where a component of the application server computer 108 (e.g., the display manager module 222) provides a “create group transaction” option. Upon selecting the option to create a group transaction at step 318, the user is provided two options at step 320 (e.g., by the display manager module 222). At step 322, the user selects an option to scan a quick response (QR) code. Upon selecting the option, the user may utilize the user computing device to scan a QR code associated with a transaction (e.g., a restaurant bill). Alternatively, the user can select an option to type in group transaction information at step 324. Upon selecting the option at step 324, the user may utilize an interface provided by the application server computer 108 to manually provide group transaction information. Upon successful submission of group transaction information at step 322 or at step 324, a group transaction will be created at step 326 (e.g., by the transaction module 218 of
The user may alternatively find a group for which a group transaction already exists by selecting the “find group” option at step 316. Upon selecting the option to find a group, the application server computer 108 may provide a number of options at step 328. The options may include, but are not limited to, a “scan group” option and/or a “type in group information” option. At step 330, the application server computer 108 may provide an interface to scan for a group. Upon selecting such an option, a component of the application server computer 108 (e.g., the group search module 216 of
At step 338, a component of the application server computer 108 (e.g., the display manager module 222) provides to the user information regarding the group transaction associated with the group created/joined. The application server computer 108 further enables the user to confirm group transaction information at step 338. For example, the user may confirm an amount associated with a group transaction, the amount being a sub-portion (e.g., $10) of a total amount associated with the group transaction (e.g., $50). At step 340, a component of the application server computer 108 (e.g., the confirmation module 220) receives a confirmation indicating that the user confirms the accompanying group transaction information.
At step 342, a component of the application server computer 108 (e.g., the confirmation module 220) makes a determination as to whether or not each group member has confirmed the group transaction information. If there are still group members for which confirmation have not been received, then the application server computer 108 may wait for receipt of the next confirmation at step 340 to reassess the situation. Alternatively, the component of the application server computer 108 (e.g., the confirmation module 220) may make a determination at step 342 that all group members have confirmed the group transaction information. Accordingly, a component of the application server computer 108 (e.g., the confirmation module 220) may cause the processor 204 of
In at least one embodiment, the interface 500 may include an option 502 to create a group. Upon selection of the option 502, the user may be provided an edit box 504, for example, in order to enable the user to enter a group name. The user may utilize graphical element 506 to confirm the group name or otherwise indicate that their input has concluded. Upon selection of the graphical element 506, the sharing application 106A of
One such interface for creating a group transaction is depicted in
Returning to the flow diagram 400 of
Upon successful creation of the group, a component of the application server computer 108 (e.g., the transaction module 218 of
Alternatively, the user may select an option to scan for a group. Upon selecting such an option, the sharing application 106A-N (as instructed by a component of the application server computer 108 such as the display manager module 222 of
In at least one embodiment, the user may utilize the group information displayed at 808 to select a particular group to join at 810. Such a selection may be communicated to the application server computer 108 via the sharing application 106A-N at 812. Upon receipt of the selection, the application server computer 108 may execute instructions that cause the group participant 104 to be associated with the selected group. At 814, the application server computer 108 may provide to the sharing application 106A-N, a response indicating whether or not the group participant 104 was successfully associated with the group. The sharing application 106A-N (as instructed by a the display manager module 222) may display such information to the group participant 104 at 816.
For example,
In at least one embodiment, a group participant 104 may interact with the sharing application 106A (e.g., the sharing application 106A-N) in order to confirm his share at 1108 (e.g., utilizing an interface provided by the display manager module 222 such as the one depicted in
Returning to
In some embodiments, the authorization request messages are AFT messages and the transaction messages are AFT transactions. An AFT (Account Funding Transaction) is a transaction designed to supply funds to another account such as a Visa prepaid, debit, ATM card or on-line account. The AFT eventually will result in a debit to the sender's payment (card) account. Assuming that funds are available from the sender (or that credit is available), the issuer approves the transaction and the operator of the portal receives an indication via a processing network computer such as VisaNet that the authorization is successful.
As noted above, the crediting of the resource provider's account may be performed using an OCT transaction. Use of the OCT transaction generally assumes that the service provider bank and the recipient's issuer bank are different banks, and in that situation, the OCT transaction provides a convenient mechanism for money transfer. If the service provider bank and the recipient's issuer bank are the same bank, it is possible for that bank to simply perform an internal “on-us” credit posting to credit funds to the recipient's payment (card) account. Nevertheless, it is entirely possible that when the service provider bank and the recipient's issuer bank are the same bank, that the bank will choose to execute an OCT transaction rather than use their internal systems. This situation can occur if it is more difficult for the bank to connect internal systems than it is to execute an OCT transaction. In some cases, the time lag from the submission of the OCT transaction by the service provider bank to the actual credit of the recipient's card account can be two days or less.
Upon successful transmission of the OCT message, or at another suitable time, the processing network computer 110 may provide a transaction response at 1116. Upon receipt of the transaction response, the application server computer 108 may forward the transaction response to the sharing application 106A at 1118. Accordingly, the sharing application 106A may provide information from the transaction response to the group participant 104 at 1120 and/or to the group creator 102 at 1122. An example interface 1400 is provided in
At a later point in time, a clearing and settlement process may optionally occur between the authorizing entities (e.g., issuers) associated with the group members and the authorizing entity (e.g., an issuer) or acquirer associated with the resource provider (e.g., a merchant).
Embodiments of the present invention may also provide for faster transaction processing as it reduces the friction that occurs in transactions where users are required to perform multiple transactions individually instead of as a group. By including multiple transactions of a group into a single group transaction, computing resources and network bandwidth are conserved. Sharing electronic transactions is a problem that is routed in technology. By providing the embodiments of the invention described above, a solution is provided to enable a group of users to share a transaction in an user-friendly, efficient manner.
Also, as noted above, in embodiments of the invention, multiple debit messages may be sent to the various group members' issuers and this may be initiate the transmission of a single credit message to the resource provider's financial institution. If, for example, there are five customers at a restaurant, a single credit message may be sent to the resource providers' financial institution rather than five separate credit messages. This reduces the number of messages that would be transmitted relative to conventional group payment methods, and reduces the chances for errors, thereby improving transaction efficient.
The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described
Examples of such subsystems or components shown in the above figures may be interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory comprising computer readable media), monitor, which is coupled to display adapter, and others may be included. Peripherals and input/output (I/O) devices, which couple to I/O controller (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as a serial port. For example, the serial port or an external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or a fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may embody a computer readable medium.
Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
The above description is illustrative and is not restrictive. Many variations of the invention may become apparent to those skilled in the art upon review of the disclosure. The scope of the invention can, therefore, be determined not with reference to the above description, but instead can be determined with reference to the pending claims along with their full scope or equivalents.
One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.
