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 .
This communication is in response to the RCE filed on 02/25/2026. Claims 1-3, 5-8, 10-16, and 18-23 are currently pending in the application.
Response to Arguments
Applicant's arguments filed 02/25/2026 have been fully considered but they are moot in view of the rejections made below in response to applicant’s amendments.
Claim Rejections - 35 USC § 103
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 14-16, 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20150193768 to Douglas et al. (hereinafter Douglas) in view of US. PGPub. No. 20140258122 to Wardman et al. (hereinafter Wardman) and further in view of US.PGPub. No. 20120284175 to Wilson et al. (hereinafter Wilson).
Regarding claim 14, Douglas discloses a method for providing in-application
alerts (¶0024, “in-app alert, etc”), comprising:
receiving, at a computer program executed by a backend and from a user electronic device (¶0042, “User device 120A may be configured with storage that stores one or more operating systems that perform known operating system functions when executed by one or more processors”, wherein the operating system serves as the backend) a transaction request from a user that was initiated from an electronic device for the user (¶0028, “User 120 may operate a user device 120A, which may be a desktop computer, laptop, tablet, smartphone…”), (¶0030, “…user 120 may use user device 120A to browse a webpage of merchant 140 that runs on server 141, and may make a purchase of products or services offered by merchant 140 through the webpage.…”), the transaction request involving a pending transaction with a transaction recipient (¶0060, “…merchant 140 may request authorization to complete a purchase transaction using an account of user 120 held by FSP 110. Server 111 may determine that user 120 is located at merchant 140 and is about to make a purchase there.”, wherein user 120 is the user and the transaction recipient is merchant 140), and comprising contact information for the transaction recipient (¶0077, “Web page 1060 may display additional information about a merchant, including, for example, the name and address 1070 of merchant B…”),
querying, by the computer program, a third party with the contact information for the transaction recipient for a suspicious score for the transaction recipient (¶0031, “Third party server 150 may communicate with at least one of FSP 110, merchant 140, and user device 120A via network 130. Third party server 150 may be associated with a third party. The third party may be, for example, a bank other than FSP 110, a credit reporting agency, a social network company, a rating company, a survey company, or any other suitable data reporting source. Third party server 150 may provide information or data to at least one of FSP 110, merchant 140, or user device 120A. For example, in some examples, third party server 150 may send ratings and reviews data about merchant 140 to FSP 110 and/or user device 120A.”), (¶0065-¶0066, “… The pre-purchase alert message 610 may ask user 120 whether user 120 would like to receive additional information, such as ratings and reviews, about this merchant. The pre-purchase alert message 610 may provide options, e.g., a Yes button 620 and a No button 630, for user 120 to select to indicate whether user 120 wishes to receive additional information about this merchant. User 120 may select the Yes button 620 to indicate user's desire to receive additional information, or the No button 630 to indicate user's desire not to receive additional information….”);
receiving, by the computer program and from the third party, the suspicious score (¶0031, “…, third party server 150 may send ratings and reviews data about merchant 140 to FSP 110 and/or user device 120A…”), (¶0063, “…the threshold score may be set or based on information provided by FSP 110, user 120, and/or a third party. Server 111 may determine that an alert should be triggered, for example, when the comparison indicates that merchant 140 has a low reputation score.”);
determining, by the computer program, that the transaction recipient is suspicious based on the suspicious score (¶0063, “…Server 111 may determine that an alert should be triggered, for example, when the comparison indicates that merchant 140 has a low reputation score, wherein triggering an alert due to low reputation score of the merchant indicates that the transaction has been determined to be suspicious);
determining, by the computer program, that the user has been in contact with the transaction recipient in response to the determination that the transaction recipient is suspicious (¶0025, “…, after the FSP identifies a suspicious transaction, the FSP app may send an alert message to the user to caution the user that the transaction appears to be out of a normal range of amounts or volumes, the transaction may be fraudulent, or that the merchant has poor ratings or reviews, which may mean that the products and/or services purchased from the merchant may have a high likelihood of being subject to future disputes. Based on a user response received from the user, the FSP may provide, e.g., through the FSP app, further information to the user regarding the merchant, such as ratings and reviews of the merchant, to assist the user to make a decision as to whether the transaction should be avoided or canceled to avoid future trouble or disputes…wherein the FSP providing, e.g., through the FSP app, further information to the user regarding the merchant, such as ratings and reviews of the merchant, to assist the user to make a decision as to whether the transaction should be avoided or canceled to avoid future trouble or disputes indicates that the user has been in contact with the transaction recipient); and
requiring, by the computer program, additional verification from the user to execute the pending transaction in response to the determination that the user has been in contact with the transaction recipient (¶0060, “…merchant 140 may request authorization to complete a purchase transaction using an account of user 120 held by FSP 110. Server 111 may determine that user 120 is located at merchant 140 and is about to make a purchase there.”, wherein user 120 being determined to be located at merchant 140 and about to make a purchase there means both are in contact with each other and requesting authorization to complete a purchase transaction is requiring additional verification after swiping a bank card), (¶0050, “server 111 may receive data relating to an activity of user 120. The data relating to the activity of user 120 may include, for example, GPS data received from GPS 324 indicating that user 120 is near or at merchant 140, such as a grocery store, an auto repair shop, an electronic devices retailer, etc. The data relating to the activity of user 120 may also include, for example, data indicating that user 120 is about to make or has made a purchase of products and/or services at merchant 140...”) (¶0058, “…the alert message may be displayed on display 310 of user device 120A. The alert message may include options that may be selected by user 120 to indicate whether user 120 desires to receive additional information regarding the transaction and/or merchant. The additional information may include, for example, ratings and reviews of merchant 140 …).
However, Douglas does not explicitly disclose the following limitation:
wherein the transaction recipient comprises an individual;
wherein the suspicious score is based on the contact information being associated with sources of scams;
executing, by the computer program, the pending transaction in response to receipt of the additional verification.
Wardman discloses wherein the transaction recipient comprises an individual (¶0039, “…the user 102 must input his or her name, address, telephone number, date of birth, email address, and social security number to apply for the new account. The new account is approved by the service provider or financial institution and the service provider or financial institution issues a line of credit to the user 102…”);
wherein the suspicious score is based on the contact information being associated with sources of scams (¶0016, “… In various aspects, this may include the type of transaction and/or the location information from the user device 120. As such, the profile may be used for recognizing patterns of potential fraud, setting transaction limits on the user, etc.”), (¶0029, “…The third party server 130 takes the contact information, queries its database(s) and determines the age of the contact information. The third party server 130 transmits the age of the contact information to the service provider server 180 in any suitable way, including, but not limited to Secure File Transfer Protocol (SFTP), API calls, etc. The service provider server 180 then assigns a confidence metric to the contact information.”), (¶0041-¶0042, “…based on the age of the contact information, the service provider server 180 assigns the contact information a confidence metric. In one embodiment, the confidence metric is scaled to reflect the relative risk of fraud. The confidence metric indicates the likelihood or probability that the user 102 is a fraudster. The confidence metric may be a numerical value (e.g., 0.2 out of a range of values between 0 and 1, where 1 indicates that the user has committed identity theft) or may be a qualitative description (e.g., "highly suspicious," "slightly suspicious," or "not suspicious"). For example, if the age of the contact information is less than a month old, the confidence metric assigned may be "very suspicious," to indicate a very high probability that the user 102 is a fraudster. On the other hand, if the age of the contact information is determined to be 10 years old or older, the confidence metric assigned may be "not suspicious," to indicate that there is a low probability that the user 102 is a fraudster…”);
executing, by the computer program, the pending transaction in response to receipt of the additional verification (¶0017, “The user device 120, in one embodiment, may include a user identifier as one or more attributes related to the user 102, such as personal information (e.g., a user name, password, photograph image, biometric id, address, social security number, phone number, email address, etc.) and banking information (e.g., banking institution, credit card issuer, user account numbers, security information, etc.). In various implementations, the user identifier may be passed with network traffic data of the user 102 to the service provider server 180, and the user identifier may be used by the service provider server 180 to associate the user 102 with a user account maintained by the service provider server 180.”), (¶0012, “The age of the contact information is determined, and based on the age of the contact information, a confidence metric is assigned to the contact information. The confidence metric is then used to determine the honesty and trustworthiness of the user, which can in turn be used to determine the scope of transactions that are allowed with the financial account…”), (¶0044, “… other information may be combined with the age of the contact information to provide a greater degree of certainty that the user is a fraudster or that he or she is authentic. Such information may include, for example, information from other credit applications and other identity records sharing common identity-related information with the user 102, voice biometrics, length of stay at an address, etc.”), (¶0039, “The method 200 begins at step 202, where a new financial account is created by user 102 by entering contact information into a form accessible by the user device 120 and/or by providing the contact information over the phone. In various other embodiments, the user 102 provides the contact information by mail or in person. In one embodiment, the new financial account is set up with a service provider, such as PayPal, Inc. of San Jose, Calif., USA. In another embodiment, the new financial account is set up with a financial institution (e.g., a bank). In either embodiment, the user 102 must input his or her name, address, telephone number, date of birth, email address, and social security number to apply for the new account. The new account is approved by the service provider or financial institution and the service provider or financial institution issues a line of credit to the user 102. The financial institution may send the user information to the service provider to determine whether the user 102 is trustworthy.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Douglas in claim 14 to include wherein the transaction recipient comprises an individual as disclosed by Wardman and be motivated in doing so in order to physically identify the recipient of the transaction.
However, the combination of Douglas and Wardman does not explicitly disclose that the transaction request received from a user electronic device is a pending person-to-person request.
Wilson discloses a pending person-to-person transaction request from a user electronic device (Abstract, ¶0058, “…Each financial institution 104 may be coupled to one or more portable computing devices ("PCDs") 101 that are operated by the financial institution's customers, which include senders and receivers in person-to-person transactions.”), (¶0062, “Some exemplary functions of the payment switch module 102 include, but are not limited to, providing notifications to financial institutions 104 of pending person-to-person payments; tracking whether a P2P payment has been received, accepted and/or rejected; and generating and passing messages relating to person-to-person transactions between financial institutions. The payment switch module 102 generally defines the payload or the content of the messages that are exchanged between two or more financial institutions 104 in connection with a person-to-person transaction.”), (¶0101, “…TABLE-US-00010 TABLE 10 Person Types - may represent an individual consumer; either acting as the Debtor or Creditor in a payment transaction. Parameter Description Type Cardinality Required FirstName The Customer's first name. String 0 . . . 1* N LastName The Customer's last name. String 0 . . . 1* N CustomerFIPartyID A unique customer String 0 . . . 1* N identifier supplied and managed by a Member FI 104…”);
Requiring additional verification from the user to execute the person-to-person (P2P) and executing the person-to-person (P2P) in response to receiving the additional verification (¶0189-¶0190, FIGs 4A and 4B, “…the payment switch module 102 via the create payment API 106B3 forwards the secure party identifier in addition to the payment information such as the payment amount to the sender financial institution 104A. In block 424, the sender financial institution 104A relays the data that includes the secure party identifier and the payment information for display on the portable computing device 101, such as illustrated in FIG. 15D described below. In decision block 426, the portable computing device 101 prompts the sender to select whether or not he or she recognizes the intended receiver based on the secure party identifier.”, wherein the secure party identifier that was received in addition to the payment information is interpreted as the claimed additional verification)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Douglas and Wardman in claim 14 to include a person-to-person pending transaction including senders and receivers as disclosed by Wilson and be motivated in doing so in order to leverage the existing payment systems to transfer funds from a first party to a second party electronically such that the second party has access to the transferred funds in a matter of seconds-Wilson ¶0003 in parts.
Regarding claim 15, Douglas in view of Wardman and further in view of Wilson discloses the method of claim 14.
Douglas further discloses wherein the person-to-person transaction comprises making a payment to the transaction recipient or sending money to the transaction recipient (¶0024, “…Financial transactions may include, for example, payment of a user purchase of products or services from a merchant using a credit card, debit card, bank account, loyalty card, etc.”). See also ¶0046 of Wilson.
Regarding claim 16, Douglas in view of Wardman and further in view of Wilson
discloses the method of claim 14.
Douglas further discloses wherein the third party comprises a mobile network operator or
an internet service provider (¶0029, the operator of the wireless cellular network or the provider of the internet network 130).
Regarding claim 18, Douglas in view of Wardman and further in view of Wilson discloses the method of claim 14.
Douglas further discloses wherein the backend is a backend for a financial institution (¶0027, “FSP 110 may be a bank, a credit card company, a lender, or other type of financial service entity that generates, provides, manages, and/or maintains financial service accounts for one or more users, such as credit cards, debit cards, etc. FSP 110 may operate at least one server 111”).
Regarding claim 19, Douglas in view of Wardman and further in view of Wilson discloses the method of claim 14.
Douglas further discloses wherein the backend is a backend for a cash transfer service (¶0027, “FSP app 252 may cause processor 220 to execute one or more processes related to financial services provided to customers including, but not limited to, processing credit and debit card transactions, checking transactions, fund deposits and withdrawals, transferring money between financial accounts...”).
Regarding claim 20, Douglas in view of Wardman and further in view of Wilson discloses the method of claim 14.
Douglas further discloses wherein the additional verification is received in an out-of-band message (¶0038, “…it is understood that database 270 may be part of memory 240, storage device 260, or an external storage device located outside of server 111”, wherein the information about the transaction, merchant 140, user 120, ratings and reviews stored in the storage device located outside of server 111 is considered out of bound messages for verification of the transaction), (¶0054, The data relating to the activity of user 120 may also include geographical information (e.g., the location) about the transaction. For example, server 111 may detect that a purchase was made at a merchant located over 250 miles from where user 120 typically makes purchases…”, wherein the information about far away geographical location of the transaction to confirm the legitimacy of the purchases is interpreted as out of bound verification message).
Regarding claim 21, Douglas in view of Wardman and further in view of Wilson discloses the method of claim 14.
Wardman further discloses wherein the contact information comprises a phone number and/or an email address for the transaction recipient (¶0039, “…. the user 102 must input his or her name, address, telephone number, date of birth, email address, and social security number to apply for the new account. The new account is approved by the service provider or financial institution and the service provider or financial institution issues a line of credit to the user 102…”), see also ¶0048 Wardman and ¶0011 of Wilson.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Douglas and Wardman in claim 14 to include the telephone number or email address of transaction recipient as disclosed by Wardman and be motivated in doing so in order to promptly contact the recipient if there is any suspicion/fraud in the transaction.
Claims 1-3, 5- 8, and 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200389552 to TRIM et al. (hereinafter TRIM) in view of US. PGPub. No. 20030050880 to Degen et al. (hereinafter Degen) and further in view of US.PGPub. No. 20120284175 to Wilson et al. (hereinafter Wilson).
Regarding claim 1, TRIM discloses a method for providing in-application alerts (abstract, “…receiving, by a computing device of a call recipient, a call request message from a remote caller device of a caller,”), comprising:
receiving, at a computer program and from an operating system executed by a user electronic device associated with a user (¶0042, FIG. 2, recipient device 60, wherein the recipient device 60 is associated with a (user) call recipient ), a notification that a message was received by the user electronic device and a caller ID for the message and/or a message sender identifier (¶0005, “there is a computer program product comprising a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by a computing device to cause a computing device of a call recipient to: receive a call request message from a remote caller device of a caller…receive an incoming telephone call from the caller, the incoming call including a caller identification (ID) identifier…”), (¶0040, “Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment”);
However, TRIM, even though discloses comparing, by the computer program, the caller ID for the message and/or the message sender identifier to data in one or more database in ¶0056, does not explicitly disclose the following limitation:
associating calls with suspicious or fraudulent transactions,
comparing, by the computer program, the caller ID for the message and/or the message sender identifier to data in one or more database, wherein the database comprises an association of message sender identifiers to sources of scams,
determining, by the computer program, that the message is suspicious based on the message sender identifier being in the database
identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message;
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending person-to-person transaction activity may be suspicious.
Degen discloses linking calls with suspicious or fraudulent transactions (¶0001, “This invention relates generally to the field of credit transactions, and in particular to the authorization of credit transactions. More specifically, the invention relates to systems and techniques for detecting fraudulent calls made when requesting whether a credit transaction is authorized.”), (¶0003, “…The individuals use the potential account numbers to call an authorization service, via an authorization request number, in order to ascertain whether the potential account number is authorized for a given dollar amount. These fraudulent calls are often made from home phones, cell phones, pay phones, etc. Once the individuals learn that a potential account number is authorized, they may attempt to use the potential account number on the Internet, in a mail order, in a telephone order, in an in person transaction, etc.”), (¶0029, “…Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”).
comparing, by the computer program, the caller ID for the message and/or the message sender identifier to data in one or more database, wherein the database comprises an association of message sender identifiers to sources of scams (FIG. 2, ¶0021- ¶0029, “This person might query various public and private data bases and conduct proactive investigation (calls the originating phone number in a pretext call) in order to ascertain ownership and control of the phone number. This way the person can verify whether that phone number is related to the merchant account which is involved in the "suspect" transaction which has previously qualified under the fraud search rules as a suspect transaction and as probably being indicative of fraudulent activity. This person, or investigator, then "marks" the transaction and therefore the telephone number (or other authorization request) as good or bad. If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”), (¶0053, “…These fields contain data related to the authorization requests. These fields include: the Caller ID phone number, the card number, the authorization request date, the time of the authorization request, the dollar amount requested, the DNIS, the merchant number, and the approval number, if any.”);
determining, by the computer program, that the message is suspicious based on the message sender identifier being in the database ¶0029, “…If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”);
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending transaction activity may be suspicious (¶0029, “…If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”), (¶0019, “… As used herein, the term "bank" refers to a bank, financial institution, credit issuer, credit/charge card company or the like.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM to include associating calls to fraudulent activities as disclosed by Degen and be motivated in doing so in order to warn a credit card issuer of probable fraudulent activity at an early stage-Degen ¶0004 in parts.
The combination of TRIM and Degen does not explicitly disclose the following limitation:
identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message;
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending person-to-person transaction activity may be suspicious.
Wilson discloses identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message (¶0169, “Referring back to FIG. 4A, block 401 is the first step in method 400A. In block 401, the sender initiates a person-to-person payment using a portable computing device 101 such as illustrated in FIG. 15A. As discussed above, the portable computing device 101 is not limited to a mobile phone and may include other devices, such as, but not limited to, a personal digital assistant, a pager, a smartphone, a tablet portable computing device, a navigation device, and a hand-held or personal computer with a wireless connection or link.”), (¶0205-¶0207, FIGs 4A and 4B, “In block 456, the portable computing device 101B of the receiver receives the message from the receiver's financial institution 104B. The receiver operating the portable computing device 101B may login to the system 101 at his or her own discretion. The receiver may login to the system 101 within a few minutes or within a few days in order to accept the payment from the sender…Next, in block 460, upon receipt of the message sent through the process pending payments API 106D2, the payment switch module 102 looks up and retrieves pending payments for the receiver that are listed in the transaction database 108B. The receiver may have more than one pending payment depending upon the number of payments that may have been sent by other sender's over the course of a period of time.”)
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending person-to-person transaction activity may be suspicious (¶0107, “… If the alias is not found within the registry database 108A, an informational message is returned with a limited set of velocity options. An unidentified payee is a valid response for this operation.”), (¶0223, “FIG. 6 illustrates a continuation flowchart of the method 400C of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee. Block 602 is the first step in method 400C which originates from a negative result or the "NO" branch following decision block 426 of FIG. 4 in which a sender cancels a payment because he or she does not recognize the secure party identifier ("SPI") presented in block 424 of FIG. 4.”, wherein a notification of payment rejection is a form of warning that the transaction is suspicious), see also ¶0231, ¶0238, and ¶0267-¶0268.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM and Degen to include identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message as disclosed by Wilson and be motivated in doing so in order to prevent fraudulent transactions and thus enhancing the security of the system.
Regarding claim 8, TRIM discloses a method for providing in-application alerts (abstract, “…receiving, by a computing device of a call recipient, a call request message from a remote caller device of a caller,”), comprising:
receiving, at a computer program executed by a backend and from a user electronic device associated with a user (¶0042, FIG. 2, recipient device 60, wherein the recipient device 60 is associated with a (user) call recipient ), a notification that a message was received by the user electronic device and a caller ID for the message and/or a message sender identifier (¶0005, “there is a computer program product comprising a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by a computing device to cause a computing device of a call recipient to: receive a call request message from a remote caller device of a caller…receive an incoming telephone call from the caller, the incoming call including a caller identification (ID) identifier…”), (¶0040, “Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment” , wherein the operating system is the backend that executes the computer program);
However, TRIM, even though discloses comparing, by the computer program, the caller ID for the message and/or the message sender identifier to data in one or more database in ¶0056, does not explicitly disclose the following limitation:
associating calls with suspicious or fraudulent transactions,
comparing, by the computer program, the caller ID for the message and/or the message sender identifier to data in one or more database, wherein the database comprises an association of message sender identifiers to sources of scams,
determining, by the computer program, that the message is suspicious based on the message sender identifier being in the database
identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message;
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending person-to-person transaction activity may be suspicious.
Degen discloses linking calls with suspicious or fraudulent transactions (¶0001, “This invention relates generally to the field of credit transactions, and in particular to the authorization of credit transactions. More specifically, the invention relates to systems and techniques for detecting fraudulent calls made when requesting whether a credit transaction is authorized.”), (¶0003, “…The individuals use the potential account numbers to call an authorization service, via an authorization request number, in order to ascertain whether the potential account number is authorized for a given dollar amount. These fraudulent calls are often made from home phones, cell phones, pay phones, etc. Once the individuals learn that a potential account number is authorized, they may attempt to use the potential account number on the Internet, in a mail order, in a telephone order, in an in person transaction, etc.”), (¶0029, “…Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”).
comparing, by the computer program, the caller ID for the message and/or the message sender identifier to data in one or more database, wherein the database comprises an association of message sender identifiers to sources of scams (FIG. 2, ¶0021- ¶0029, “This person might query various public and private data bases and conduct proactive investigation (calls the originating phone number in a pretext call) in order to ascertain ownership and control of the phone number. This way the person can verify whether that phone number is related to the merchant account which is involved in the "suspect" transaction which has previously qualified under the fraud search rules as a suspect transaction and as probably being indicative of fraudulent activity. This person, or investigator, then "marks" the transaction and therefore the telephone number (or other authorization request) as good or bad. If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”), (¶0053, “…These fields contain data related to the authorization requests. These fields include: the Caller ID phone number, the card number, the authorization request date, the time of the authorization request, the dollar amount requested, the DNIS, the merchant number, and the approval number, if any.”);
determining, by the computer program, that the message is suspicious based on the message sender identifier being in the database ¶0029, “…If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”);
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending transaction activity may be suspicious (¶0029, “…If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent. Appropriate action can then be taken, such as performing a more thorough investigation and contacting the authorities and the fraud victim.”), (¶0019, “… As used herein, the term "bank" refers to a bank, financial institution, credit issuer, credit/charge card company or the like.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM to include associating calls to fraudulent activities as disclosed by Degen and be motivated in doing so in order to warn a credit card issuer of probable fraudulent activity at an early stage-Degen ¶0004 in parts.
The combination of TRIM and Degen does not explicitly disclose the following limitation:
identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message;
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending person-to-person transaction activity may be suspicious.
Wilson discloses identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message (¶0169, “Referring back to FIG. 4A, block 401 is the first step in method 400A. In block 401, the sender initiates a person-to-person payment using a portable computing device 101 such as illustrated in FIG. 15A. As discussed above, the portable computing device 101 is not limited to a mobile phone and may include other devices, such as, but not limited to, a personal digital assistant, a pager, a smartphone, a tablet portable computing device, a navigation device, and a hand-held or personal computer with a wireless connection or link.”), (¶0205-¶0207, FIGs 4A and 4B, “In block 456, the portable computing device 101B of the receiver receives the message from the receiver's financial institution 104B. The receiver operating the portable computing device 101B may login to the system 101 at his or her own discretion. The receiver may login to the system 101 within a few minutes or within a few days in order to accept the payment from the sender…Next, in block 460, upon receipt of the message sent through the process pending payments API 106D2, the payment switch module 102 looks up and retrieves pending payments for the receiver that are listed in the transaction database 108B. The receiver may have more than one pending payment depending upon the number of payments that may have been sent by other sender's over the course of a period of time.”)
issuing, by the computer program and in response to the identification, a warning to the user electronic device that the pending person-to-person transaction activity may be suspicious (¶0107, “… If the alias is not found within the registry database 108A, an informational message is returned with a limited set of velocity options. An unidentified payee is a valid response for this operation.”), (¶0223, “FIG. 6 illustrates a continuation flowchart of the method 400C of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee. Block 602 is the first step in method 400C which originates from a negative result or the "NO" branch following decision block 426 of FIG. 4 in which a sender cancels a payment because he or she does not recognize the secure party identifier ("SPI") presented in block 424 of FIG. 4.”, wherein a notification of payment rejection is a form of warning that the transaction is suspicious), see also ¶0181, ¶0231, ¶0238, and ¶0267-¶0268.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM and Degen to include identifying, by the computer program, a pending person-to-person transaction activity being conducted by the user using an application executed by the user electronic device within a predetermined period of time from receipt of the message as disclosed by Wilson and be motivated in doing so in order to prevent fraudulent transactions and thus enhancing the security of the system.
Regarding claim 2, TRIM in view of Degen and further in view of Wilson discloses the method of claim 1.
TRIM further discloses wherein the message comprises a telephone call (¶0053, “…the recipient device 60 may match the telephone number (e.g., 976-555-1212) identified in the call request message with a telephone number in the contact list of the recipient device 60, and store the validated identifier with the telephone number in the contact list…”), a SMS message, an email, or a push notification.
Regarding claim 3, TRIM in view of Degen and further in view of Wilson discloses the method of claim 1.
Degen further discloses further comprising: receiving, by the computer program and from a third party, a notification that the message is suspicious (¶0029, “…If it is determined at the investigation area 108 that there exists probable fraudulent activity, then this is communicated to the appropriate bank 106 via the receiving center and the management center at step S208. Thus, the bank is warned that further fraud is imminent…”, wherein the receiving center and the management center that communicate the result of the investigation to the bank is interpreted as the third party).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM, Degen, and Wilson to include receiving a notification from a third party that a message is suspicious as disclosed by Degen and be motivated in doing so in order for the bank to take appropriate action, such as performing a more thorough investigation and contacting the authorities and the fraud victim-Degen ¶0029 in parts.
Regarding claim 5, TRIM in view of Degen and further in view of Wilson discloses the method of claim 1.
TRIM further discloses (¶0018, Nuisance callers that utilize deceptive caller ID identifiers to fool call recipients into answering a telephone call, which they may not have otherwise answered.”), and
Degen further discloses wherein the pending transaction activity comprises making a payment to an unknown entity (¶0022, “…Once the criminal receives authorization they typically use the account number to commit fraud by making a purchase…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM, Degen, and Wilson to include determining pending transaction activity of making payment to an unknown entity as disclosed by Degen and be motivated in doing so in order to prevent criminal element from stealing authorization request numbers-Degen ¶0022 in parts.
Regarding claims 6 and 11, TRIM in view of Degen and further in view of Wilson discloses the methods of claims 1 and 8 respectively.
Wilson further discloses further comprising:
requesting, by the computer program, additional verification to execute the pending person-to-person transaction activity (¶0189-¶0190, “… In block 422, the payment switch module 102 via the create payment API 106B3 forwards the secure party identifier in addition to the payment information such as the payment amount to the sender financial institution 104A., wherein the secure party identifier that was received in addition to the payment information is interpreted as the claimed additional verification);
receiving, by the computer program, the additional verification (¶0190, “…In block 424, the sender financial institution 104A relays the data that includes the secure party identifier and the payment information for display on the portable computing device 101, such as illustrated in FIG. 15D described below. In decision block 426, the portable computing device 101 prompts the sender to select whether or not he or she recognizes the intended receiver based on the secure party identifier.”); and
executing, by the computer program, the pending activity (FIGs 4A and 4B, steps 422-426, 428-434, 436-442), and
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the methods of TRIM, Degen, and Wilson to include additional verification to execute the pending person-to-person transaction as disclosed by Wilson and be motivated in doing so in order to prevent fraudulent transactions– Wilson ¶0136 in parts.
Regarding claims 7 and 13, TRIM in view of Degen and further in view of Wilson discloses the methods of claim 1 and 8 respectively.
Wilson further discloses further comprising: receiving, by the computer program, approval to execute the pending person-to-person transaction activity (¶0055, “One advantage of the system 100 is that transfers of value in a person-to- person payment transaction may occur almost instantaneously from the perspective of the sender and receiver, such as on the order of minutes or even seconds, and depending upon the approvals needed for the transaction from the sender and the receiver operating their respective portable computing devices 101A, 101B.…”); and
executing, by the computer program, the pending person-to-person transaction activity (FIGs 4A and 4B, steps 422-426, 428-434, 436-442);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the methods of TRIM, Degen, and Wilson in claims 1 and 8 respectively to include execution of pending person-to-person transaction activity as disclosed by Wilson and be motivated in doing so in order to have the payment transaction occur almost instantaneously from the perspective of the sender and receiver – Wilson ¶0055 in parts.
Regarding claim 10, TRIM in view of Degen and further in view of Wilson discloses the method of claim 8.
TRIM further discloses (¶0018, Nuisance callers that utilize deceptive caller ID identifiers to fool call recipients into answering a telephone call, which they may not have otherwise answered.”), and
Degen further discloses wherein the pending transaction activity comprises making a payment to an unknown entity (¶0022, “…Once the criminal receives authorization they typically use the account number to commit fraud by making a purchase…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM, Degen, and Wilson to include determining pending transaction activity of making payment to an unknown entity as disclosed by Degen and be motivated in doing so in order to prevent criminal element from stealing authorization request numbers-Degen ¶0022 in parts.
Wilson further discloses pending person-to-person transaction (¶0062, “Some exemplary functions of the payment switch module 102 include, but are not limited to, providing notifications to financial institutions 104 of pending person-to-person payments…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM, Degen, and Wilson by implementing the pending person-to-person transaction of Wilson in the method of TRIM, Degen, and Wilson and be motivated in doing so in order to eliminate the chance that fraudulent transactions occurring within and/or across the system -Wilson ¶0136 in parts.
Regarding claim 12, TRIM in view of Degen and further in view of Wilson discloses the method of claim 11.
TRIM further discloses wherein the additional verification is received in an out-of-band communication (¶0049, “…In other implementations, an out of band token exchange is made through other protocols such as email, near field communication (NFC), or Bluetooth of an authentication token, wherein the registration message can be as simple as a short string of characters, or as convoluted as cryptographically strong tokens such as public keys, etc.”). See also ¶0050 and ¶0053.
Claims 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20200389552 to TRIM et al. (hereinafter TRIM) in view of US. PGPub. No. 20030050880 to Degen et al. (hereinafter Degen) and further in view of US.PGPub. No. 20120284175 to Wilson et al. (hereinafter Wilson) and further in view of US. Pat. No. 8984632 to Laffoon et al. (hereinafter Laffoon).
Regarding claims 22-23, TRIM in view of Degen and further in view of Wilson discloses the methods of claims 1 and 8 respectively.
Wilson further discloses pending person-to-person transaction (¶0062, “Some exemplary functions of the payment switch module 102 include, but are not limited to, providing notifications to financial institutions 104 of pending person-to-person payments…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM, Degen, and Wilson by implementing the pending person-to-person transaction of Wilson in the method of TRIM, Degen, and Wilson and be motivated in doing so in order to eliminate the chance that fraudulent transactions occurring within and/or across the system -Wilson ¶0136 in parts.
However, TRIM in view of Degen and Wilson does not explicitly disclose the limitation of:
wherein the pending transaction activity comprises installing suspected malware on the user electronic device.
Laffoon discloses wherein the pending transaction activity comprises installing suspected malware on the user electronic device (Coln.3, lines 53-67-Coln.4, lines 1-7, “…As a result, the present systems and methods may identify the applications that are running and/or just installed that are common across multiple mobile devices to identify the potential malware that abuse premium rate services by using SMS messages and/or phone call activities.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of TRIM, Degen, and in claims 1 and 8 to include wherein the pending transaction activity comprises installing suspected malware on the user electronic device as disclosed by Laffoon and be motivated in doing so in order to identify the applications that are installed or running on a mobile device at the time a malicious activities are performed in the network-Laffoon Coln.3, lines 53-63 in parts.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights