KR20170074855A - Facilitating sending and receiving of payments using message-based contextual prompts - Google Patents

Abstract

The present disclosure relates to a system, method and apparatus for transmitting and receiving payments using an integrated payment and messaging system. In particular, the integrated billing and messaging system allows users to exchange messages as well as send and receive electronic messages. Additional implementations include enabling payment transactions by reasoning payment events. Additional implementations include enabling payment transactions between groups of users. In addition, the one or more implementations allow a user to initiate a payment transaction without first providing a payment credential.

Description

{FACILITATING SENDING AND RECEIVING OF PAYMENTS USING MESSAGE-BASED CONTEXTUAL PROMPTS}

One or more embodiments relate generally to systems and methods for peer-to-peer electronic payment transactions. More particularly, one or more embodiments relate to a system and method for improving the ease and convenience of electronic payment transactions.

The electronic payment system allows a user to perform a payment transaction with another person through a software application on one or more types of devices (e.g., desktop devices and mobile devices). Some electronic payment systems allow users to perform payment transactions with financial institutions or businesses. Other electronic payment systems allow users to perform payment transactions (i.e., peer-to-peer payment transactions) with other users of the electronic payment system.

In theory, conventional electronic payment systems provide a convenient method for transferring money between users. However, conventional electronic payment systems have some disadvantages that often cause users to complain, disrupt and generate unsatisfactory payment processes. One of these disadvantages of the conventional electronic payment system is that it is generally a stand-alone system that both the sender and the receiver must register. Because of the number and limited functionality of such systems, it is often the case that one of the sender or receiver is not a member of a particular electronic payment system. Therefore, the sender, receiver or all may have to go through a time-consuming process of setting up an account to use the system to send or receive a payment and providing sensitive financial information. Often, the user may rarely use the electronic payment system after the first transaction.

In this regard, conventional electronic payment systems generally require users to provide sensitive financial information to access the functions of the system and begin the payment process. Therefore, users typically need to provide sensitive financial information in order to test the system or find friends who are using the system. When creating an account and providing sensitive financial information, the user may only attempt to send a payment to another user, knowing that the intended recipient is not the user or does not want to use the electronic payment system.

In addition, the payment process used by many conventional electronic payment systems is troublesome and complicated. For example, conventional electronic payment systems generally have an inflexible transaction structure and low flexibility. In other words, a user of a conventional system can only initiate and / or perform a payment transaction in a specified, predetermined manner. For example, the payment process of many conventional electronic payment systems involves the transmission of a series of emails with links. Users often have to continue the payment process, such as approving or declining payment by clicking on an email link. Process steps such as sending separate emails at each stage of an electronic transaction are not intuitive and can cause confusion or frustration to the user.

The limited nature of conventional electronic payment systems also adds to the inconvenience. In particular, the independent nature of traditional electronic payment systems typically requires that users open separate applications for payment transactions only to send or receive payments. The inconvenience of the independent nature of conventional electronic payment systems can frustrate users from using such a system.

For example, when sending a payment using a conventional stand-alone electronic payment system, the user can determine whether the intended recipient has registered with the electronic payment system, whether the intended recipient is capable of receiving the payment, You may or may not receive a payment. As such, a user of a conventional electronic payment system may feel that the payment is transmitted to the cyber space without any actual context or feedback.

In addition to the above, conventional electronic payment systems are limited to one-to-one payment transactions. Therefore, if a user wants to collect a payment from a plurality of counterpart users, or if he wants to send a payment to a plurality of counterpart users, the user should generally perform an individual transaction with each individual counterpart user. The time and effort required to collect payments from a group of users may cause the user to abandon the adoption of conventional electronic payment systems.

Therefore, the conventional electronic payment system and method have a number of disadvantages.

One or more of the embodiments described herein solves one or more of the above problems or other problems and / or provides advantages in a system and method for increasing the speed and convenience of electronic payment transactions. In particular, one or more embodiments provide a payment system that is integrated with a messaging system that allows two or more users to send and receive electronic payments as well as messages. For example, the system and method may enable a user to send electronic payment through a messaging interface that allows a user to exchange electronic messages with a counterpart user. The integration of electronic payment systems and messaging systems can provide users with the ability to send and receive electronic payments within the flow of conversations. Thus, one or more embodiments allow users to communicate and conduct transactions on settlement transactions without having to open a separate application dedicated to electronic settlement.

The integrated electronic payment and messaging system can also enable payment transactions to be performed flexibly in a natural flow that is not limited to a rigid predetermined process. For example, one or more systems may include reasoning of payment events based on a pass-through message exchanged between users. In particular, one or more embodiments analyze an electronic message exchanged between two or more users to determine whether there is a likelihood of a payment event involving more than one user. After deducing the payment event, one or more embodiments provide an option to initiate a payment transaction between users based on the inferred payment event. Thus, one or more embodiments may allow a user to initiate a payment transaction with another user based on a message exchanged between users without interfering with the natural flow of the message exchange.

One or more additional or alternative embodiments include providing an option to request payment from a group of users. In particular, one or more embodiments may detect that a user may wish to receive payment from a group of users. For example, the system and method can detect that a group of friends is in a restaurant or otherwise participates in an event that one user can pay for another user. The system and method may identify the user in the group and provide the user with the option of requesting a payment from a single transaction from the other user in the group.

Additionally, the systems and methods described herein may enable a user to initiate a payment transaction without first having to provide a payment credential. Therefore, the user can determine whether the desired recipient is a user of the system before providing sensitive financial information. If the desired recipient is not a user of the system, the system may ask the user to join the desired recipient and verify that the recipient has joined before providing the payment credential. Thus, one or more embodiments can ensure that the recipient will receive the funds before providing sensitive financial information.

In addition to the above, one or more embodiments include providing a selectable element to an interface of a messaging user interface to set a payment amount for a payment transaction. In particular, one or more embodiments provide a selectable element having an associated numeric (e.g., currency) value to request to initiate a settlement transaction in a conversation with another user. In one or more embodiments, selecting one or more selectable elements may increase the settlement amount of the settlement transaction to a corresponding numerical value of each selected element. The selectable elements allow the user to incrementally increase the amount of payment in real time.

Additional features and advantages of the embodiments are set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of such exemplary embodiments. The features and advantages of such embodiments may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims. These and other features will become more fully apparent from the following description and the appended claims, or may be learned by practice of such exemplary embodiments, which are described below.

Are included in the scope of the present invention.

In order to explain the manner in which the above-recited, other advantages and features of the present disclosure can be obtained, a more particular description of the present invention, briefly summarized above, will be made with reference to specific embodiments shown in the accompanying drawings. It should be noted that the drawings are not drawn to scale and that elements of similar structure or function are generally designated with the same reference numerals throughout the drawings for illustrative purposes. In the following figures, blocks (e.g., large dashes, small dashes, dashed-dashes, dashes, and dashes) with parenthesized text and dotted border boundaries are shown to illustrate optional features or operations that add additional features to the embodiments of the present disclosure. ) Is used herein. However, such notation should not be taken to mean that they are the only option or optional operation, and / or that blocks with solid boundaries are not optional in certain embodiments of the present specification. It will be appreciated that these drawings depict only typical embodiments of the present invention and are therefore not to be considered limiting of its scope, and this specification will be described and explained with additional specificity and detail through the use of the accompanying drawings .
1 illustrates a schematic diagram of an exemplary system that facilitates the transmission of messages and settlements in accordance with one or more embodiments.
Figure 2 shows a detailed schematic diagram of the system of Figure 1 in accordance with one or more embodiments.
Figures 3a-3d illustrate a sequence-flow diagram illustrating interaction as part of a payment process between a sender and a recipient in accordance with one or more embodiments.
Figures 4A-4O illustrate a user interface for completing a payment transaction as described with reference to Figures 3A-3C in accordance with one or more embodiments.
5A-5D illustrate a user interface for initiating a settlement without first providing a payment credential according to one or more embodiments.
6A-6C illustrate a user interface for performing settlement transactions in the flow of conversations according to one or more embodiments.
Figures 7A-7C illustrate a user interface for performing payment transactions based on inferred payment events in accordance with one or more embodiments.
8A-8E illustrate a user interface for collecting payments from a group of opponent users according to one or more embodiments.
9A-9B illustrate a user interface for initiating a settlement from a group of opponent users according to one or more additional embodiments.
10 illustrates a flow diagram of a sequence of actions for inferring a payment event based on an exchanged message according to one or more embodiments and initiating a payment transaction in response to the inferred payment event.
11 illustrates a flow diagram of a sequence of actions for inferring a payment event based on an exchanged message according to one or more embodiments and initiating a payment transaction in response to the inferred payment event.
12 illustrates a flow diagram of a sequence of actions in a method for enabling group settlement transactions in accordance with one or more embodiments.
FIG. 13 illustrates a flow diagram of a sequence of actions of another method for enabling group settlement transactions in accordance with one or more embodiments.
Figure 14 illustrates a flow diagram of a sequence of actions in a method for initiating a settlement without first providing a payment credential in accordance with one or more embodiments.
Figure 15 shows a flow chart of a series of actions of another method for initiating a settlement without first providing a payment credential according to one or more embodiments.
Figure 16 shows a flow diagram of a series of actions in a method for setting a payment amount for a payment transaction in accordance with one or more embodiments.
Figure 17 shows a flow diagram of a series of actions of another method of setting a payment amount for a payment transaction in accordance with one or more embodiments.
18 shows a block diagram of an exemplary computing device in accordance with one or more embodiments.
19 illustrates an exemplary network environment of a social networking system in accordance with one or more embodiments.
20 illustrates an exemplary social graph for a social networking system in accordance with one or more embodiments.

Embodiments of the present disclosure provide an integrated messaging and payment system that increases the ease and efficiency of sending and receiving payments. In particular, one or more embodiments provide an integrated messaging and payment system that integrates an electronic payment system and an electronic messaging system. The integrated messaging and billing system may allow two or more users to send and receive messages as well as electronic payment. For example, the unified messaging and payment system may allow the user to send an electronic payment to the counterpart user (s) via a messaging interface that also allows for the exchange of electronic messages with the counterpart user (s).

By integrating an electronic payment system and a messaging system, the system can provide the user with the ability to send and receive electronic payments within the conversation flow. Thus, the system can allow the user to communicate and perform transactions on the payment transaction without opening a separate application dedicated to electronic payment. Increased ease and efficiency of smoothly transferring payment during the exchange of messages provided by one or more embodiments of the system can lead to greater use and satisfaction of electronic payments.

An integrated messaging and billing system can provide flexibility in initiating settlement transactions. In other words, by integrating an electronic payment system and a messaging system, the system can allow a user to initiate a payment in various ways. In particular, the integrated messaging and billing system allows a user to initiate a payment based on the context of the conversation without being limited to starting the payment with a strict predetermined process. For example, the integrated messaging and billing system can infer payment events based on electronic messages exchanged between users. Specifically, the unified messaging and billing system can analyze electronic messages exchanged between two or more users to determine whether a payment event is likely to occur. After inferring the payment event, the integrated message and payment system may provide an option to initiate a payment transaction between the users based on the inferred payment event. Thus, in one or more embodiments, the unified messaging and billing system may allow a user to initiate a settlement transaction with another user based on a message exchanged between the users without interfering with the natural flow of message exchange between users.

Specifically, the integrated message and billing system can identify a specific phrase or string that represents or inferences a payment event. For example, the network system can identify the string "You owe me $ 15 in a movie ticket". Based on the inferred payment, the integrated messaging and billing system may provide an option to initiate a payment or otherwise suggest that one or more users transmit the payment. For example, the network system may set "$ 15" as an optional element that the user can choose to initiate a payment.

In one or more additional embodiments, the integrated message and billing system may provide an option to request a payment from a group of users. In particular, the integrated messaging and billing system can detect that a user may desire to receive a payment from a group of users. For example, the system may detect that a group of friends is in a restaurant or otherwise participates in an event that one user can pay for another user. The integrated messaging and billing system can identify users within the group and provide the user with the option of requesting a payment from a user within the group in a single transaction.

Additionally, one or more embodiments of the integrated message and billing system described herein may enable a user to initiate a payment transaction without first having to provide a payment credential. Therefore, the user can determine whether the desired recipient is a user of the system before providing sensitive financial information. If the desired recipient is not a user of the unified messaging and billing system, the unified messaging and billing system may allow the user to request that the intended recipient subscribe. Therefore, the integrated messaging and payment system can ensure that the recipient will receive the funds before providing sensitive financial information.

If the recipient subscribes or provides a payment credential, the integrated message and payment system can induce the sender to complete the payment by providing a payment credential. As such, the unified messaging and billing system may apply other types of social pressure to send a reminder to the recipient or induce the sender to provide a payment credential. Social pressure can encourage senders to complete payment transactions by providing payment information.

In addition, the one or more embodiments provide a user interface that provides a more efficient and / or more enjoyable user experience when sending or receiving a payment. For example, one or more embodiments include custom graphical user interface objects that enhance a user's experience. Specifically, the message user interface may include icons, stickers, or other selectable objects tailored to the user. For example, the integrated messaging and billing system can provide a different graphic object corresponding to a common call, which can detect a user's location and select a sticker or a user to enter a payment amount. The integrated messaging and billing system can detect each selection of sticker / object and increase the payment amount. As such, an integrated messaging and payment system can provide users with an experience similar to taking money from a purse or handbag to reach a payment amount.

As such, the integrated messaging and billing system senses or infer the payment amount and provides the user with a sticker or other selectable icon or object corresponding to the inferred or sensed amount. Therefore, the integrated messaging and billing system can increase the efficiency by reducing the need for the user to enter the payment amount.

As used herein, the term "message" or "messages" refers to any form of electronic communication between two or more computing devices. The message may include a text message, a picture, a sticker or other icon, video, voice recording, music, voice mail, and the like. In one or more embodiments, the message is an instant message that is communicated in real time or near real time. However, in an alternative embodiment, the message may refer to anything from an electronic communication, such as an SMS message, an e-mail, or a social network post or comment.

The term "payment message" also refers to a message that indicates payment information that allows the system to initiate a payment transaction. For example, the payment message may include a data package that includes additional information such as payment amount, sender, recipient, payment method, as well as user-provided text for the message.

As used herein, the term "settlement transaction" refers to any type of electronic transaction in which a currency or credit is exchanged between two or more entities. For example, a payment transaction may be a financial electronic transaction between two users of an integrated message and payment system. In another example, a payment transaction may be a financial electronic transaction between a user and a financial institution or another multi-person entity. In addition, the settlement transaction may represent a monetary gift, a redemption of a liability, a loan, a settlement considering the purchase of goods and / or services, or another type of money transfer. Additionally, the payment transaction can be in one or more currencies and can be converted into one or more additional currencies based on the exchange rate.

As used herein, the terms "event" and "payment event" refer to any action associated with a payment transaction. Specifically, an event refers to an action that initiates, attempts to initiate, completes, or otherwise associates a payment transaction between an integrated message and two or more entities by a billing system or user. For example, the billing system may initiate a payment transaction (e.g., request a payment or make a payment), complete a payment transaction, or perform another action associated with a payment transaction, from an electronic message by a user of the integrated message and payment system You can infer an event indicating that you want to do so.

As used herein, the term "natural language syntax" refers to text that includes the common language used by the user. Specifically, the natural language syntax may include special syntax or text that is not specifically structured to interact with the computing device. For example, a natural language syntax may include a dialogue language between two users of an integrated message and billing system. Described herein, a user may use natural language when communicating with each other through a messaging graphical user interface (e.g., text message, email or chat message).

As used herein, the term " account "or" payment credential "refers to a user's debit card account, bank account, credit card account, messaging account, gift card, It can refer to any other account. The meanings of the terms and additional terms will become more apparent in light of the following description with reference to the drawings.

1 is a schematic diagram illustrating an integrated messaging and payment system 100 in accordance with one or more embodiments. An overview of the system 100 is described with reference to FIG. Thereafter, a more detailed description of components and processes of the system 100 is provided in connection with the remaining figures.

As shown in FIG. 1, the system 100 uses a corresponding number of client devices 104a, 104b, 104n to communicate with a user 102a, a user 102b and a maximum any number of users 102n Quot; user ") interact with each other. As further shown in FIG. 1, a client device may communicate with server device (s) 108 via network 105. In addition, the system 100 may include a payment network 115 communicatively coupled to the server device (s) 108 via a network 105. 1 illustrates a particular arrangement of a user, client device, network 105, server device network 115, but various additional arrangements are possible. For example, the client devices 104a, 104b, 104n may communicate directly with the server devices 108 by bypassing the network 105. [

As mentioned briefly above, Figure 1 shows that user 102a and user 102b may use each of client devices 104a and 104b to communicate with each other through server device (s) 108 Respectively. For example, user 102a and user 102b may exchange electronic messages that include text, digital content (e.g., audio, image, video), location information, and other types of data and information . For example, a user 102a using the client device 104a may create an intended message for the user 102b. After creating the message, the user 102a may cause the client device 104a to send the message intended for the user 102b to the server device (s) 108 over the network 105. [ The server device (s) 108 may identify the user 102b as the intended recipient and forward the message to the client device 104b associated with the user 102b.

In addition to allowing a user to exchange electronic communications, the system 100 may allow a user to send and receive money payments to each other. In one or more embodiments, the system 100 may allow a user to define a payment message and send it to another user. For example, the system 100 may allow the user 102a to send a payment to the user 102b via the server device (s) 108 and the payment network 115. [ Similarly, the user 102b may receive a notification of payment and accept or decline the payment. As described in greater detail below, the server device (s) 108 may communicate with the payment network 115 to coordinate transactions facilitating settlement between users (i.e., their accounts).

While system 100 may facilitate settlement between users 102a and 102b, system 100 may also facilitate settlement between two or more users, such as a group of users. For example, user 102a may send a payment to users 102b and 102n. In one or more embodiments, the user 102a may send a payment to multiple users within the same payment transaction, as described in more detail below. In addition, in one or more embodiments, a group of users may be provided with the ability to send and / or receive a payment to or from another group or individual user via the system 100.

On the other hand, Figure 1 shows users as people, but users may include other entities such as business, government, or other entities. For example, user 102a may use system 100 to provide a payment for a service or product to a business. For example, the user 102a may communicate with the business via the system 100 and ultimately may decide to make a purchase of the product or service from the business. Using the same system 100, the user 102b may then send a payment for the product or service to the business. Similarly, a business can send payments to another business or supplier regardless of whether it is an individual or a business entity.

As described above, as shown in FIG. 1, users 102a and 102b may interact with client devices 104a and 104b, respectively. Examples of client devices include computing devices such as mobile devices (e.g., smart phones, tablets), laptops, desktops, or any other type of computing device. 18 and the corresponding description provide additional information regarding the computing device. Also, as described above, the client device may communicate via the network 105. In one or more embodiments, the network 105 includes the Internet or the World Wide Web. However, the network may include one or more private and / or public networks using various communication technologies and protocols, which will be further described below with reference to FIG.

As briefly described above, the system 100 may coordinate the transmission and receipt of payments between users. For example, the user 102a may create a payment message and send it to the user 102b. For example, user 102a may define a payment method (e.g., credit card, debit card, account balance of originating user 102a), payment amount, payment currency, billing description and / Lt; RTI ID = 0.0 > 104a. ≪ / RTI >

For example, from the perspective of the user 102a, the originating user 102a may create and transmit a payment message in a manner similar to transmitting a communication message (e.g., text). For example, in one or more embodiments, the user 102a may create a payment message indicating the amount of payment the user 102a wishes to transfer to the user 102b. After creating the payment message, the originating user 102a may then send a payment message to the user 102b via the server device (s).

In one or more embodiments, the system 100 may coordinate transactions between one or more accounts of the originating user 102a and one or more accounts of the receiving user 102b via the payment network 115. For example, in response to receiving a payment message from an originating user 102a, the server device (s) may communicate transaction information processing payment using one or more components within the payment network 115. [ Alternatively or additionally, the system 100 may directly maintain one or more user accounts, and thus the system 100 may adjust the portion of the transaction or transaction.

As shown in FIG. 1, the payment network 115 may include a payment gateway system 118, a payment processing system 120, a card network system 122, and an issuing bank system 124. However, in an alternative embodiment, the payment network 115 may include more or fewer components, depending on the particular embodiment of the system 100. [

In one or more embodiments, for example, the system 100 may communicate with the payment network 115 to authorize and process the transaction. For example, the system 100 may send a transaction to the payment gateway system 118 as shown in FIG. Once the payment gateway system 118 receives the transaction, the payment gateway system 118 may send the transaction to a processor (e.g., the payment processing system 120) used by the payment receiving user acquisition bank. The payment processing system 120 may send the transaction to the appropriate card network system 122 based on the method of payment (e.g., the account of the calling user). In many instances, the card network system 122 then forwards the transaction to the issuing bank system 124.

The issuing bank system 124 approves or rejects the transaction and sends the decision back to the card network system 122. The card network 122 then sends a decision to the payment processing system 120. The payment processing system 120 may then forward the determination to the payment gateway system 118, and in one or more embodiments, the payment gateway system 118 may manage the details associated with the transaction and the determination. The payment processing system 120 also sends a decision to the system 100.

In addition to transaction approval, payment network 115 may also perform settlement operations. For example, the system 100 may cooperate with the payment gateway system 118 to submit a daily bulk settlement, including one or more captured transactions, to the acquisition bank via the acquisition bank's preference payment processing system 120. The settlement processing system 120 then sends a lump sum settlement to the server of the acquisition bank (not shown), which records the deposit of each transaction within the lump sum settlement of accounts associated with the settlement receiving user.

The acquiring bank may then send a request for funds that satisfies the deposit amount to the payment processing system 120 and the payment processing system 120 forwards the funds request to the appropriate card network system 122. [ Card network system 122 then sends the request for funds to issuing bank system 124. The issuing bank system 124 may post the transaction to the account of the originating user and deliver the release of funds to the card network system 122 and the release of the funds may then be forwarded to the payment processing system 120, . Additional details regarding the specific systems, methods, components, and processes of the system 100 are described below.

2 shows a schematic diagram showing further details of the system 100. As shown in FIG. As shown, the system 100 may include client devices 104a and 104b, server device (s) 108, and a payment network 115. In general, the system 100 may allow a user of the client device 104a to send a payment or receive a payment to the recipient of the client device 104b. In addition, the system may allow a user of client device 104a to exchange messages with a user of client device 104b.

As shown, the system 100 may include various components on the client devices 104a and 104b and the server device (s) For example, FIG. 2 illustrates a client application 102 (FIG. 2) in which client devices 104a and 104b each may include a client application 202 having various components and a server device ). ≪ / RTI > The client application 202 and the components of the network application 204 operate together to allow a user to send a payment, receive a payment, and exchange messages as described in detail below.

As shown, the client application 202 includes a user interface manager 206, a user input detector 208, a messaging handler 210, a message analyzer 212, a position detector 214, a payment message generator 216, And a data manager 218. Figure 2 illustrates a network application 204 that includes a communications manager 230, a status manager 232, a message database 234, a billing manager 236, a transaction database 238, a profile database 240, As shown in FIG. As described below, the network application 204 may also optionally include a social graph 250, which includes node information 252 and edge information 254. Each of the components 206-218, 230-240, and 236-254 may communicate with each other using any suitable communication technology. Although components 206-218, 230-240, and 236-254 are shown as separate in Figure 2, any of the components 206-218, 230-240, 236-254 may be a single facility or module Or may be divided into a larger number of components that can provide a particular embodiment. 2 depicts specific components as part of network application 204 and as part of other components and client application 202, although the invention is not so limited. In an alternate embodiment, one or more components shown as part of the client application 202 may be part of the network application 204 or vice versa.

The components 206-218, 230-240, and 236-254 may include software, hardware, or both. For example, components 206-218, 230-240, 236-254 may be stored on non-volatile computer-readable storage media and stored on client devices 104a, 104b or server device (s) 108 And may include computer instructions executable by at least one processor. When executed by at least one processor, the computer-executable instructions may cause the client device (s) 104a, 104b or the server device (s) 108 to perform the methods and processes described herein. Alternatively, components 206-218, 230-240, and 236-254 may include hardware, such as a special purpose processing device, to perform a particular function or group of functions. Additionally or alternatively, the components 206-218, 230-240, 236-254 may comprise a combination of computer-executable instructions and hardware.

In one or more embodiments, the client application 202 may be a native application installed on the client device 104a, 104b. For example, the client application 202 may be a mobile application that is installed and executed on a mobile device, such as a smartphone or tablet. Alternatively, the client application 202 may be a desktop application, a widget, or any other form of native computer program. Alternatively, the client application 202 may be a remote application accessed by the client device 104a, 104b. For example, the client application 202 may be a web application running within the web browser of the client devices 104a, 104b.

As noted above and as shown in FIG. 2, the communication application 202 may include a user interface manager 206. The user interface manager 206 may provide, manage, and / or control a graphical user interface (or simply "user interface") to allow a user to create, view, . For example, the user interface manager 206 may provide a user interface that facilitates creation of a message, such as an instant message. Similarly, the user interface manager 206 may provide a user interface for displaying messages received from other users.

More specifically, the user interface manager 206 may facilitate display of the user interface (e.g., via a display device associated with the client device 104a, 104b). For example, the user interface may comprise a plurality of graphical components, objects, and / or elements that allow a user to create, send, and receive messages or payments. More specifically, the user interface manager 206 may instruct the client device 104a, 104b to display a group of graphical components, objects, and / or elements that enable a user to view a communication thread (e.g., FIG. 4A) .

In addition, the user interface manager 206 may instruct the client device 104a, 104b to display one or more graphical objects or elements that facilitate user input for composing and sending messages. For illustrative purposes, the user interface manager 206 may provide a user interface that allows a user to provide user input to the communication application 202. For example, the user interface manager 206 may provide one or more user interfaces that allow a user to enter one or more types of content as messages. As used herein, "content" refers to any data or information to be included as part of a message. For example, the term "content" will be used herein to describe any text, image, digital media, file, location information, billing information, and any other data that may be included as part of the message.

As described above, an example of the content that can be included in the message is the payment from the calling user to the receiving user. In one or more embodiments, the user interface manager 206 may provide a user interface that allows a user to easily and efficiently define and transmit a payment to one or more other users. For example, the user interface manager 206 may provide one or more input fields and / or one or more user selectable elements through which a user may interact to create and transmit a payment.

In addition to the above, the user interface manager 206 may receive commands or communications from one or more components of the communication application 202 to display updated message information, updated status of payment and / or updated available actions can do. The user interface manager 206 may update the available options based on whether a particular option is available at a particular point in the transaction process. The user interface manager 206 may add, remove, and / or update various other selectable behaviors within the sender and / or recipient status messages, as described below.

The user interface manager 206 may facilitate input of text or other data to be included in an electronic communication or message. For example, the user interface manager 206 may provide a user interface that includes a keyboard. The user may interact with the keyboard using one or more touch gestures to select text to include in the electronic communication. For example, a user may use the keyboard to describe one or more other content items in electronic communication and / or to enter accompanying messages. In addition to text, a user interface including a keyboard interface can facilitate input of various other characters, symbols, icons, or other character information.

Accordingly, the user interface manager 206 provides a user interface that provides a more efficient and / or more enjoyable user experience when sending or receiving a payment. The user interface manager 206 may provide a message user interface that may include icons, stickers, or other selectable objects tailored to the user. For example, the user interface manager 206 may provide a sticker or other graphical object corresponding to a common call that the user may choose to enter a payment amount. As such, the user interface manager 206 may provide the user with an experience similar to withdrawing money from a purse or handbag to reach a payment amount. As such, the user interface manager 206 may provide a sticker or other selectable icon or object corresponding to the inferred or detected amount. Therefore, the user interface manager 206 can increase the efficiency by reducing the need for the user to input the payment amount.

As further shown in FIG. 2, the communication application 202 may include a user input detector 208. In one or more embodiments, the user input detector 208 may detect, receive and / or facilitate user input in any suitable manner. In some examples, the user input detector 208 may detect one or more user interactions with the user interface. As referred to herein, "user interaction" means a single interaction or combination of interactions received from a user via one or more input devices.

For example, the user input detector 208 may detect user interaction from a keyboard, mouse, touchpad, touch screen, and / or any other input device. If the client device 104a, 104b includes a touch screen, the user input detector 208 may include one or more touch gestures (e.g., gesture swipe, tap gesture, pinch gesture, or reverse pinch) from the user Gesture) can be detected. In some instances, a user may provide a touch gesture directed to and / or associated with one or more graphic objects or graphic elements of the user interface.

The user input detector 208 may additionally or alternatively receive data indicative of user interaction. For example, the user input detector 208 may receive one or more user configurable parameters from the user, one or more user commands from the user, and / or any other appropriate user input. User input detector 208 may receive input data from one or more components of communication application 202, from a repository of client devices 104a and 104b, or from one or more remote locations (e.g., network application 204) can do.

The communication application 202 may perform one or more functions in response to the user input detector 208 detecting user input and / or receiving other data. In general, by providing one or more user inputs that the user input detector 208 can sense, the user controls the communication application 202 and navigates within it, otherwise the communication application 202 Can be used. For example, in response to user input detector 208 detecting a user input, one or more components of communication application 202 may allow a user to select a recipient for a message, compose a message, Select the content, and / or send the message to the recipient. Also, in response to the user 208 detecting a user input by the detector 208, one or more components of the communication application 202 may navigate through one or more user interfaces for reviewing a received message, I will.

In one or more embodiments, in response to the user input being detected by the user input detector 208, the communication application 202 may cause the user to generate a payment to be sent to one or more other users. For example, a user desiring to send a payment may interact with a payment element provided in a menu in the user interface. Upon detection of a user interaction with a payment element, the user input detector 208 may cause the user interface manager 206 to provide a user interface for generating a payment. Thus, in response to the user input detector 208 detecting a user input, the communication application 202 may cause the user to create a customized payment that defines the payment to be sent to the other user, as described below.

As further shown in FIG. 2, the communication application 202 may be provided or may include a message handler 210 that manages the message sent from the communication application 202. For example, the message handler 210 may interact with the user interface manager 206 and the user input detector 208 to coordinate the transmission and reception of messages using the communication application 202. The message handler 210 may direct the sending and receiving of messages from the network application 204 to the network application 204 on the course of the electronic message session between a plurality of participants. The message handler 210 may organize incoming and outgoing messages and direct the user interface manager 206 to display the messages.

In one or more embodiments, the message handler 210 may facilitate receiving and transmitting data through the communication application 202. [ In particular, the message handler 210 may facilitate transmission and reception of messages. For example, the message handler 210 may format the message and package the content to be included in the message in any mandatory form that may be transmitted over one or more communication channels, using an appropriate communication protocol, as described herein . Similarly, the message handler 210 may process messages that the client device 204 receives from other users.

In addition to providing a communication function for the communication application 202, the message handler 210 may provide access to the message data. For example, the message handler 210 may access the contact list to include or data representing one or more contact groups and recipients for the message. For illustrative purposes, the message handler 210 may obtain and provide data representing the contact list to the user interface manager 206, and may allow the user to search and browse the contact list, and ultimately, You can choose to select a contact or contact group. In one or more embodiments, the social networking system may manage remote contact list data (e.g., a "buddy list") and the message handler 210 may include a contact list on the social networking system Data can be accessed.

The message handler 210 may also provide access to other local or remote data that the communication application 202 may use to create, send, and receive messages. For example, the message handler 210 may obtain access to files, images, audio, video, and other content that a user may include in the message. Moreover, the message handler 210 may provide access to one or more functions of the originating client device 204 to provide the user with the ability to capture or generate content to include in the message. For example, the message handler 210 may activate a camera, microphone, or other function that allows the user to capture the content to include in the message.

Additionally, the message handler 210 can facilitate the transfer of payment. In particular, FIG. 2 includes a payment message generator 216 in which the communication application 202 may generate a payment message that the message handler 210 may send to the network application 204 to initiate a payment process / transaction . For example, when the sender selects a payment component on the user interface, the payment message generator 216 may generate a data package containing the payment information received from the sender. The payment message may include an indication of the amount of money to be transferred as part of the payment transaction as well as any necessary information that allows the network application to perform the payment transaction.

In one or more embodiments, the payment message generator 216 may generate a payment message from the payment amount, one or more sender identifiers, one or more recipient identifiers, one or more payment methods or sender account information, authentication information, call information, And may generate a data package that includes any other data that may help facilitate payment to the recipient. Alternatively, the payment message may simply identify the recipient and amount of the payment. The payment message generator 216 may forward a payment message (e.g., a data package containing billing information) to the message handler 210 for transmission to the network application 204. [

The payment message generator 216 may also obtain payment information from various sources. For example, the payment message generator 216 may obtain payment information directly from the sender via the user input detector 208. Additionally or alternatively, the payment message generator may obtain access to the payment information managed by the data manager 218 on the client device 104a, 104b. For example, the communication application 202 may allow a sender to enter and store various payment methods and / or to identify a default payment method, a default currency call, or other user preferences associated with the transmission and / or reception of a payment .

In one or more embodiments, the payment message generator 216 may access and provide the token within the payment message. The token may reference a payment credential stored by the network application 204. For example, the payment message generator 216 may include a payment message that is included in the payment message or identifies the originator and / or originating client device 104a authorized to create a payment using the payment credential stored by the network application 204, Token to be included together with the token.

As mentioned above, the client application 202 may further include a message analyzer 212. [ The message analyzer 212 may analyze the messages sent or received by the client application 202 for potential payment events. In one or more embodiments, the message analyzer 212 may deduce a payment event from an electronic message exchanged between users based on the contextual content in the exchanged message. Specifically, the message analyzer 212 may identify a particular phrase or character string that represents an opportunity for settlement. For example, a character string may comprise a predetermined character string from an electronic message in a conversation between two or more users. Identifying a predetermined character string that indicates a payment event in a message allows the message analyzer 212 to deduce a payment event without complying with stringent requirements for a user to initiate a payment transaction with one or more other users.

According to some embodiments, the message analyzer 212 may analyze the natural language. In particular, a user may communicate with one or more other users using a natural language phrase of an electronic message. By using natural language detection, the message analyzer 212 can interpret the contents of the message to other users. If the user sends a request to start a payment transaction using a natural language, the message analyzer 212 may provide an option to infer the request from the natural language and initiate a payment transaction. Additionally or alternatively, the message analyzer 212 may provide an option to complete the initiated payment transaction.

In accordance with one or more additional or alternative embodiments, the message analyzer 212 may provide a method by which a user initiates group settlement based on a message associated with a user of the system 100. Specifically, the message analyzer 212 can identify group events associated with two or more users by analyzing an electronic message, user's location, social network data or other data from one or more users and / or one or more users. For example, the message analyzer 212 may include a message in the information feed associated with the user, social network data (check-in, user profile, post, likes, information about the friend), a message of conversation between two or more users, The message or any other electronic message associated with the user may be analyzed to identify the natural language or string associated with the event. Additionally, the message analyzer 212 may determine the number of users in the group based on the electronic message.

The message analyzer 212 may provide an option to request one or more users in the group to request payment from other users in the group using the inferred events and users in the determined group. In particular, the message analyzer 212 may identify one or more group readers to provide an option to request a payment. The one or more group readers may then request payment for a transaction on the payment or event for the event from the identified one or more users in the group. The user who has received the request can then make a payment to one or more group leaders using the payment system.

After deducing the payment event, the message analyzer 212 may provide an option to initiate a payment transaction based on the inferred payment event. Thus, in one or more embodiments, the system 100 may allow a user to initiate a settlement transaction with another user based on a message exchanged between users without interfering with the natural flow of messages between users. Specifically, the message analyzer 212 can identify a particular phrase or string that indicates or inferences a payment event. For example, the message analyzer 212 may identify the string "You owe me $ 15 in a movie ticket." Based on the inferred payment, the message analyzer 212 may instruct the user interface manager 206 to provide an option to initiate a payment or otherwise suggest that one or more users send a payment. For example, the user interface manager 206 may set "$ 15" as a selectable element that a user may select to initiate a payment.

The client application 202 may further include a position detector 214. The location detector 214 may determine the location of the client device 104a, 104b, cell tower triangulation, WIFI received signal strength indication, WIFI wireless fingerprint, wireless-frequency identification, 104b may access or identify the location of the client device 104a, 104b based on the GPS information from the long-distance communication. The location detector 214 may then provide the location of the client devices 104a and 104b to the message analyzer 212 or the network application 204. [ In addition, the location detector 214 may receive an indication of the location of other client devices from the network application 204 and provide them to the message analyzer 212.

As discussed above, the client device 104a may include the data manager 218 shown in FIG. The data manager 218 may manage message data indicating the data used in conjunction with creating, sending, and receiving messages between the user and one or more other users. For example, the message data may be associated with providing the ability for a user to communicate using a message log, contact list, content, historical communication, and communication application 202 to provide other similar types of communication applications 202 Data may be included.

The data manager 218 may also manage payment data indicating the information used to generate the payment message. For example, payment data may include payment method data (i.e., credentials) and such account data (e.g., bank or credit card account data). In addition, the payment data may include a payment preference (e.g., a default payment method). In general, the payment data may include any data that can be used in conjunction with the payment message generator 216 generating a payment.

As described briefly above, in addition to the client devices 104a and 104b, the system 100 may further include a network application 204 in which all or part is implemented in the server device (s) In one or more embodiments of the invention, the network application 204 includes a social networking system (e.g., but not limited to FACEBOOK (TM)), while in other embodiments the network application 204 includes an email application, A search engine application, a banking application, or any other type of application that uses a user account.

In one or more embodiments in which network application 204 includes a social networking system, network application 204 may include a social graph 250 for representing and analyzing a plurality of users and concepts. The node repository 252 of the social graph 250 may store node information including a node for a user, a node for a concept, a node for a transaction, and a node for an item. The edge store 254 of the social graph 250 may store edge information including relationships between nodes and / or behaviors that occur within the social networking system. Additional details regarding social networking systems, social graphs, edges, and nodes are provided below with respect to FIG.

The communication manager 230 may process messages received from the client application 202. For example, the communication manager 230 may interact with the message handler 206 of the client application 202. The communication manager 230 may serve as an indicator for a message that is sent back and forth between users in an electronic message conversation. The communication manager 230 may receive the message from the client application 202, detect the intended recipient of the message, and send the message to the client application 202 (or device) associated with the intended recipient. A typical descriptor recognizes that the communication manager 230 may direct a message for a recipient to a number of client devices associated with the recipient (i. E., Each device for which the user has installed a version of the client application 202) something to do.

In addition, the communication manager 230 may also re-format or otherwise modify the content or format of the message based on the messaging protocol used by the destination communication device or type. Thus, in one or more embodiments, system 100 may allow participants using different communication platforms to exchange messages. For example, the communication manager 230 may receive messages from a first protocol (SMS, IM, XMPP, APNS, etc.), re-format the messages into a second protocol, Lt; / RTI >

State manager 232 may track the status of the users of client application 202 and / or client devices 104a, 104b. For example, state manager 232 may determine when the user is logged in to client application 202, when the user is active in client application 202, when client device 104a, 104b associated with the user or user account is online or active Can be identified. The state manager 232 may send an indication (e.g., a push notification) to the client application 202 to inform the client application 202 of the status of the user, device, message or payment. The user interface manager 206 may add, modify, or change or update the status notification based on the indication received from the status manager 232. For example, the status manager 232 may indicate that another user is accessing a message, receiving a payment, sending a payment, being active, or displaying a device or device type (e.g., mobile vs. web) To the client application 202. < RTI ID = 0.0 > The user interface manager 206 eventually updates the user interface to inform the user of the status.

The network application 204 may also include a message database 234. The message database 234 may manage message data representing the content of messages from an electronic message session among a plurality of participants. The message database 234 may manage state data representing the above-mentioned information tracked by the state manager 232. The message database 234 thus provides an archive of message threads that the network application 204 can provide to the user when there is a demand or once the user logs into the client application 202 using the new computing device can do.

The payment manager 236 of FIG. 2 may integrate the sending and receiving of payment messages, initiate payment transactions, and may use one or more application programming interfaces (APIs). For example, when communication manager 230 is able to receive a payment message, communication manager 230 may send any payment details to payment manager 236. The payment manager 236 may then use the payment details retrieved from the payment message to initiate a payment transaction using the payment network 115.

The payment manager 236 may adjust the transaction corresponding to the payment defined in the payment message. As described generally above, the payment manager 236 may coordinate transactions through the payment network 115 corresponding to payment messages, monitor the status of the transactions, and provide status information related to the transactions. More specifically, the payment network 115 may authenticate the transaction, fund the transaction, and / or resolve the group of individual transactions or transactions described above with reference to FIG. In one or more embodiments, the payment manager 236 may use one or more application programming interfaces (APIs) to communicate relevant information to the payment network 115.

To complete the transaction, the payment manager 236 may access or obtain a payment credential for the recipient (e.g., deposit account information, debit card, credit card, gift card, electronic wallet). The payment manager 236 may obtain the recipient's payment credentials in a variety of ways. In one exemplary embodiment, the recipient may register one or more deposit accounts or other payment credentials to the network application 204. [ If the user registers another payment credential or deposit account, the user profile database 240 may manage the payment credentials.

After the payment manager 236 receives the payment information, the payment manager 236 can identify the recipient. The payment manager 236 may index the recipient in the user profile database 240 to determine whether the recipient has registered a payment credential. At this point, the payment manager 236 may initiate the transaction.

If the recipient's user profile does not include a payment credential, the payment manager 236 may instruct the communication manager 230 to send a message to the recipient to encourage the recipient to provide a payment credential. The message may encourage the recipient to register a payment credential by providing one or more interactive fields that allow the recipient to provide payment credential details. Additionally or alternatively, if the recipient determines that he or she does not have a registered payment credential, then the payment manager 236 may generate a temporary deposit 242. In particular, the payment manager 236 may generate an account number and associate the account number with the recipient's user profile. In one or more embodiments, the recipient may already have a temporary account 242, and therefore the payment manager 236 may use the previously created temporary account to complete the transaction. In particular, the ad hoc account 242 may allow the payment manager 236 to proceed to the instant to process the transaction without delaying the payment process in terms of the sender or recipient.

Upon completion of the settlement, the settlement manager 236 deposits the settlement amount in the temporary account 242. [ In one or more embodiments, the payment manager 236 may cause the communication manager 230 to send a message to the recipient that provides a hyperlink and / or indication to remit from the temporary account to the registered deposit account. Alternatively, if the recipient does not want to register the deposit account, the message system may provide the recipient with an instruction to withdraw money from the temporary account.

In addition to coordinating transactions through the payment network 115, the payment manager 236 may also coordinate transactions for one or more system user accounts. In one or more embodiments, the network application 204 may support user cash accounts, such as gift card accounts, cash card accounts, or similar types of user accounts. The sender can specify the sender's user cash account as a method of payment and similarly the recipient can set the user's cash account of the sender to the registered deposit account. Thus, in at least some embodiments, an entire transaction or a substantially whole transaction can be processed within the network application 204.

In one or more embodiments, the system 100 may also allow a recipient to register a credit card account as a payment credential to receive funds. To send funds to the user's credit card, the payment manager 236 may send a refund request to pay the payment amount to the recipient's credit card account. In one or more embodiments, the refund request may include a refund request that is not referenced. An unreferenced refund request is a refund request that is not attached to a previous funds transaction that has a user's credit card account. Most credit card companies allow the processing of refund requests that are not referenced, resulting in applying the credit in the amount of the refund request to the receiving credit card account. For example, if the recipient has a negative balance in the credit card account, the amount of the refund request may be applied as a negative balance. Similarly, if the recipient has a balance of zero in the credit card account, the refund requested amount may generate a positive credit card account balance that the recipient can consume for it.

In one or more embodiments, the payment network coordinator 256 may coordinate and process collective credit card funding requests and bulk credit card refund requests. In particular, due to various charge structures associated with credit card payments, the payment network coordinator 256 may process bulk credit card funds and refund requests to minimize potential charges.

The payment manager 236 of FIG. 2 may perform various functions related to requesting and accepting a payment request, and coordinating information received from the communication manager 230 to adjust the payment process. For example, the payment manager 236 may generate and store a payment credential. More specifically, the user (e.g., sender and recipient) may already have an account with the network application, and thus may be an already registered user, or may still need to set up an account. In one embodiment, at least a portion of the user may also be a member of the social networking system and, when messaging using the system 100, also includes identifiers ("IDs") and user profiles associated with the social networking account Lt; / RTI > Alternatively, another user may not be a member of the social networking system and may need to create an account to become a registered member of the system 100. In this example, the billing manager 236 receives data from such a user via (client application 202), creates an account, and provides a unique ID and user billing profile for those users to be referred to later during the billing process Can be generated. In some cases, the payment manager 236 may also augment the user profiles of previous social networking users to include payment profile features that may be non-existent.

In setting up or augmenting an account, a user may submit one or more payment credentials, such as credit cards, debit cards, deposit accounts or other bank accounts, gift card accounts, shop credit accounts, and the like. When adding a payment method, the user may be required to submit the card and / or account number, expiration date, security code, transfer or routing identification number, and banking information required for the money transfer. The user can also generate a security code for the credit card, for example, to generate an authentication code, such as a personal identification number (PIN), or, for example, only to provide a single payment method or to provide some other authentication code. The user can also select a default payment method.

The user billing profile stored by the user profile database 240 may thus include uniquely generated user (or group) IDs for each registered user (regardless of whether they are social networking users and / or messaging users) have. The user profile database 240 may provide a repository for the payment credentials of users of the network application 204. For example, a user may create an "account" with network application 204, which allows the user to provide payment information to network application 204. [ The network application 204 may then store the payment information in the user profile database 240. In one or more embodiments, the user profile database 240 may be associated with a user, such as: gender, middle name, name, payment card number (e.g., credit card, debit card), expiration date (year and / A billing address (including a street name, a house number, a city, a state or province, a postal code, a country, etc.) related to a credit card, a credit card A telephone number associated with the billing address, and one or more shipping addresses (including fields similar to the billing address). When the payment card includes a debit card, the profile storage module may also store the PIN for the debit card. In an embodiment where the network application 204 includes a social networking system, the payment information stored in the user profile database 240 may be associated with a node of the node store 252 that represents the user.

In any case, upon receiving a payment message from the sender, the payment manager 236 may detect the user (or group) ID of the sender and retrieve the payment profile for that user (or entity). The payment manager 236 may then generate a transaction package that includes the transaction ID, sender, and recipient associated with the payment amount. The transaction package may also include a default payment method and related information, unless the transaction package chooses to send the payment to the recipient with the alternative payment method, including the payment information for the alternative payment method. The payment manager 236 may then send the transaction package to the payment network 115 to initiate the payment authorization process.

The transaction database 238 of FIG. 2 may be a transaction database 238 (e.g., in the form of a graph object) that is associated with each attempted or completed transaction, transaction ID, date, amount of transaction, Messages, and any other information collected on the transaction. With this information, the payment manager 236 can, upon request, provide the user with a summary of one or more transactions as a history of requested payment, rejected payment, and completed payment.

The payment manager 236 may perform various other additional steps and methods to efficiently manage the payment process. In one or more embodiments, for example, upon receipt of a payment message, the payment manager 236 generates a transaction identifier (or simply "transaction ID") and associates the transaction identifier with the payment information in the payment message and / . For example, when creating a transaction ID, the payment manager 236 may send the transaction ID and payment information to the transaction database 238. The transaction database 238 may include a data table or similar data matrix that stores transaction information according to the transaction ID.

In one or more embodiments, after the transaction ID is associated with a particular payment message, the transaction ID may be embedded or embedded within substantially any communication within the system 100 that is associated with a particular payment. Thus, the transaction ID allows the payment manager 236 to manage and process multiple payments in an organized manner. For example, the payment manager 236 may include an instruction to include the transaction ID in any information sent to the client device 104a, 104b. In response, the messaging handler 210 may also include a transaction ID in any information sent from the client device 104a, 104b to enable the payment manager 236 to effectively and reliably identify the particular transaction for which the information corresponds .

As described above, the network application 204 may include a transaction database 238 that manages transaction information for each payment message received via the client device 104a. For example, the transaction information may include other transaction information as well as other transaction information such as one or more of the sender identifier, the recipient identifier, the amount of payment, the payment method (e.g., sender account), the deposit method (e.g., recipient account), the transaction history, And may include a transaction ID. In one or more embodiments, transaction information is managed in the form of one or more graph objects that are updated with any updates or actions to the transaction.

As previously mentioned, the network application may also manage one or more ad hoc accounts 242. The ad hoc account 242 may function as a "hot account" type that provides funds for settlement from the sender's account or deposits made to the recipient's account prior to resolution. For example, with some payment methods, the payment of the payment may take some time, or even days, before the money is debit from the sender's account. However, payment authorization requests can identify and specify funds to meet payments. Thus, upon receiving a successful response from the payment authorization request, the payment manager 236 may pay the payment amount from the temporary account 242 to provide a shorter time for the payment to reach the recipient's account. When the payment is received from the sender's account, the temporary account is updated with respect to the amount of the payment.

As discussed, the systems and components described above in connection with FIGS. 1-2 can allow users of the messaging system to send and receive payments easily, effectively, and securely through the integrated messaging and billing system 100. [ 3A-3D illustrate example process diagrams of one or more exemplary embodiments of a process implemented by the system 100 described above. Consistent with the system 100 shown in Figures 1 and 2, Figures 3a-3d illustrate an outgoing client device 104a having a client application 202, a receiving client device 104b having a client application 202, Server device (s) 108 that supports network 204, and payment network 115.

In one or more embodiments, the process by which a user sends a payment to another user via system 100 may be initiated by the originating user (or simply "sender") associated with originating client device 104a, May begin with providing user input to the client application 202. [ In particular, as described above, the sender can access one or more user interfaces that allow the sender to define the payment made to the receiving user (or simply "recipient"). In addition, the client application 202 may cause the originating client device 104a to send 304 a payment message to the network application 204 as shown in Figure 3A

The network application 204 may receive the payment message 302 and use the information provided by the payment message 302 to determine whether the sender has a payment credential 306 in the file. For example, the network application 204 may retrieve a user profile for a user from the profile database 240 using a network identifier (e.g., a user name or other identity) to determine whether the user profile has an associated payment credential You can decide. If the sender has a payment credential 306, the network application 204 validates the sender and / or payment credentials 306 and acts 308-315 are skipped, as described in connection with act 316 .

If the user does not have a payment credential 306, the network application 204 may ask the user to provide a payment credential 306. [ In particular, the communication manager 230 sends (308) an induction to the client device 104a to induce the caller to provide a payment credential 306. The network application 204 may cause the communication manager 230 to send (308) the induction before proceeding with the payment transaction shown in Figures 3A-3D. Alternatively, after the recipient verifies that the network application 204 has a payment credential in the file as described below with respect to FIGS. 5A-5D, the network application 204 may determine that the communication manager 230 has sent a payment credential 306 to send (308) an indication for.

After receiving the inducement 308 that provides the payment credential, the user may ignore or close the inducement 308. After the predetermined time, the network application 204 responds to the request from the other user, (E.g., when the caller next logs in to the client application 202). In any case, the sender may enter the payment credential information using the client device 104a (310). The sender client device 104a may send the payment credential information 310 to the network application 204 (312).

Upon receiving the payment credential information 310, the network application 204 may associate one or more payment credentials 306 with the caller based on the payment credential information 310. Optionally, the network application 204 may generate 314 a token. The token 314 may map to the payment credential details and cause the network application 204 to retrieve the payment credential in response to a subsequent payment request. In particular, network application 204 may return a random string referred to as a "token" as a pointer to a stored payment credential. The token 314 preferably has no algorithmic relationship with the payment credential at all, and therefore the payment credential can not be derived based on the token itself (e.g., by applying the decryption algorithm only to the token). This token 314 is therefore considered to be the cardholder data because it is a random string that is not possible to describe any sensitive data without the use of the network application 204 containing a list of payment credentials and their corresponding tokens It does not. The payment token generated by the network application 204 may allow validation of the payment request as described in more detail below. The network application 204 may provide the token 314 to the originating client device 202.

At this point, or depending on whether the sender already has a payment credential 306 in the file, the network application 204 may perform the validation step 316 to validate the sender and / or payment credentials (316). For example, the network application 204 may validate a payment message 302 that includes a valid token 314 that references a stored payment credential 306.

As an alternative to validating the user, the client application 202 may obtain, identify or otherwise find a user identifier for the sender for the network application 204. For example, the client application 202 may access a user's obfuscated (e.g., hashed, encrypted, or algorithmically translated) user identifier present in the originating computing device 104a. This user identifier may identify a user profile / account for a user of the network application 204 (e.g., a social networking application). In one or more embodiments of the present invention, the user identifier may only be present when accessed from a portion of the shared memory accessed or stored by the network application 204, and the user is currently "logged on " In one or more embodiments, the user identifier is accessed from a cookie (e.g., a HyperText Transfer Protocol (HTTP) cookie) or an application cache (HyperText Markup Language version 5 (HTML5) application cache) at the user's computing device 104a.

The client application 202 may send a complex user identifier along with the payment message 302. [ The network application 204 may then verify that the complex user identifier is valid. This process may function as an authentication to the sender, indicating that the presence of an appropriate complex user identifier for the network application 204 on the user's computing device 104a has been authenticated by the network application 204 already at the originator .

If the network application 204 does not validate the sender or payment credentials, the network application 204 sends out a communication that causes the client application 202 to present an error message indicating to the sender that the payment can not be authenticated To the client device 104a. In one or more embodiments, the error message may include a prompt to allow the sender to provide additional authentication information, agree with the terms and conditions, or otherwise verify their identity. The originating client device 104a may then send the modified payment request to the network application 204. [ The network application 204 may then attempt to validate the sender / payment credentials. If the network application 204 can not validate the sender / payment credentials, the network application 204 may then terminate the settlement transaction based on the settlement message 302.

When the network application 204 validates the sender / payment credentials, the network application 204 may generate 318 a transaction ID as shown in FIG. 3A. As described above, the network application 204 may associate a transaction ID unique to each received payment message. The network application 204 may include various files, objects, messages, and / or files to allow the network application 204 to effectively identify and process messages, status updates, and other information for each payment made through the network application 204 You can include the transaction ID within other information. For example, as described above, network application 204 may associate a transaction ID with a graph object that manages information corresponding to the processing of a payment message.

Optionally, as indicated at 320, the network application 204 may authorize the payment network 115 for the payment credential of the sender (e.g., the payment card of the sender) for a payment amount or other amount (e.g., $ 0.01 or $ 100.00) The request can be sent, and approval or rejection of the payment card can be accepted. The payment network 115 may then forward the payment credential acknowledgment in response to the network application 204, as indicated at 322. Those skilled in the art will recognize that a selective acceptance request may occur in the timeline beforehand or at a later time. In an alternative implementation, the network application 204 may send an authorization request for the payment credentials of the sender to the payment amount as part of the payment transaction request 338. [

In response to the transmission of payment message 302, the client application 202 may publish (324) the payment message content in response to providing the payment credentials 306 or in response to a signal from the network application 204 have. For example, the user interface manager 206 may add the text of the payment message 302 to the communication thread with the message exchanged between the sender and the recipient as the transmitted message.

Similarly, the network application 204 sends the payment message content 328 to the receiving client device 104b to allow the client application 202 of the receiving client device 104b to publish (329) the payment message content 328 can do. For example, the user interface manager 206 may add the text of the payment message 302 to the communication thread with the message exchanged between the sender and recipient as the received message.

The network application 204 may use the information provided by the payment message 302 to determine whether the recipient has a payment credential 326 in the file. For example, the network application 204 may use a network identifier (e.g., a user name or other identity) to index the user profile for the recipient in the user profile database 240 to determine if the user profile has an associated billing credential . If the recipient has a payment credential 326, the network application 204 may validate the recipient and / or the payment credential 326.

If the recipient does not have a payment credential 336, the network application 204 may request the recipient to provide a payment credential 336. [ In particular, the communication manager 230 may send 330 an induction to the recipient client device 104b to induce the recipient to provide a payment credential 326. [ Network application 204 may cause communication manager 230 to send (330) an induction before proceeding with a payment transaction.

After receiving the induction 330 that provides the payment credential, the recipient may ignore or close the induction 330, after the predetermined time has elapsed, in response to a request from another user, (E.g., when the recipient subsequently logs in to the client application 202). In any case, the recipient may use the client device 104b to enter payment credential information (332). The recipient client device 104b may send the payment credential information 332 to the network application 204 (334).

Upon receiving the payment credential information 332, the network application 204 may associate one or more payment credentials 326 with the recipient based on the payment credential information 332. [ Optionally, the network application 204 may generate a token 335 that is similar to the token 314. The token 335 may map to the payment credential details and cause the network application 204 to retrieve the payment credential in response to the subsequent payment request described above.

At this point in time, or depending on whether the recipient already has a payment credential 326 in the file, the network application 204 may perform the validation step 336 to send the recipient and / or payment credential 326 Can be validated. For example, the client application 202 may obtain, identify, or discover a user identifier for the recipient for the network application 204, as described above with respect to caller validation. The client application 202 on the client device 104b may send the complex user identifier to the network application 204 in response to receiving the payment message content 328. [ The network application 204 may then verify that the complex user identifier is valid. This process indicates that the presence of an appropriate complex user identifier for the network application 204 at the recipient's computing device 104b indicates that the recipient has already been authenticated by the network application 204, have.

If the network application 204 does not validate the sender or payment credentials, the network application 204 may send a communication that causes the client application 202 to present an error message indicating that the payment can not be authenticated to the recipient To the receiving client device 104b. In one or more embodiments, the error message may include a prompt to allow the recipient to provide additional authentication information, agree with the terms and conditions, or verify their identity.

Optionally, the network application 204 may send an authorization request to the payment credential of the recipient (e.g., the payment card of the recipient) for the payment amount or other amount (e.g., $ 0.01 or $ 100.00) to the payment network 115 , You can approve or decline the payment card authorization. The payment network 115 may then forward the payment credential acknowledgment in response to the network application 204. Those skilled in the art will recognize that a selective acceptance request may occur in the timeline beforehand or at a later time. Thus, in one or more embodiments, the payment network 215 may verify that the recipient account can approve the payment.

Continuing with FIG. 3C, when the network application 204 validates the sender / recipient, the network application 204 may send a payment transaction request 338 to the payment network 115 to process the settlement funds. In particular, the payment transaction request 338 may provide an instruction to charge 340 the payment information and the payment amount to the payment credentials of the sender. In addition, the instruction may instruct the payment network 115 to deposit the payment credentials of the recipient. Depending on the settlement credential (e.g., a settlement account type) and the deposit account type, the settlement funds may take various forms. Figure 3D illustrates an additional process for settlement funds, discussed below.

When providing the settlement funds, the payment network 115 may send a payment transaction response 330 to the network application 204 as shown in FIG. 3A. Specifically, the settlement transaction response 330 may indicate that the settlement fund provision is successful. The network application 204 may then send a payment completion status update to the caller client device 104a. Similarly, the network application 204 sends a billing status update to the recipient client device 104b.

FIG. 3D illustrates a further example of a payment process, particularly illustrating a further example of a funding process that allows network application 204 to process payments using a variety of payment methods and deposit accounts. FIG. 3D illustrates an example of a process flow in which the system separates and processes a request for funds from a sender's account and deposits the settlement to the recipient's account. In one or more embodiments, for example, the sender's account is accessed in the first payment network Where possible, the account of the recipient is available in the second payment network. In this situation, in order to process the payment, the network application 204 may act as an intermediary for processing the payment.

The process flow shown in FIG. 3D continues after FIG. 3B, i.e. after the network application 204 validates the sender and receiver. The network application 204 may send 346 a payment request to the payment network 115 requesting that the payment amount be charged 348 to the sender's payment credential 348 and sent to the network application 204. In response, the payment network 115 may provide settlement funds from the sender's account by electronically remitting from the sender's account to the network application 204 (350). When receiving the electronic transfer, the network application 204 may apply 352 the payment to the temporary account. In one or more embodiments, the network application 204 may create a new account for applying the settlement. Alternatively, the network application 204 may apply a payment to a master temporary account that includes various other payments that are identified and organized by unique transaction IDs associated with each payment.

The network application 204 may then deposit the payment at the recipient's payment credential. In particular, as shown in FIG. 3D, the network application 204 may electronically transfer the payment to the recipient's payment credential via the payment network 115 or other payment network. In particular, the network application 204 may send funds to the payment network 115 with an instruction to apply (354) the payment of funds to the recipient's payment account. If the recipient's payment credential is not a deposit account (e.g., a credit card), the payment request 354 may include a refund request. Alternatively, the network application 204 may prepare a closing package to settle a plurality of settlement transactions together. For example, in one or more embodiments, due to the slow nature of the payment method, the network application 204 may include a plurality of the same type of settlement in a settlement package that processes multiple settlements as a single settlement transaction.

The payment network 115 sends a payment credit response 358 to the network application 204 when successfully depositing the payment to the recipient's account. After receiving the transfer confirmation 358, the network application 208 fetches the temporary account 352 for the payment amount, thereby setting the settlement of the temporary account for the payment. To complete the payment process, the network application 204 may send a payment completion status update to the originating client device 104b and send a payment status update to the receiving client device.

As will be described in greater detail below, the components of the system 100 described in connection with FIGS. 1 and 2 may provide one or more graphical user interfaces in conjunction with and / or in combination with other components. In particular, a component may allow a user to interact with a set of display elements for various purposes. In particular, Figures 4A through 4O and the following description illustrate various exemplary embodiments of user interfaces and features in accordance with the general principles described above.

For example, Figures 4A-4O illustrate various views of the GUIs provided by the client application 202 to facilitate sending and receiving of payments and electronic messaging. In some instances, client devices (i.e., client devices 104a and 104b) may implement some or all of system 100. For example, FIG. 4A illustrates a client device 400 that may implement one or more components of a client device 202. As shown in FIG. 4A, the client device 400 is a handheld device, such as a mobile telephone device (e.g., a smartphone). As used herein, the term "handheld device " refers to a device that is configured and sized to be picked up / operated in one hand of the user. In a further or alternative example, but not limited to, any other suitable computing device, such as, without limitation, a tablet device, a handheld device, a larger wireless device, a laptop or desktop computer, a PDA device, and / One or more of the processes and / or operations described herein may be performed.

The client device 400 may include any of the features and components described below with reference to the computing device 1800 of FIG. As shown in FIG. 4A, the client device 400 includes a touch screen display 402 that can display or provide a user interface through which user input may be received and / or detected. As used herein, "touch screen display" refers to a display of a touch screen device. In one or more embodiments, the touch screen device may be a client device 104a, 104b (e.g., a laptop, tablet computer, PDA, media player, cellular phone) having at least one surface on which a user may perform a touch gesture have. Additionally or alternatively, the client device 400 may include any other suitable input device, such as a touchpad or those described below with reference to FIG.

As mentioned above, the system 100 may incorporate an electronic messaging system and an electronic payment system. FIG. 4A illustrates a person or contact user interface 404 provided by the user interface manager 206 on the touch screen 402. FIG. The contact user interface 404 may provide a list of contacts of the user ("Donald") of the client device 400. In particular, the contact user interface 404 may allow a user to list "friends" or contacts 406 that are connected or associated within the system 100.

The contact user interface 404 may further provide one or more states of each of the contacts 406. For example, the contact user interface 404 may determine whether a given contact or counterpart user is active (e.g., logged into the client application 202, connected to the Internet, or recently performed an act using the client application 202) Can be displayed through the first status indicator 408. The first status indicator 408 may include a graphical user interface object, such as an icon, for example. In one embodiment, the first status indicator 408 includes a point of a first color (e.g., green) next to the name of each active user that is active. Along the lines, the first status indicator 408 may also include a second color (e.g., gray) point next to the inactive users.

The contact user interface 404 may display, via the device indicator 410, whether a contact or counterpart user is currently in use on a given type of device. The device indicator 410 may include a graphical user interface object, such as an icon, for example. For example, as shown, the device indicator 410 may include the word "Web" that indicates that the other user is logged into the client application 202 or is active using the personal computer. Along similar lines, the device indicator 410 may include the word "Mobile" indicating that a given contact is logged or active in the client application 202 using a mobile device, e.g., a mobile phone. Additionally or alternatively, the device indicator 410 may indicate a brand or model of the client device of a given counterpart user.

In accordance with the personal information setting of a given counterpart user, the contact user interface 404 may further include a payment status indicator 411. [ The payment status indicator 411 may indicate whether a given counterpart user is able to receive or transmit an electronic settlement using the system 100 or whether it has been registered. For example, the presence of a payment status indicator 411 next to the name of a given opponent may indicate that a given opponent has a billing credential associated with their account or profile in the system 100 or network application 204 have. The payment status indicator 411 may include, for example, a graphical user interface object such as an icon. For example, as shown in FIG. 4A, the payment status indicator 411 may include dollar signs or other symbols generally associated with a payment transaction.

The client application 202 may receive a notification or indication of the status of the contact associated with the user of the client device 400 from the status manager 232 of the network application 204. [ For example, the client application 202 may send a notification or status update to the network application 204 to indicate when the client application 202 is active or online. The state manager 232 may then send the status of the contacts associated with the given user to the client device 104a associated with the given user. Along the lines, the state manager 232 determines whether a given user has a billing credential associated with their profile and can provide an indication to the client device 400 of the contacts of the user having the ability to send and receive payments You can decide.

In view of the present disclosure, those of ordinary skill in the art will recognize that the integration of electronic messaging systems and electronic payment systems can provide significant advantages over conventional payment applications. In particular, the user can access the contact user interface 404, determine which counterparty user is active, and thus determine if any counterparty user is available to talk about a payment transaction or even to recognize receipt of a payment You can decide. Additionally, the contact user interface 404 may optionally allow the user to know which counterpart user has a payment credential. Thus, the contact user interface 404 can notify the user whether the counterpart user is able to " instantly " receive a payment or whether the user should invite the counterpart user to register.

As described above, the system 100 can facilitate the reception and transmission of data. In one or more embodiments, communication manager 230 facilitates receiving and transmitting electronic communications between computing devices 104a, 104b, In addition, in one or more embodiments, the user interface manager 206 displays the electronic communication sent and received via the communication manager 230. [ In one or more embodiments, user interface manager 206 may display electronic communications sent and received via communication manager 230 at a messaging thread within a messaging graphical user interface. For example, a user may interact with a contact list in the list of contacts of the contact user interface 404 to open a messaging graphical user interface that facilitates message exchange with the contact. 4B shows a messaging graphical user interface 412 provided by the user interface manager 206 on the touch screen 402 when the user selects the contact "Joe" from the contact user interface 404.

As shown, the messaging graphical user interface 412 may include a communication thread 414 that includes an electronic message 416a sent from the user's account of the client device 400. [ Similarly, communication thread 414 may include an electronic message 416b received by the account of the other user (i.e., "Joe"). The user interface manager 206 organizes the communication thread 414 to allow a new message to be added to the bottom of the communication thread 414 and older messages to be displayed at the top of the communication thread 414. In one or more embodiments, do. In an alternative embodiment, the user interface manager 206 may organize the messages 416a, 416b in any manner that can display to the user a temporal or other relationship between the messages 416a, 416b .

The user interface manager 206 provides various electronic communication features that help the user distinguish between electronic communications in the communication thread 414. 4B, the user interface manager 206 may send an electronic message 416a (e. G., ≪ RTI ID = 0.0 > 416a) < / RTI > sent from an account of a user of the client device 400, ). On the other hand, the user interface manager 206 displays the electronic message 416b received by the messaging handler 210 pointed toward the opposite side (i.e., the left side) of the messaging graphical user interface 412. In one or more embodiments, the placement and orientation of the electronic messages 416a, 416b provides the user of the client device 400 with a clear indicator of the starting point of the various electronic communications displayed in the messaging graphical user interface 412. [

Another feature provided by the user interface manager 206 that helps the user distinguish electronic communication may be the color of the electronic communication. For example, as shown in FIG. 4B, the user interface manager 206 displays the transmitted electronic message 416a in a first color and the received electronic message 416b in a second color. In one or more embodiments, the first and second hues may be black and white, respectively, with an inverted typeface hue. In an alternative embodiment, the user interface manager 206 may display electronic messages 416a, 416b with a contour of a different color than a white background.

In yet another alternative embodiment, the user interface manager 206 can distinguish the received electronic message 416a from the received electronic message 416b, with different fonts, different sizes, or with a different pattern of backgrounds Lt; RTI ID = 0.0 > 416a < / RTI > For example, in one or more embodiments, the user interface manager 206 displays a transmitted electronic message 416a with a white typeface on a blue background. Similarly, in at least one embodiment, the user interface manager 206 displays a received electronic message 416b with a black typeface on a gray background.

As mentioned above, the user interface manager 206 may also provide a message input control palette or toolbar 422. 4B, the user interface manager 206 displays a message input control palette or toolbar 422 as part of the messaging graphical user interface 412. In one or more embodiments, the message entry control palette or toolbar 422 includes various selectable message entry controls that provide various message entry options or other options to the user. 4B, the message input control palette or toolbar 422 may include a text input control 424a, a billing control 424b, a camera viewfinder input control 424c, a multimedia input control 424d, a symbol input control 424e ), And likelihood indicator controls 424f. In one or more alternative embodiments, the message input control palette or toolbar 422 may provide input controls 424a-424e in a different order, provide other input controls not shown in Figure 4b, One or more input controls 424a-424e shown may be omitted.

As described in more detail below, a user may interact with any of the input controls 424a-424e to create and transmit different types of electronic communications. For example, if the user interacts with the text input control 424a, the user interface manager 206 may include a touch screen display keyboard (not shown) in the portion of the messaging graphical user interface 412 that the user may use to create the text message 420 418 < / RTI > Similarly, if a user interacts with the multimedia input control 424d, the user interface manager 206 may provide a multimedia content item (e. G., To display digital pictures, digital video, etc.) within a portion of the messaging graphical user interface 412 Display area can be provided. Similarly, if the user interacts with the camera viewfinder input controls 424c, the user interface manager 206 may be a digital camera (not shown) that a user may use to capture, transmit, and add digital pictures or digital video to the communication thread 306 Interface within the portion of the messaging graphical user interface 412.

A user may interact with any message input controls 424a-e to send and create messages or payments to one or more other users via the system 100. [ For example, in FIG. 4B, the user's finger is shown as interacting with payment control 424b. In one or more embodiments, the user input detector 208 may detect interaction of the user's finger or other input device with the payment control 424b (e.g., tap-tap gesture). When the user input detector 208 detects a tap-tap gesture on the payment control 424b, the user interface manager 206 sends a payment user interface 415 within the portion of the messaging user interface 412, Can be displayed.

In particular, as shown in FIG. 4C, the user interface manager 206 may provide a communication thread 411 to a first portion (i.e., the upper portion) of the messaging user interface 412. The user interface manager 206 may provide a payment user interface 415 to a second portion (i.e., the lower portion) of the messaging user interface 412. Accordingly, the user interface manager 206 may allow a user to view the communication thread 414 and any new messages, while also initiating a payment transaction. In an alternative embodiment, the user interface manager 102 may align the communication thread 414 and the payment user interface 415 horizontally or in a different arrangement than the vertical arrangement. In another further embodiment, the billing user interface 415 may include an overlay or a separate user interface on the messaging user interface 412.

As will be apparent from the description herein, the payment user interface 415 allows a user to initiate a payment transaction (send a payment, request a payment, etc.) while simultaneously viewing a message for a payment transaction with one or more opponent user can do. For example, FIG. 4C shows that a user ("Donald") of the device 400 (hereinafter referred to as sender) has sent a message: "Hey Joe, how much was dinner the other night? In response, an opponent user ("Joe") (hereinafter referred to as the recipient) participating in the conversation in the communication thread 414 replied: "It was about $ 50 including the tip. In response to this conversation or messaging session, the sender may want to send a payment to the recipient. The messaging user interface 412 may allow the sender to do so without navigating away from the communication thread 414 or the messaging user interface 412. [

As shown, the payment user interface 415 may provide a plurality of quick selectable elements 430a, 430b, 430c, and 430d for setting a payment amount. In some implementations, the fast send selectable element 430a, 430b, 430c, 430d includes an icon that allows the sender to view the numeric value associated with the fast send selectable element 430a, 430b, 430c, 430d. In one or more embodiments, the selectable elements 430a, 430b, and 430c may have associated numerical values based on common currency values. For example, the selectable element 430a, 430b, 430c may have a numerical value determined by the call rate for the call used by the caller. To illustrate, if the caller uses US dollars, the selectable icon may have the same numerical value as a typical US dollar rate (eg, "$ 1", "$ 5", and "$ 10"). In one example, the system 100 may be based on a credential entered by a user, information entered by a user, the current location of the client device 400 detected by the location detector 214 and / or other information associated with the caller Thereby automatically detecting the currency used by the user. In a further or alternative embodiment, the selectable elements 430a, 430b, 430c may have numeric values that are not conventional currency values.

In another example, a sender may customize a selectable element by adding, removing and / or modifying numerical values associated with the selectable element. Specifically, the sender may choose to use a value greater than the built-in payment interface 415 as one or more selectable elements 430a, 430b, and 430c. The sender may select an additional selectable element 430d for adding or modifying, for example, the selectable elements 430a, 430b, 430c of the payment interface 415. [ Additionally or alternatively, the additional selectable element 430d may cause the user interface manager 206 to display a list or menu of all possible selectable elements for increasing the payment amount when selected, May not fit into the graphical user interface due to the size of the device 400. Alternatively, the selection of the selectable element 430d may cause the user interface manager 206 to provide a numeric keypad as shown in Figures 4e and 4h.

In a further or alternative embodiment, the client application 202 may allow the caller to customize the appearance of the selectable elements 430a, 430b, and 430c. Specifically, the icons may be configured in shape, size, color, and / or other visual characteristics. For example, the sender may select a pre-loaded icon 430a, 430b, 430c (e.g., each selectable element 430a, 430b, 430c may be represented by a miniature note model of the corresponding currency value) You can choose from options. As another example, the sender may upload a user-created icon for the selectable element 430a, 430b, 430c.

The user input detector 208 may detect the selection when the originator selects one of the quick send selectable elements 430a, 430b, 430c, 430d by selecting an element that is tapped or otherwise selected. Upon detecting the selection of the first quick-send selectable element (e.g., element 430c shown in FIG. 4C), the user input detector 208 causes the user interface manager 206 to send a preliminary or initial payment to the messaging user interface 412 to the communication thread 414. The user interface manager 206 may increase the payment amount 432 of the communication thread 414 when the user selects an additional quick send selectable element. For example, FIG. 4D shows that when a sender selects a quick send selectable element 430b twice and a quick send selectable element 430b, the user interface adds the amount corresponding to each quick send selectable element (i.e., $ 10 + $ 10 + $ 5) to the updated payment amount 432 shown in FIG. 4d.

In one or more embodiments, the system 100 may display the payment amount 432 within the communication thread 414 of both the originator and the recipient included in the conversation. Specifically, the system 100 may update the communication thread 414 of both the sender and the receiver included in the conversation in real time to indicate that the sender has initiated and is selecting the payment amount. For example, if the sender selects the selectable element 430c with $ 10 displayed, the system 100 updates the communication thread 414 for both the sender and the receiver to send the current payment amount to a message within the time- . As the sender selects an additional selectable element, the system 100 updates the payment amount 432 by increasing the initial or previous payment amount to the corresponding value of the selected element. Increasing the payment amount may include a sum of the numerical values of two or more selectable elements.

In some embodiments, the system 100 provides a timer for increasing the payment amount 432. Specifically, the user input detector monitors the time from the selection of the selectable element 430a, 430b, 430c and if the sender does not select the selectable element 430a, 430b, 430c within the inactive threshold time, the payment amount 432 Determine the end and process the transaction. For example, the inactivity threshold time may be 3 seconds (or any time including the user-settable time), and if the sender has not selected any selectable element 430a, 430b, 430c within 3 seconds , The client application 202 may settle the payment amount 432 and the payment message generator 216 may prepare and transmit a payment message based on the payment amount 432. [ Alternatively, the payment interface 415 may include a "send" icon or other selectable option or a graphical user interface through which the sender can choose to indicate that the payment amount 432 is final.

In addition to the above, the user interface manager 206 may provide various animations for the payment amount 432 and associated payment messages. For example, instead of tapping and selecting selectable elements 430a, 430b, and 430c, a user may perform a swipe-up gesture toward communication thread 414. The user interface manager 206 may then animate various "bills" floating in the payment amount 432. [ When shown in the recipient's communication thread 414, animation of the bill and payment enhancement can be seen by the caller as "letting the rain down" to the recipient. In an alternative embodiment, the user interface manager 206 may provide alternative or additional animation. Further, in one or more embodiments, the sender or recipient may select one or more animation options.

It should be noted that the payment interface 415 of Figures 4C and 4D in this discussion is an implementation of the payment interface. 4E illustrates an alternative embodiment of the payment interface 415a. As shown, the payment interface 415a includes a numeric keypad 438 that allows a user to select a payment amount 432 by entering a desired number consecutively (e.g., reaching $ 25 by 2, 5 then 5). In one or more embodiments, the user may select the payment interface 415, 415a desired to use.

In another alternate embodiment of the payment interface 415b shown in Figure 4f, the payment interface 415b may provide the option of entering a payment amount using one of a plurality of "quick send" amounts. As shown, the payment interface 415b may include a plurality of selectable elements 430e, 430f, 430g, 430h corresponding to different "quick send" amounts. Specifically, each selectable element 430e, 430f, 430g, 430h corresponds to a corresponding response, which the system 100 treats as a separate settlement amount and is treated as the final settlement entered by the system 100 when selected by the user And has a currency value. When the user selects the selectable element 430f, the system 100 enters the corresponding "quick send" amount ($ 10) into the payment user interface 415b and the selectable element 430e, 430f, 430g, 430h from the payment interface 415b. Therefore, according to one embodiment, the "quick send" amount may not be summed with other payment amounts before completing the settlement transaction.

In one or more embodiments, system 100 may intelligently place amounts that are likely to be selected by the caller in a "quick send" amount associated with selectable element 430e, 430f, 430g, 430h. For example, the system 100 may select a "quick send" amount based on the sender's transaction history. Optionally, the system 100 may place a payment amount previously used by the caller in the generally or specifically used previous payment sent to the recipient by the caller on the selectable element 430e, 430f, 430g, 430h . In a further or alternative embodiment, the system 100 may place a common monetary value based on the user's location, as described above, on at least a portion of the selectable elements 430e, 430f, 430g, 430h.

In another implementation, the system 100 may detect the amount to include in a "quick send" amount by analyzing one or more messages exchanged between the sender and the recipient. Specifically, the system 100 may analyze the message of the communication thread 414 and deduce a "quick send" amount based on the content of one or more messages. For example, the system 100 may determine that one or more messages in the communication thread 414 indicate that the user owes the user a certain amount of money. To illustrate, the recipient can send the message string "It was about $ 50 including the tip." As shown in FIG. 4f. In response to detecting the amount "$ 50 ", system 100 may place a $ 50" quick send "amount in one of selectable elements 430h as shown in FIG. 4f. The system 100 may additionally or alternatively place an associated amount in one or more other selectable elements 430g. For example, the system 100 may detect the number of users of the conversation (in this case, 2) and may deduce the inferred amount (i.e., $ 50) from the number of participants in the communication thread 414, ($ 25) as the quick transmission amount (430g) by dividing the amount by the number

The user interface manager 206 may display the payment amount 432 based on the "quick send" amount within the payment interface 415b as shown in FIG. 4g. This allows the user to review the amount and verify that he / she wants to send the amount by selecting the "Send" option. 4G, the payment interface 415b may occupy the lower portion of the touch screen 402 to allow the user to view the communication thread 414 while entering or checking the payment amount 432. [

In one or more alternative embodiments, when selecting a fast transmission amount, the user interface manager 206 may provide a payment interface that does not include a communication thread. For example, as shown in FIG. 4h, the payment interface 456 includes the features of the payment interface 415b of FIG. 4g as well as the keypad 438. The keypad 438 may allow the sender to modify or change the payment amount 432 entered upon selection of the fast selectable element 430g.

In addition to displaying the payment interface 456 of Figure 4G when the user selects a quick send selectable element 430e-430h, the user interface manager (e. G., &Quot; 206 may also provide the payment interface 456 of Figure 4g. For example, referring back to FIG. 4F, payment interface 415b may include a payment input selectable element 454 that allows a user to manually enter payment amount 432. [ If the user wishes to enter an amount that is not included in the quick send selectable element 430e-430h, the user may select the payment input selectable element 454 and navigate to the payment interface 456 of Figure 4g .

In addition, in one or more embodiments, the user interface that constitutes the settlement process flow may not include the fast send selectable elements 430a-430g. In this embodiment, when the user selects payment control 424b of Figure 4b, user interface manager 206 may provide payment interface 456 of Figure 4g. The user can then manually enter the payment amount 432 using the keypad 438. [ Once the user enters the desired payment amount 432, the user can select a payment selectable element 437 or transmit a selectable element 437. [

Referring again to Figure 4h, in accordance with one or more embodiments, the payment interface 456 or other payment user interface 415, 415a, 415b may include a payment credential element 458. [ The payment credential element 458 may display the payment credentials of the user for whom payment is to be made. For example, the payment credential element 458 may include a brand of card with the last four digits of the credit or debit card number, as shown in Figures 4g and 4h.

If the user wishes to use another payment credential or add a payment credential, the user may select the payment credential element 458. [ In response to the selection of the payment credential element 458, the user interface manager 206 may provide a selection interface that allows the user to select another payment credential for the file. Alternatively, if the user does not have a payment credential in the file, the payment credential element 458 may allow the user to enter a new payment credential. Specifically, when selecting a payment credential element 458, the user interface manager may provide a credential user interface 434 as described in connection with Fig. 4i.

In a further or alternative embodiment, in response to the originator selecting a payment selectable element 437 or a sending element (see FIG. 4e), the sender may select the payment element 437 or cause a payment message to be sent In response, the client application 202 may send a request to the network application 204 to determine whether the sender has a registered payment credential. If the sender is not associated with a registered payment credential, the user interface manager 206 may present a credential user interface 434 that allows the sender to register a payment credential, as shown in Figure 4i For example, providing payment information as described above). Alternatively or additionally, the graphical interface allows the user to enter payment information (e.g., a debit or credit card number) that facilitates a one-time payment without requiring the originator to create an account or store the payment credential You can offer acceptable disposable payment options. In another alternative implementation, in response to the selection by the originator to enter a new payment credential via the credential element 458 as shown in Figures 4G and 4H, the user interface manager 206 may access the credential user interface 434 ) Can be displayed.

The skilled artisan will appreciate that the credential user interface 434 may vary depending on which payment credentials the sender chooses to input. In one or more embodiments, the user interface manager 206 may provide a list of acceptable payment credentials (e.g., credit card, debit card, gift card, bank account). If the user selects a type of payment credential, the user interface manager 206 may provide an applicable credential user interface 434. [ For example, FIG. 4I illustrates a credential user interface 434 for entering a credit or debit card. As shown, the user may enter, via the numeric keypad 438, the credit card number associated with the credit card, the validity period, the security code, and the billing zip code. Once the payment information has been entered, the messaging handler 212 may send the payment credential information to the network application 206 to store the payment credentials, as described above with respect to Figures 3A-3D.

After the sender inputs the payment credential details (by an automatic reminder, a manual reminder from the sender, or by the sender's own choice), the system 100 can continue processing the settlement transaction. In one or more embodiments, the client application 202 may provide the sender with the option of using a PIN or other shortcut to process a future payment transaction. For example, the client application 202 may use the pop-up window 440 in the messaging interface 412 to ask the sender if the sender wants to create a PIN for sending money for additional security, ) Or other notifications to the sender.

If the sender chooses to enter a PIN for processing future payment transactions, the client application 202 may present a PIN creation interface 442 for generating a PIN as shown in FIG. 4k. Specifically, the PIN generation interface may allow the sender to generate a unique PIN associated with the sender's stored credentials. For example, the PIN may be a four-digit number (or a string of any length) that the sender may enter via the numeric keypad 438 before processing the future payment transaction. In some instances, the system 100 may also request that the sender verify the PIN by generating a PIN and re-entering the PIN to relate the PIN to the stored credentials.

For future billing transactions, the system 100 may present a PIN input interface from which the sender can enter a PIN. Entering a PIN may allow the system 100 to associate with the PIN to process a payment transaction using a stored credential for the user. Thus, input of a PIN will allow the sender to initiate and complete the settlement transaction without having to remember the credentials each time the sender wishes to send money to the other user via the system 100.

The user interface manager 206 determines that the communication thread 414 on the originating client device 400 and the communication thread 422 on the originating client device 400 have been updated to reflect that the payment amount 432 has been finalized and transmitted when the originator has completed the payment amount 432 increase and the payment message has been transmitted. And / or the payment amount 432 (or any other text of the payment message) at the recipient's communication thread 414. For example, to reflect that a payment message has been sent as a message and a payment transaction has begun, the user interface manager 206 may change certain characteristics of the payment message (including only the payment amount 432 in this case) in the messaging thread 414 . For example, in one or more embodiments, the user interface manager 206 may determine the location of the payment message, the border width of the payment message, the background color of the payment message, the size and font of the payment message, Features can be changed. For example, after the payment message is transmitted in FIG. 4L, the user interface manager 206 changes the background of the payment message from white shown in FIG. 4D to black shown in FIG. 4L, To the white of Figure 4I.

In one embodiment, the user interface manager 206 may animate the payment amount when the payment amount is finalized by causing the payment amount to "bounce" within the messaging interface 412. When animating a payment amount, the user interface manager 206 may animate characters and / or images individually or wholly in the amount of the payment.

Additionally or alternatively, the user interface manager 206 may modify the appearance (e.g., animate the payment amount) until one or more actions associated with the payment transaction are completed. For example, the user interface manager 206 may determine whether the recipient accepts the payment amount, or if the sender and / or recipient inputs a credential, or the system 100 completes the payment transaction and transfers funds from the sender to the recipient You can animate the amount of your payments. In a further or alternative embodiment, the user interface manager 206 may apply modifications to the appearance of the payment amount during the amount of time once the payment amount is finalized. Additionally or alternatively, the user interface manager 206 may apply modifications to the appearance of the payment amount based on other criteria, such as when the payment transaction is completed, when the money is available to the sender, or if the payment transaction has failed have.

Figures 4m-4o illustrate a graphical user interface for the recipient client device 400a. 4M shows the messaging interface 412a in the recipient client device 400a after the originator initiates a payment transaction to remit the payment to the recipient. In one or more embodiments, the system 100 may notify the recipient that the caller has initiated a payment transaction. For example, the user interface manager 206 may display the payment amount in the communication thread 414a of the messaging interface 412a and the identity of the sender (e.g., "Donald has sent you money") in the payment message 432a have. To illustrate, the user interface manager 206 may insert a payment amount into a communication thread 414a that has other messages exchanged between the sender and the recipient. Additionally or alternatively, the user interface manager 206 may display the payment amount in other ways (e.g., by providing a notification in the notification area of the recipient client device 400a).

Additionally or alternatively, the user interface manager 206 may show other notifications indicating that the sender has sent a payment to the recipient on or within the drop-down overlay 450 or messaging interface 412a. In one example, the drop-down overlay 450 may allow the recipient to select an element within the drop-down overlay 450, such as a drop-down overlay 450 or an acceptance element 452, ) ≪ / RTI > confirmation request. After the recipient approves the payment transaction, the system 100 may begin the process of completing the payment transaction and transferring funds to the recipient from the originator. In an alternative embodiment, the drop-down overlay 450 can only draw the recipient into a payment transaction while the system 100 automatically processes and completes the settlement transaction.

In one or more embodiments, when a recipient chooses to accept payment, system 100, client application 202 may send a request to network application 204 to determine whether the recipient has a registered payment credential have. If the recipient is not associated with a registered billing account, the user interface manager 206 may be configured to allow the recipient to register the billing credential (e.g., provide billing information as described above) The user interface 434 can be displayed. Alternatively, or in addition, the graphical interface may be configured to allow a one-time payment (e.g., a debit card or credit card number) to allow the recipient to enter billing information enabling a one-time payment without requiring the sender to create an account Options can be displayed.

The skilled artisan will recognize that the credential user interface 434 may vary depending on which payment credentials the recipient chooses to enter. In one or more embodiments, the user interface manager 206 may provide a list of acceptable payment credentials (e.g., credit card, debit card, gift card, bank account). If the recipient selects a type of payment credential, the user interface manager 206 may provide an applicable credential user interface 434. [ For example, FIG. 4n shows a credential user interface 434 for entering a credit or debit card. As shown, the user may enter, via the numeric keypad 438, the credit card number associated with the credit card, the validity period, the security code, and the billing zip code.

After the recipient enters the payment credentials, the system 100 may complete the payment transaction. Specifically, the system 100 may complete the settlement transaction by sending funds from the sender to the recipient. In some instances, transferring funds from an originator to a recipient may involve transferring funds to a temporary account associated with the recipient until the transaction is approved by the corresponding financial institution, as described above with respect to Figures 3a-3d . In an alternative example, completing the settlement transaction may include direct remittance to the destination account entered by the recipient. 4O, after completing (or after the recipient has selected to complete the payment transaction), the system 100 may display a payment completion message 458 notifying the recipient that the payment transaction has been completed, Lt; / RTI > will receive a payment within a certain time frame.

In some embodiments, the sender and / or recipient may set or change settings for the payment transaction. Specifically, the sender and / or recipient can manage settings for the payment method (e.g., debit card, direct deposit / withdrawal, credit card). For example, when a user changes settings for a payment method, the messaging application will process the payment transaction later according to the settings set by the user. In some instances, a user may set individual settings for sending a payment and receiving a payment, where the system 100 processes the payment sent from the user using a payment method or account different from when the payment was received by the user can do.

As discussed above, one or more embodiments enable a sender to initiate a payment transaction without providing a payment credential. Therefore, the integrated messaging and payment system can ensure that the recipient will receive the funds before providing sensitive financial information. Figures 5A-5D illustrate alternatives to the flow shown in Figures 4A-4O where the originator provides a delayed payment credential. In particular, as described above, if the sender is not associated with a registered billing account, the user interface manager 206 may determine that the sender has registered a payment credential, as shown in Figure 5a (similar to that shown in Figure 4f) (E. G., Provide payment information as described above). ≪ / RTI > At this point, the sender may not have the time or information necessary to enter the full payment credentials. Alternatively, the sender may want to be assured that the recipient will accept the payment before providing the payment credential. In any case, the sender can select the "Skip" element 439 without entering payment credential information.

When selecting the "Skip" element 439, the system 100 may store information associated with the request to initiate a payment transaction and generate a transaction ID. Specifically, the information storage may allow the system 100 to refer back to the stored information when the caller finally enters the credentials. For example, the system 100 may store the identity information for the sender, the recipient, the payment amount, and other information that enables the system 100 to resume processing the same payment transaction initiated by the caller quickly. In some instances, the system 100 may store information in the server device (s) In another example, client device 104a may store at least a portion of the information for later use by system 100 when completing a payment transaction.

At this point, the system 100 may send a notification to the recipient of the payment transaction. Figure 5B illustrates the messaging interface 412a in the recipient client device 400a after the originator initiates a payment transaction to remit the payment to the recipient. In one or more embodiments, the system 100 may notify the recipient that the caller has initiated a payment transaction. For example, the user interface manager 206 may display a settlement amount and display a payment message 432a indicating that the sender wants to send money to the recipient (e.g., "Donald wants to send you money"). In order to distinguish the system 100 from the payment amount that has a valid credential from the sender, the user interface manager 206 may send a " Pending ... "or other signal that allows the recipient to know that the payment transaction is still pending . To illustrate, the user interface manager 206 may insert a payment amount into a communication thread 414a that has other messages exchanged between the sender and the recipient. Additionally or alternatively, the user interface manager 206 may display the payment amount in other ways (e.g., by providing a notification in the notification area of the recipient client device 400a).

Additionally or alternatively, the user interface manager 206 may show other notifications indicating that the caller has initiated a payment transaction on or within the drop-down overlay 450a or messaging interface 412a. In one example, the drop-down overlay 450a may allow the recipient to select an element in the drop-down overlay 450a, such as a drop-down overlay 450a or an approval element 452, ) ≪ / RTI > confirmation request. In one or more embodiments, when a recipient chooses to accept payment, system 100, client application 202 may send a request to network application 204 to determine whether the recipient has a registered payment credential have. If the recipient is not associated with a registered payment account, the user interface manager 206 provides a credential user interface 434 that allows the recipient to register the payment credential (e.g., provide payment information as described above) Can be displayed.

If the recipient has a payment credential, the system can send a notification to the sender of the payment transaction to inform the sender that the recipient has approved the transaction. 5C illustrates the messaging interface 412 of the originator client device 400 after the recipient accepts the payment. For example, the user interface manager 206 may show a payment amount 432 indicating the payment amount and an indication that the transaction is still pending (i.e., "Pending ..." or another signal). Additionally or alternatively, the user interface manager 206 may display the payment amount in other ways (e.g., by providing a notification in the notification area of the recipient client device 400a).

Further, the user interface manager 206 may show other notifications indicating that the recipient has approved the settlement on or within the drop-down overlay 500 or messaging interface 412 and that the caller is pending payment credential provisioning. As an example, the drop-down overlay 500 may include a selectable option, as shown in Figure 4i, or a credential user interface 434 that allows the sender to register a payment credential (e.g., to provide payment information as described above) The element 502 can be selected to open. From this point on, the settlement transaction can be continued as described above.

Alternatively, if the caller is away or otherwise busy with the device 104a, the caller may not be able to provide a payment credential at this time. In this case, the client application 202 may send a notification to the recipient indicating that the caller has not yet provided a payment credential. In response to this notification, the user interface manager 206 may provide the recipient with a reminder option 504 in the message as shown in FIG. 5D. Specifically, the reminder option 504 may impose social pressure on the recipient by reminding the sender of the payment transaction. For example, selecting the reminder option 504 may cause the system 100 to send a message to the sender to complete the settlement transaction by entering a credential for the settlement transaction. In some cases, the message to the sender may cause a message or notification to appear within the messaging user interface 412 of the originating client device 104a and / or originating client device 104a. Additionally or alternatively, the system 100 may display the credential user interface 434 to the sender in response to a reminder message from the recipient. In a further embodiment, the system may generate a social network post indicating that billing is pending and post it to the sender and / or recipient's account. These social network posts can create social pressure to provide the credentials to the sender to complete the transaction.

In some implementations, the system 100 may provide a safeguard that prevents the recipient from abusing the reminder message. Specifically, if the recipient repeatedly selects the reminder option 504, the fast and / or repeated reminders of the originator client device 104a may irritate the caller. Thus, the system 100 can provide a timer so that the recipient can send an additional reminder only after a predetermined time.

In another embodiment, in response to various events, the system 100 may automatically send a reminder to the caller. For example, the system 100 may send a reminder to the originator to enter a credential in response to detecting that the recipient has entered a credential to receive a payment. In this example, the system 100 may send a notification to the recipient indicating that the sender has not entered a credential and that the recipient can not withdraw funds. In another example, the messaging system 100 may send a reminder at an appropriate time after a previous reminder or after a certain time after some other event (e.g., a predetermined time for a request to initiate a payment). In a further example, the messaging system 100 may send a reminder at the appropriate time based on an analysis of one or more electronic messages associated with the recipient (or other user).

In the case where the network application 204 includes a social networking system, the network application 204 may provide a social network post to the feed of the sender, recipient or sender or recipient's "friend. &Quot; This social network post may indicate that payment has begun from the sender to the recipient but is pending until the sender provides a payment credential. Therefore, the system 100 may apply social pressure or other inducements that encourage the caller to enter a payment credential and complete a payment transaction.

In addition to providing a social network post that encourages the sender to enter a payment credential, the system 100 may provide a social network post that encourages the recipient to accept the payment and enter the payment credential. In addition, the system 100 may provide a social network post that announces the payment from the sender to the recipient. In addition, the system 100 may provide a social network post indicating that the user has provided a payment credential to inform "friends " that they can now send and receive payments to the user. It will be appreciated by those of ordinary skill in the art in light of this disclosure that such social network posts may be subject to the privacy settings of the sender or recipient.

In addition to providing a payment interface that allows a caller to initiate a payment transaction, the system 100 allows the user to send or initiate a payment directly from the messaging user interface 412 without having to open a separate or dedicated user interface can do. As will become apparent from the following description, this may allow a user to send and receive a payment without interrupting the flow of the conversation. For example, the client application 202 may deduce a payment based on a predetermined string, as shown in FIG. 6A. Specifically, the message analyzer 212 may recognize a particular grammar that allows a user to perform a payment event associated with a payment transaction. For example, the sender may send a message containing a predetermined string (such as a symbol) to the recipient, and the message analyzer 212 may recognize the grammar as a request to initiate a payment transaction. In some instances, the system 100 may be configured to perform a payment transaction based on a predetermined string, such as requesting a payment from one or more other users, sending a payment to one or more users, setting a payment amount for a payment transaction, One or more operations may be performed.

To illustrate, the sender and receiver can communicate with each other through a message about possible payment transactions. For example, FIG. 6A shows a communication thread 414 with a message for payment due to a concert ticket. For example, as shown in FIG. 5A, the recipient can send a reminder that the sender is owed to the recipient. The sender may send a message 600 containing a predetermined string indicating the payment event to the recipient. When the caller responds to the recipient, the caller can send a message containing the predetermined string "$$" indicating the intention of the caller to make a payment to the recipient. For example, the message analyzer 212 can deduce that the payment amount is equal to the numeric value after the string "$$ " (e.g.," $$ 25 "means that the sender wants to pay $ 25 to the recipient) Quot; $$ "string without any other input from the user.

It will be appreciated that a typical descriptor allows system 100 to select strings that are not commonly used in special grammars (such as two dollar signs). In one or more embodiments, the system 100 may enable a user to customize the grammar recognized for different payment events. Specifically, the user can modify an existing grammar, remove an existing grammar, or add a new grammar. Additionally or alternatively, a user may modify existing payment events associated with a particular grammar, remove existing payment events associated with a particular grammar, or add new payment events associated with a particular grammar. Thus, the user can customize the payment flow to recognize the customized string associated with the customized payment event.

In a further embodiment, the payment control 424b of the message input control palette or toolbar 422 may operate in a special grammar. In other words, if the user selects payment control 424b, user input detector 208 may recognize that the user desires to send a payment. The payment message generator 216 identifies any amount entered after the selection of the payment control 424b as a payment amount.

After the message analyzer deduces the payment event based on the predetermined string, the system 100 may continue the payment transaction process. For example, if the sender does not have a payment credential in the file, the system 100 may provide a credential user interface 434 to request the payment credential from the sender. Alternatively, if the user already has a payment credential in the file and provided a PIN, the user interface manager 206 may display the PIN verification user interface. For example, FIG. 6B shows a PIN drop-down overlay 602 on or in the messaging interface 412 or other notification that allows the originator to verify that he wants to provide the PIN and send a payment.

The skilled artisan will appreciate that the PIN verification user interface 602 may enable the user to verify that he or she desires to send a payment based on a special grammar. Thus, the PIN verification process prevents the user from forgetting the special grammar and sending the payment by mistake. As discussed below in conjunction with FIG. 7C, if the user chooses not to use the PIN, the system 100 may provide a separate billing confirmation user interface that prevents the user from accidentally sending a payment.

When the sender completes the message 600 configuration including the special grammar and payment amount and confirms the payment by PIN entry or otherwise, the payment message generator may generate a payment message, which is ultimately sent to the network application 204. In response to the payment message, the network application may process the payment and message (600). For example, the network application 204 may send a message 600 to the recipient client device 104b to allow the corresponding message 600a to be provided to the recipient's messaging interface 412b, as shown in Figure 6c . Furthermore, the network application 204 can remit to the recipient.

In addition, as shown in FIGS. 6A and 6C, the user interface manager 206 may indicate that it includes payment by changing one or more properties or attributes of the message 600, 600a. For example, both FIGS. 6A and 6C highlight the amount of messages 600 and 600a. Further, in one or more embodiments, the user interface manager 206 may set the visually differentiated payment amount as a selectable element. When selecting a visually differentiated payment amount in the communication thread 141, the payment message generator 216 may cause the caller to cancel the payment, change the payment amount, or otherwise change one or more parameters of the payment.

When the sender completes the message 600 configuration including the special grammar and payment amount and confirms the payment by PIN entry or otherwise, the payment message generator may generate a payment message, which is ultimately sent to the network application 204. In response to the payment message, the network application may process the payment and message (600). For example, the network application 204 may send a message 600 to the recipient client device 104b to allow the corresponding message 600a to be provided to the recipient's messaging interface 412b, as shown in Figure 6c . Furthermore, the network application 204 can remit to the recipient.

In addition to allowing a user to initiate a payment transaction in advance, one or more embodiments intelligently initiate a payment transaction or induce a user to initiate a payment transaction. For example, one or more embodiments include inferring a payment event based on an electronic message exchanged between users. In particular, one or more embodiments may analyze an electronic message exchanged between two or more users to determine whether there is a possibility of a payment event involving more than one user. After deducing a payment event, one or more embodiments provide an option to initiate a payment transaction between users based on the inferred payment event. Thus, one or more embodiments may allow a user to initiate a payment transaction with another user based on a message exchanged between users without interfering with the natural flow of the message exchange.

For example, FIG. 7A shows a communication thread 414 showing a plurality of messages exchanged between "Rodger" (hereinafter caller) and "Joe " FIG. 7A shows that the recipient has sent the sender the message "Hey I'm short on cash and need some money." In response, the sender sent the message "How much money do you need?" The recipient replied to the message "I need about 75 bucks to pay bills." (416c).

The message analyzer 212 may analyze incoming and outgoing messages between a sender and a recipient. When analyzing a message, the messaging system 210 may parse the message into any type of group of sentences, words, phrases, characters, and / or message analyzers 212 that can interpret the content of the message. Specifically, the message analyzer 212 may interpret the content to deduce a payment event from the message. For example, the message analyzer 212 may interpret the conversation and determine that the recipient requests money from the sender based on a message generated by one or both of the sender and the recipient.

While analyzing the message between the sender and the recipient, the message analyzer 212 may interpret the natural language of the message corresponding to the payment event. Specifically, the message may include an intention to initiate a payment transaction using a natural language by the sender or recipient. The message analyzer 212 may determine the payment event rather than performing a rigorous predetermined series of actions for interpreting the natural language using the natural language processing to initiate and process the payment transaction. To illustrate, the message analyzer 212 may determine from the message between the sender and the recipient that the recipient requests the sender $ 75 as a payment event.

In response to the inferred payment event, the user interface manager 206 may provide an option to initiate a payment transaction. In particular, the user interface manager 206 may provide the caller with the option to initiate a payment transaction by modifying one or more messages in the graphical user interface of the originator client device 104a. For example, the user interface manager 206 may convert "75 bucks" of the recipient's message 416c into a payment start selectable element 700. In another example, the user interface manager 206 may convert the entire message 416c into a payment start selectable element. In a further example, the user interface manager 206 may provide a notification (e.g., a pop-up window or other onscreen element) to ask the caller whether the caller wants to initiate a payment transaction with the recipient.

In any case, the user interface manager 206 may modify the attributes or characteristics of one or more of the messages 416c, or portions thereof, to indicate the generation of the billing start selectable element 700. For example, the user interface manager 206 may highlight "75 bucks " as shown in FIG. 7A. Alternatively, the user interface manager 206 may change the underline, font style, size, color, etc., or otherwise visually distinguish the payment start selectable element 700.

Because the message analyzer 212 can interpret the natural language, the message analyzer 212 can deduce a payment event based on a change in the text or content of the message. For example, if the recipient is referred to as "75 dollars", "$ 75", "seventy-five dollars", etc. instead of "75 bucks", the message analyzer 212 interprets the content and deduces the amount of the inferred payment transaction . Additionally, the message analyzer 212 may deduce from the message that the caller is the person to pay and that the recipient requests the money. Thus, the message analyzer 212 can deduce and pre-populate whether the sender or recipient initiates a transaction within the messaging application to expedite payment transactions.

To help the message analyzer 212 identify a potential payment event, the system 100 may include a list of predetermined terms or phrases indicating that a payment event is available. For example, a phrase that indicates that a payment event is possible may be a sole or "you owe me", "I owe you", "your portion is", "your half is "" pay me, "" I will pay you, "and so on. In this way, the message analyzer 212 can deduce that a payment event is possible using the contents of a plurality of messages during a conversation. For example, a message of "$ 45" may not be sufficient to indicate that a payment event is available. On the other hand, a message consisting of "$ 45" after a message of "how much do I have you" can indicate the probability of a payment event.

In addition to the above, the message analyzer 212 may calculate the probability of a payment event using the machine learning model and historical data of other users of the social networking system that initiated the payment event. In one or more embodiments, the message analyzer 212 trains the machine learning model using historical data collected by the user, whether or not each user participated in a payment event, and the type of event. The machine learning model can use multiple data points in the collected data as variables to generate a predictive algorithm. For example, the machine learning model may analyze transmitted or received messages or other behaviors of a first user or users performed prior to initiating a payment. The message analyzer 212 may then provide the second user with the option of participating in a payment event when they recognize that the second user has performed the same or similar activity.

In one or more embodiments, the system 100 may generate a training set for training a machine learning model based on content obtained via one or more users' social networking profiles or other profiles associated with the system 100. For example, the system 100 may identify a user of the social networking system that performed the payment transaction. The system 100 may then collect information about such users, such as location, exchanged messages, check-ins, social network posts, etc., before performing a payment transaction. Thus, the system can identify communication data, social network data or users, or collect other information associated with the user. To illustrate, the system 100 may retrieve data from a user profile for a specific period of time (e.g., one week before the event or one month before the payment transaction). In other exemplary embodiments, the duration may vary based on the event.

In one or more embodiments, the system 100 may weight data based on a corresponding date. For example, the system 100 may determine that a change in the relationship state of April 1 is not a reliable indicator of the payment transaction detected. The system 100 may remove unreliable data from the training set.

The system 100 may also calculate the probability of a user participating in a payment event based on a training set based on the user ' s communication and behavior. The system 100 may train a machine learning model based on several factors including the words of the electronic message associated with the user, the length of the message, the frequency of communication to the user, the type of action taken, and the like. In such an embodiment, the system 100 may assign a high probability of a payment event to a user whose communication data indicates a high frequency of the identified word. The machine learning model may generate a prediction algorithm that calculates the probability of a user participating in a payment event or a payment event occurring.

If the user's probability score is above the provided critical score, the system 100 may predict that the payment event has occurred, is happening, or is likely to occur. Based on this determination, the system 100 may provide the user with an option to initiate a payment event as described above. In particular, the system 100 may convert a portion of the message into a payment start selectable element 700. In another example, the user interface manager 206 may convert the entire message 416c into a payment start selectable element. In a further example, the user interface manager 206 may provide a notification (e.g., a pop-up window or other onscreen element) to ask the caller whether the caller wants to initiate a payment transaction with the recipient.

After the user input detector 208 detects a user selection of the payment start selectable element 700, the system 100 may continue the payment transaction processing as described above. For example, if the sender does not have a payment credential in the file, the system 100 may provide a credential user interface 434 to request the payment credential from the sender. Alternatively, if the sender already has a payment credential in the file and provided a PIN, the user interface manager 206 may display the PIN verification user interface 602 as shown in FIG. 7B. The skilled artisan will appreciate that the PIN verification user interface 602 may enable the user to verify that he or she desires to send a payment based on the inferred payment event.

If the user has not provided a PIN, the system 100 may provide a payment confirmation interface 708 as shown in FIG. 7C. In particular, the payment confirmation interface 708 allows the caller to enter or confirm payment amounts associated with payment transactions, as well as other details associated with payment transactions. For example, the payment confirmation interface 708 may include a payment type element 710, a payment amount field 712, a payment source element 716, an origination confirmation option 714, and a numeric keypad 438. In some instances, the payment confirmation interface 708 may include more or fewer graphics components and / or features than those shown in FIG. 7C.

In one or more embodiments, the system 100 may prepare a payment confirmation interface 708 based on information deduced from the message between the sender and the recipient. Specifically, the system 100 may be able to pre-match as much information as possible from the analyzed message to the payment confirmation interface 708 to speed up the payment transaction process. For example, the system 100 may automatically select a "Send Money" payment type rather than a "Request Money" payment type based on information deduced from the message. In addition, the system 100 may pre-populate the payment amount field 712 with the payment amount inferred from the message. In some embodiments, the sender may change any information previously placed in the payment confirmation interface 708 (e.g., payment amount, payment type) using, for example, a numeric keypad 438.

In some embodiments, the payment information may include a payment source element 716. In particular, the payment source element 716 allows the caller to enter a payment source to complete a payment transaction. For example, the sender may select the payment source element 716 and enter the payment credential interface 434, shown in FIG. 4n, to enter billing information (e.g., credit card information, debit card information, financial account information) You can gate.

In one or more embodiments, the system 100 may additionally or alternatively provide an option for the recipient to initiate a payment transaction. Specifically, the system 100 may provide an option to request money from the originator in a payment transaction. For example, the system 100 may convert text or other content of one or more messages of a recipient's communication thread into selectable elements. When a recipient selects a selectable element corresponding to an inferred transaction event, the system 100 may initiate a payment transaction to allow the recipient to send a request for funds to the sender.

As described above, the system 100 may enable settlement transactions between user groups. For example, the system may provide an option to initiate a payment transaction based on a payment event inference involving a plurality of opponent users. The system 100 may deduce such payment events based on exchanged messages, social network posts, connections between users, location data, etc. in a group communication session. Figures 8A-8D illustrate an example of providing options to initiate group settlement.

8A shows a timeline or information feed 800 of a social network. The information feed may include an electronic message from a user of the client device that further corresponds to an electronic message from another user in the system 100 to the user. Specifically, information feed 800 may include a composite of electronic messages (e.g., social network posts) that may be related to a user based on a relationship with a creator of the user's electronic message. For example, an electronic message posted by the author of the system 100 may appear in the information feed 800 if the user has a predetermined relationship (e.g., "friend") with the creator of the electronic message. In various cases, the electronic message of the information feed 800 may be ordered according to the time the author posted the electronic message or according to the importance ranking system determined by the system 100. [

In one or more embodiments, the electronic message may be a message generated by the system 100 or by another user in association with the group event. Specifically, the electronic message may be any message inside the messaging application and associated with the group event. For example, the electronic message may include a message identifying the user and displaying an event associated with the user. In some instances, the electronic message may also identify other users associated with the event.

In one or more embodiments, a user may publish an electronic message to a social networking system. Specifically, a user may post electronic messages associated with group events in his information feed 800. For example, the electronic message may be a check-in message 804 that indicates that the user is eating at the restaurant by tagging the other user (e.g., "At The Good Diner with John Doe, Brutus Pendleton, and Jane Smith. ). In some instances, the electronic message may indicate that at least one other user of system 100 is also in the restaurant with the user.

In one or more implementations, the system 100 may use any information associated with an electronic message to identify past, present, or future group events, in addition to members of the user and / or group. For example, the system 100 may use location information (as shown in map 806 of FIG. 8A) and may review information and other information associated with an event of one or more electronic messages of the system 100 have. In some cases, the system 100 may use user interaction information, such as comments associated with electronic messages or information associated with "like ". The system 100 may also utilize shared data associated with one or more messages (e.g., which users have shared electronic messages with other users).

According to various additional or alternative embodiments of the system 100, the system 100 may predict events associated with one or more users of the system 100. Specifically, the event may include concerts, restaurant visits, amusement park visits, work activities, birthdays, baby births, adoptions, deaths, marital status changes, graduations, employment status, age, health, In one or more examples, the system 100 may determine an event based on whether there is a cost or a gift associated with the event. For example, the system 100 may identify that the user is a birthday and that there is a product in the wish list based on the social network data. The system 100 may then identify a friend of the user who wants to buy the product for the user's birthday. The system 100 may then send a payment request notification. In this embodiment, the user (i. E., The birthday person) may avoid receiving a payment request notification and in fact deciding that the system has sent a payment request notification to allow a friend to buy a gift. The system 100 may determine a friend to provide a payment request notification based on the location information based on the RSVP of the user's birthday party based on the relationship between the user and each friend and the relationship between friends (i. E. You can choose.

The system 100 may use the machine learning model and historical data of other users of the social networking system between events defined by the system 100 to calculate the probability of a user participating in the event. In one or more embodiments, the system 100 trains the machine learning model using historical data collected about the user, whether each user has undergone an event change, and the type of event. The machine learning model can use multiple data points in the collected data as variables to generate a predictive algorithm. For example, the use of words such as "celebrate", the presence of a proposed virtual gift to a user, the number of times another user clicked on a user's profile, a change in other profile information, such as a change in address or gender, An electronic message posted in the information feed of yourself and / or another user, and the like.

In one or more embodiments, the system 100 may generate a training set for training a machine learning model based on content obtained via one or more users' social networking profiles or other profiles associated with the system 100. For example, the system 100 may collect marital status information, employment information, home address information, age information, communication data, social network data, or other information associated with a user or user. For example, the system 100 may retrieve data from a user profile for a particular period of time prior to the recorded event (e.g., one week before the event or one month before the event). In other exemplary embodiments, the duration may vary based on the event.

In one or more embodiments, the system 100 may weight events based on corresponding dates. For example, the system 100 may determine that a change in the relationship state of April 1 is not a reliable indicator of the detected event. The system 100 may remove unreliable data from the training set.

The system 100 may also calculate the probability of a user experiencing an event based on a training set based on communication and behavior of the user in the system 100. The system 100 may train a machine learning model based on several factors including the words of the electronic message associated with the user, the length of the message, the frequency of communication to the user, the type of action taken, and the like. The machine learning model can generate a prediction algorithm that calculates the probability of a user experiencing a particular event. If the user's probability score is above the provided critical score, the system 100 may predict that the user is experiencing the event.

The system 100 may use the user's historical data as an input to determine a probability score that indicates whether the user will experience a particular event based on historical data of another user. In one example, the system 100 may classify a user as experiencing an event if the user's probability score is higher than the threshold score. In another example, the system 100 may identify a letter, word or phrase that represents an event of an electronic message exchanged between two or more users of the system 100. In such an embodiment, the system 100 may assign a high probability of an event to a user whose communication data indicates a high frequency of the identified word.

As described above, using the machine learning model, the system 100 can deduce events from one or more electronic messages associated with one or more users of the system 100. [ The system 100 may also infer one or more members associated with a user and an event.

In response to the group event inference, the system 100 may provide the user with an option to allow the user to initiate a settlement transaction with one or more other members of the group. For example, the system 100 may provide an option to an electronic message in which the system 100 inferred an event, as shown in FIG. 8A. To illustrate, the system 100 may provide a payment collection element 808 (e. G., "Collect Payment") in a text field of an electronic message. In some cases, the option may be inline within an electronic message. Alternatively, the system 100 may provide a push notification or other electronic message to induce a payment transaction to begin.

In one or more embodiments, the system 100 senses the user selecting an option to initiate a payment transaction with one or more members of the group and displays the payment request interface 810 to the messaging application as shown in FIG. 8B . The payment request interface 810 may provide an interface for a user to request money from one or more members of the group according to the inferred event. For example, the payment request interface 810 may display an amount 812 associated with a payment event. The amount 812 may be pre-positioned based on the content analyzed by the message analyzer 212. Alternatively, the user can manually enter the total amount.

In one or more additional or alternative embodiments, the system 100 may deduce the cost from one or more messages associated with the group event. In particular, the system 100 may analyze one or more electronic messages and information associated with the messages to determine the cost. For example, the system 100 may discover the cost of the event based on the content contained in the electronic message from the third party site. To illustrate, if the group event is a concert, the system 100 can determine the cost of the ticket based on multiplying each ticket value by the number of users in the group and visiting the website to buy a concert ticket. The user can modify the total cost deduced by manually changing the total cost 812 and / or by modifying the number of users in the list of group members.

The payment request interface 810 may further include a list of users identified to be associated with the payment event. For example, FIG. 8B includes a list of users 814a-814c tagged in a post 804. For example, the system 100 may infer members of a group based on one or more electronic messages associated with the event and / or relationships between users of the system 100. [ To illustrate, the system 100 may determine the level of the relationship between the user and the member (e.g., how close the relationship is or whether the relationship is a "high count" relation) Based on who has checked in with the user at the current location, who is physically close to the user at the current time, who has a friend relationship with the user, whether any user is identified in one or more electronic messages, etc. Can be displayed. The system 100 may display the proposed members of the group in the billing request interface 810 so that the user can identify the members of the group.

In one example, the user may modify the proposed list by adding or removing users from the list of members by selecting the cancel option 816 or the add friend option 818. [ The user can modify the list if one or more members do not belong to the group or if the user decides not to collect payments from one or more users of the group. Therefore, the user may potentially remove each proposed member to create a list of members that were not originally shown in the payment request interface 810. [

The payment request interface 810 may provide the user with the ability to equally divide the total amount 812 by selecting the option 818a. In addition, the payment request interface 810 may provide the ability to divide the total amount 812 in a custom manner by selecting a custom option 818b for the user. When the custom option 818b is selected, the user interface manager 206 may provide a custom request interface 820 as shown in FIG. 8C. In the custom request interface 820, the user can place a custom request amount 822 individually for each user. For example, a user may enter an amount for each individual user based on what the user owes or other criteria. To illustrate, if the event corresponds to a dinner event where the user paid for a meal, the user may enter a custom payment amount 822 corresponding to each user's food cost for each user.

Upon confirming the payment, the payment message generator 216 can prepare the payment message and transmit it to the network application 204. [ The payment message may include information provided to the payment request interface 810 and / or the custom request interface 820, e.g., an identification of each user and a payment amount sent to each user. Alternatively, the payment message generator 216 may prepare and transmit an individual payment message for each user included in the request.

The network application 204 may process a payment request for each user. In particular, the network application 204 may send a payment request notification to each user. The payment request transmission may include a push notification sent to one or more client devices associated with the user. Upon receiving the notification, the client application 202 may display a payment request notification. For example, the client application 202 may provide a notification indicator 840 via a notification control 842. The notification indicator 840 may inform the user of the received notification.

Upon selection of the notification control 842, the user interface manager 206 may provide a notification interface 844. The notification interface 844 may display a plurality of notifications received for the user client device 400c. In one example, the notification interface 844 displays a payment request notification 846 at the top of the list of notifications for the user, as shown in FIG. 8D. The payment request notification 846 may include a selectable element 848, or the entire payment request notification 846 may be a selectable element. The system may also provide an option for the sender to put pressure on the social by reminding the recipient of the payment transaction. For example, by selecting a reminder option (similar to the reminder option 504 described above), the system 100 can send a message to the recipient to complete the settlement transaction by entering a credential for the settlement transaction. In some cases, the message to the recipient may cause a message or notification to appear in the messaging user interface 412 of the originating client device 104a and / or originating client device 104a. Additionally or alternatively, the system 100 may display the credential user interface 434 to the recipient in response to a reminder message from the recipient. In a further embodiment, the system may generate a social network post indicating that billing is pending and post it to the sender and / or recipient's account. These social network posts can create social pressure to provide the credentials to the sender to complete the transaction.

When the user selects payment request notification 846 of notification interface 844, user interface manager 206 provides a payment confirmation interface 708 as shown in Figure 8E and also as described above in connection with Figure 7C . Alternatively, the user interface manager 206 may provide a PIN verification interface as described above with respect to FIG. 6B. In any case, the PIN verification user interface or payment confirmation interface 708 may allow the user to confirm the payment. In response, the client application may send a payment message to the network application 204 to cause the network application 204 to process the payment transaction as described above.

In one or more embodiments, the user may pay the total cost associated with the group event after collecting from the group's peer users. For example, a user may enter a payment transaction with a business associated with a group event (e.g., a restaurant). The user can enter into a payment transaction with the company using the system 100. [

In an additional or alternative implementation, the user can initiate a single payment transaction with the business and group users, allowing the business to directly collect payments from each user without requiring the user to collect payments from the user in an individual transaction. Specifically, the system 100 may infer group events based on input from a vendor. In this embodiment, the user can arrange a payment transaction for the group as a whole as a one-to-one transaction (e.g., to split a bill at a restaurant) where the business is the recipient but the user confirms the group user, have. Allowing users to prepare these payment transactions can simplify the payment transaction between the group and the business.

As described above, the system 100 can infer payment events by analyzing the natural language of the electronic message. The system 100 may also deduce a group settlement event. Specifically, as shown in FIG. 9A, the system 100 includes comments 902 associated with an electronic message as well as a user's electronic message (e.g., status message 800 in the information feed 900) Lt; / RTI > In one or more examples, a user may use a natural language to indicate that he is going to a future event. To illustrate, if a user (identified as a user by system 100) says "Going to the Old Wizard Puppet concert in Palo Alto ... Who wants to come?", The system 100 analyzes the natural language A future event can be determined to be a specific concert at the Palo Alto location.

In addition, the system 100 may determine that one or more additional users may join the concert with the user based on comments 902 and "Likes" 906 associated with the status message 904 (or other electronic message) . Specifically, the system 100 may analyze the content of the comment 902 associated with the status message 904 to determine whether one or more users who commented on the status message 904 are users of the group associated with the group event. For example, if the user has commented on the concert as "Show sounds way cool, I'm in!" In response to the status message 904, the system 100 will determine that the user also goes to the concert and is a user of the group . In another example, system 100 may analyze "like" 906 for status message 904 to determine whether the corresponding user is a user of the group. Described system 100 may identify the user and analyze the electronic message associated with the identified user to determine whether the user is a user of the group.

As described above, the system 100 may provide a payment collection option 908 for the user to initiate a payment process for collecting payments from a user of the group. If option 908 is selected, the system 100 sends a payment request interface 810 containing a list of users 814c, 814d, 814e, as shown in FIG. 9B and as described above in connection with FIG. Can be displayed. The user may modify the list of users to include more, fewer, or other users than are listed.

In one or more embodiments, the user may choose to equally divide the total cost 812. Specifically, choosing to equally divide the total cost 812 may cause the system 100 to automatically divide the requested payment amount based on the total cost 812 and the number of users in the user list. For example, the system 100 may divide the total cost 812 by the number of users (including users) to obtain a payment amount for requesting the user. After confirming the details of the group (e. G., User and settlement partition), the user can send a payment request to each user in the payment request interface 810. [ The consolidation request process can then proceed as described above with respect to Figures 8a-8e.

Figures 1-9, corresponding text, and examples provide a number of different systems and devices for transmitting and receiving payments using an integrated electronic payment and messaging system. In addition to the foregoing, embodiments may be described in terms of a flowchart including acts and steps of a method for achieving a particular result. For example, Figures 12-19 illustrate a flow diagram of an exemplary method in accordance with one or more embodiments.

FIG. 10 shows a flow diagram of a method 1000 for initiating a payment transaction based on payment event inferences. The method 1000 includes an act 1002 of analyzing an electronic message. Act 1002 includes one or more electronic message analysis exchanged between a user and one or more other users by at least one processor. As an example, act 1002 may include analyzing an electronic message of a messaging conversation that includes a user and one or more opponent users. Further, act 1002 may include parsing the text of the plurality of messages to identify one or more phrases or terms.

The method 1000 also includes an act 1004 of inferring a settlement event. In particular, act 1004 includes inferring a settlement event based on an analysis of one or more electronic messages exchanged between a user and one or more counterpart users. Act 1004 may include identifying a natural language phrase that points to a payment event from one or more electronic messages. For example, action 1004 may include using a natural language processing technique to infer payment events from the natural language of messages exchanged between a user and one or more users. As an example, action 1004 may include inferring that a natural language technique is desired to start a payment transaction.

Act 1004 may also include identifying a language that indicates sending or borrowing money to one or more counterpart users. In some cases, a natural language phrase may include at least one predetermined phrase, string, or symbol. In one example, a symbol may include one or more dollar signs. For example, natural language phrases can include numbers. In one example, the act 1004 may include sending a predetermined symbol (e.g., "$$ 25") followed by a payment amount, indicating that the user wishes to initiate a payment transaction and send the payment amount to one or more other users, And detecting in an electronic message (e.g., an instant message) to the other user.

Additionally, method 1000 includes act 1006 initiating a settlement transaction. Specifically, act 1006 includes initiating a settlement transaction based on a settlement event, by at least one processor. Act 1006 may include providing an option to initiate a payment transaction, for example, by creating a selectable object in relation to a natural language phrase.

In one example, act 1006 may include making at least some of the natural language phrases selectable. Act 1006 includes modifying a group of identified words, phrases, or characters to indicate that a group of words, phrases, or characters is selectable to initiate a payment transaction between the user and one or more other users (e.g., , Highlighting, underlining, color, or otherwise modifying the appearance).

Act 1006 may additionally or alternatively include providing a confirmation request to the user. In one example, providing an acknowledgment request may include providing an acknowledgment request in response to the selection detection of the selectable object and before initiating the settlement transaction. Act 1006 may also include providing the user with an option to request a payment from one or more other users.

Act 1006 may also include sending a request to remit the payment to the one or more counterparties from the user without further user interaction upon detecting a predetermined symbol followed by the settlement amount. For example, sending a request to send a payment amount may include sending a payment amount to one or more counterpart users in response to detecting a predefined symbol and payment amount in an electronic message from the user to one or more users.

As part of act 1006, or as an additional act, method 1000 includes, by at least one processor, sensing a selection of a selectable object by a user and initiating a settlement transaction in response to the select detection . In some examples, sensing a selection of a selectable element by a user may include sensing a touch input, a cursor input, a voice input, or other type of input selecting a selectable element by the user. In one or more examples, initiating a settlement transaction may include displaying to the user a request to complete a transaction with one or more counterpart users for a payment amount inferred from one or more electronic messages.

11 illustrates a flow diagram of a sequence of actions in a method 1100 for initiating a payment transaction based on payment event inferences. The method includes an act 1102 of analyzing an electronic message. Act 1102 includes analyzing one or more electronic messages exchanged between a user and one or more other users by at least one processor. Act 1102 may include identifying natural language content of one or more electronic messages. Identifying natural language content may include parsing one or more electronic messages into a plurality of logical components, and may further include parsing one or more electronic messages into characters, words, and phrases.

The method 1100 includes an act 1104 of inferring a settlement event. In particular, the act includes inferring a settlement event based on an analysis of one or more electronic messages exchanged between the user and one or more counterparty users. Act 1104 may include, from one or more electronic messages, identifying a payment event from natural language content. Identifying the payment event may include, in natural language content, identifying a payment request from one or more other users using natural language processing. Identifying the payment event may alternatively include, in natural language content, identifying a request to send a payment to one or more other users using natural language processing.

Additionally, the method 1100 includes an act 1106 of identifying content associated with a payment event. Specifically, act 1106 includes identifying content associated with a payment event, in one or more electronic messages exchanged between a user and one or more other users. For example, act 1106 may include identifying text that indicates that a user desires to initiate a settlement transaction between one or more opponent users. Act 1106 may include inferring a user's intention to initiate a payment transaction based on an analysis of characters, words and / or phrases from one or more messages. Additionally or alternatively, act 1106 may include identifying a payment amount in one or more electronic messages.

The method 1100 also includes an act 1108 of converting the content to a selectable object. More specifically, act 1108 comprises, by at least one processor, converting the content to a selectable object for initiating a settlement transaction based on a settlement event. For example, act 1108 may include converting at least a portion of text indicating that a payment transaction is desired to begin to a selectable object. Act 1108 may include converting a word, phrase, symbol, or payment amount into a selectable object. In a further or alternative example, act 1108 may include adding new text or selectable objects associated with the identified content using the identified content of one or more electronic messages.

As part of act 1108, or as an additional act, method 1100 can include identifying a predetermined string in one or more electronic messages and performing an action associated with the settlement transaction based on the predetermined string. For example, identifying a predetermined character string may include identifying a group of symbols, characters, or characters that includes a particular grammar associated with a particular action for a payment event. A particular grammar may include predetermined combinations and / or sequences of groups of symbols, letters, or characters. As an example, performing an action may include performing an action upon identifying a predetermined character string that includes a particular grammar.

Figure 12 shows a flow diagram of a series of acts of a method 1200 for enabling settlement between groups of users. The method 1200 includes an act 1202 of analyzing an electronic message. Specifically, act 1202 includes analyzing one or more electronic messages by at least one processor. In one example, the one or more electronic messages may include one or more electronic messages exchanged in an electronic messaging session, one or more social network posts, or other electronic messages. In one example, an electronic message may include data generated by one or more devices corresponding to one or more other users, including location information periodically transmitted by one or more devices.

The method 1200 also includes an act 1204 of identifying a payment event. In particular, act 1204 includes identifying a settlement event based on an analysis of one or more electronic messages. In various examples, the payment event may be a past event, an event currently taking place, or a future event.

Act 1204 may include identifying a natural language phrase that points to a payment event from one or more electronic messages. Act 1204 may additionally or alternatively include identifying location information for the other user. Identifying location information may include identifying location information based on location information obtained from one or more electronic messages and / or electronic devices associated with one or more other users.

Additionally, the method 1200 includes an act 1206 of identifying a partner user associated with a payment event. In one example, act 1206 may include determining that one or more electronic messages include an identifier corresponding to an opponent user. For example, act 1206 may include identifying a counterpart user based on location information used to identify the settlement event. In some cases, act 1206 may also be based on the relationship established between the peer users, the previous interaction between the peer users, the peer's distance to each other and / or the specific location, or other information about the peer user or payment event And identifying the user.

The method 1200 also includes an act 1208 that provides an option to request a payment. Specifically, act 1208 includes providing, by at least one processor, an option of requesting a user of a counterparty to make a settlement from a counterparty user. As an example, act 1208 may include displaying an option in a message exchanged between opponent users. In another example, act 1208 may include displaying an option in a social network post posted by the user. In one example, act 1208 may include modifying the content of one or more electronic messages to create a selectable object associated with the option requesting a payment.

As part of, or as an additional act of, action 1208, method 1200 may include identifying a payment amount from one or more electronic messages and providing a payment amount to an option to request payment from the other user. Additionally, the method 1200 may include dividing a payment amount by the number of opponent users and providing a split payment amount to an individual payment request for each opponent user. For example, dividing the payment amount may include calculating the number of counterparty users associated with the payment event and dividing the total payment amount by the number of counterparts calculated. For example, providing a payment amount divided for an individual payment request for each counterpart user includes generating a payment request that includes a payment amount divided by an identifier of each counterpart user.

FIG. 13 shows a flow chart of a sequence of actions of a method 1300 for enabling settlement between groups of opponent users. The method includes an act 1302 of analyzing an electronic message. Specifically, act 1302 includes analyzing one or more electronic messages by at least one processor. In one example, the one or more electronic messages may include one or more electronic messages in one or more information feeds corresponding to the other user. As another example, one or more electronic messages may include one or more electronic messages exchanged between at least two counterpart users. In one example, an electronic message may include data generated by one or more devices corresponding to one or more other users, including location information periodically transmitted by one or more devices.

The method 1300 also includes an act 1304 of identifying a payment event. In particular, act 1304 includes identifying a settlement event based on an analysis of one or more electronic messages. In one example, act 1304 may include identifying a natural language phrase that points to a payment event from one or more electronic messages. In an alternative example, act 1304 may include identifying location information for the other user. In some cases, identifying the location information may include identifying location information from an electronic message associated with the one or more other users. In other cases, identifying the location information may include identifying location information from the electronic device corresponding to the one or more other users.

The method 1300 includes an act 1306 of identifying a partner user associated with a payment event. In one example, act 1306 includes identifying an opponent user associated with the event based on an analysis of the one or more electronic messages. In one example, act 1306 includes identifying an opponent user based on an analysis of the electronic message generated by the electronic device corresponding to the one or more opponent users. Act 1306 may detect the location of the electronic device corresponding to one or more counterpart users and determine a settlement event based on the distance of the counterpart user from the particular location.

Additionally, the method 1300 includes an act 1308 that provides a suggestion of the other user. More specifically, act 1308 comprises providing, by at least one processor, a user of a counterpart user with a suggestion of at least one other user of the counterpart user to request a settlement from at least one other user. In one example, the proposal of at least one other user of the plurality of opponent users is based on the strength of the relationship between the user and at least one other user. For example, the relationship strength may be based on a number of interactions between a user and at least one other user, a number of common friends between a user and at least one other user, or a separation between a user and at least one other user. In another example, the proposal of at least one other user of the other user is based on a previous payment interaction between the user and at least one other user. For example, the previous payment interaction may include a previous group payment involving the user and at least one other user.

The method 1300 also includes an act 1310 that provides an option to request a payment. Specifically, act 1310 includes providing, by at least one processor, an option of requesting a user of a counterparty user to make a payment from at least one other user based on the offer. For example, act 1310 may include displaying a selectable option requesting a settlement from each proposed opponent user in the list of proposed opponent users.

As part of act 1310, or as an additional act, method 1300 may include providing an inducement to a user to request payment from at least one other user. For example, the method 1300 may include displaying an induction to the user to request a payment from at least one other user in response to identifying at least one other user associated with the payment event.

As part of act 1310, or as an additional act, method 1300 includes identifying a payment amount from one or more electronic messages, providing a payment amount to an option to request payment from a requesting optional partner, Dividing the amount by the number of opponent users and providing the divided payment amount to an individual payment request for each counterpart user. For example, dividing a payment amount by the number of opponent users may include dividing the total payment amount for a payment transaction by the number of opponent users identified in association with the payment event.

14 shows a flow diagram of a series of actions of a method 1400 for initiating a settlement transaction without a payment credential. The method 1400 includes an act 1402 of receiving a request to initiate a payment event. Act 1402 includes receiving, at the server, a request from the user to initiate a payment transaction between the user and one or more other users. For example, the action 1402 may include receiving identification information and a payment amount for a payment transaction from a user at the server, and storing identification information and a payment amount for the payment transaction in the server.

As part of act 1402, or as an additional act, the method may include receiving payment information from a user at the server, and processing the payment transaction with the payment information received using the stored identification information and the stored payment amount . For example, processing a payment transaction may include completing a payment transaction by the user confirming payment information for accessing the account to remit one or more counterparties from the user based on the stored identification information and the stored payment amount .

The method 1400 also includes an act 1404 that provides an option to enter payment information. Act 1404 includes providing an option for the user to enter payment information by the server. For example, the payment information may include financial account information for the user. To illustrate, payment information may include an account number and a routing number for a financial account. In another embodiment, the payment information may include credit card information.

The method 1400 further includes an act 1406 of receiving an indication of delaying the entry of payment information. Specifically, act 1406 includes receiving an indication from the user to delay entering the payment information. In one example, act 1406 may include detecting a passive indication of delaying the entry of payment information based on the elapsed time since receipt of the request. Act 1406 may include detecting that the elapsed time without receiving payment information after receiving the request satisfies the time threshold. In another example, act 1406 may include detecting an active indication that defer the input based on the act of dealing performed by the user. Describing, the act of deferring may include a selection of deferring the entry of payment information.

Additionally, the method 1400 includes an act 1408 of providing a notification of a payment transaction. In particular, act 1408 includes providing a notification to one or more counterparties of the settlement transaction. In another example, act 1408 may include providing an electronic message to one or more counterpart users. In one example, the notification includes a notification that the user is sending a payment to one or more other users. The notification may also include a payment amount for payment.

As part of act 1408 or as an additional act, method 1400 may include receiving a request to complete a settlement transaction from one or more counterpart users and an option to enter billing information secondly by at least one processor . ≪ / RTI > In one example, act 1408 may include receiving a request to complete the settlement transaction after providing the notification of the settlement transaction to one or more counterpart users.

As part of the action 1408, or as an additional action, the method 1400 may include sending a reminder notification to the user to enter payment information. In one example, the method 1400 may include sending a reminder notification in response to detecting a selection of a reminder option from one or more of the other user. As another example, method 1400 may include sending a reminder notification in response to determining that a particular period of time has elapsed after receiving a request to initiate a payment transaction. As another example, the method 1400 may include sending a reminder notification in response to determining that a particular time period has elapsed after receiving the previous reminder notification. Alternatively, the method 1400 may include canceling the settlement transaction in response to determining that a particular period of time has elapsed since receiving the request to initiate the settlement transaction.

15 shows a flow chart of a series of actions of method 1500 for enabling settlement transactions without first receiving a payment credential from a sender. The method 1500 includes an act 1502 of receiving a request to initiate a payment event. Act 1502 includes receiving, at the server, a request from a user to initiate a payment transaction between the user and one or more other users. For example, the action 1502 may include receiving identification information and a payment amount for a payment transaction from a user at the server, and storing identification information and a payment amount for the payment transaction in the server.

As part of act 1502, or as an additional act, method 1500 includes receiving payment information from a user at the server and processing the payment transaction with the payment information received using stored identification information and stored payment amount can do. For example, processing a payment transaction may include completing a payment transaction by the user confirming payment information for accessing the account to remit one or more counterparties from the user based on the stored identification information and the stored payment amount .

Additionally, the method 1500 includes an act 1504 of providing a first induction for entering payment information. In particular, act 1504 includes providing, by the server, a first indication to the user to enter payment information in response to the detected payment transaction.

The method 1500 also includes an act of receiving an indication 1506 that delays the input. Act 1506 includes receiving an indication of delaying the input of payment information from the user. Act 1506 may include receiving an indication that the user is actively ignoring guidance. Act 1506 may include detecting a selection by a user to postpone the entry of payment information. Act 1506 may alternatively include receiving an indication that the user manually ignores the induction. Act 1506 may include detecting that the elapsed time without receiving payment information after receiving a request to initiate a payment transaction satisfies a time threshold.

The method 1500 includes an act 1508 of providing a notification of a payment transaction. Act 1508 includes providing a notification to one or more counterparties of the payment transaction. In one example, act 1508 may include sending an electronic message to one or more other users. In one example, the notification includes a notification that the user is sending a payment to one or more other users. The notification may also include a payment amount for payment.

Additionally, the method 1500 includes an act 1510 of providing a second induction for entering payment information. In particular, act 1510 includes providing the user with a second induction to enter payment information for the payment transaction detected by the server and in response to the received indication at the appropriate time. In one example, act 1510 may include providing a second induction in response to detecting a reminder notification that the user enters payment information.

As part of an action 1510, or as an additional action, the method 1500 may include determining an appropriate time by analyzing one or more electronic messages associated with one or more counterpart users. Alternatively, the method 1500 may include determining an appropriate time based on a predetermined time for the sensed payment transaction. Alternatively, the method 1500 may include receiving a request to complete a payment transaction from one or more of the other user and determining an appropriate time based on the request to complete the payment transaction.

16 shows a flow chart of a series of actions of a method 1600 of setting a payment amount in a payment transaction. The method 1600 includes an act 1602 of identifying a request to initiate a payment transaction. Act 1602 includes identifying, by at least one processor, a request to initiate a payment transaction between a user and at least one other user participating in a conversation using the messaging application.

The method 1600 also includes an act 1604 of providing a plurality of selectable elements 1100. In particular, act 1604 includes providing a plurality of selectable elements 1100 associated with a number in a messaging graphical user interface of the messaging application in response to an identified request on a display device of the mobile device. For example, the associated value may correspond to a payment amount to increase a payment amount associated with a payment transaction.

Method 1600 also includes act 1606 sensing the selection of two or more selectable elements 1100. Specifically, act 1606 includes, by at least one processor, sensing the selection of two or more selectable elements 1100 of the plurality of selectable elements 1100. In one example, the plurality of selectable elements 1100 include icons representing monetary values. To illustrate, the plurality of selectable elements 1100 may include an icon representing a common currency value corresponding to the user's nationality.

Act 1606 may also include detecting flickering motion of two or more selectable elements 1100 towards a conversation thread within a messaging graphical user interface. As an alternative example, act 1606 may include sensing a tab motion of two or more selectable elements 1100.

The method 1600 also includes an act 1608 of calculating a payment amount. In particular, act 1608 includes calculating a settlement amount for a settlement transaction by aggregating numerical values associated with the selected two or more selectable elements 1100 by at least one processor.

As part of, or as an additional act to act 1608, method 1600 may also include monitoring touch inputs associated with two or more selectable elements 1100. [ The method 1600 may also increase or decrease the amount of payment based on the direction of the touch input. The method 1600 may increase the amount of the payment in response to sensing the upward flicking motion of the touch input associated with the at least two selectable elements 1100. [ As another example, in response to sensing a downward flicking motion of a touch input associated with more than one selectable element 1100, the amount of payment may be reduced.

As part of, or as an additional act to, action 1610, method 1600 may also include monitoring a period after selection of one of selectable elements 1100 of a plurality of selectable elements 1100. The method 1600 may also include determining that the monitored period meets a predetermined inactivity threshold. The method 1600 may also include sending a request to complete the settlement transaction with the calculated settlement amount in response to determining that the monitored period satisfies the determined inactivity threshold. Alternatively, the method 1600 may include completing the settlement transaction with the calculated settlement amount in response to determining that the monitored period satisfies the predetermined inactivity threshold. The inactivity threshold may be a user-configurable time threshold.

For example, sending a request to complete a payment transaction may include generating a transfer message that includes an indication of a payment transaction, sending an indication of a payment transaction, and sending an electronic message to one or more other users. have. The method 1600 may include sending an electronic message as part of a time-dependent flow of the conversation within the messaging graphical user interface.

As part of, or as an additional act, the method 1600 further comprises detecting a selection by a user sending the calculated payment amount to the one or more counterpart users, and determining a payment amount calculated by the server associated with the messaging application And sending. For example, sending a calculated payment amount to a server associated with a messaging application may involve sending a payment amount calculated as an electronic message in a message exchange that includes a user and one or more other users. In one example, the message exchange is an instant message exchange within an instant messaging application.

In some cases, the method 1600 may also include converting the calculated payment amount based on one or more counterpart user's money to another amount. For example, the method 1600 can detect the country of one or more opponent users and convert the calculated payment amount based on the currency for the detected country to a converted value.

As part of, or as an additional act, the method 1600 may also include providing an initial payment amount in response to detecting a selection of the first selectable element (1100). The method 1600 also changes the initial payment amount provided to the messaging graphical user interface in response to detecting the selection of the second selectable element 1100 by adding the value associated with the second selectable element 1100 to the initial payment amount Lt; / RTI > For example, adding the value associated with the second selectable element 1100 to the initial payment amount may be accomplished by sensing the selection of the first selectable element 1100 and then detecting the selection of any other element, Element 1100. [0033] [0034] FIG.

As part of act 1608, or as an additional act, method 1600 may include providing a settlement amount to a conversation thread of the messaging graphical user interface in response to a payment amount calculation. The method 1600 may also include sending a request to complete the settlement transaction. For example, the request may include an electronic message provided to the conversation thread of the messaging graphical user interface.

The method 1600 may also include modifying the appearance of the payment amount in response to sending a request to complete the payment transaction. For example, modifying the appearance of a payment amount may include modifying the color of the payment amount or animating the payment amount. To remedy this, modifying the appearance of the payment amount may include modifying the appearance of the payment amount until the payment amount is approved. As an example, the method 1600 may include detecting approval of a payment amount and further modifying the appearance of the payment amount.

17 shows a flow chart of a series of actions in a method 1700 of setting a payment amount in a payment transaction. The method 1700 includes an act 1702 of receiving a message from an opponent user. Specifically, act 1702 includes receiving a message for a user of the mobile device from a partner user at the mobile device. For example, the message may include a message sent to the user by the other user.

The method 1700 also includes an act 1704 of adding a message to the messaging graphical user interface. Specifically, act 1704 includes adding a message to a messaging graphical user interface displayed on a mobile device, and the messaging graphical user interface includes a communication thread that includes a plurality of electronic messages exchanged between a user and a partner user. For example, act 1704 may include a message in a communication thread according to a time-dependent flow of a plurality of electronic messages exchanged between a user and a counterpart user.

The method 1700 further includes an act 1706 of identifying a request to initiate a payment transaction. Act 1706 includes identifying a request to initiate a payment transaction between a user and a counterpart user by at least one processor. For example, the request may include a natural language request, a special grammar request, or a selection of a messaging application's payment request option.

The method 1700 further includes act 1708 providing a plurality of selectable icons. Specifically, act 1708 includes providing a plurality of selectable icons representing monetary values within the messaging graphical user interface.

As part of act 1708, or as an additional act, the method may include determining a currency used by the user and setting a currency value based on the determined currency. For example, determining the currency may include determining the country where the user is located. For example, the currency value may correspond to a common currency value at which the user is located.

The method also includes act 1710 of sensing a selection of two or more selectable icons. In particular, act 1710 includes, by one or more processors of the mobile device, sensing a selection of two or more selectable icons of a plurality of selectable icons.

In addition, the method 1700 includes an act 1712 of calculating a payment amount. Act 1712 includes calculating a settlement amount for a payment transaction by aggregating monetary values associated with the selected two or more selectable elements by at least one processor. For example, act 1712 may include increasing the amount of payment for each selected icon. Act 1712 may include increasing the amount of payment upon detecting the selection of each selected icon.

The method 1700 also includes an act 1714 of sending a remittance request. In particular, action 1714 includes a request to remit payment to the counterpart user from the user. For example, act 1714 may include monitoring a period after selection of one of a plurality of selectable icons. Act 1714 may further comprise determining that the monitored period meets a predetermined inactivity threshold. Act 1714 may also include sending a request to remit the payment amount in response to determining that the monitored period meets a predetermined inactivity threshold. Alternatively, act 1714 may comprise completing a settlement transaction for a settlement amount, in response to determining that the monitored period satisfies a predetermined inactivity threshold. In one example, the inactivity threshold is a user-configurable time threshold.

The method 1700 also includes an act 1716 of adding a message indicating the payment amount sent. Specifically, act 1716 includes adding a message to the messaging graphical user interface indicating that the payment amount has been sent to the counterpart user. For example, act 1716 may include adding a message to the conversation thread in accordance with a time-dependent flow of the electronic message of the conversation thread.

As part of act 1716, or as an additional act, method 1700 may include providing an initial settlement amount to a conversation thread in response to detecting a selection of a first selectable element. The method 1700 also includes changing the initial payment amount provided to the messaging graphical user interface to the payment amount in response to detecting the selection of one or more selectable icons by adding the currency value associated with the one or more selectable icons to the initial payment amount . Act 1716 may further include modifying the appearance of the payment amount provided to the conversation thread in response to sending a request to remit the payment amount from the user to the counterpart user. Act 1716 may additionally or alternatively include modifying the appearance of the payment amount provided to the conversation thread in response to detecting approval of the payment amount from the opponent user.

Embodiments of the present disclosure may include or utilize computer hardware, such as, for example, a special purpose or general purpose computer that includes one or more processors and system memory as described in more detail below. Embodiments within the scope of this disclosure also include physical and other computer-readable media for performing or storing computer-executable instructions and / or data structures. In particular, the one or more processors described herein may be stored on a non-transitory computer-readable medium and may be, at least in part, as instructions executable by one or more computing devices (e.g., any media content access device described herein) Can be implemented. In general, a processor (e.g., a microprocessor) receives an instruction from a non-transient computer-readable medium (e.g., memory, etc.) and executes such instruction, Perform one or more processes.

The computer-readable medium may be any available medium that can be accessed by a general purpose or special purpose computer system. Computer-readable media for storing computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example and without limitation, embodiments of the present disclosure may include at least two distinct types of computer-readable media: non-transitory computer-readable storage media (devices) and a transmission medium.

Non-transient computer-readable storage media (devices) may be embodied in a variety of forms, including RAM, ROM, EEPROM, CD-ROM, solid state drives May be used to store certain program code means in the form of a memory, other optical disk storage, magnetic disk storage or other magnetic storage device, or computer-executable instructions or data structures, and may be accessed by a general purpose or special purpose computer ≪ / RTI >

"Network" is defined as one or more data links that enable the transport of electronic data between a computer system and / or a module and / or other electronic device. When information is transferred or provided to a computer over a network or other communication connection (wired, wireless, or a combination of wired or wireless), the computer appropriately regards the connection as a transmission medium. The transmission medium may include a network and / or data link that may be used to carry certain program code means in the form of computer-executable instructions or data structures, and which may be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

In addition, upon reaching various computer system components, the program code means in the form of computer-executable instructions or data structures may be automatically transferred from a transmission medium to a non-transitory computer-readable storage medium (or vice versa) Lt; / RTI > For example, computer-executable instructions or data structures received on a network or data link may be buffered in RAM within a network interface module (e.g., a "NIC") and then stored in a computer system RAM and / May eventually be delivered to the storage medium (devices). Thus, it should be understood that non-transitory computer-readable storage media (devices) may be included in a computer system component that also (or even principally) utilizes a transmission medium.

For example, computer-executable instructions, when executed on a processor, include instructions and data that cause a general purpose computer, special purpose computer, or special purpose application processing device to perform a particular function or group of functions. In some embodiments, the computer-executable instructions are executed on a general purpose computer to convert the general purpose computer into a special purpose computer that embodies elements of the present specification. The computer executable instructions may be, for example, a binary number, an intermediate format instruction, such as an assembly language, or even source code. While the subject matter of the invention has been described in language specific to the acts of structural features and / or methods, it will be understood that the subject matter of the invention as defined in the appended claims is not necessarily limited to the features or acts described above . Rather, the features and acts described are set forth as example forms of implementing the claims.

It will be appreciated by those of ordinary skill in the art that the present specification may be applied to any type of computer system, including but not limited to a personal computer, desktop computer, laptop computer, message processor, hand-held device, multi-processor system, microprocessor-based or programmable consumer electronics, network PCs, , Mobile telephones, PDAs, tablets, pagers, routers, switches, and the like, as will be appreciated by those skilled in the art. The present disclosure may also be practiced in a distributed system environment in which both local and remote computer systems that are linked (by a combination of wired data links, wireless data links, or wired and wireless data links) over a network perform operations. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

Embodiments of the present disclosure may also be implemented in a cloud computing environment. In the present description, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be used in the market to provide ubiquity and convenient on-demand access to a shared pool of configurable computing resources. Shared pools of configurable computing resources can be provisioned quickly through virtualization and can be distributed with little management effort or service provider interaction, and then scaled accordingly.

The cloud-computing model can be composed of various features, such as on-demand self-service, wide network access, resource pooling, fast agility, measured services, and the like. The cloud-computing model can also expose a variety of service models, such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The cloud-computing model can also be deployed using different deployment models, such as private clouds, community clouds, public clouds, hybrid clouds, and the like. In the present description and claims, "cloud-computing environment" is an environment in which cloud computing is utilized.

FIG. 18 shows a block diagram of an exemplary computing device 1800 that may be configured to perform one or more of the processes described above. One of ordinary skill in the art will recognize that one or more computing devices, such as computing device 1800, may implement billing system 100. 18, the computing device 1800 includes a processor 1802, a memory 1804, a storage 1806, an I / O interface 1808, which may be communicatively coupled by a communication infrastructure 1812 And a communication interface 1810. [ Exemplary computing device 1800 is shown in Figure 18, while the components shown in Figure 18 are not intended to be limiting. Additional or alternative components may be used in other embodiments. In addition, in certain embodiments, computing device 1800 may include fewer components than those shown in FIG. The components of the computing device 1800 shown in FIG. 18 will now be described in further detail.

In one or more embodiments, the processor 1802 includes hardware for executing instructions, e.g., those that constitute a computer program. By way of example, and not limitation, to execute the instructions, processor 1802 may retrieve (or fetch) instructions from internal registers, internal cache, memory 1804, or storage 1806, . In one or more embodiments, the processor 1802 may include one or more internal caches for data, instructions, or addresses. By way of example and not limitation, processor 1802 may include one or more instruction cache, one or more data cache, and one or more translation lookaside buffers (TLBs). The instructions in the instruction cache may be a copy of instructions in the memory 1804 or the store 1806.

Memory 1804 can be used to store data, metadata, and programs for execution by the processor (s). The memory 1804 may store one or more volatile and non-volatile memory, such as a random access memory (RAM), a read only memory (ROM), a solid state drive (SSD), a flash, a phase change memory It can contain repositories. Memory 1804 may be internal or distributed memory.

Storage 1806 includes storage for storing data or instructions. By way of example and not limitation, storage device 1806 may include the non-temporary storage medium described above. The storage device 1806 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a USB (Universal Serial Bus) drive or a combination of two or more thereof. The storage device 1806 may include removable or non-removable (or fixed) media as appropriate. Storage device 1806 may be internal or external to computing device 1800. In one or more embodiments, the storage device 1806 is a non-volatile, solid state memory. In another embodiment, the storage device 1806 includes a ROM. If appropriate, the ROM may be a mask programmed ROM, a programmable ROM (PROM), a removable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically programmable ROM (EAROM) Or a combination of two or more thereof.

The I / O interface 1808 allows the user to provide input to the computing device 1800, receive the output, or otherwise transmit data or receive data therefrom. The I / O interface 1808 may include a mouse, a keypad or keyboard, a touch screen, a camera, a light scanner, a network interface, a modem, other known I / O devices, or a combination of such I / O interfaces. I / O interface 1808 may be coupled to a user, including but not limited to a graphics engine, a display (e.g., a display screen), one or more output drivers One or more devices for presenting the output. In a particular embodiment, the I / O interface 1808 is configured to provide graphical data for presentation to a user on a display. The graphical data may represent one or more graphical user interfaces and / or any other graphical content capable of providing a particular implementation.

Communication interface 1810 may include hardware, software, or both. In any case, communication interface 1810 may provide one or more interfaces for communication between computing device 1800 and one or more other computing devices or networks (e.g., packet-based communication). By way of example, and not limitation, communication interface 1810 may be a wireless adapter, such as a wireless adapter or a network interface controller (NIC) or other wired-based network for communicating over a wireless network, e.g., WI- Or a NIC.

Additionally or alternatively, the communication interface 1810 may be an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN) Or a combination of two or more of them. One or more portions of one or more of these networks may be wired or wireless. For example, the communication interface 1810 may be a wireless communication network, such as a wireless PAN (e.g., a BLUETOOTH WPAN), a WI-FI network, a Wi-MAX network, a cellular telephone network An appropriate wireless network, or a combination thereof.

In addition, communication interface 1810 may facilitate communication using various communication protocols. Examples of communication protocols that may be used include but are not limited to data transmission media, communication devices, Transmission Control Protocol ("TCP "), Internet Protocol "), Hypertext Transfer Protocol Secure (" HTTPS "), Session Initiation Protocol (" SIP "), Simple Object Access Protocol (" SOAP "), Extensible Mark- (&Quot; SMTP "), Real Time Transport Protocol (" RTP "), User Datagram Protocol (" UDP "), Global System for Mobile Communications (TDMA) technology, Short Message Service (SMS), Multimedia Message Service (MMS), radio frequency ("RF") signaling technology, Long Term Evolution Techniques, in-band and out-of-band signaling techniques, and other suitable communication networks and techniques.

Communications infrastructure 1812 may include hardware, software, or both, that combine the components of computing device 1800 together. By way of example, and not limitation, communication infrastructure 1812 may be an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT Standard architecture bus, an INFINIBAND interconnect, a low-pin-count bus, a memory bus, a micro channel architecture (MCA) bus, a PCI (Peripheral Component Interconnect) bus, a PCIe (PCI- technology attachment bus, a Video Electronics Standards Association local (VLB) bus or other suitable bus, or a combination thereof.

As mentioned above, the system 100 may include a social networking system. Social networking systems can enable users (e.g., people or organizations) to interact with the system and with each other. As mentioned above, the system 100 may include a social networking system. Social networking systems can enable users (e.g., people or organizations) to interact with the system and with each other. A social networking system may generate and store user profiles associated with a user in a social networking system as input from a user. The user profile may include demographic information, communication channel information, and information about the user ' s personal interests. The social networking system may also include, as input from a user, services for creating and storing a record of a user's relationship with other users of the social networking system, as well as facilitating social interaction between users (e.g., , Photo-sharing, online calendar and event organization, messaging, games, or advertising). In addition, the social networking system may allow users to post photos and other multimedia content items to a user's profile page (commonly known as a "wall post" or "timeline post") or a photo album, And may be accessible to other users of the social networking system according to the configured personal information settings.

FIG. 19 illustrates an exemplary network environment 1900 of a social networking system. The network environment 1900 includes a client system 1906, a social networking system 1902 and a third party system 1908 that are interconnected via a network 1904. 19 shows a specific configuration of the client system 1906, the social networking system 1902, the third party system 1908 and the network 1904, but the description herein refers to the client system 1906, the social networking system 1902, Third party system 1908, and network 1904, as will be appreciated by those skilled in the art. By way of example, and not limitation, two or more client systems 1906, a social networking system 1902, and a third-party system 1908 may be directly connected to one another bypassing the network 1904. As another example, two or more client systems 1906, a social networking system 1902, and a third-party system 1908 may be located, in whole or in part, physically or logically in the same place with respect to each other. 19 shows a particular number of client systems 1906, a social networking system 1902, a third party system 1908 and a network 1904, although the present specification is intended to cover any suitable number of client systems 1906, A social networking system 1902, a third party system 1908, and a network 1904. By way of example and not limitation, network environment 1900 may include a number of client systems 1906, a social networking system 1902, a third party system 1908, and a network 1904.

The present specification contemplates any suitable network 1904. One or more portions of network 1904 may include, but are not limited to, an ad hoc network, an intranet, an extranet, a VPN, a local area network (LAN), a wireless local area network (WLAN) A wide area network (MAN), a portion of the Internet, a portion of a public switched telephone network (PSTN), a cellular telephone network, or a combination of two or more thereof. Network 1904 may include one or more networks 1904.

The link may connect or connect the client system 1906, the social networking system 1902, and the third party system 1908 to the communications network 1904. The present specification considers any suitable link. In certain embodiments, the one or more links may be one or more wired (e.g., Digital Subscriber Line (DSL) or Data Over Cable Service Interface Specification (DOCSIS)), wireless (e.g., Wi-Fi or WiMax (Worldwide Interoperability for Microwave Access) , Optical (e.g., SONET (Synchronous Optical Network) or SDH (Synchronous Digital Hierarchy) link). In a particular embodiment, each of the one or more links may be part of an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, , Another link, or a combination of two or more of such links. The links do not necessarily have to be the same throughout the network environment 1900. The one or more first links may differ from the one or more second links in one or more aspects.

In a particular embodiment, the client system 1906 may be implemented as a hardware, software, or embedded logic component, or as an electronic device, including a combination of two or more such components, capable of performing the appropriate functions implemented or supported by the client system 1906 Device. By way of example and not limitation, client system 1906 may include any of the computing devices discussed above with respect to FIG. The client system 1906 may allow a network user to access the network 1904 at the client system 1906. The client system 1906 may allow its users to communicate with other users in the other client system 1906. [

The client system 1906 may include a web browser 932, such as MICROSOFT INTERNET EXPLORER, GOOGLE CHROME or MOZILLA FIREFOX, and may include one or more add-ons, plug-ins, or other extensions, You can have a YAHOO TOOLBAR. A user at client system 1906 may enter a URL (Uniform Resource Locator) or other address that directs the web browser to a particular server (e.g., server or server associated with third party system 1908) Can generate HTTP (Hyper Text Transfer Protocol) requests and communicate HTTP requests to the server. The server may accept the HTTP request and may communicate one or more Hyper Text Markup Language (HTML) files to the client system 1906 in response to the HTTP request. The client system 1906 may render the web page based on the HTML file from the server for presentation to the user. The present specification considers any suitable web page file. By way of example and not limitation, web pages may be rendered from an HTML file, an Extensible Hyper Text Markup Language (XHTML) file, or an Extensible Markup Language (XML) file, depending upon the particular need. Such pages may also execute scripts such as, for example and without limitation, those written in JAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, and combinations of script and markup languages such as AJAX (Asynchronous JAVASCRIPT and XML). In this specification, references to a web page encompass one or more corresponding web page files (which the browser may use to render the web page), and vice versa.

In a particular embodiment, the social networking system 1902 may be a network-addressed computing system capable of hosting an online social network. The social networking system 1902 may generate, store, receive, and transmit social networking data, such as, for example, user-profile data, concept-profile data, social graph information, or other appropriate data related to an online social network. The social networking system 1902 may be accessed by other components of the network environment 1900, either directly or via the network 1904. [ In a particular embodiment, the social networking system 1902 may include one or more servers. Each server may be an integrated server or a plurality of computers or a distributed server spanning multiple data centers. The server may be any of a variety of types, such as, but not limited to, a web server, a news server, a mail server, a message server, an ad server, a file server, an application server, an exchange server, a database server, a proxy server, Another server appropriate to perform, or any combination thereof. In a particular embodiment, each server may comprise hardware, software, or a combination of two or more such components for performing the appropriate functions implemented or supported by the embedded logic component or server. In a particular embodiment, the social networking system 1902 may include one or more data stores. A data store can be used to store various types of information. In certain embodiments, the information stored in the data store may be organized according to a particular data structure. In a particular embodiment, each data store may be a relational, columnar, correlated, or other appropriate database. Although this specification describes or illustrates a particular type of database, the present specification contemplates any suitable type of database. Certain embodiments may provide an interface through which the client system 1906, the social networking system 1902, or the third party system 1908 may be able to manage, retrieve, modify, add or delete information stored in the data store have.

In a particular embodiment, the social networking system 1902 may store one or more social graphs in one or more data stores. In a particular embodiment, the social graph may comprise a plurality of nodes that may include a plurality of user nodes (each corresponding to a particular user) or a plurality of concept nodes (each corresponding to a particular concept) . The social networking system 1902 can provide a user of an online social network with the ability to communicate and interact with other users. In a particular embodiment, a user may subscribe to an online social network via a social networking system 1902 and then add (e.g., add) a connection (e.g., relationship) to a number of other users of the social networking system 1902 can do. As used herein, the term "friend" may refer to any other user of the social networking system 1902 who has made a connection, association, or relationship through the social networking system 1902.

In a particular embodiment, the social networking system 1902 may provide the user with the ability to take actions on various types of items or objects supported by the social networking system 1902. [ By way of example and not limitation, the items and objects may be group or social networks to which users of social networking system 1902 may belong, events or calendar entries that may be of interest to the user, computer-based applications available to the user, A transaction that allows an item to be bought and sold through the user, an interaction with an advertisement that the user can perform, or other appropriate items or objects. A user may be connected to an external system of a third party system 1908 that is separate from the social networking system 1902 and connected to the social networking system 1902 via the network 1904 or any other system that may be represented in the social networking system 1902 Can interact.

In a particular embodiment, the social networking system 1902 may link various entities. By way of example, and not limitation, the social networking system 1902 may allow users to interact with each other, as well as to receive content from a third party system 1908 or other entity, or to allow users to interact with an application programming interface (API) Channels to interact with these entities.

In a particular embodiment, third party system 1908 may include one or more types of servers, one or more data stores, one or more interfaces including, but not limited to, APIs, or any other suitable Component. The third party system 1908 may be operated by an entity that is different from the entity that operates the social networking system 1902. However, in a particular embodiment, the social networking system 1902 and the third-party system 1908 are associated with each other to provide social networking services to the users of the social networking system 1902 or the third- . In this regard, the social networking system 1902 may provide a platform or backbone that other systems, such as the third-party system 1908, may use to provide the user with social networking services and features on the Internet.

In a particular embodiment, the third party system 1908 may include a third party content object provider. The third party content object provider may include a source of one or more content objects that may be communicated to the client system 1906. By way of example and not limitation, the content object may include information relating to an object or activity of interest to the user, such as movie time, movie review, restaurant review, restaurant menu, product information and review, or other appropriate information . As another example, without limitation, the content object may include an incentive content object, such as a coupon, a discount ticket, a gift certificate, or other appropriate incentive object.

In a particular embodiment, the social networking system 1902 also includes a user-generated content object that can enhance user interaction with the social networking system 1902. The user-generated content may include anything the user can add, upload, transmit, or "publish" to the social networking system 1902. By way of example, and not limitation, a user may communicate a post from a client system 1906 to a social networking system 1902. A post may include data, such as status updates or other textual data, location information, pictures, video, links, music or other similar data or media. The content may also be added to the social networking system 1902 by a third party through a "communication channel ", e.g., a news feed or stream.

In a particular embodiment, the social networking system 1902 may include various servers, sub-systems, programs, modules, logs, and data stores. In a particular embodiment, the social networking system 1902 includes: a web server, an action logger, an API-request server, an association and ranking engine, a content-object classifier, A content store, an inference module, an authentication / personal information server, a search module, an ad-targeting module, a user-interface module, a user-profile store, a connection store, a third party content store, or a location store. The social networking system 1902 may also include suitable components, such as a network interface, a security mechanism, a load balancer, a failover server, a management-and-network operation console, other suitable components, have. In a particular embodiment, the social networking system 1902 may include one or more user profile stores for storing user profiles. The user profile may include, for example, personal information, demographic information, behavioral information, social information, or other types of technical information such as work experience, education, hobbies or preferences, interests, intimacy, or location. The interest information may include interests related to one or more categories. Categories may be generic or specific. By way of example, and not limitation, if a user "likes" an article about a shoe brand, the category may be a brand, or a general category of "shoes" or "clothing". The connection store can be used to store connection information about the user. The connection information may represent users who have similar or common career histories, group memberships, hobbies, academic backgrounds, or who share common attributes or are related in any way. The connection information may also include user-defined connections between different users and content (both internal and external). The web server may be used to link the social networking system 1902 via the network 1904 to one or more client systems 1906 or one or more third party systems 1908. The web server may include a mail server or other messaging functionality for receiving and routing messages between the social networking system 1902 and the one or more client systems 1906. The API-requesting server may allow the third-party system 1908 to access information from the social networking system 1902 by calling one or more APIs. The behavior logger can be used to receive communications from the web server about the user's actions in and out of the social networking system 1902. Along with the action log, the third party content object log may be maintained for user exposure to the third party content object. The notification controller may provide information related to the content object to the client system 1906. The information may be pushed to the client system 1906 as an alert, or the information may be pulled from the client system 1906 in response to a request received from the client system 1906. The authentication server may be used to enforce one or more privacy settings of a user of the social networking system 1902. [ The user's privacy settings determine how specific information related to the user can be shared. The authentication server may be configured to allow the user to participate in what their behavior is being logged by the social networking system 1902 or shared with other systems (e.g., third party system 1908), e.g., by setting appropriate personal information settings Or not to participate. The third party content object store may be used to store a content object received from a third party, e.g., a third party system 1908. The location store may be used to store location information that is received from client system 1906 and associated with the user. The ad-pricing module may combine social information, current time, location information, or other appropriate information to provide the user with appropriate advertisements in the form of a notification.

FIG. 20 shows an exemplary social graph 2000. In a particular embodiment, the social networking system 1902 may store one or more social graphs 2000 in one or more data stores. In a particular embodiment, the social graph 2000 may include a number of nodes that may include a plurality of user nodes 2002 or a plurality of concept nodes 2004, and a plurality of edges 2006 connecting the nodes . The exemplary social graph 2000 shown in FIG. 20 is shown in a two-dimensional visual map representation for purposes of the present invention. In a particular embodiment, the social networking system 1902, the client system 1906, or the third party system 1908 may have access to the social graph 2000 and related social graph information for the appropriate application. The nodes and edges of the social graph 2000 may be stored as data objects in, for example, a data store (e.g., a social graph database). Such a data store may include one or more searchable or queryable indexes of nodes or edges of the social graph 2000.

In a particular embodiment, the user node 2002 may correspond to a user of the social networking system 1902. By way of example, and not limitation, a user may interact with (e.g., a person or a person), an entity (e.g., a corporation, a business or a third party application) or a social networking system 1902 or a social networking system ) Group. In a particular embodiment, when a user registers an account in the social networking system 1902, the social networking system 1902 may create a user node 2002 corresponding to the user, ). ≪ / RTI > Where appropriate, the users and user nodes 2002 described herein may refer to user nodes 2002 associated with registered users and registered users. Additionally or alternatively, the users and user nodes 2002 described herein may refer to users who are not registered with the social networking system 1902, if appropriate. In a particular embodiment, the user node 2002 may be associated with information provided by the user and information collected by various systems including the social networking system 1902. By way of example and not limitation, a user may provide their name, profile picture, contact information, birthday, gender, marital status, family relationship, workplace, education, preference, or other personal information. Each user node of the social graph may have a corresponding web page (commonly known as a profile page). In response to the request including the user name, the social networking system can access the user node corresponding to the user name and configure the profile page including the name, profile photo, and other information associated with the user. The profile page of the first user may display to the second user all or a portion of the information of the first user based on one or more personal information settings by the first user and the relationship between the first user and the second user.

In a particular embodiment, the concept node 2004 may correspond to a concept. By way of example and not limitation, the concept may include a location (e.g., a movie theater, a restaurant, a sights or a city); A web site (e.g., a website associated with the social network system 1902 or a third party web site associated with the web-application server); An entity (e.g., a person, a business, a group, a sports team, or a celebrity); (E.g., audio files, video files, digital pictures, text files, structured documents or applications) that may be located on an external server, such as a social networking system 1902 or a web-application server, for example; Physical property rights or intellectual property rights (for example, sculptures, artwork, movies, games, songs, ideas, photographs or books); game; activity; Idea or theory; Another suitable concept; Or two or more of these concepts. Concept node 2004 may be associated with information gathered by various systems, including social networking system 1902, or information of a concept provided by a user. By way of example and without limitation, the conceptual information may include a name or a title; One or more images (e.g., an image of a cover page of a book); Location (e.g., address or geographic location); A website (which may be associated with a URL); Contact information (e.g., telephone number or e-mail address); Other appropriate concept information; Or any suitable combination of such information. In a particular embodiment, each concept node 2004 may be associated with one or more data objects corresponding to information associated with the concept node 2004. In a particular embodiment, each concept node 2004 may correspond to a web page.

In a particular embodiment, in the social graph 2000, a node may represent a web page (which may be referred to as a "profile page"), or may be represented by that web page. The profile page may be hosted or accessed by the social networking system 1902. In addition, the profile page may be hosted on a third party web site associated with the third party server 1908. By way of example and not limitation, a profile page corresponding to a particular external web page may be a particular external web page, and such profile page may correspond to a particular concept node 2004. The profile page can be viewed by all or other users of the selected subset. By way of example and not limitation, user node 2002 may have a corresponding user profile-page in which the user may add content, make declarations, or otherwise express themselves. As yet another example, without limitation, the concept node 2004 may be associated with a concept corresponding to the concept node 2004, such that one or more users may add content, make declarations, You can have a concept-profile page.

In a particular embodiment, the concept node 2004 may represent a third party web page or resource hosted by a third party system 1908. The third party web page or resource may include content (e.g., which may be implemented in JavaScript, AJAX or PHP code) that represents an action or activity among other elements, a selectable or other icon, or other interactable object have. By way of example and not limitation, a third party web page may include selectable icons, such as "like", "check in", "eat", "recommend", or other appropriate action or activity. A user viewing a third party web page may select one of the icons (e.g., "Eat") to perform an action, and the client system 1906 may send a message to the social networking system 1902, respectively. In response to the message, the social networking system 1902 sends an edge (e.g., a "eating" edge) between the user node 2002 corresponding to the user and the concept node 2004 corresponding to a third- And store the edge 2006 in one or more data stores.

In a particular embodiment, the pair of nodes in the social graph 2000 may be interconnected by one or more edges 2006. The edge 2006 connecting the node pairs can express the relationship between the node pairs. In a particular embodiment, the edge 2006 may include or represent one or more data objects or attributes corresponding to the relationship between the node pairs. By way of example and not limitation, the first user may indicate that the second user is the "friend" of the first user. In response to this indication, the social networking system 1902 may send a "friend request" to the second user. If the second user confirms the "friend request, " the social networking system 1902 may generate an edge 2006 (FIG. 2) connecting the user node 2002 of the first user and the user node 2002 of the second user in the social graph 2000 ) And store the edge 2006 as the social-graph information in one or more data stores. In the example of FIG. 20, the social graph 2000 describes an edge 2006 indicating the friendship between user "A " and user nodes 2002 of user" B " The user node 2002 of FIG. Although the present specification describes or illustrates a particular edge 2006 with a particular attribute connecting a particular user node 2002, the present specification describes any suitable edge 2006 with any suitable attribute connecting the user node 2002 ). By way of example and not limitation, edge (2006) can be used to identify relationships among friends, family relationships, business or employment relationships, fan relationships, followers, visitor relationships, subscriber relationships, top / bottom relationships, reciprocal relationships, Or two or more of these relationships. Furthermore, although this specification generally describes that nodes are connected, this specification also describes that a user or concept is connected. Herein, reference to a user or a concept being connected may refer to where the nodes corresponding to these users or concepts are connected in the social graph 2000 by one or more edges 2006, if appropriate.

The edge 2006 between the user node 2002 and the concept node 2004 may represent a specific action or activity performed by a user of the user node 2002 against a concept associated with the concept node 2004. [ have. By way of example and not limitation, and as shown in FIG. 20, a user may select concepts as "like," "attended," "played," "listened, Quot; cooked ", "worked at ", or" watched ", each of which may correspond to an edge type or subtype. The concept-profile page corresponding to concept node 2004 may include, for example, a selectable "check-in" icon (e.g., a clickable "check-in" icon) or a selectable "add to favorites" . Similarly, after the user clicks on such an icon, the social networking system 1902 may generate a "favorite" edge or a "check in" edge in response to a user action corresponding to each action. As another example, without limitation, a user (user "C") can listen to a particular song ("Ramble On") using a particular application (SPOTIFY, an online music application). In this case, the social networking system 1902 has "listened" edges 2006 and "used" between the user node 2002 corresponding to the user and the concept node 2004 corresponding to the song and application ) "Edge (shown in FIG. 20) to indicate that the user has listened to the song and used the application. In addition, the social networking system 1902 generates a "played" edge 2006 (shown in FIG. 20) between the concept node 2004 corresponding to the song and the application, so that a particular song is executed Can be displayed. In this case, the "played" edge 2006 corresponds to an action performed by an external application (SPOTIFY) against an external audio file (song "Imagine"). Although the present specification describes an edge 2006 with a particular attribute connecting the user node 2002 and the concept node 2004, the present specification is intended to include any suitable attribute connecting the user node 2002 to the concept node 2004, Lt; RTI ID = 0.0 > 2006 < / RTI > In addition, although the present specification describes the edge between the concept node 2004 and the user node 2002 representing a single relationship, the present disclosure encompasses a concept node 2004 between the user node 2002 representing one or more relationships and the concept node 2004. [ Lt; / RTI > By way of example and not limitation, edge 2006 may represent all that a user likes and uses in a particular concept. Alternatively, another edge 2006 may be defined between the user node 2002 and the concept node 2004 (as shown in Figure 20, the user node 2002 for user "E " and the concept node & (2004)) (or a plurality of single relationships).

In a particular embodiment, the social networking system 1902 may generate an edge 2006 between the user node 2002 and the concept node 2004 in the social graph 2000. By way of example, and not limitation, a user may view a concept-profile page (e.g., using a web browser or special purpose application hosted by a user's client system 1906) to allow the user to click on the " Quot; icon indicates that the user's client system 1906 has sent a message indicating that the user liked the concept associated with the concept-profile page to the social networking system 1902 ). ≪ / RTI > In response to the message, the social networking system 1902 may be configured to provide a user interface between the user node 2002 and the concept node 2004 associated with the user, as shown by the "like" edge 2006 between the user and the concept node 2004 Gt; 2006 < / RTI > In a particular embodiment, the social networking system 1902 may store the edge 2006 in one or more data stores. In a particular embodiment, the edge 2006 may be automatically formed by the social networking system 1902 in response to a particular user action. If, for example and without limitation, the first user uploads a picture, watches a movie, or listens to a song, the edge 2006 may include a user node 2002 corresponding to the first user and a concept node 2004 As shown in Fig. Although the specification describes forming a particular edge 2006 in a particular manner, the present specification contemplates forming any suitable edge 2006 in any suitable manner.

In a particular embodiment, the ad may be text (which may be HTML-linked), one or more images (which may be HTML-linked), one or more videos, audio, one or more ADOBE FLASH files, Or any other suitable advertisement in any suitable digital format presented on one or more web pages within one or more emails. Additionally or alternatively, the advertisement may be one or more sponsored news (e.g., a news-feed or a ticker item on the social networking system 1902). The sponsored news may include advertisements that allow an advertiser to show social behaviors within a user's profile page or a pre-determined area of another page, along with additional information associated with the advertiser, or to bump-up (Eg, "liking" a page, commenting on or "liking" a post on a page, RSVP on an event related to a page, etc.) by a user who is promoted, promoted, Voting on posted questions on a page, checking in to a place, using an application or playing a game, "liking" or sharing a website). Advertisers can pay money to promote social behavior. By way of example and not limitation, an advertisement may be included between search results on a search-result page, wherein the sponsored content is promoted relative to the non-sponsored content.

In a particular embodiment, an advertisement may be requested to display in a social networking system web page, a third party web page, or another page. The ad may be placed on a dedicated portion of the page, such as a banner area at the top of the page, a column on the side of the page, a GUI on the page, a pop-up window, a drop- Can be displayed elsewhere. Additionally or alternatively, the advertisement may be displayed within the application. The ad may be displayed within a dedicated page and may require the user to interact with the advertisement or view the advertisement before accessing the page or using the application. The user can, for example, view the advertisement through a web browser.

The user may interact with the advertisement in any suitable manner. The user can click or otherwise select the advertisement. By selecting an advertisement, the user can be directed to a page associated with the advertisement (or to a browser or other application used by the user). In a page associated with an advertisement, a user may take additional actions, such as purchasing a product or service associated with the advertisement, receiving information related to the advertisement, or subscribing to a newsletter associated with the advertisement. An advertisement with audio or video may be played back by selecting a component of the advertisement (such as a "play button"). Alternatively, by selecting an advertisement, the social networking system 1902 may execute or modify a user ' s specific behavior.

The ad may also include social networking system functionality that the user can interact with. By way of example and not limitation, the advertisement may allow the user to "like" or otherwise guarantee the advertisement by selecting an icon or link associated with the warranty. As another example, without limitation, an ad may allow a user to search for content related to an advertiser (e.g., by executing a query). Similarly, the user may share the advertisement with other users (e.g., via the social networking system 1902), or RSVP (e.g., via the social networking system 1902) to events associated with the advertisement. Additionally or alternatively, the advertisement may include a social networking system context addressed to the user. By way of example and not limitation, the advertisement may display information about a user's friend in the social networking system 1902 that performed an action related to the subject of the advertisement.

In a particular embodiment, the social networking system 1902 can determine the social graph intimacy (which may be referred to herein as "intimacy") of the various social graph entities for each other. Intimacy can indicate the strength or the degree of interest between a particular object associated with an online social network, such as a user, concept, content, behavior, advertising, other objects associated with an online social network, or any suitable combination thereof. In addition, intimacy can be determined for an object associated with third party system 1908 or other appropriate systems. The total familiarity for the types of social graph entities, subjects, or content for each user can be established. The total intimacy can vary based on continuous checking of an action or relationship associated with the social graph entity. While this specification describes determining a particular intimacy in a particular manner, the present specification describes determining any suitable intimacy in any suitable manner.

In a particular embodiment, the social networking system 1902 may measure or quantify social graph intimacy using an intimacy factor (which may be referred to herein as a "coefficient "). The coefficient may represent or quantify the strength of the relationship between particular objects associated with an on-line social network. The coefficient may also represent a probability or function that the user estimates an expected probability of performing a particular action based on the user ' s interest in that action. In this way, the future behavior of the user can be predicted based on the user ' s previous actions, where the coefficients can be calculated at least in part by the history of the user's behavior. The coefficients may be used to predict any number of behaviors that may be internal or external to the online social network. By way of example and not limitation, such acts include various types of communications such as, for example, sending a message, publishing content, or commenting on content; Various types of viewing behaviors, such as accessing or viewing profile pages, media or other appropriate content; Coincidence information for one or more social graph entities of various types, such as being in the same group, tagging the same photo, checking in to the same location, or participating in the same event; Or other appropriate actions. While this specification describes measuring intimacy in a particular manner, the present specification contemplates measuring intimacy in any suitable manner.

In a particular embodiment, the social networking system 1902 may calculate the coefficients using various factors. Such factors may include, for example, user behavior, type of relationship between objects, location information, other appropriate factors, or any combination thereof. In certain embodiments, the different factors can be weighted differently when calculating the coefficients. The weights for each factor may be static, or the weights may vary depending on, for example, the user, the type of relationship, the type of action, the user's location, and so on. The ratings for the factors can be combined according to their weights to determine the total coefficient for the user. By way of example and not limitation, a particular user action may be assigned both a rating and a weight, while a relation associated with a particular user action is assigned a rating and a correlating weight (e.g., a total weight of 100%). In order to calculate a user's coefficient for a particular object, the rating assigned to the user's behavior may include, for example, 60% of the total count, while the relationship between the user and the object may comprise 40% of the total count . In a particular embodiment, the social networking system 1902 may be configured to determine the time after accessing the information, the decay factors, the frequency of access, the relationship to the information or the relationship to the object that accessed the information, Various variables can be considered when determining the weights for the various factors used to calculate the coefficients, such as the relationship to the graph entities, the short- or long-term averages of user behavior, user feedback, other appropriate variables or any combination thereof have. By way of example and without limitation, the coefficient may include an attenuation factor that causes the intensity of the signal provided by a particular action to decay over time, so that more recent behavior is more relevant when calculating coefficients. The ratings and weights can be continuously updated based on a continuous tracking of the actions on which the coefficients are based. Any type of process or algorithm may be used to assign, combine, averageize, etc. the weights assigned to the rating and factors for each factor. In a particular embodiment, the social networking system 1902 may use a machine-learning algorithm that exposes the user to historical activity and past user responses or various options, measures the response, and is trained on the data that is farmed from the user. Can be determined. Although the present specification describes calculating coefficients in a particular manner, the present specification contemplates calculating coefficients in any suitable manner.

In a particular embodiment, the social networking system 1902 may calculate the coefficients based on the user ' s behavior. The social networking system 1902 may monitor these behaviors in an online social network, in a third party system 1908, in other appropriate systems, or in any combination thereof. Any suitable type of user behavior may be tracked or monitored. Common user behaviors include viewing profile pages, creating or publishing content, interacting with content, subscribing to a group, listing and confirming participation in an event, checking in to a location, liking a particular page, Creating pages, and performing other tasks that facilitate social behavior. In a particular embodiment, the social networking system 1902 may calculate a coefficient based on a user's behavior with a particular type of content. The content may be associated with an online social network, a third party system 1908, or other appropriate system. The content may include a user, a profile page, a post, a news story, a headline, an instant message, a chat room conversation, an email, an advertisement, a picture, video, music, other appropriate objects or any combination thereof. The social networking system 1902 may analyze the user's behavior to determine if one or more behaviors indicate intimacy with the subject, content, other users, By way of example, and not limitation, if the user is able to frequently post content about "coffee" or the like, the social networking system 1902 may determine that the user has a high coefficient for the concept coffee. Certain behaviors or behavior types may be assigned higher weights and / or ratings than other behaviors, which may affect the total counts that are calculated. By way of example, and not limitation, if a first user is emailing to a second user, the weight or rating for that action may be higher than if the first user simply browsed the user profile page for the second user.

In a particular embodiment, the social networking system 1902 may calculate a coefficient based on the type of relationship between particular objects. Referring to the social graph 2000, the social networking system 1902 may analyze the number and / or type of edges 2006 that connect the concept node 2004 with a particular user node 2002 when calculating the coefficients . By way of example and not limitation, a user node 2002 connected to a spouse-type edge (representing two users married) has a higher coefficient than a user node 2002 connected to a friend-type edge . That is, depending on the weights assigned to the behaviors and relationships for a particular user, the total intimacy may be determined to be higher for the content for the user's spouse than for the user's friend. In a particular embodiment, the relationship the user has with another object may affect the weight and / or rating of the user's behavior when calculating the coefficients for that object. By way of example and not limitation, if a user is tagged to a first photo but only likes a second photo, then having a tagged-in-type relationship with the content has a higher weighting And / or ratings, the social networking system 1902 may determine that the user has a higher coefficient for the first picture than the second picture. In a particular embodiment, the social networking system 1902 may calculate a coefficient for a first user based on a relationship that one or more second users make with a particular object. That is, the connection relation and the coefficient that other users make with the object may affect the coefficient of the first user for the object. By way of example and not limitation, a first user may be associated with one or more second users or have a high count for those second users, and those second users may be associated with or associated with a particular object The social networking system 1902 may determine that the first user also has a relatively high count for that particular object. In a particular embodiment, the coefficients may be based on the spacing between the specific objects. The spacing between any two nodes is defined as the minimum number of hops required to traverse the social graph from one node to another. The degree of separation between two nodes can be regarded as an association between a user or a concept represented by two nodes in the social graph. For example, two users with user nodes (i.e., primary nodes) directly connected by an edge may be described as "connected users" or "friends". Similarly, two users with user nodes (i.e., secondary nodes) that are only connected through other user nodes may be described as "friends of friends. &Quot; The lower coefficient may represent that the probability of a first user sharing interest in a content object of a user indirectly connected to the first user in the social graph 2000 is reduced. By way of example and not limitation, the social graph entities closer (i.e., lesser) in the social graph 2000 may have higher coefficients than the entities farther apart in the social graph 2000.

In a particular embodiment, the social networking system 1902 may calculate the coefficients based on the location information. Objects that are geographically closer together may be considered more relevant or more interested in each other than objects that are more distant. In a particular embodiment, the user's coefficient for a particular object may be based on the proximity of the location of the object to the current location (or location of the user's client system 1906) associated with the user. The first user may be more interested in other users or concepts that are closer to the first user. By way of example, and not limitation, if the user is one mile from the airport and two miles from the gas station, the social networking system 1902 may determine that the user has a higher coefficient for the airport than the gas station based on the proximity of the user to the airport have.

In certain embodiments, the social networking system 1902 may perform certain actions on the user based on the count information. The coefficients may be used to predict whether a user will perform a particular action based on the user ' s interest in that action. A coefficient can be used to create or present any type of object to a user, such as an advertisement, search result, news story, media, message, notification, or other appropriate object. In addition, the coefficients can be used to rank and order these objects when appropriate. In this manner, the social networking system 1902 can provide information that is relevant to the user's interests and current situation, and increases the likelihood that users will find this information of interest. In a specific embodiment, the social networking system 1902 may generate content based on the coefficient information. The content object may be provided or selected based on user-specific coefficients. By way of example and not limitation, the measures may be used to generate media for the user, wherein the user may be presented with media having a high total count for the media object. As another example, without limitation, the coefficient may be used to generate an ad for a user, where the user may be presented with an ad with a high total count for the advertised object. In a particular embodiment, the social networking system 1902 may generate search results based on the coefficient information. The search results for a particular user may be scored or ranked based on the coefficients associated with the search results for the querying user. By way of example and not limitation, search results corresponding to objects with higher coefficients may be ranked higher in search result pages than results corresponding to objects with lower coefficients.

In a particular embodiment, the social networking system 1902 may calculate a coefficient in response to a request for a coefficient from a particular system or process. Any process may request a calculated count for a user to anticipate a possible action (which may be the subject) that the user may perform in a given situation. The request may also include a set of weights for use with the various factors used to calculate the coefficients. The request may originate from a process running on an online social network, from a third party system 1908 (e.g., via an API or other communication channel), or from another suitable system. In response to the request, the social networking system 1902 may calculate the coefficient (or access the coefficient information if it is already calculated and stored). In a particular embodiment, the social networking system 1902 may measure the intimacy for a particular process. Other processes (both inside and outside the online social network) can request a count on a particular object or set of objects. The social networking system 1902 may provide an intimacy associated with the particular process that requested the intimacy. In this way, each process receives an affinity whose process is customized for the other context using the familiarity.

With respect to social graph intimacy and intimacy coefficients, certain embodiments are described in U.S. Patent Application No. 11/503093, filed August 11, 2006, and U.S. Patent Application No. 11/503093, filed December 22, 2010, U.S. Patent Application No. 12/977027, U.S. Patent Application No. 12/978265, filed December 23, 2010, and U.S. Patent Application No. 13/632869, filed October 1, 2012, Components, features, methods, operations, or steps described in connection with the embodiments disclosed herein.

In a particular embodiment, one or more content objects of an online social network may be associated with personal information settings. Personal information settings (or "access settings") for an object may be stored in any appropriate manner, e.g., in association with an object, at an index on an authentication server, or in any other suitable manner or any combination thereof. The privacy setting of an object may specify how the object (or specific information associated with the object) can be accessed (e.g., browsed or shared) using an online social network. If the privacy settings for an object allow a particular user to access the object, the object may be described as "visible" to the user. By way of example and not limitation, a user of an online social network may specify personal information settings for a user-profile page that identifies a set of users who may have access to career information on a user profile page, Access is excluded. In a particular embodiment, the privacy settings can specify a "block list" of the user that should not be allowed to access certain information associated with the object. That is, the block list may specify one or more users or entities whose objects are not visible. By way of example and not limitation, a user may specify a set of users who can not access the photo album associated with the user, thus excluding such user from accessing the photo album (and, on the other hand, Perhaps allowing a specific user to access the photo album). In a particular embodiment, the personal information settings may be associated with a particular social graph element. The personalization settings of a social graph element, such as a node or an edge, may specify how a social graph element, information associated with a social graph element, or a content object associated with a social graph element can be accessed using an online social network . By way of example, and not limitation, a particular concept node 2004 corresponding to a particular photo may have a privacy setting that specifies that the photo can only be accessed by the users tagged with the photo and their friends. In a particular embodiment, the privacy settings may allow users to participate in or not participate in what their behavior is being logged by the social networking system 1902 or shared by other systems (e.g., third party system 1908) have. In a particular embodiment, privacy settings associated with an object may specify any suitable granularity of denied access or denial of access. By way of example and not limitation, access or denial of access may be provided to a particular user (e.g., only the principal, his or her roommate, and his or her boss), a user within a certain degree of disposition (e.g., ("Private"), third party system (1908), and / or a third party system (1908), all users (" A particular application (e.g., a third party application, an external web site), other appropriate users or entities, or any combination thereof. Although the present specification describes the use of specific privacy settings in a particular manner, the present specification contemplates using any appropriate privacy settings in any suitable manner.

In a particular embodiment, the one or more servers may be an authentication / personal information server for enforcing privacy settings. In response to a request from a user (or other entity) for a particular object stored in the data store, the social networking system 1902 may send a request for the object to the data store. The request may identify the user associated with the request and may be used only by the user (or the user's client system 1906) if the authentication server determines that the user is authorized to access the object based on the personal information settings associated with the object Lt; / RTI > If the requesting user is not authenticated to access the object, the authentication server may prevent the requested object from being retrieved from the data store, or prevent the requested object from being sent to the user. In the context of a search query, an object may only be created as a search result only if the querying user is authenticated to access the object. That is, the object must have a visible visibility to the querying user. If an object has visibility that is not visible to the user, the object can be excluded from the search results. Although the present specification describes enforcing privacy settings in a particular manner, the present specification contemplates enforcing privacy settings in any suitable manner.

The foregoing specification is described with reference to specific and illustrative embodiments thereof. Various embodiments and aspects of the disclosure are described herein with reference to the details discussed herein, and the accompanying drawings illustrate various embodiments. The foregoing description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are set forth in order to provide a thorough understanding of various embodiments.

Additional or alternative embodiments may be realized in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Accordingly, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (20)

Analyzing at least one electronic message exchanged between the user and the at least one counterpart user by at least one processor;
Inferring a payment event based on an analysis of one or more electronic messages exchanged between a user and one or more other users by at least one processor; And
And initiating a settlement transaction based on the settlement event, by at least one processor. The method according to claim 1,
Wherein inferring a payment event comprises identifying a natural language phrase that points to a payment event from one or more electronic messages. The method of claim 2,
Wherein the natural language phrase includes at least one predetermined phrase, string or symbol. The method of claim 2,
The symbol contains one or more dollar signs. The method of claim 2,
Wherein initiating a payment transaction comprises providing the user with an option to initiate a payment transaction. The method of claim 5,
Providing a user with an option to initiate a payment transaction comprises creating a selectable object in connection with a natural language phrase. The method of claim 6,
Wherein creating a selectable object with respect to a natural language phrase comprises making at least a portion of the natural language phrase selectable. The method of claim 5,
Sensing, by at least one processor, a selection of a selectable object by a user; And
And initiating a settlement transaction in response to detection of the selection. The method according to claim 1,
Providing an option to the user to initiate a payment transaction comprises providing the user with a confirmation request. The method according to claim 1,
Wherein initiating a payment transaction based on a payment event comprises providing the user with an option to request payment from one or more counterpart users. The method according to claim 1,
Inferring a payment event based on an analysis of one or more electronic messages exchanged between a user and one or more counterpart users comprises identifying the language in which the user indicates that he or she wants to send or borrow money to one or more counterpart users . The method according to claim 1,
The step of deducing the settlement includes sensing a predetermined symbol followed by the settlement amount,
Wherein initiating the settlement transaction comprises sending a request to remit the settlement amount to the at least one counterpart user from the user without additional user interaction upon detecting a predetermined symbol followed by the settlement amount. Analyzing at least one electronic message exchanged between the user and the at least one counterpart user by at least one processor;
Inferring a payment event based on an analysis of one or more electronic messages exchanged between a user and one or more counterpart users;
Identifying, in one or more electronic messages exchanged between a user and one or more counterpart users, content associated with a payment event; And
Converting the content to a selectable object for initiating a payment transaction based on the payment event, by at least one processor. 14. The method of claim 13,
Wherein analyzing the one or more electronic messages comprises identifying natural language content of one or more electronic messages. 15. The method of claim 14,
Wherein identifying the payment event comprises using natural language processing to identify a payment request from one or more other user in the natural language content. 15. The method of claim 14,
Wherein the identifying the payment event comprises using natural language processing to identify a request to send a payment to one or more counterpart users in the natural language content. 14. The method of claim 13,
Identifying a predetermined string in one or more electronic messages; And
And performing an action associated with the settlement transaction based on the predetermined string,
The action includes requesting a payment from one or more of the other user, sending a payment to one or more of the other user, setting a payment amount for the payment transaction, or confirming the payment transaction. At least one processor;
A display device; And
17. A mobile device comprising at least one non-transient computer readable storage medium storing instructions,
The instructions, when executed by the at least one processor, cause the mobile device to:
Analyzing one or more electronic messages exchanged between a user and one or more counterpart users;
Inferring a payment event based on an analysis of one or more electronic messages exchanged between the user and one or more counterpart users; And
Causing the payment transaction to be initiated based on the payment event. 19. The method of claim 18,
Inferring a payment event includes identifying a natural language phrase that points to a payment event from one or more electronic messages. 19. The method of claim 18,
Initiating a payment transaction comprises providing a user with an option to initiate a payment transaction by creating a selectable object in connection with a natural language phrase.

Images