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 .
DETAILED ACTION
Claims 1-20 are pending in this application.
Claim Objections
Claims 1, 5, 8, 14 and 18 are objected to because of the following informalities:
Regarding claims 1, 8 and 14, claim 1 there is a “-“ sign in front of firewall this should be removed. Appropriate correction is required.
Regarding claim 5, claim 5 should have the limitation “the system –“ replaced with the system comprising one or more processors configured to accept/deny. (Emphasis added). Appropriate correction is required.
Regarding claim 14, claim 14 should be rewritten to say “a non-transitory computer-readable storage media,” (Emphasis added). Appropriate correction is required.
Regarding claim 18, claim 18 should have the “-“ replaced with a colon “:” Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3-7, 9-18 of U.S. Patent No: 12,236,422. Although the claims at issue are not identical, they are not patentably distinct from each other because all the limitations of the instant Application are anticipated by U.S. Patent No: 12,236,422.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dixon et al (“Dixon,” US 20080109473), Peram et al (“Peram,” US 20170098219) Varghese et al ("Varghese," US 20060282660), in view of Shraim et al ("Shraim," US 20060069697) and further in view of Tomasofsky et al ("Tomasofsky," US 20200265416).
Regarding claim 1, Dixon discloses a system for identifying genuine user-merchant association, the system comprising one or more processors and/or transceivers individually or collectively programmed to:
check the validity or expiration of a network certificate associated with a request to create a certificate score, (Dixon, [0103], [0257], [0360] & [0006] describes checking
the validity and/or authorization of a certificate from a device from which a request
originates to create a reputation score based on a certificate; [0257] describes the certificate came from an SSL certificate vendor meaning the certificate is a network
certificate; [0265]; [0395] also describes using SSL)
the request being from a user and for access to a subscription service of a
merchant, (Dixon, [0139], [0407], [0258] describes a request from a user to access a
website URL made through a reputation server and access services such as pay per
view or subscriptions from a merchant)
analyze previous communication from the user device from which the request
originates across a plurality of entities and regions to create a previous communication
score; (Dixon, [0111], [0250], describes analyzing emails [previous communication from
the device from which the request originates across a plurality of entities and regions] to
create a spam score of each message based on reputation; [0006] describes a request)
output a weighted final score comprising a determination of whether to accept or
deny the request based at least in part on one or more of the certificate score, (Dixon,
[0332] describes each of these dimensions of reputation may also be combined into an
aggregated score; [0150] describes a reputation where there is a process for allowing or
denying features associated with web content that originated from a request; [0103],
[0257], [0360] describes checking the validity and/or authorization of a certificate from a
device from which a request originates to create a reputation score based on a certificate; [0006] describes a request)
the previous communication score, (Dixon, [0332] describes each of these
dimensions of reputation may also be combined into an aggregated score; [0111], [0250] describes the previous communication score)
Dixon fails to explicitly disclose the request being from a user and for access to a trial subscription service of a merchant; the analysis including a determination that multiple previous communications from the user embody and a common internet protocol (IP) address, the previous communication score reflecting higher fraud likelihood of the multiple previous communications from the common IP address, the consistency being indicative of attempted repeated fraudulent utilization of the trial subscription service; a weighted final score incorporating a weighting toward denying the request based on the determination of and the common IP address; generate a corresponding recommendation to the merchant to accept or deny the request from the user.
However, in an analogous art, Peram discloses the request being from a user and for access to a trial subscription service of a merchant; (Peram, [0017], describes a free trial offered as part of account creation; [0019] describes repeated acquisition of successive free-trial accounts as free trial abuse which determines a trial period before calculating the fraud score)
the analysis including a determination that multiple previous communications from the user embody and a common internet protocol (IP) address, the previous communication score reflecting higher fraud likelihood of the multiple previous communications from the common IP address, the consistency being indicative of attempted repeated fraudulent utilization of the trial subscription service; (Peram, [0062] describes where many account are created in a short time from a specific IP address, later accounts from that IP may be regarded as more likely fraudulent; its rules receive different point/score adjustments according to predictive value; [0019] separately identifies the relevant fraud as free-trial abuse)
the consistency being indicative of attempted repeated fraudulent utilization of the trial subscription service, (Peram, [0019] describes relevant fraud as free-trial abuse)
a weighted final score incorporating a weighting toward denying the request based on the determination of and the common IP address; (Peram, [0062] describes increasing the fraud likelihood/score for repeated use of the IP address)
generate a corresponding recommendation to the merchant to accept or deny the request from the user, (Peram, FIG 1, [0028]-[0030], [0063] describes a monitoring system that interacts with the service-provider account systems and automatically acts on an account based on fraud score)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Peram with the method and system of Dixon to include the request being from a user and for access to a trial subscription service of a merchant; the analysis including a determination that multiple previous communications from the user embody and a common internet protocol (IP) address, the previous communication score reflecting higher fraud likelihood of the multiple previous communications from the common IP address, the consistency being indicative of attempted repeated fraudulent utilization of the trial subscription service; a weighted final score incorporating a weighting toward denying the request based on the determination of and the common IP address; generate a corresponding. One would have been motivated to detect and handle fraudulent accounts and/or fraudulent activity associated with accounts in a network based environment (Peram, [0001]).
Dixon and Peram fails to explicitly disclose the analysis including a determination that multiple previous communications from the user embody a consistent header formatting and a common internet protocol (IP) address; the weighted final score incorporating a weighting toward denying the request based on the determination of the consistent header formatting and the common IP address.
However, in an analogous art, Varghese discloses the analysis including a
determination that multiple previous communications from the user embody a consistent
header formatting and a common internet protocol (IP) address; (Varghese, [0093], Table 4 describes the HTTP header for the browser that has the browser device information, version, patch level, HTTP protocol version; [0094] describes this header information is comparing to see if any mismatches occur they can be weighted to form a score for use in risk analysis, [0181], describes rule conditions that are useful in device and location fingerprinting such as a browser header match percentage, known browser header attributes and a weighted match percentage of selected known attributes of the browser header and checking the IP address in the device profile; [0006] describes the IP address is included in the message header and the cookie is one that has been previously sent by the server often at login. The server compares the user login data with the message IP address from the message header and the returned cookie to determine the identity of the user sending the message and whether the user is currently logged into the server. The IP address of the user is also confirmed; [0123] describes formatting; [0031]-[0032], [0038)-[0039] describe risk scoring to determine fraud)
the weighted final score incorporating a weighting toward denying the request
based on the determination of the consistent header formatting and the common IP
address, (Varghese, [0084], Table 2 describes an events and risk scoring engine to
determine and output a weighted risk score; [0025] describes denying online transactions in real-time as a function of the risk presented by both the user and the device attempting to conduct a transaction and this was based on [0094], Table 4, [0181], describes a browser header match percentage, known browser header attributes and a weighted match percentage of selected known attributes of the browser header; [0006] describes the IP address is included in the message header and the cookie is one that has been previously sent by the server often at login. The server compares the user login data with the message IP address from the message header and the returned cookie to determine the identity of the user sending the message and whether the user is currently logged into the server. The IP address of the user is also confirmed; [0123] describes formatting; [0031]-[0032], [0038)-£0039] describe risk scoring to determine fraud)
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to combine the teachings of Varghese with
the method & system of Dixon and Peram to include the analysis including a determination that multiple previous communications from the device embody a consistent header formatting and a common internet protocol (IP) address; the weighted final score incorporating a weighting toward denying the request based on the determination of the consistent header formatting and the common IP address. One would have been motivated to provide information and selectable user interfaces for enabling a service provider to take action to authorize, deny, or put on hold online transactions in real time as a function of the risk presented by both the user and the device attempting to conduct a transaction (Varghese, [0025]).
Dixon, Peram and Varghese fails to explicitly disclose the previous communication score reflecting higher fraud likelihood for consistent header formatting of the multiple previous communications from the common IP address.
However, in an analogous art, Shraim discloses the previous communication score reflecting higher fraud likelihood for consistent header formatting of the multiple previous communications from the common IP address; (Shraim, [0017], [0019], [0079] describes the previous communication score; [0122], [0124]-[0125], [0127] and [0128] describes reflecting higher fraud likelihood for phishing based on email headers and IP address; also see [0009], [0205], [0027], [0071], [0109] which goes in further detail about email headers and the common IP address)
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to combine the teachings of Shraim with the
method & system of Dixon, Peram and Varghese to include the previous communication score reflecting higher fraud likelihood for consistent header formatting of the multiple previous communications from the common IP address. One would have been motivated to detect, prevent, respond to and/or otherwise deal with online fraud (Shraim, [0004]).
Dixon, Peram, Varghese and Shraim fail to explicitly disclose conduct a messaging protocol check for a server associated with the request to create a protocol score, the messaging protocol check including and the protocol score being based on one or more of the following factors - connection of the server associated with the request to the World Wide Web, firewall of the server associated with the request, relay of a domain associated with the request by the server associated with the request, response with a hostname by the server associated with the request, or connection with the server associated with the request that is outside an established connection; based on the determination of whether to accept or deny the request, generate a corresponding recommendation to the merchant to accept or deny the request from the user.
However, in an analogous art, Tomasofsky discloses conduct a messaging
protocol check for a server associated with the request to create a protocol score,
(Tomasofsky, Step 1302, describes a checking step to identify fraud feature data
associated with a payment card transaction, wherein the payment card transaction
includes a suspect consumer presenting a payment card from a digital wallet of a
Page 13 privileged cardholder; Step 1304, FIG 13, Compute a first risk score for the payment card transaction based at least in part on the fraud feature data; 1306, generate a message in the authentication protocol, the message including at least one extension field, wherein the first risk score is included within the at least one extension field; 1308, transmit the message with the first risk score included with the at least one extension field to a party associated with the payment card transaction for use during authentication of the payment card transaction; also see [0146] which describes FIG 13)
the messaging protocol check including and the protocol score being based on
one or more of the following factors (Tomasofsky, Step 1302, describes a checking step
to identify fraud feature data associated with a payment card transaction, wherein the
payment card transaction includes a suspect consumer presenting a payment card from
a digital wallet of a privileged cardholder; Step 1304, FIG 13, Compute a first risk score
for the payment card transaction based at least in part on the fraud feature data; 1306,
generate a message in the authentication protocol, the message including at least one
extension field, wherein the first risk score is included within the at least one extension
field; 1308, transmit the message with the first risk score included with the at least one
extension field to a party associated with the payment card transaction for use during
authentication of the payment card transaction; also see [0146] which describes FIG 13)
connection of the server associated with the request to the World Wide Web,
(Tomasofsky, [0133)-£0134] & Table 4 describes a connection of the server associated a VeReq request with a World Wide Web (www) domain to determine if fraud occurred)
firewall of the server associated with the request,
relay of a domain associated with the request by the server associated with the
request, response with a hostname by the server associated with the request, or
connection with the server associated with the request that is outside an established
connection;
based on the determination of whether to accept or deny the request,
(Tomasofsky, [0048] describes based on these determinations the request for
authorization will be declined [denied] or accepted)
generate a corresponding recommendation to the merchant to accept or deny the
request from the user, (Tomasofsky, [0028], [0031], [0107], [0112] describes a
recommendation to the merchant; [0048], describes a merchant to accept or decline the
request for authorization)
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to combine the teachings of Tomasofsky with the method & system of Dixon, Peram, Varghese and Shraim to include conduct a messaging protocol check for a server associated with the request to create a protocol score, the messaging protocol check including and the protocol score being based on one or more of the fallowing factors - connection of the server associated with the request to the World Wide Web, firewall of the server associated with the request, relay of a domain associated with the request by the server associated with the request, response with a hostname by the server associated with the request, or connection with the server associated with the request that is outside an established connection; based on the determination of whether to accept or deny the request, generate a corresponding recommendation to the merchant to accept or deny the request from the user. One would have been motivated to evaluate payment card transactions for fraud (Tomasofsky, [0023]).
Regarding claim 2, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the system of claim 1.
Dixon further discloses the one or more processors and/or transceivers being further individually or collectively programmed to temporarily reject an unrecognized request to create an unrecognized request score, (Dixon, [0151] describes the reputation of web content from suspicious network activity, adware activity, [unrecognized request], [0006] describes a request; [0111] describes an equation may calculate a reputation score based on values of individual elements of reputation and comparing calculated reputation values with actual events and adjusting weights in the reputation algorithm to improve the fit between the calculated values and the actual events; [0332] describes each of these dimensions of reputation may also be combined into an aggregated score)
Regarding claim 3, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the system of claim 2.
Dixon further discloses the one or more processors and/or transceivers being further individually or collectively programmed to, after temporarily rejecting the unrecognized request, allow for the reception of the unrecognized request after a sufficient delay, (Dixon, [0006] describes requests; [0151] describes the reputation of web content from suspicious network activity, adware activity, [unrecognized request], [0143] describes denying [rejecting] web content based on its reputation from a request; [0111] describes an equation may calculate a reputation score based on values of individual elements of reputation and comparing calculated reputation values with actual events and adjusting weights in the reputation algorithm to improve the fit between the
calculated values and the actual events; [0332] describes each of these dimensions of reputation may also be combined into an aggregated score; [0278] describes reputations with a threshold; [0147] describes a time period [delay for propagating reputation)
Regarding claim 4, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the system of claim 1.
Dixon further discloses the one or more processors and/or transceivers being further individually or collectively programmed to determine, within a preset period of time, activity performed on the account from which the request originates to create an activity score, wherein the weighted final score is further based at least in part on the activity score, (Dixon, [0006] describes requests; [0139] describes reputation based on requests from a specific activity; [0151] describes the reputation of web content from suspicious network activity, adware activity, [unrecognized request], [0143] describes a duration [preset period of time] and denying web content based on its reputation; [0111] describes an equation may calculate a reputation score based on values of individual elements of reputation and comparing calculated reputation values with actual events and adjusting weights in the reputation algorithm to improve the fit between the calculated values and the actual events; [0332] describes each of these dimensions of reputation may also be combined into an aggregated score)
Regarding claim 5, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the system of claim 1.
Dixon further discloses wherein the system—accepts the request if the weighted final score of the request is within a threshold of weighted final scores the merchant has configured to accept the request, or (Dixon, [0151] describes the reputation of web content [0108] describes accepting the reputation of the web content; [0006] describes a request; [0111] describes an equation may calculate a reputation score based on values of individual elements of reputation and comparing calculated reputation values with actual events and adjusting weights in the reputation algorithm to improve the fit between the calculated values and the actual events; [0332] describes each of these dimensions of reputation may also be combined into an aggregated score; [0278] describes reputations with a threshold; [0260] describes the merchant)
denies the request if the weighted final score of the request is outside a threshold of weighted final scores the merchant has configured to accept the request, (Dixon, [0151] describes the reputation of web content from suspicious network activity,
adware activity, [unrecognized request], [0143] describes denying web content based on its reputation; [0006] describes a request; [0111] describes an equation may calculate a reputation score based on values of individual elements of reputation and comparing calculated reputation values with actual events and adjusting weights in the reputation algorithm to improve the fit between the calculated values and the actual events; [0332] describes each of these dimensions of reputation may also be combined into an aggregated score; [0278] describes reputations with a threshold)
Regarding claim 6, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the system of claim 1.
Dixon further discloses the one or more processors and/or transceivers being further individually or collectively programmed to pass the decision to accept or deny the request to the merchant, (Dixon, [0150] describes allowing features associated with web content based on using a whitelist; [0151] describes the reputation of web content from suspicious network activity, adware activity, [0143] describes denying web content based on its reputation; [0111] describes an equation may calculate a reputation score based on values of individual elements of reputation and comparing calculated reputation values with actual events and adjusting weights in the reputation algorithm to improve the fit between the calculated values and the actual events; [0006] describes requests; [0332] describes each of these dimensions of reputation may also be combined into an aggregated score; [0278] describes reputations with a threshold)
Regarding claim 7, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the system of claim 1.
Dixon further discloses wherein the weighted final score is saved in a manner suited for retrieval and use in analyzing a plurality of future requests, (Dixon, [0006]
describes requests; [0143], [0332] describes storing the reputation information as an
aggregated score for later access [future requests])
Regarding claim 8, claim 8 is directed to a computer-implemented method. Claim 8 is similar in scope to claim 1 and is therefore rejected under the same rationale.
Regarding claim 9, claim 9 is directed to the computer-implemented method of claim 8. Claim 9 is similar in scope to claim 2 and is therefore rejected under the same rationale.
Regarding claim 10, claim 10 is directed to the computer-implemented method of claim 8. Claim 10 is similar in scope to claim 3 and is therefore rejected under the same rationale.
Regarding claim 11, claim 11 is directed to the computer-implemented method of claim 8. Claim 11 is similar in scope to claim 4 and is therefore rejected under the same rationale.
Regarding claim 12, Dixon, Peram, Varghese, Shraim and Tomasofsky disclose the computer-implemented method of claim 8.
Dixon further discloses the method further comprising accessing the weighted final score for a plurality of future requests, such that the method can more easily identify genuine user-merchant association, (Dixon, [0006] describes requests; [0143], [0332] describes storing the reputation information as an aggregated score for later access [future requests]; [0260] and [0388] describes verifying the reputation of the requestor which is a merchant)
Regarding claim 13, claim 13 is directed to the computer-implemented method of claim 8. Claim 13 is similar in scope to claim 6 and is therefore rejected under the same rationale.
Regarding claim 14, claim 14 is directed to a non-transitory computer-readable storage media corresponding to the system recited in claim 1. Claim 14 is similar in scope to claim 1 and is therefore rejected under the same rationale.
Regarding claim 15, claim 15 is directed to a storage media corresponding to the system recited in claim 2. Claim 15 is similar in scope to claim 2 and is therefore rejected under the same rationale.
Regarding claim 16, claim 16 is directed to a storage media corresponding to the system recited in claim 3. Claim 16 is similar in scope to claim 3 and is therefore rejected under the same rationale.
Regarding claim 17, claim 17 is directed to a storage media corresponding to the system recited in claim 4. Claim 17 is similar in scope to claim 4 and is therefore rejected under the same rationale.
Regarding claim 18, claim 18 is directed to a storage media corresponding to the system recited in claim 5. Claim 18 is similar in scope to claim 5 and is therefore rejected under the same rationale.
Regarding claim 19, claim 19 is directed to a storage media corresponding to the system recited in claim 6. Claim 19 is similar in scope to claim 6 and is therefore rejected under the same rationale.
Regarding claim 20, claim 20 is directed to a storage media corresponding to the system recited in claim 7. Claim 20 is similar in scope to claim 7 and is therefore rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES J WILCOX whose telephone number is (571)270-3774. The examiner can normally be reached M-F: 8 A.M. to 5 P.M..
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, Luu T. Pham can be reached at (571)270-5002. 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.
/JAMES J WILCOX/Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights