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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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 16-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because independent claims 16 and 17 are directed to software per se under broadest reasonable interpretation.
Claim 16 is directed to: “A trusted application…comprising computer program code…”. Claim 16 is explicitly directed to software code, which is not patent eligible subject matter.
Claim 17 is directed to: “A computerized backend resource…” No hardware components and/or structure to the “resource” is recited. Furthermore, the term “computerized backend resource” is not explicitly defined as only hardware in the specifications. Therefore, under broadest reasonable interpretation, the computerized backend resource can be software modules, programs, or applications, which are not patent eligible subject matter. Claims 18-21 are dependent on claim 17 and are similarly rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 9 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 9 recites the limitation "the lapse". There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4 and 11-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2023/0344649 to Zamani et al. (hereinafter “Zamani”).
As per claim 1: Zamani discloses: A method of preventing fraudulent use by cloning of a trusted application executable in a secure execution environment of a host device (an offline interaction system protocol that prevents double spending using trusted execution environments (TEEs) [Zamani, ¶0042]; a trusted application is implemented within a TEE of a first device [Zamani, ¶0045]), the method involving: the trusted application starting in a locked mode in which access to protected functionality and data of the trusted application is prohibited (the trusted application maintains an amount (funds) [Zamani, ¶0135]; prior to performing an action, such as withdrawing a requested amount (i.e., the trusted application is in a “locked mode”), a server computer validates a withdraw request message [Zamani, ¶0145]); the trusted application performing a handshake procedure with a computerized backend resource to verify that a current execution state of the trusted application has not already been occupied by another instance of the trusted application (the server computer receives the withdraw request message from the first user device and determine if withdraw request is valid by validating a digital signature, wherein the digital signature [Zamani, ¶0144-0146]; the signature includes an index/counter value (referred as i), that is used to track the “state” of the trusted application [Zamani, ¶0138]; specifically, the index (or counter) represents the state of the trusted application, such that a mismatch index (i.e., a state of another “instance” of the trusted application) would indicate an invalid state of the trusted application that it has already been in (“occupied”) or never been in – this prevents the double spending problem where funds may be maliciously, or unintentionally, processed multiple times due to multiple “instance[s]” of a digital wallet (the trusted application) [Zamani, ¶0124, 0250]); and only upon successful verification by the handshake procedure, the trusted application switching to an unlocked mode in which access to the protected functionality and data is permitted (after determining the withdraw request message is valid, the server computer can update the online balance, and the indexes in both the first device and the server computer are also updated [Zamani, ¶0148]).
As per claim 2: Zamani discloses all limitations of claim 1. Furthermore, Zamani discloses: wherein the computerized backend resource maintains a record of most recent execution states as reported by instances of trusted applications during previous handshake procedures, wherein the trusted application reports the current execution state to the computerized backend resource during the handshake procedure (the trusted application can maintain an internal variable (e.g., a counter or index – or “record”), which is kept in sync with the server computers variable (e.g., a counter or index) [Zamani, ¶0124]), and wherein the computerized backend resource aborts the handshake procedure if the reported current execution state is older than the most recent execution state of the trusted application according to the record maintained by the computerized backend resource (the index value i is computed in the digital signature, which is verified in the transactions, such as depositing or withdrawing funds [Zamani, ¶0138, 0146]; for example, if the withdraw request message is invalid due, the withdrawal is denied [Zamani, ¶0148] – in other words, if the index does not match, whether being a lower value (older) or higher value (in the future), the digital signature would be invalid when verified).
As per claim 3: Zamani discloses all limitations of claim 2. Furthermore, Zamani discloses: wherein the trusted application maintains a representation of its execution state, the representation being a monotonic function of execution progress, wherein the trusted application reports the current execution state to the computerized backend resource during the handshake procedure by communicating a current value of said representation, and wherein the record maintained by the computerized backend resource contains a corresponding value of said representation at said most recently reported execution state of said trusted application (trusted application can maintain an internal variable (e.g., a counter or index), which is kept in sync with the server computers variable (e.g., a counter or index) [Zamani, ¶0124] and are incremented by a predetermined amount every request (deposit or withdraw) message [Zamani, ¶0148]).
As per claim 4: Zamani discloses all limitations of claim 3. Furthermore, Zamani discloses: wherein the representation of execution state maintained by the trusted application comprises a trusted application counter value being incremented during the handshake procedure, and wherein the record maintained by the computerized backend resource comprises a corresponding backend counter value for the trusted application (trusted application can maintain an internal variable (e.g., a counter or index), which is kept in sync with the server computers variable (e.g., a counter or index) [Zamani, ¶0124] and are incremented by a predetermined amount every request (deposit or withdraw) message [Zamani, ¶0148]).
As per claim 11: Zamani discloses all limitations of claim 1. Furthermore, Zamani discloses: wherein the trusted application is a secure digital wallet for a payment application service (maintaining deposits and withdrawals by the trusted application [Zamani, ¶0135]; additionally, [Zamani, ¶0043; Fig. 3] discloses digital wallets (i.e., the trusted applications) for signing and transmitting interaction messages).
As per claim 12: Zamani discloses all limitations of claim 11. Furthermore, Zamani discloses: wherein the protected functionality and data of the trusted application comprises a balance of the secure digital wallet (depositing and/or moving funds into the trusted application [Zamani, ¶0050]; thereby establishing a balance).
As per claim 13: Zamani discloses all limitations of claim 1. Furthermore, Zamani discloses: wherein the secure execution environment is a trusted execution environment, and wherein the protected functionality and data is maintained in protected hardware resources and executable by the trusted application being in the unlocked mode and running in the trusted execution environment (a TEE can be included on a secure element, which is a cryptographically secure computer-on-a-chip to carry out functions securely [Zamani, ¶0021-0022]).
As per claim 14: Zamani discloses all limitations of claim 1. Furthermore, Zamani discloses: wherein the secure execution environment is a software-based virtual execution environment, and wherein the protected functionality and data is maintained in an encrypted virtual storage and executable by the trusted application being in the unlocked mode and running in the software-based virtual execution environment (the TEE can be a software stack stored on a read-only memory [Zamani, ¶0022]; the trusted application within the TEE includes working through cryptographic APIs and trusted storage API for encryption and secure storage capabilities, respectively [Zamani, ¶0116]).
As per claim 15: Claim 15 is different in overall scope from claim 1 but recites substantially similar subject matter as claim 1. Claim 15 is directed to a host device corresponding to the same host device recited in the method of claim 1. Thus, the response provided above for claim 1 is equally applicable to claim 15.
As per claim 16: Claim 16 is different in overall scope from claim 1 but recites substantially similar subject matter as claim 1. Claim 16 is directed to a trusted application corresponding to the same trusted application recited in the method of claim 1. Thus, the response provided above for claim 1 is equally applicable to claim 16.
As per claim 17: Claim 17 is different in overall scope from claim 1 but recites substantially similar subject matter as claim 1. Claim 17 is directed to a computerized backend resource corresponding to the same computerized backend resource recited in the method of claim 1. Thus, the response provided above for claim 1 is equally applicable to claim 17.
As per claim 18: Claim 18 incorporates all limitations of claim 17. Claim 18 is directed to a computerized backend resource corresponding to the same computerized backend resource recited in the method of claim 2. Thus, the responses provided above for claims 2 and 17 are equally applicable to claim 18.
As per claim 19: Claim 19 incorporates all limitations of claim 18. Claim 19 is directed to a computerized backend resource corresponding to the same computerized backend resource recited in the method of claim 3. Thus, the responses provided above for claims 3 and 18 are equally applicable to claim 19.
As per claim 20: Claim 20 incorporates all limitations of claim 19. Claim 20 is directed to a computerized backend resource corresponding to the same computerized backend resource recited in the method of claim 4. Thus, the responses provided above for claims 4 and 19 are equally applicable to claim 20.
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.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Zamani in view of US 2018/0330366 to Buys et al. (hereinafter, “Buys”).
As per claim 10: Zamani discloses all limitations of claim 1. Zamani does not explicitly disclose, but Buys discloses: further involving reporting unsuccessful verification of a trusted application instance to an application provider service (when a payment or authorization has failed with a purchaser, a mobile wallet provider application (corresponding to the trusted application in Zamani) will notify the system server [Buys, ¶0227]).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to implement a reporting feature for failed requests in Zamani, such as described in Buys. This modification would have enabled a system server (“application provider service”) to provide an associated reason for transaction failures to a purchaser and the merchant, such that both parties would have understood the case of failure and enact the necessary solution(s).
Allowable Subject Matter
Claims 5-8 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 9 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Claim 21 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 101 set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2023/0222209: A rewind attack on an application program within a secure enclave can be detected by comparing state information. See Abstract.
US 2022/0245237: Detecting application clones of TEE applications. See ¶0040.
US 2022/0084013: A blockchain can validate transactions to revert double spending through a user’s digital wallet. See ¶0073.
US 2020/0127850: An attestation to an application in an enclave can verify that it is a legitimate instance of the application. See ¶0025.
US 2014/0026196: The authenticity of mobile software applications can be verified and fraudulent cloned applications detected. See Abstract.
E. Zaghloul, T. Li, M. W. Mutka and J. Ren, "Bitcoin and Blockchain: Security and Privacy," in IEEE Internet of Things Journal, vol. 7, no. 10, pp. 10288-10313, Oct. 2020, doi: 10.1109/JIOT.2020.3004273. (Discloses several known types of double-spending attacks. See pg. 10297.)
T. C. Lam and V. K. Wei, "A mobile agent clone detection system with itinerary privacy," Proceedings. Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Pittsburgh, PA, USA, 2002, pp. 68-73, doi: 10.1109/ENABL.2002.1029991. (Discloses detecting unauthorized cloning of mobile agents to detect double-spending of e-cash. See Abstract.)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT B LEUNG whose telephone number is (571)270-1453. The examiner can normally be reached Mon - Thurs: 10am-7pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JUNG KIM can be reached at 571-272-3804. 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.
/ROBERT B LEUNG/Primary Examiner, Art Unit 2494