DETAILED ACTION
Status of Claims
Claims 1, 15, and 19 have been amended.
Claims 1-20 are currently pending and have been considered by the examiner.
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 .
Response to Arguments
101 Rejection:
Applicant’s arguments have been considered and have been deemed unpersuasive based upon the rationale provided in the following 101 rejection.
Prior Art Rejection:
Applicant’s arguments have been considered and are moot in view of new grounds for rejection.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claim 1-14 are directed towards a method and claims 15-20 are directed to a system/apparatus. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A method for providing account transaction control and management, the method comprising:
receiving, by communications hardware of a user device, a transaction attempt associated with a payment account of a user, wherein the payment account includes an initial transaction limit and a secondary transaction limit and wherein the initial transaction limit is defined by smart mobile wallet management circuitry of the user device;
determining, by the smart mobile wallet management circuitry of the user device, whether a transaction amount of the transaction attempt exceeds the initial transaction limit;
in response to determining the transaction amount exceeds the initial transaction limit, providing, by the communications hardware, a first limit violation notification to the user;
receiving, by the communications hardware and based on the first limit violation notification, a first limit override confirmation from the user, wherein the first limit override confirmation comprises a mobile driver’s license (mDL) associated with the user;
authenticating, by user authentication circuitry and based on the first limit override confirmation, the user based on the mDL; and
in response to successfully authenticating the user, enabling, by the smart mobile wallet management circuitry, the secondary transaction limit associated with the payment account.
Regarding Step 2A Prong One, the claims recite the abstract idea of risk mitigation. Specifically, the claims recite the limitations underlined above which recite the process of mitigating risk associated with an economic transaction which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of mitigating risk in an economic transaction. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as a “communications hardware of a user device” and “circuitry” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “communications hardware of a user device” and “circuitry” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of a “communications hardware of a user device” and “circuitry” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “communications hardware of a user device” and “circuitry” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite risk mitigation. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-14 and 16-18 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claims 2-4, 6, 8-12 and 16-18 recite additional steps which are also directed towards the recited abstract idea.
Claim 5 merely further describes the values used to detect violations when performing the recited abstract idea.
Claim 7 merely further describes the process of authenticating which is directed towards the abstract idea.
Claims 13-14 merely further describe data use to perform the recited abstract idea associated with the mDL.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
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.
Claim(s) 1-8 and 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Benkreira et al. (US 20240046272 A1) in view of Prabhakar et al. (US 20240346122 A1) in further view of Shrestha et al. (US 20240232313 A1)
Regarding Claims 1, 15, and 19, Benkreira disclsoes:
A method for providing account transaction control and management, the method comprising:
receiving, by communications hardware, a transaction attempt associated with a payment account of a user (See Benkreira: Para. [0121] – “At sequence step 730 the merchant payment system 704 can transmit a payment request to the issuer server 703 upon the user, for example, using their contactless card 701 to perform a transaction at the merchant payment system 704”), wherein the payment account includes an initial transaction limit (See Benkreira: Para. [0111] – “At step 635, the issuer server can determine a first transaction limit based on the parameters including user data and merchant data.”) and a secondary transaction limit (See Benkreira: Para. [0113] – “At step 640 the issuer server can determine a second transaction limit. The second transaction limit can be greater than the first transaction limit.”);
determining, by smart mobile wallet management circuitry, whether a transaction amount of the transaction attempt exceeds the initial transaction limit (See Benkreira: Para. [0114] – “At step 645, transactions can be processed based on any flags that are set at the time of a transaction request is submitted. Transaction requests can be transmitted from a merchant payment system when a user utilizes their payment instrument to purchase goods or services. If a flag is set for merchant associated with a payment request, a transaction request exceeding the first transaction request limit can be authorized”);
in response to determining the transaction amount exceeds the initial transaction limit, providing, by the communications hardware, a first limit violation notification to the user (See Benkreira: Para. [0100] – “At step 510, the client device can display a prompt for seeking confirmation that the user wishes to bypass a transaction limit.”);
receiving, by the communications hardware and based on the first limit violation notification, a first limit override confirmation from the user (See Benkreira: Para. [0101] – “At step 515, if the user indicates that they desire to bypass a transaction limit (such as by selecting a button displayed in the prompt associated with step 510), an application of the client device can transmit to an issuer server (associated with the contactless card) a transaction bypass request and location data”),
authenticating, by user authentication circuitry and based on the first limit override confirmation, the user (See Benkreira: Para. [0107] – “At step 625, the issuer server can set a flag associated with the selected one or more merchant. In embodiments where the user does not select a particular merchant (and instead the server identifies a particular merchant based on the location data alone), a flag associated with the merchant identified by the server can be set. The flag can indicate that a transaction limit can be exceeded for the particular merchant.”)
in response to successfully authenticating the user, enabling, by the smart mobile wallet management circuitry, the secondary transaction limit associated with the payment account (See Benkreira: Para. [0107] – “At step 625, the issuer server can set a flag associated with the selected one or more merchant. In embodiments where the user does not select a particular merchant (and instead the server identifies a particular merchant based on the location data alone), a flag associated with the merchant identified by the server can be set. The flag can indicate that a transaction limit can be exceeded for the particular merchant.”).
However, Benkreira fails to explicitly disclose:
wherein the first limit override confirmation comprises a mobile driver’s license (mDL) associated with the user; and
authenticating the user based on the mDL
However, in a similar field of endeavor, Prabhakar discloses:
An authorization element which comprises a mobile driver’s license associated with a user; and
Authenticating the user based on the mDL (See Prabhakar: Para. [0008] – “In other solutions, a user may store a digital token (for example, a PIN, password or pre-signed or pre-certified verified biometric template) on a personal device (such as a smartphone) and may transmit this digital token from the personal device to the point-of-service for identity authentication … In another example, as described in mobile driver license standard ISO/IEC 18013-5, the user presents her pre-certified verified biometric template to the point-of-service terminal from her personal smartphone using either NFC or QR code, and the terminal performs a 1:1 biometric comparison between the template and a live biometric capture to confirm the user's identity to the service such as airport access”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the generic method of user identity authentication disclosed by Behkreira for the biometric mobile driver’s license method of user identity authentication disclosed by Prabhakar yielding the predictable result of an increase in the security strength of the invention by leveraging the security benefits of biometric security, specifically it’s spoof resistant properties.
However, the combination of Behkreira and Prabhakar fails to explicitly disclose:
wherein the initial transaction limit is defined by smart mobile wallet management circuitry of the user device
However, in a similar field of endeavor, Shrestha discloses:
wherein the initial transaction limit is defined by smart mobile wallet management circuitry of the user device (See Shrestha: para. [0086] – “FIG. 9 illustrates an example of a first GUI 900 at a first user device 104 enabled for user inputs indicating a set of restrictions for a set of transactions in accordance with at least some embodiments. One or more restrictions may be input via the first GUI 900. In some embodiments, at least one of the restrictions may specify a transaction value, where the transaction value indicates the maximum value for which a payment method associated with the restriction may be used. For example, using the first GUI 900, a value of fifty dollars may be entered as the transaction value, thus, if a user attempts to use a token associated with the transaction value for a purchase that exceeds fifty dollars, the transaction may be rejected. In some embodiments, a default transaction value limit may be set, such that if a transaction value is not input via the first GUI 900, the default transaction value may still apply. For example, if a user does not input a transaction value via the first GUI 900, a default limit of $2,000 may be set as the transaction value.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the system disclosed by the combination of Benkreira and Prabhakar to allow the user to define the initial transaction limit using the smart mobile wallet management circuitry of a movile user device as disclosed by Shrestha increasing the security strength of the invention by enabling a user to personally set their risk tolerance instead of using predetermined metrics.
Regarding Claims 2 and 16, the combination discloses:
receiving, by the communications hardware, an account limitation configuration request from a user device associated with the user (See Benkreira: Para. [0111] – “At step 635, the issuer server can determine a first transaction limit based on the parameters including user data and merchant data. The first transaction limit can be a normal transaction limit which is applied to a specific user when no flag is set for a particular merchant—i.e. when no request to bypass a transaction limit has been made by the user. The first transaction limit can vary by merchant and by user. In some embodiments, the first transaction limit can be predefined, and can be determined, for example, before any transaction request is received from the client device. In other embodiments, the first transaction limit can be determined when a transaction request is received.”); and
in response to receipt of the account limitation configuration request, updating, by the smart mobile wallet management circuitry and based on the account limitation configuration request, the payment account to include the initial transaction limit and the secondary transaction limit (See Benkreira: Para. [0122] – “The predictive model can take, as an input, the user data and the merchant determined in, for example, step 620, and can determine a transaction limit based thereon.”).
Regarding Claims 3 and 17, the combination discloses:
determining, by the smart mobile wallet management circuitry, whether the transaction amount of the transaction attempt exceeds the secondary transaction limit (See Benkreira: Para. [0114] – “If a flag is set for merchant associated with a payment request, a transaction request exceeding the first transaction request limit can be authorized, but transaction having transaction amounts that exceed the second (higher) transaction limit will not be authorized.”); and
in response to determining the transaction amount of the transaction attempt does not exceed the secondary transaction limit, allowing, by the smart mobile wallet management circuitry, the transaction attempt (See Benkreira: Para. [0114] – “If a flag is set for merchant associated with a payment request, a transaction request exceeding the first transaction request limit can be authorized, but transaction having transaction amounts that exceed the second (higher) transaction limit will not be authorized.”).
Regarding Claims 4 and 18, the combination discloses:
in response to determining the transaction amount of the transaction attempt exceeds the secondary transaction limit, providing, by the communications hardware, a second limit violation notification to the user (See Benkreira: Para. [0100] – “At step 510, the client device can display a prompt for seeking confirmation that the user wishes to bypass a transaction limit.”);
receiving, by the communications hardware and based on the second limit violation notification, a second limit override confirmation from a user device (See Benkreira: Para. [0101] – “At step 515, if the user indicates that they desire to bypass a transaction limit (such as by selecting a button displayed in the prompt associated with step 510), an application of the client device can transmit to an issuer server (associated with the contactless card) a transaction bypass request and location data”); and
allowing or denying, by the smart mobile wallet management circuitry, the transaction attempt (See Benkreira: Para. [0107] – “At step 625, the issuer server can set a flag associated with the selected one or more merchant. In embodiments where the user does not select a particular merchant (and instead the server identifies a particular merchant based on the location data alone), a flag associated with the merchant identified by the server can be set. The flag can indicate that a transaction limit can be exceeded for the particular merchant.”).
Regarding Claim 5, the combination discloses:
wherein providing one or more of the first limit violation notification or the second limit violation notification further comprises causing display of the first limit violation notification or the second limit violation notification via one or more of a point-of-sale terminal associated with the transaction attempt, the user device, or a smart mobile wallet associated with the user (See Benkreira: Para. [0100] – “At step 510, the client device can display a prompt for seeking confirmation that the user wishes to bypass a transaction limit.”).
Regarding Claim 6, the combination discloses:
determining, by the smart mobile wallet management circuitry, whether the payment account is linked to a smart mobile wallet associated with the user; and in an instance in which the payment account is not linked to the smart mobile wallet: receiving, by the communications hardware, payment account data associated with the payment account from a user device, and linking, by the smart mobile wallet management circuitry and based on the payment account data, the payment account to the smart mobile wallet such that one or more transaction attempts associated with the payment account are facilitated via the smart mobile wallet (See Benkreira: Para. [0052] – “According to some embodiments, the contactless card 305 may include a virtual payment card. In those embodiments, the application 311 may retrieve information associated with the contactless card 305 by accessing a digital wallet implemented on the client device 310, wherein the digital wallet includes the virtual payment card.”).
Regarding, Claim 7, the combination disclsoes:
wherein authenticating the user further comprises authenticating, by the user authentication circuitry, the user based on a secondary authentication factor provided by a user device (See Benkreira: Para. [0107] – “At step 625, the issuer server can set a flag associated with the selected one or more merchant. In embodiments where the user does not select a particular merchant (and instead the server identifies a particular merchant based on the location data alone), a flag associated with the merchant identified by the server can be set. The flag can indicate that a transaction limit can be exceeded for the particular merchant.”).
Regarding Claim 8, the combination discloses:
receiving, by the communications hardware, a temporary account limitation override configuration request, wherein the temporary account limitation override configuration request is a request to override one or more of the initial transaction limit or the secondary transaction limit for a predetermined amount of time and comprises the mDL associated with the user (See Benkreira: Pra. [0113] – “In particular, the second transaction limit can be determined based on, for example, a certain percentage of the account value of the user. In some embodiments, a predictive model can be utilized to determine the second transaction limit. The predictive model can be trained using user data of similar users, and/or merchant data as a training set. For example, the predictive model can determine an appropriate transaction amount by considering other similarly situated users, and a higher range of transaction amount for such users.”);
authenticating, by the user authentication circuitry and based on the temporary account limitation override configuration request, the user based on the mDL associated with the user (See Prabhakar: Para. [0008] – “In other solutions, a user may store a digital token (for example, a PIN, password or pre-signed or pre-certified verified biometric template) on a personal device (such as a smartphone) and may transmit this digital token from the personal device to the point-of-service for identity authentication … In another example, as described in mobile driver license standard ISO/IEC 18013-5, the user presents her pre-certified verified biometric template to the point-of-service terminal from her personal smartphone using either NFC or QR code, and the terminal performs a 1:1 biometric comparison between the template and a live biometric capture to confirm the user's identity to the service such as airport access”); in response to authenticating the user, generating, by the smart mobile wallet management circuitry and based on the temporary account limitation override configuration request, a temporary transaction override limit, wherein the temporary transaction override limit may be higher than one or more of the initial transaction limit or the secondary transaction limit (See Benkreira: Para. [0100] –“ At step 510, the client device can display a prompt for seeking confirmation that the user wishes to bypass a transaction limit.”); and updating, by the smart mobile wallet management circuitry, the payment account with the temporary transaction override limit (See Benkreira: Para. [0122] – “The predictive model can take, as an input, the user data and the merchant determined in, for example, step 620, and can determine a transaction limit based thereon.”).
Regarding Claim 10, the combination discloses:
generating, by the smart mobile wallet management circuitry, an account limitation violation report associated with payment account; and providing, by the communications hardware, the account limitation violation report to the user (See Benkreira: Para. [0100] – “At step 510, the client device can display a prompt for seeking confirmation that the user wishes to bypass a transaction limit.”).
Regarding Claim 11, the combination discloses:
generating, by the smart mobile wallet management circuitry and based on the account limitation violation report, one or more recommendations; and providing, by the communications hardware, the one or more recommendations to the user (See Benkreira: Pra. [0015] – “The user can then readily enable the transaction limit to be exceeded by interacting with the client device which displays a selectable option for the user to exceed the transaction limit.”).
Regarding Claim 12, the combination discloses:
wherein authenticating the user based on the mDL further comprises: executing, by the user authentication circuitry and based on the first limit override confirmation, an mDL authentication request, wherein the mDL authentication request is a request to authenticate the mDL associated with the user (See Prabhakar: Para. [0022] – “The invention additionally provides a service-access-control system configured to enable secure biometric authentication at a point-of-service terminal in connection with a request for providing a service to a user.”);
generating, by mDL management circuitry and based on the mDL authentication request, a digital token (See Prabhakar: Para. [0058] – “In various embodiments, one or both of the first data block and the second data block may comprise or be derived from any data record associated with the user, such as user's biometric data or data derived from the user's biometric data, a digital token or digital key assigned to user, or some cryptographic construct derived from user specific data”);
transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL to the user (See: Prabhakar: Para. [0128] – “First communication device 102 transmits to service-access-control system 104 the SOD and the DG1 data object. Service-access-control system 104 validates the SOD using the digital signature from the issuing authority, and uses the SOD to verify the authenticity of data within the DG1 data object, and subject to successful verification, reads the hash of DG2 from the SOD, and stores it in the second data block associated with the user identified based on the data in the DG1 data object (e.g. based on the passport number, or on the name and date of birth).”);
receiving, by the communications hardware and from the IA system, an mDL validity response, wherein the mDL validity response is generated based on the digital token, and wherein the mDL validity response indicates verified credential data associated with the mDL; and
authenticating, by the user authentication circuitry, the user based on the mDL validity response (See Prabhakar: Para. [0056] – “In another embodiment, the enrolled biometric may be read from a file or received through an application programming interface (API) or from a biometric database maintained by a third party or extracted from a photo encoded as a QR code or extracted from a picture of a photo ID document (such as a driver's license or a passport) or read from an NFC chip of an ID document such as a biometric passport. In particular embodiments, biometric data may be enrolled as a valid biometric template for the purposes of performing the present invention, only after authenticating or validating the biometric data—for example, after validating an acquired biometric against a government issued photo ID, or a 3rd party ID, or after validation of the biometric by the business or service provider.”).
Regarding Claim 13, the combination discloses:
wherein the mDL authentication request comprises one or more of user identification data, desired credential data associated with the mDL, or user attribute data associated with the user (See Prakhabar: Para. [0022] – “wherein the first communication device is configured to transmit to the point-of-service terminal (a) a first data payload, wherein (1) data within the first data payload is based on the first data block, and (2) at least one of the data within the first data payload or the first data block or the second data block is associated with any of the user, the service, or the user's access to the service.”).
Regarding Claim 14, the combination discloses:
wherein the mDL validity response further indicates verified user device identification data related to a user device associated with the user (See Benkreira: Para. [0101] – “At step 515, if the user indicates that they desire to bypass a transaction limit (such as by selecting a button displayed in the prompt associated with step 510), an application of the client device can transmit to an issuer server (associated with the contactless card) a transaction bypass request and location data”).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bekreira in view of Prakhabar in further view of Shrestha and Mimassi (US 20220292516 A1).
Regarding Claim 9, the combination of Behkreira, Prakhabar, and Shrestha discloses the method of claim 8 but fails to explicitly disclose:
disabling, by the smart mobile wallet management circuitry, one or more of the initial transaction limit or the secondary transaction limit for the predetermined amount of time.
However, in a similar field of endeavor, Mimassi discloses:
disabling, by the smart mobile wallet management circuitry, one or more of the initial transaction limit or the secondary transaction limit for the predetermined amount of time (See Mimassi: para. [0081] – “a pre-authorized limit that indicates how much the a sub-account (or a bank card associated with the sub-account) may spend in total; a pre-authorized per transaction limit; a pre-authorized limit on the number of transactions that may be conducted before the sub-account/card is disabled; a rule that indicates a geographic region where a sub-account/card may be used (e.g., specific state, country, zip code, etc.); a rule that indicates which vendors and/or merchants that a sub-account may conduct business with; and a rule that indicates a specific time period (e.g., hours, days, weeks, etc.) wherein the sub-account may be pre-authorized to conduct transactions.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the transaction system disclosed by the combination of Benkreira Prakhabar, and Shrestha to include the ability to disable a transaction limit for a period of time disclosed by Mimassi yielding the predictable result of an increase in the efficiency of the invention by removing the need of processing redundant transactions.
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 NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
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, Neha Patel can be reached at 571-270-1492. 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.
/NICHOLAS K PHAN/Examiner, Art Unit 3699
Prosecution Insights