DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following is Office Action on the merits in response to the communication received on 4/13/26.
Claim status:
Amended claims: 1, 3-6, 8, 12, 13, 15, 16, 19 and 20
Canceled claims: 2 and 7
Added New claims: 21 and 22
Pending claims: 1, 3-6, and 8-22
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-6, and 8-22 are rejected under 35 U.S.C. § 101 because the claimed invention is not directed to statutory subject matter. Specifically, the invention of claims 1, 3-6, and 8-22 is directed to an abstract idea without significantly more.
Independent claims 1, 6 and 15 are directed to a method (claims 1 and 15) and a system (claim 6). Therefore on its face, each of claims 1, 6 and 15 is directed to a statutory category of invention under Step 1 of the 2019 PEG. However each of claims 1, 6 and 15, is also directed to an abstract idea without significantly more, under Step 2A (Prong One and Prong Two) and Step 2B of the 2019 PEG, which is a judicial exception to 35 U.S.C. 101, as detailed below. Using the language of independent claim 1 to illustrate the claim recites the limitations of, (i) associating, based on application of the machine learning model, respective user classifications of a plurality of user classifications to individual user accounts of the user accounts; (ii) storing, account data associated with the user accounts, wherein the account data indicates the respective user classifications; (iii) monitoring, payments between the user accounts; (iv) based at least in part on the monitoring, detecting, that a first user account associated with a first user classification is attempting to make a payment to a second user account associated with a second user classification; (v) in response to the detecting, determining, and using location data and contact book data accessible, whether, at a time of the detecting a first location associated with the first user account is within a threshold distance from a second location associated with the second user account, and whether, at the time of the detecting a quantity of user accounts that have shared contact books that include respective identifiers associated with both the first user account and the second user account satisfies a threshold quantity; (vi) in response to determining at least one of: (i) that the first location is not within the threshold distance from the second location, or (ii) that the quantity of the user accounts that have shared the contact books that include the respective identifiers fails to satisfy the threshold quantity, causing, the payment to automatically fail; and (vii) sending, an instruction associated with the first user account and executing a payment application associated with the payment service, and wherein the instruction causes the payment application to present a user interface element notifying a user that the payment failed under the broadest reasonable interpretation (BRI) covers methods of organizing human activity: fundamental economic principles or practices – mitigating risk but for the recitation of generic computers and generic computer components. (Independent claims 6 and 15 recite similar limitations and the analysis is the same).
That is, other than reciting a computing system, a datastore, a user device and training, by a computing system associated with a payment service, a machine learning model using training data comprising contextual data associated with historical payments between user accounts associated with the payment service nothing in the claim precludes the steps from being directed to methods of organizing human activity: fundamental economic principles or practices – mitigating risk. If a claim limitation under its BRI, covers methods of organizing human activity but for the recitation of generic computers, then the limitations fall within the “methods of organizing human activity” grouping of abstract ideas. Therefore, claim 1 recites an abstract idea under Step 2A Prong One of the Revised Patent Subject Matter Eligibility Guidance 84 Fed.Reg 50 (“2019 PEG”).
This “methods of organizing human activity” is not integrated into a practical application under Step 2A prong Two of the 2019 PEG. In particular claim 1 recites the following additional elements of, a computing system, a datastore, a user device and training, by a computing system associated with a payment service, a machine learning model using training data comprising contextual data associated with historical payments between user accounts associated with the payment service. This judicial exception is not integrated into a practical application. In particular, the claim only recites the additional elements – a computing system, a datastore, a user device and training, by a computing system associated with a payment service, a machine learning model using training data comprising contextual data associated with historical payments between user accounts associated with the payment service.
The computing system, datastore, user device and training, by a computing system associated with a payment service, a machine learning model using training data comprising contextual data associated with historical payments between user accounts associated with the payment service are recited at a high-level or generality (i.e. as a generic computer performing generic computer functions) such that, they amount to no more than instructions to apply the abstract idea with a computer (see MPEP 2106.05(h)). Accordingly these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the 2019 PEG independent claim 1 does not include additional elements that are sufficient to amount to significantly more than the abstract idea. The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computing system, a datastore, a user device and training, by a computing system associated with a payment service, a machine learning model using training data comprising contextual data associated with historical payments between user accounts associated with the payment service, associating, based on application of the machine learning model, respective user classifications of a plurality of user classifications to individual user accounts of the user accounts; storing, account data associated with the user accounts, wherein the account data indicates the respective user classifications; monitoring, payments between the user accounts; based at least in part on the monitoring, detecting, that a first user account associated with a first user classification is attempting to make a payment to a second user account associated with a second user classification; in response to the detecting, determining, and using location data and contact book data accessible, whether, at a time of the detecting a first location associated with the first user account is within a threshold distance from a second location associated with the second user account, and whether, at the time of the detecting a quantity of user accounts that have shared contact books that include respective identifiers associated with both the first user account and the second user account satisfies a threshold quantity; in response to determining at least one of: (i) that the first location is not within the threshold distance from the second location, or (ii) that the quantity of the user accounts that have shared the contact books that include the respective identifiers fails to satisfy the threshold quantity, causing, the payment to automatically fail; and sending, an instruction associated with the first user account and executing a payment application associated with the payment service, and wherein the instruction causes the payment application to present a user interface element notifying a user that the payment failed, amount to instructions to apply the abstract idea with a computer. The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations individually. The Dependent claim(s) when analyzed individually are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail to establish that the claim(s) are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually do not amount to significantly more than the abstract idea. Claims 3-5, 8-14 and 16-22 merely further explain the abstract idea.
When viewed individually the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly claims 1, 3-6, and 8-22 are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5-6, 11-15 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over, Chandrasekaran (U.S. Pub. No. 10,728,701), in view of Janzer (U.S. Pub. No. 2017/0048248) and Anasta (U.S. Pub. No. 2022/0383406) and Olenoski (U.S. Pub. No. 2021/0350381).
With respect to claim 1:
Chandrasekaran teaches:
A computer-implemented method comprising: {…..} based at least in part on the monitoring, detecting, by a computing system associated with a payment service, that a first user account associated with a first user type is attempting to make a payment to a second user account associated with a second user type (“It may be noted that for the purposes of illustration, rather than limitation, “user A” is a user associated user account A (of the collaboration platform 120) and with client device 110A and “user B” is a user associated user account B and with client device 110B” (Chandrasekaran Column 8 Lines 60-64) and “A collaboration platform may be one or more of numerous platforms, such as a social networking platform, purchasing platform, a messaging platform, creation platform, and so forth” (Chandrasekaran Column 2 Lines 29-32) “In some implementations, an additional functionality 121 may include a sharing functionality that allows user A and user B to share items with each other via the collaboration platform 120. For example, users of a gaming platform may have a sharing functionality that allows users to purchase, trade, or transfer virtual items, such as virtual currency, in a virtual gaming environment” (Chandrasekaran Column 6 Lines 6-12) and “In implementations, users may buy, sell, or trade game items, such as in-platform currency (e.g., virtual currency), with other users of the collaboration platform 120” Chandrasekaran Column 3 Lines 37-39);
in response to the detecting, determining, by the computing system and using location data and contact book data accessible to the computing system, whether, at a time of the detecting: (i) a first location associated with the first user account is within a threshold distance from a second location associated with the second user account, {…..} (“In implementations, proximity friending may include an attempt by user A to find friends that are nearby or in a physical proximity with user A. In implementations, physical proximity (also referred to as “proximity” herein) may refer to a physical closeness between two users or closeness of the client devices 110 of the users. In some implementations, physical proximity may be a range defined by the range of the network (e.g., Wi-Fi® network, WLAN) that the client devices 110 are accessing. In implementations, the physical proximity relative a user may be in a range that less than 1 mile (from the user), less than 1000 feet, or another range, if applicable. In some implementations, an indication of physical proximity of two users may indicate the relative proximity between two users, where the relative proximity is determined without knowing the absolute location (e.g., longitude and latitude) of the two users. For example, system 200 may known or estimate that two users are proximate one another, but not know the absolute location of at least one of users. In other implementations, system 200 may know the location of the users and estimate the proximity of two or more users based on the known locations” (Chandrasekaran Column 9 Lines 4-25) and “In one example, collaboration platform 120 may (scan) send a request to proximity friending module 140 requesting a physical proximity indicator. In one embodiment, proximity friending module 140, responsive to the request from collaboration platform 120, queries client device 110 or an application of client device 110 for the physical proximity indicator, such as an identifier of the WLAN currently accessed by the client device 110. For example, responsive to the request from collaboration platform 120, proximity friending module 140 of client device 110 may send a system call to the operating system (OS) of the client device 110 to request the physical proximity indicator or send a function call to another application executing on client device 110. The physical proximity indicator may be sent to proximity friending module 140 responsive to the call and proximity friending module 140 may then send the physical proximity indicator to collaboration platform 120” (Chandrasekaran Column 10 Lines 51-67) and “In some implementations, an invitation operation 240 may send invitation information such as the user account name of the potential proximate friend (e.g., other user determined to be proximate user A), an avatar or image associated with the potential proximate friend's account, information regarding a mutual friend(s) (e.g., account name of mutual friend(s), indicator that no mutual friends exist, etc.), user input control options (e.g., invite, cancel, ignore, etc.) to be presented with the invitation at the client device 110A” Chandrasekaran Column 14 Lines 5-14); and
in response to determining at least one of: (i) that the first location is not within the threshold distance from the second location, or (ii) that the number of the user accounts that have shared the contact books that include the respective identifiers fails to satisfy the threshold number, causing, by the computing system, the payment to automatically fail (“In some implementations, verification operations 230 may be performed in a similar manner as scan operation 216 as described above. In performing verification operations 230, collaboration platform 120 may determine that client device 110A or 110B or both are no longer accessing the same WLAN and cancel or update the corresponding friend request 212 in a similar manner as described with respect to scan operation 216 above. It may be noted that verification operation 230 may be performed one or more times for a particular client device 110 in implementations. In some implementations, responsive to verifying user A and user B are currently in physical proximity, collaboration platform 120 collaboration platform 120 may perform an invitation operation 240. In some implementations, responsive to verifying that user A and user B are not currently in physical proximity, collaboration platform 120 may refrain performing an invitation operation 240” (Chandrasekaran Column 13 Lines 24-40) and “In some examples, collaboration platform 120 may continue to perform scan operations, such as scan operation 216, to determine if the physical proximity indicator associated with client device 110A has changed” (Chandrasekaran Column 14 Lines 31-34) and “In some implementations, the base functionalities are granted to all (or most) users of collaboration platform 120, and the additional functionalities 121 are granted between users that form a trusted relationship via proximity friending. In some implementations, the additional functionalities 121 may allow for one or more additional privileges or interactions between users (e.g., messaging functionalities, following functionalities, sharing functionalities, purchasing functionalities, inviting functionalities, etc.). In implementations, the one or more additional functionalities 121 may be available between users of a trusted relationship. In some implementations, users that have not established a trusted relationship with each other may be prevented from using the additional functionalities 121 to interact with each other” Chandrasekaran Column 5 Lines 14-28).
Chandrasekaran does not teach; however Anasta teaches:
{. . . . .} training, by a computing system associated with a payment service, a machine learning model using training data comprising contextual data associated with historical payments between user accounts associated with the payment service (“The account data stored by the user account database 304 and the transactions database 303 may, but need not be related to each other. For example, the account data stored by the user account database 304 might correspond to a user account for a bank website, whereas the financial account data stored by the transactions database 303 might be for a variety of financial accounts (e.g., credit cards, checking accounts, savings accounts) managed by the bank. As such, a single user account might provide access to one or more different financial accounts, and the accounts need not be the same. For example, a user account might be identified by a username and/or password combination, whereas a financial account might be identified using a unique number or series of characters” (Anasta Pgh. [0035]) and “In step 402, the computing device may train a machine learning model. The machine learning model might be implemented by, e.g., the machine learning model server 302. The machine learning model might be trained based on the training data and in a manner that teaches the machine learning model to correlate account activity and one or more credit scores. For example, the computing device may train, using the training data, a machine learning model to determine whether account activity indicates a risk to credit scores. Such a risk might be indicated if, for example, the credit score lowers in any way, drops in an amount that satisfies a threshold, lowers in a manner that satisfies a threshold, or the like” (Anasta Pgh. [0043]) and “In step 403, the computing device may process account data. Account data might be stored by the user account database 304 and may indicate information about one or more accounts. Processing the account data may comprise determining whether an account may be associated with an underage user. For example, the computing device may process account data associated with a first financial account to determine whether the first financial account is associated with at least one underage user. An underaged user might be defined based on local law: for example, an underaged user might be defined as being under eighteen years old (e.g., under the age of majority in many states), under twenty-one years old (e.g., under the drinking/gambling age in many states), or the like. Because customers might be located in a variety of different countries, the particular definition of adulthood might depend on the location of a user. As such, processing the account data may comprise determining whether a user is underaged based on, e.g., a geographical location of that user” Anasta Pgh. [0045]);
storing, in a datastore, account data associated with the user accounts, wherein the account data indicates the respective user classifications (“In step 409, the computing device may add a limitation to the account. A limitation may be any restriction on the account, including how the account may be used. The limitation may be based on the indication of the risk to the credit score. For example, the computing device may, based on determining that the first financial account is associated with the at least one underage user, and based on the indication of risk to the credit score associated with the at least one underage user, add at least one limitation to the first financial account. The limitation may be added to the account limitations database 305 such that the limitation applies to future transactions conducted by the account. Examples of limitations are discussed below with respect to FIG. 5” Anasta Pgh. [0056]); and
monitoring, by the computing system, payments between the user accounts (“The transactions database 303 might comprise data relating to one or more transactions conducted by one or more financial accounts associated with a first organization. For example, the transactions database 303 might maintain all or portions of a general ledger for various financial accounts associated with one or more users at a particular financial institution. The data stored by the transactions database 303 may indicate one or more merchants (e.g., where funds were spent), an amount spent (e.g., in one or more currencies), a date and/or time (e.g., when funds were spent), or the like. The data stored by the transactions database 303 might be generated based on one or more transactions conducted by one or more users. For example, a new transaction entry might be stored in the transactions database 303 based on a user purchasing an item at a store online and/or in a physical store. As another example, a new transaction entry might be stored in the transactions database 303 based on a recurring charge (e.g., a subscription fee) being charged to a financial account” Anasta Pgh. [0033]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Anasta’s teachings in order “to determine whether account activity indicates a risk to credit scores” Anasta Abstract.
Chandrasekaran does not teach; however Olenoski teaches:
associating, by the computing system and based on application of the machine learning model, respective user classifications of a plurality of user classifications to individual user accounts of the user accounts (“Aspects described herein may relate to applying machine learning techniques as part of registering a payment card with one or more accounts of one or more merchants. For example, an unsupervised learning classifier may be trained to determine classifications indicating merchant groups and/or classifications indicating user groups. These classifications may be based on types of payment cards, category codes associated with merchants, spending information associated with users, demographic information associated with users, types of devices associated with users, and the like. After the unsupervised learning classifier is trained, the unsupervised learning classifier may be used as part of a process for registering a user's payment card with a merchant. For example, the unsupervised learning classifier may be used to determine, based on the payment card associated with a user, a classification indicative of a merchant group and/or a user group. A merchant group may, based on the classification, indicate one or more merchants that are recommended for registration. A user group may, based on the classification, indicate one or more users that have similar preferences as the user. The user group may be associated with a listing of merchants that are recommended for registration. Based on the classification, the user may be able to select which merchants to register the payment card. Based on the selection, the payment card may be registered with the user's account at the selected merchants” Olenoski Pgh. [0005]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Olenoski’s teachings in order “to determine classifications of merchant groups and/or user groups” Olenoski Abstract.
Chandrasekaran does not teach; however Janzer teaches:
in response to the detecting, determining, {…..} (ii) a number of user accounts of the payment service that have shared contact books that include respective identifiers associated with both the first user account and the second user account satisfies a threshold number (“The verification module 122 verifies user accounts alleged to have a parental relationship with another user. In one embodiment, shown in FIG. 2, the verification module 122 includes an account verification module 210, an adult verification module 220, and a relationship verification module 230. For example, the verification module 122 determines whether a user alleged to have a parental relationship with a child user (a “purported parent”) has an account with the online service associated with the social networking system 120, whether the purported parent is an adult and whether the purported parent is connected to the child user. In other embodiments, the verification module 122 performs any suitable actions for verifying a parental relationship between a purported parent and a child user” (Janzer Pgh. [0026]) and “The account verification module 210 verifies that a purported parent has a valid account. For example, the account verification module 210 compares information identifying a purported parent with stored user accounts to verify that information identifying the purported parent corresponds to information in at least one stored user account. Additionally, the account verification module 210 analyzes a stored user account corresponding to the information identifying a purported parent to verify that the stored user account is authentic. For example, the account verification module 210 retrieves actions, locations, demographic data or other information associated with a user account to determine that the user account is authentic. Illustratively, the account verification module 210 may verify a user account based on the number of established connections associated with the user account. More specifically, the probability that an account is valid increases as the account has more connections. Therefore, the account verification module 210 may determine that an account is authentic if the account has greater than a threshold number of connections. If the user account does not have greater than a threshold number of connections, the account verification module 210 may determine that the account is not valid or, alternatively, flag the account for further verification” (Janzer Pgh. [0027]) and “The relationship verification module 230 determines whether the purported parent user is the parent of a child user. In some instances, the relationship verification module 230 leverages various social signals (e.g., information derived from connections, user profiles, user actions) to verify a parental relationship. In one embodiment, the relationship verification module 230 determines whether the user account of the child user is connected to the user account associated with the purported parent and, if the accounts are connected, determines whether the connection has a type associated with a parental relationship. Additional data associated with the user accounts of the child user and of the purported parent may be used to verify the parental relationship. For example, location data associated with the child user and purported parent user accounts is analyzed, or pictures having the child user and the purported parent tagged are analyzed to further determine the relationship between the child user and the purported parent. In one embodiment, after verifying a parent-child relationship, the relationship verification module 230 automatically establishes a connection between the user account of the child user and the user account of the purported parent having a specified type indicating a parental relationship” (Janzer Pgh. [0029]); and “In another embodiment, the relationship verification module 230 determines whether the purported parent user is the parent of the child user by comparing social data about the purported parent user with data provided by the child user. For example, the relationship verification module 230 determines that the purported parent user and the child user have the same last names, live in the same region, have the same address, or have declared relationships with the same family members” (Janzer Pgh. [0062]) and “Connections between the purported parent user and other users may also be used to verify 305 a parental relationship between the purported parent user and the child user. For example, the purported parent user has verified a parent-child relationship with some of its other children in the online service. If other child users connected to the purported parent have similar attributes to the child user requesting the account, a parental relationship between the purported parent user and the child user requesting the account may be verified 305” Janzer Pgh. [0065]); and
sending, by the computing system, an instruction to a user device associated with the first user account and executing a payment application associated with the payment service, the instruction causing the payment application to present a user interface element notifying a user of the user device that the payment failed (“The authorization module 124 determines whether to create a new user account or to allow access to an existing user account. Additionally, if a child user requests creation of a new user account, the authorization module 124 communicates with the verification module 122 to identify a user account associated with a verified parent of the child user and requests authorization to create the requested account from the verified parent. The communication module 125 communicates a response from the verified parent to the authorization module, which sends the authorization to the account registration module 121 to create the account if the response from the verified parent is an approval. If the response from the verified parent is a denial, the authorization module 124 does not provide authorization to create the account and may communicate a message to the requesting child user via the communication module 125 indicating the account was not created” (Janzer Pgh. [0030]) and “If the purported parent user denies authorization to the child user, the child user's account is denied” Janzer Pgh. [0069]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
With respect to claim 5:
Chandrasekaran does not teach; however Janzer teaches:
wherein: the threshold number is a first threshold number; the computer-implemented method further comprises, in response to determining {. . . . . } that the number of the user accounts that have shared the contact books that include the respective identifiers satisfies the first threshold number, determining whether the number of the user accounts that have shared the contact books that include the respective identifiers satisfies a second threshold number greater than the first threshold number; and the causing the payment to automatically fail is further in response to determining that the number of the user accounts that have shared the contact books that include the respective identifiers fails to satisfy the second threshold number (“The social CAPTCHA asks the user to identify information about other users connected to the user or about interactions in the social networking system. For example, a user may be presented with five users and asked which of them is connected to the user in the social networking system” Janzer Pgh. [0050]) and “Connections between the purported parent user and other users may also be used to verify 305 a parental relationship between the purported parent user and the child user. For example, the purported parent user has verified a parent-child relationship with some of its other children in the online service. If other child users connected to the purported parent have similar attributes to the child user requesting the account, a parental relationship between the purported parent user and the child user requesting the account may be verified 305” (Janzer Pgh. [0065]) and “The regulation module 128 may additionally prevent users of the online service that are above the minimum threshold age and not connected to a child user by two degrees or less (e.g., not a friend of a friend) from locating the child user via a search interface of the online service. In one embodiment, the regulation module 128 also prevents users that are not connected to a child user by two degrees or less and above the minimum threshold age from sending connection requests to the child user” Janzer Pgh. [0083]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
Chandrasekaran teaches:
{. . . . .} the computer-implemented method further comprises, in response to determining that the first location is not within the threshold distance from the second location {. . . . .} (“In implementations, proximity friending may include an attempt by user A to find friends that are nearby or in a physical proximity with user A. In implementations, physical proximity (also referred to as “proximity” herein) may refer to a physical closeness between two users or closeness of the client devices 110 of the users. In some implementations, physical proximity may be a range defined by the range of the network (e.g., Wi-Fi® network, WLAN) that the client devices 110 are accessing. In implementations, the physical proximity relative a user may be in a range that less than 1 mile (from the user), less than 1000 feet, or another range, if applicable. In some implementations, an indication of physical proximity of two users may indicate the relative proximity between two users, where the relative proximity is determined without knowing the absolute location (e.g., longitude and latitude) of the two users. For example, system 200 may known or estimate that two users are proximate one another, but not know the absolute location of at least one of users. In other implementations, system 200 may know the location of the users and estimate the proximity of two or more users based on the known locations” Chandrasekaran Column 9 Lines 4-25).
With respect to claims 6 and 15:
Chandrasekaran teaches:
A system comprising: one or more processors; and memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: detecting that a first user account associated with a first user type is attempting to make a payment to a second user account associated with a second user type (“It may be noted that for the purposes of illustration, rather than limitation, “user A” is a user associated user account A (of the collaboration platform 120) and with client device 110A and “user B” is a user associated user account B and with client device 110B” (Chandrasekaran Column 8 Lines 60-64) and “A collaboration platform may be one or more of numerous platforms, such as a social networking platform, purchasing platform, a messaging platform, creation platform, and so forth” (Chandrasekaran Column 2 Lines 29-32) “In some implementations, an additional functionality 121 may include a sharing functionality that allows user A and user B to share items with each other via the collaboration platform 120. For example, users of a gaming platform may have a sharing functionality that allows users to purchase, trade, or transfer virtual items, such as virtual currency, in a virtual gaming environment” (Chandrasekaran Column 6 Lines 6-12) and “In implementations, users may buy, sell, or trade game items, such as in-platform currency (e.g., virtual currency), with other users of the collaboration platform 120” (Chandrasekaran Column 3 Lines 37-39) and “FIG. 4 is a block diagram illustrating an exemplary computer system 400, in accordance with implementations. The computer system 400 executes one or more sets of instructions that cause the machine to perform any one or more of the methodologies discussed herein. Set of instructions, instructions, and the like may refer to instructions that, when executed computer system 400, cause computer system 400 to perform one or more operations of proximity friending module 140. The machine may operate in the capacity of a server or a client device in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute the sets of instructions to perform any one or more of the methodologies discussed herein. The computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 416, which communicate with each other via a bus 408” Chandrasekaran Column 15 Line 53 to Column 16 Line 16);
in response to the detecting, determining whether a set of conditions is satisfied, the set of conditions comprising: (i) a first condition that a first location associated with the first user account is within a threshold distance from a second location associated with the second user account (“In implementations, proximity friending may include an attempt by user A to find friends that are nearby or in a physical proximity with user A. In implementations, physical proximity (also referred to as “proximity” herein) may refer to a physical closeness between two users or closeness of the client devices 110 of the users. In some implementations, physical proximity may be a range defined by the range of the network (e.g., Wi-Fi® network, WLAN) that the client devices 110 are accessing. In implementations, the physical proximity relative a user may be in a range that less than 1 mile (from the user), less than 1000 feet, or another range, if applicable. In some implementations, an indication of physical proximity of two users may indicate the relative proximity between two users, where the relative proximity is determined without knowing the absolute location (e.g., longitude and latitude) of the two users. For example, system 200 may known or estimate that two users are proximate one another, but not know the absolute location of at least one of users. In other implementations, system 200 may know the location of the users and estimate the proximity of two or more users based on the known locations” (Chandrasekaran Column 9 Lines 4-25) and “In one example, collaboration platform 120 may (scan) send a request to proximity friending module 140 requesting a physical proximity indicator. In one embodiment, proximity friending module 140, responsive to the request from collaboration platform 120, queries client device 110 or an application of client device 110 for the physical proximity indicator, such as an identifier of the WLAN currently accessed by the client device 110. For example, responsive to the request from collaboration platform 120, proximity friending module 140 of client device 110 may send a system call to the operating system (OS) of the client device 110 to request the physical proximity indicator or send a function call to another application executing on client device 110. The physical proximity indicator may be sent to proximity friending module 140 responsive to the call and proximity friending module 140 may then send the physical proximity indicator to collaboration platform 120” (Chandrasekaran Column 10 Lines 51-67) and “In some implementations, an invitation operation 240 may send invitation information such as the user account name of the potential proximate friend (e.g., other user determined to be proximate user A), an avatar or image associated with the potential proximate friend's account, information regarding a mutual friend(s) (e.g., account name of mutual friend(s), indicator that no mutual friends exist, etc.), user input control options (e.g., invite, cancel, ignore, etc.) to be presented with the invitation at the client device 110A” Chandrasekaran Column 14 Lines 5-14); and
in response to determining that the set of conditions is not satisfied, causing the payment to automatically fail (“In some implementations, verification operations 230 may be performed in a similar manner as scan operation 216 as described above. In performing verification operations 230, collaboration platform 120 may determine that client device 110A or 110B or both are no longer accessing the same WLAN and cancel or update the corresponding friend request 212 in a similar manner as described with respect to scan operation 216 above. It may be noted that verification operation 230 may be performed one or more times for a particular client device 110 in implementations. In some implementations, responsive to verifying user A and user B are currently in physical proximity, collaboration platform 120 collaboration platform 120 may perform an invitation operation 240. In some implementations, responsive to verifying that user A and user B are not currently in physical proximity, collaboration platform 120 may refrain performing an invitation operation 240” (Chandrasekaran Column 13 Lines 24-40) and “In some examples, collaboration platform 120 may continue to perform scan operations, such as scan operation 216, to determine if the physical proximity indicator associated with client device 110A has changed” (Chandrasekaran Column 14 Lines 31-34) and “In some implementations, the base functionalities are granted to all (or most) users of collaboration platform 120, and the additional functionalities 121 are granted between users that form a trusted relationship via proximity friending. In some implementations, the additional functionalities 121 may allow for one or more additional privileges or interactions between users (e.g., messaging functionalities, following functionalities, sharing functionalities, purchasing functionalities, inviting functionalities, etc.). In implementations, the one or more additional functionalities 121 may be available between users of a trusted relationship. In some implementations, users that have not established a trusted relationship with each other may be prevented from using the additional functionalities 121 to interact with each other” Chandrasekaran Column 5 Lines 14-28).
Chandrasekaran does not teach; however Janzer teaches:
{. . . . .} (ii) a second condition that a number of mutual connections of the first user account and the second user account satisfies a threshold number (“The verification module 122 verifies user accounts alleged to have a parental relationship with another user. In one embodiment, shown in FIG. 2, the verification module 122 includes an account verification module 210, an adult verification module 220, and a relationship verification module 230. For example, the verification module 122 determines whether a user alleged to have a parental relationship with a child user (a “purported parent”) has an account with the online service associated with the social networking system 120, whether the purported parent is an adult and whether the purported parent is connected to the child user. In other embodiments, the verification module 122 performs any suitable actions for verifying a parental relationship between a purported parent and a child user” (Janzer Pgh. [0026]) and “The account verification module 210 verifies that a purported parent has a valid account. For example, the account verification module 210 compares information identifying a purported parent with stored user accounts to verify that information identifying the purported parent corresponds to information in at least one stored user account. Additionally, the account verification module 210 analyzes a stored user account corresponding to the information identifying a purported parent to verify that the stored user account is authentic. For example, the account verification module 210 retrieves actions, locations, demographic data or other information associated with a user account to determine that the user account is authentic. Illustratively, the account verification module 210 may verify a user account based on the number of established connections associated with the user account. More specifically, the probability that an account is valid increases as the account has more connections. Therefore, the account verification module 210 may determine that an account is authentic if the account has greater than a threshold number of connections. If the user account does not have greater than a threshold number of connections, the account verification module 210 may determine that the account is not valid or, alternatively, flag the account for further verification” (Janzer Pgh. [0027]) and “The relationship verification module 230 determines whether the purported parent user is the parent of a child user. In some instances, the relationship verification module 230 leverages various social signals (e.g., information derived from connections, user profiles, user actions) to verify a parental relationship. In one embodiment, the relationship verification module 230 determines whether the user account of the child user is connected to the user account associated with the purported parent and, if the accounts are connected, determines whether the connection has a type associated with a parental relationship. Additional data associated with the user accounts of the child user and of the purported parent may be used to verify the parental relationship. For example, location data associated with the child user and purported parent user accounts is analyzed, or pictures having the child user and the purported parent tagged are analyzed to further determine the relationship between the child user and the purported parent. In one embodiment, after verifying a parent-child relationship, the relationship verification module 230 automatically establishes a connection between the user account of the child user and the user account of the purported parent having a specified type indicating a parental relationship” (Janzer Pgh. [0029]); and “In another embodiment, the relationship verification module 230 determines whether the purported parent user is the parent of the child user by comparing social data about the purported parent user with data provided by the child user. For example, the relationship verification module 230 determines that the purported parent user and the child user have the same last names, live in the same region, have the same address, or have declared relationships with the same family members” (Janzer Pgh. [0062]) and “Connections between the purported parent user and other users may also be used to verify 305 a parental relationship between the purported parent user and the child user. For example, the purported parent user has verified a parent-child relationship with some of its other children in the online service. If other child users connected to the purported parent have similar attributes to the child user requesting the account, a parental relationship between the purported parent user and the child user requesting the account may be verified 305” Janzer Pgh. [0065]); and
sending an instruction to a user device associated with the first user account and executing a payment application associated with a payment service, the instruction causing the payment application to present a user interface element notifying a user of the user device that the payment failed (“The authorization module 124 determines whether to create a new user account or to allow access to an existing user account. Additionally, if a child user requests creation of a new user account, the authorization module 124 communicates with the verification module 122 to identify a user account associated with a verified parent of the child user and requests authorization to create the requested account from the verified parent. The communication module 125 communicates a response from the verified parent to the authorization module, which sends the authorization to the account registration module 121 to create the account if the response from the verified parent is an approval. If the response from the verified parent is a denial, the authorization module 124 does not provide authorization to create the account and may communicate a message to the requesting child user via the communication module 125 indicating the account was not created” (Janzer Pgh. [0030]) and “If the purported parent user denies authorization to the child user, the child user's account is denied” Janzer Pgh. [0069]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
With respect to claims 11 and 18:
Chandrasekaran does not teach; however Janzer teaches:
wherein the mutual connections of the first user account and the second user account comprise user accounts of the payment service that have shared contact books that include respective identifiers associated with both the first user account and the second user account (“The verification module 122 verifies user accounts alleged to have a parental relationship with another user. In one embodiment, shown in FIG. 2, the verification module 122 includes an account verification module 210, an adult verification module 220, and a relationship verification module 230. For example, the verification module 122 determines whether a user alleged to have a parental relationship with a child user (a “purported parent”) has an account with the online service associated with the social networking system 120, whether the purported parent is an adult and whether the purported parent is connected to the child user. In other embodiments, the verification module 122 performs any suitable actions for verifying a parental relationship between a purported parent and a child user” (Janzer Pgh. [0026]) and “The account verification module 210 verifies that a purported parent has a valid account. For example, the account verification module 210 compares information identifying a purported parent with stored user accounts to verify that information identifying the purported parent corresponds to information in at least one stored user account. Additionally, the account verification module 210 analyzes a stored user account corresponding to the information identifying a purported parent to verify that the stored user account is authentic. For example, the account verification module 210 retrieves actions, locations, demographic data or other information associated with a user account to determine that the user account is authentic. Illustratively, the account verification module 210 may verify a user account based on the number of established connections associated with the user account. More specifically, the probability that an account is valid increases as the account has more connections. Therefore, the account verification module 210 may determine that an account is authentic if the account has greater than a threshold number of connections. If the user account does not have greater than a threshold number of connections, the account verification module 210 may determine that the account is not valid or, alternatively, flag the account for further verification” (Janzer Pgh. [0027]) and “The relationship verification module 230 determines whether the purported parent user is the parent of a child user. In some instances, the relationship verification module 230 leverages various social signals (e.g., information derived from connections, user profiles, user actions) to verify a parental relationship. In one embodiment, the relationship verification module 230 determines whether the user account of the child user is connected to the user account associated with the purported parent and, if the accounts are connected, determines whether the connection has a type associated with a parental relationship. Additional data associated with the user accounts of the child user and of the purported parent may be used to verify the parental relationship. For example, location data associated with the child user and purported parent user accounts is analyzed, or pictures having the child user and the purported parent tagged are analyzed to further determine the relationship between the child user and the purported parent. In one embodiment, after verifying a parent-child relationship, the relationship verification module 230 automatically establishes a connection between the user account of the child user and the user account of the purported parent having a specified type indicating a parental relationship” (Janzer Pgh. [0029]); and “In another embodiment, the relationship verification module 230 determines whether the purported parent user is the parent of the child user by comparing social data about the purported parent user with data provided by the child user. For example, the relationship verification module 230 determines that the purported parent user and the child user have the same last names, live in the same region, have the same address, or have declared relationships with the same family members” (Janzer Pgh. [0062]) and “Connections between the purported parent user and other users may also be used to verify 305 a parental relationship between the purported parent user and the child user. For example, the purported parent user has verified a parent-child relationship with some of its other children in the online service. If other child users connected to the purported parent have similar attributes to the child user requesting the account, a parental relationship between the purported parent user and the child user requesting the account may be verified 305” Janzer Pgh. [0065]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
With respect to claims 12 and 19:
Chandrasekaran does not teach; however Janzer teaches:
wherein: the threshold number is a first threshold number; the operations further comprise, {. . . . .}, determining whether a third condition that the number of the mutual connections satisfies a second threshold number greater than the first threshold number is satisfied; and the causing the payment to automatically fail is further in response to determining that the third condition is not satisfied (“The social CAPTCHA asks the user to identify information about other users connected to the user or about interactions in the social networking system. For example, a user may be presented with five users and asked which of them is connected to the user in the social networking system” Janzer Pgh. [0050]) and “Connections between the purported parent user and other users may also be used to verify 305 a parental relationship between the purported parent user and the child user. For example, the purported parent user has verified a parent-child relationship with some of its other children in the online service. If other child users connected to the purported parent have similar attributes to the child user requesting the account, a parental relationship between the purported parent user and the child user requesting the account may be verified 305” (Janzer Pgh. [0065]) and “The regulation module 128 may additionally prevent users of the online service that are above the minimum threshold age and not connected to a child user by two degrees or less (e.g., not a friend of a friend) from locating the child user via a search interface of the online service. In one embodiment, the regulation module 128 also prevents users that are not connected to a child user by two degrees or less and above the minimum threshold age from sending connection requests to the child user” Janzer Pgh. [0083]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
Chandrasekaran teaches:
{. . . . .} in response to determining that the first condition is not satisfied and that the second condition is satisfied {. . . . } (“In implementations, proximity friending may include an attempt by user A to find friends that are nearby or in a physical proximity with user A. In implementations, physical proximity (also referred to as “proximity” herein) may refer to a physical closeness between two users or closeness of the client devices 110 of the users. In some implementations, physical proximity may be a range defined by the range of the network (e.g., Wi-Fi® network, WLAN) that the client devices 110 are accessing. In implementations, the physical proximity relative a user may be in a range that less than 1 mile (from the user), less than 1000 feet, or another range, if applicable. In some implementations, an indication of physical proximity of two users may indicate the relative proximity between two users, where the relative proximity is determined without knowing the absolute location (e.g., longitude and latitude) of the two users. For example, system 200 may known or estimate that two users are proximate one another, but not know the absolute location of at least one of users. In other implementations, system 200 may know the location of the users and estimate the proximity of two or more users based on the known locations” Chandrasekaran Column 9 Lines 4-25).
With respect to claims 13 and 20:
Chandrasekaran teaches:
wherein: the first location comprises a first verified location determined from first location data stored in a datastore in association with the first user account; and the second location comprises a second verified location determined from second location data stored in the datastore in association with the second user account (“In one implementation, collaboration platform 120 may perform verification operations 230A and 230B (also referred to as verification operations 230) to verify if users A and B are still or currently in physical proximity. In some implementations, collaboration platform 120 may perform verification operation 230 responsive to determining user A and user B are in physical proximity or determining user A and user B are currently requesting a proximity friendship or both. In some implementations, verification operations 230 may help confirm that users are still or currently in proximity with one another. For example, user A and user B may have submitted friend requests 212 and each user may have used the same WLAN at some point in time (as determined from matching physical proximity indicators). At a later time, user A or user B moved from the range of the common WLAN. The verification operations 230 help identify if user A and user B are currently in proximity of one another” Chandrasekaran Column 12 Line 65 to Column 13 Line 14).
With respect to claim 14:
Chandrasekaran teaches:
wherein the first location comprises a first geographic location of the user device at a time of the detecting (“In implementations, proximity friending may include an attempt by user A to find friends that are nearby or in a physical proximity with user A. In implementations, physical proximity (also referred to as “proximity” herein) may refer to a physical closeness between two users or closeness of the client devices 110 of the users. In some implementations, physical proximity may be a range defined by the range of the network (e.g., Wi-Fi® network, WLAN) that the client devices 110 are accessing. In implementations, the physical proximity relative a user may be in a range that less than 1 mile (from the user), less than 1000 feet, or another range, if applicable. In some implementations, an indication of physical proximity of two users may indicate the relative proximity between two users, where the relative proximity is determined without knowing the absolute location (e.g., longitude and latitude) of the two users. For example, system 200 may known or estimate that two users are proximate one another, but not know the absolute location of at least one of users. In other implementations, system 200 may know the location of the users and estimate the proximity of two or more users based on the known locations” (Chandrasekaran Column 9 Lines 4-25).
Claims 3-4, 8-10 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over, Chandrasekaran (U.S. Pub. No. 10,728,701), in view of Janzer (U.S. Pub. No. 2017/0048248) and Anasta (U.S. Pub. No. 2022/0383406) and Olenoski (U.S. Pub. No. 2021/0350381) and Diuk Wasser (U.S. Pub. No. 10,929,772).
With respect to claim 3:
Chandrasekaran does not teach; however Diuk Wasser teaches:
wherein: the first user type is representative of a first age range; and the second user type is representative of a second age range less than the first age range and below an age threshold (“FIG. 1 illustrates an example system 100 including an example user age bracket module 102 configured to provide a determination of an age bracket for a user of a social networking system or any other type of community or group, according to an embodiment of the present technology. An age bracket can be a span of consecutive years of age (or ages) as indicated by a number of years. For example, an age bracket can be a span of two, three, four, five, or any suitable number of years of age. One or more age brackets can be included in an age division. An age division can be a division of ages based on a dividing age. For example, a first age division can be all ages equal to or less than a dividing age and a second age division can be all ages greater than the dividing age” (Diuk Wasser Column 3 Lines 40-53) and “The machine learning model module 104 can train a machine learning model to provide a score that is predictive of an age division for a user. A dividing age can be selected so that a first age division is equal to or less than the dividing age and a second age division is greater than the dividing age. The machine learning model can be a trained using a supervised learning technique in which various features can be used. The features can include, for example, a stated age of a user, a percentage of connections of the user on the social networking system that claim to be a same age as the user, as well as other features. In an evaluation stage, user information including feature values relating to a user can be provided to the machine learning model to provide a score relating to a preliminary determination of an age division for a user. Functionality of the machine learning model module 104 is described in more detail herein” (Diuk Wasser Column 4 Lines 14-29) and “For example, a first age division can be equal to or less than a dividing age and a second age division can be greater than the dividing age. In this example, a label can indicate whether a user is within the first age division or within the second age division. In one instance, a dividing age can be 18 years of age, and a first age division can span years of age equal to or less than 18 and a second age division can span years of age greater than 18. Other dividing ages are possible. In some embodiments, more than two age divisions can be based on a plurality of dividing ages” Diuk Wasser Column 6 Lines 24-33).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Diuk Wasser’s teachings in order “to predict an age division for a user based on user information” Diuk Wasser Abstract.
With respect to claim 4:
Chandrasekaran does not teach; however Janzer teaches:
sending, by the computing system a notification to one or more user devices associated with one or more user accounts that sponsor the second user account as a parent or a guardian, the notification indicating that the payment was attempted, and that the payment failed (“The social networking system may, in an automatic manner, also periodically or continuously notify a verified parent user of actions in the social networking system performed by the child user associated with the verified parent user” (Janzer Pgh. [0009]) and “Additional administrative settings allow the verified parent of the child user to monitor actions taken by the child user within the online service. For example, a social networking system may automatically send notifications regarding a child user's actions to a user account associated with a verified parent of the child user” (Janzer Pgh. [0017]) and “As used herein, an “online service” includes a social networking system, a website external from the social networking system, an online service, a game or other online application, a media item, or any other computing environment that requires parental authorization. The online service can be a portion of a website, an online application that is run on a website, or media items shown on a website. In some embodiments, the computing resource is a social networking system that provides users a way to connect and communicate with other users. Social networking systems allow users to establish relationships or connections with others and share information in a variety of useful ways” (Janzer Pgh. [0018]) and “The authorization module 124 determines whether to create a new user account or to allow access to an existing user account. Additionally, if a child user requests creation of a new user account, the authorization module 124 communicates with the verification module 122 to identify a user account associated with a verified parent of the child user and requests authorization to create the requested account from the verified parent. The communication module 125 communicates a response from the verified parent to the authorization module, which sends the authorization to the account registration module 121 to create the account if the response from the verified parent is an approval. If the response from the verified parent is a denial, the authorization module 124 does not provide authorization to create the account and may communicate a message to the requesting child user via the communication module 125 indicating the account was not created” Janzer Pgh. [0030]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
With respect to claims 8 and 16:
Chandrasekaran does not teach; however Diuk Wasser teaches:
wherein: the first user type is representative of a first age range; and the second user type is representative of a second age range less than the first age range and below an age threshold (“FIG. 1 illustrates an example system 100 including an example user age bracket module 102 configured to provide a determination of an age bracket for a user of a social networking system or any other type of community or group, according to an embodiment of the present technology. An age bracket can be a span of consecutive years of age (or ages) as indicated by a number of years. For example, an age bracket can be a span of two, three, four, five, or any suitable number of years of age. One or more age brackets can be included in an age division. An age division can be a division of ages based on a dividing age. For example, a first age division can be all ages equal to or less than a dividing age and a second age division can be all ages greater than the dividing age” (Diuk Wasser Column 3 Lines 40-53) and “The machine learning model module 104 can train a machine learning model to provide a score that is predictive of an age division for a user. A dividing age can be selected so that a first age division is equal to or less than the dividing age and a second age division is greater than the dividing age. The machine learning model can be a trained using a supervised learning technique in which various features can be used. The features can include, for example, a stated age of a user, a percentage of connections of the user on the social networking system that claim to be a same age as the user, as well as other features. In an evaluation stage, user information including feature values relating to a user can be provided to the machine learning model to provide a score relating to a preliminary determination of an age division for a user. Functionality of the machine learning model module 104 is described in more detail herein” (Diuk Wasser Column 4 Lines 14-29) and “For example, a first age division can be equal to or less than a dividing age and a second age division can be greater than the dividing age. In this example, a label can indicate whether a user is within the first age division or within the second age division. In one instance, a dividing age can be 18 years of age, and a first age division can span years of age equal to or less than 18 and a second age division can span years of age greater than 18. Other dividing ages are possible. In some embodiments, more than two age divisions can be based on a plurality of dividing ages” Diuk Wasser Column 6 Lines 24-33).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Diuk Wasser’s teachings in order “to predict an age division for a user based on user information” Diuk Wasser Abstract.
With respect to claims 9 and 17:
Chandrasekaran does not teach; however Janzer teaches:
sending a notification to one or more user devices associated with one or more user accounts that sponsor the second user account as a parent or a guardian, the notification indicating that the payment was attempted, and that the payment failed (“The social networking system may, in an automatic manner, also periodically or continuously notify a verified parent user of actions in the social networking system performed by the child user associated with the verified parent user” (Janzer Pgh. [0009]) and “Additional administrative settings allow the verified parent of the child user to monitor actions taken by the child user within the online service. For example, a social networking system may automatically send notifications regarding a child user's actions to a user account associated with a verified parent of the child user” (Janzer Pgh. [0017]) and “As used herein, an “online service” includes a social networking system, a website external from the social networking system, an online service, a game or other online application, a media item, or any other computing environment that requires parental authorization. The online service can be a portion of a website, an online application that is run on a website, or media items shown on a website. In some embodiments, the computing resource is a social networking system that provides users a way to connect and communicate with other users. Social networking systems allow users to establish relationships or connections with others and share information in a variety of useful ways” (Janzer Pgh. [0018]) and “The authorization module 124 determines whether to create a new user account or to allow access to an existing user account. Additionally, if a child user requests creation of a new user account, the authorization module 124 communicates with the verification module 122 to identify a user account associated with a verified parent of the child user and requests authorization to create the requested account from the verified parent. The communication module 125 communicates a response from the verified parent to the authorization module, which sends the authorization to the account registration module 121 to create the account if the response from the verified parent is an approval. If the response from the verified parent is a denial, the authorization module 124 does not provide authorization to create the account and may communicate a message to the requesting child user via the communication module 125 indicating the account was not created” Janzer Pgh. [0030]).
It would have been obvious to one of ordinary skill of the art to have modified Chandrasekaran’s teachings to incorporate Janzer’s teachings in order to “manage the account and actions of the child user” Janzer Abstract.
With respect to claim 10:
Chandrasekaran teaches:
wherein the notification includes a selectable option to block the first user account from making future payments to the second user account (“In some implementations, the request may include user input controls that allow user B to select one or more of accepting the friend request, denying the friend request, or blocking the sending user from future friend requests” (Chandrasekaran Column 14 Lines 44-48) and “A collaboration platform may be one or more of numerous platforms, such as a social networking platform, purchasing platform, a messaging platform, creation platform, and so forth” (Chandrasekaran Column 2 Lines 29-32) “In some implementations, an additional functionality 121 may include a sharing functionality that allows user A and user B to share items with each other via the collaboration platform 120. For example, users of a gaming platform may have a sharing functionality that allows users to purchase, trade, or transfer virtual items, such as virtual currency, in a virtual gaming environment” (Chandrasekaran Column 6 Lines 6-12) and “In implementations, users may buy, sell, or trade game items, such as in-platform currency (e.g., virtual currency), with other users of the collaboration platform 120” Chandrasekaran Column 3 Lines 37-39).
Claims 21-22 are objected to as being dependent upon a rejected base claim, but would overcome rejections under 35 U.S.C. 103 if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 4/13/26 have been fully considered but they are not persuasive.
35 USC § 101
The Applicant states that “the instant claims integrate any abstract idea into a practical application by encompassing technological improvements to conventional payment service systems” (page 13) and the amended claims “represent improvements to payment service systems and thus integrate the alleged abstract idea into a practical application” (page 16). The Examiner disagrees with these sentences because the claim amendments further define and recite a more narrow abstract idea. The applicant has not shown how the claims improve a computer or other technology, invoke a particular machine, transform matter, or provide more than a general link between the abstraction and the technology, MPEP 2106.05(a)-(c) & (e). The Examiner disagrees with the sentence that the claim “features, even if any of them is individually conventional, represent an inventive concept in combination, and therefore the claims represent significantly more than the abstract idea” (page 17). The claims do not use generic and conventional components in a non-conventional manner. Instead, the invention uses conventional components arranged in a conventional manner to perform a conventional process. User account classification is not an unconventional activity. The data and algorithm are conventional, and are arranged and used in a conventional manner. The claims are an improvement of the abstract idea only. They are a business solution to the business problem of classifying user accounts. The claims do not provide an improvement over prior systems and only add details to the abstract idea. They do not address a problem particular to the Internet and merely apply the abstract idea on a general computer. The amended claims make the abstract idea more specific. Applicant’s remarks about why these limitations provide a practical application fail to surface any technical improvement identified in the specification and, therefore this is not an inventive concept and significantly more.
35 USC § 103
The claims are rejected under 35 USC § 103 as indicated above in the Office action.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARLA HUDSON whose telephone number is (571)272-1063. The examiner can normally be reached M-F 9:30 a.m. - 5:30 p.m. ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.H./Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights