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 Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 103:
The examiner has carefully considered the Applicant's arguments filed on June 12, 2025, but finds them not persuasive.
Applicant first argues that "Scipioni discloses only a single layer of approval from a first user" and that the amended claims 1 and 8 clarify "a sequential, two-layer approval process that is neither shown nor suggested by the prior art." In response, the examiner respectfully disagrees. Scipioni explicitly teaches a sequential, two-layer approval process in paragraph [0008], which states: "In another embodiment, in response to receiving the authorization from the first user device, the second user device may be required to enter a security code before the instruction to make the payment will be sent." This directly contradicts Applicant's assertion that Scipioni only discloses a single layer of approval, as Scipioni clearly describes a scenario where both the first user's authorization and the second user's security code entry are required before payment is authorized, constituting a sequential two-layer approval process.
Secondly, Applicant argues that the amended claims recite specific technical implementation details regarding QR codes that are not disclosed in Scipioni. In response, while Scipioni uses the term "security code" rather than "QR code," the functional implementation is substantially similar. The security code in Scipioni serves the same authentication purpose as the claimed QR code. Moreover, the use of QR codes as security tokens is well-established in the art, as evidenced by Joshi (col. 5, lines 30-45) and Pinto (paragraph [0042]). The specific implementation details regarding QR code generation and transmission represent merely a predictable variation or combination of known elements in the art and are thus obvious under 35 U.S.C. 103.
Thirdly, regarding the "pre-assigned approver linked to the first user" limitation, Scipioni explicitly teaches in paragraph [0007-0008] a system for "associating a first user device and a payment account in a database" and allowing "the first user device [to] send a designation of the second user device to use the payment account." This clearly establishes the claimed relationship between users where one user is designated as an approver for transactions, which directly corresponds to the claimed "pre-assigned approver linked to the first user."
Finally, the examiner notes that the rejection is based on a combination of references (Scipioni, Joshi, Pinto, Grigg, etc.), and Applicant has not presented specific arguments regarding how the combination fails to teach the claimed elements. It is the combination of references, not just Scipioni alone, that renders the claimed invention obvious. The additional references clearly teach aspects related to QR code implementation, security verification, and multi-layer approval processes that complement the teachings of Scipioni.
Therefore, the rejections under 35 U.S.C. 103 are maintained. Since Applicant has not presented specific arguments regarding the dependent claims beyond their dependence on allegedly allowable independent claims, those rejections are likewise maintained.
DETAILED ACTION
This is a reply to the application filed on 06/12/2025, in which, claims 1-20 are pending. Claims 1, and 8 are independent. Claims 2-4, 9 and 15-20 are cancelled.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
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, 5, 6 are rejected under 35 U.S.C. 103 as being unpatentable over Scipioni et al. (US 20140006280 A1, referred to as Scipioni), in view of Joshi et al. (US 10230705 B1, referred to as Joshi) in further view of Pinto et al. (US 20160381026 A1, referred to as Pinto) and in further view of Grigg et al. (US 8195576 B1, referred to as Grigg).
In reference to Claim 1, Scipioni teaches: A method for increasing a security of sensitive customer data when processing message data, the method comprising: authorizing a first user’s login credentials on a digital secure client-access application running on the first user’s mobile device in response to authorization of login credentials associated with the user, the user being a first user; (See Scipioni [0029] and Fig 1; securely logging into a digital client-access application on a user's mobile device, where the first user launches an application requiring previously provided login credentials like a username and password to access their payment account.);
Launching a message processing application (Scipioni: [0033]-[0034] provides for second user device launching a web browser to process web pages);
When the message processing application obtains a first message (Scipioni: [0033]-[0034] provides for receiving a payment request at second user device as web page), verifying the first message (See Scipioni [0025], [0034]-[0035] reveals a method within a payment authorization system that involves verifying the recipient of a transaction) comprising:
Verifying details of a transaction included in the message data; (See Scipioni [0025], [0034]-[0035], Fig 4a, LHS provides second user receives message and verifies payment request for certain products and services)
Wherein details of a transaction include a recipient (Scipioni: [0034] provides one of the details of a transaction is the payee or merchant; [0035] any number of known information can be presented on the transaction details; It would have been obvious to one of ordinary skill in the art to include recipient for verification on the transaction details page of Scipioni to allow the second (and first) users to make an informed decision of whether to authorize the payment requests.);
Wherein the message data comprises a recipient and processing the transaction is in response to verifying the recipient (See Scipioni [0025], [0034]-[0035]; discloses method within a payment authorization system that involves verifying the recipient of a transaction.)
Receiving approval from the first user of the transaction included in the readable message data (see Scipioni [0036] and Figure 4a: the second user receives a payment request, verifies the transaction details, and inputs the phone number of the first user to approve the transaction.)
Prior to initiating the transaction, verifying a receipt of approval of the transaction from the first user’s mobile device and a receipt of approval of the transaction from the second user’s mobile device, the verifying comprising: receiving the approval, generating, in response to receipt of the first approval, a second message via the message device, the second message comprising first message data (see Scipioni [0041] and Fig 4b: sending an authorization request with payment information to the first user's device following the approval of transaction details by the second user)
Transmitting the second message to a second user for receipt of a second approval, from the second user's mobile device, of the digital secure client-access application, the second user being a pre-assigned approver linked to the first user; (see Scipioni [0030] and [0041] and Fig 2: states the verification request is based off preassigned approvers but also shows the instructions on how to become a preassigned approver.)
Prompting the second user to approve the transaction in response to the prompting, receiving the second approval of the transaction; (see Scipioni [0041] and Fig 4b: Prompts the user to approve or deny the transaction.)
Receiving approval from the second user; (see Scipioni [0044] and Figure 4d: The payment authorization system provider sends an authorization request to the first user's device. This request includes an authorization confirmation and an authorization pad (such as a pin pad) for the second user to enter a security code.)
In response to an approval of the transaction via the second user, and in response to the verifying of the first message and the approval of the transaction by the first user, initiating the transaction; (See Scipioni [0047] and Fig 4e: The payment authorization system provider sending a "purchase completed" page to the second user's device after both users have approved the transaction. This page includes details of the purchase and confirmation of its completion.)
However, Scipioni does not teach; processing a message comprises scanning a QR code. message data comprising scanning a quick-response (“QR”) code, a message processing application comprises a QR code scanner, wherein a message comprises a QR code, identifying any QR code scanner running on the mobile device, In response to the identifying, temporarily deactivating each QR code scanner running on the mobile device, in response to the deactivating, activating a secure QR code scanner, wherein a security of the QR code scanner is derived from the digital secure client-access application, when the QR code secure scanner scans a first QR code, verifying QR code data embedded in the first QR code, wherein verifying a message comprises verifying a security of a uniform resource locator (“URL”) included in the QR code data, releasing the QR code data embedded in the first QR code to the first user as readable QR code data, in response to verifying the URL, upon logging out of the digital secure client-access application on the first user’s mobile device, reactivating each deactivated identified QR code scanner.
In an analogous art, Joshi discloses message processing applications such as various QR code scanning devices on a client device, such as cameras, infrared sensors, NFC devices, and RFID readers, and notes that a client device may have multiple scanning devices like a front-facing and back-facing camera (see Joshi Col. 5 lines 66-67 and Col. 6 lines 1-8) as well as a message comprising QR code data (see Joshi Col. 11 lines 65-67 and Col. 12 lines 1-3 and Fig 5A.)
Therefore, Joshi discloses
wherein a message processing application comprises a QR code secure scanner (Joshi: Fig 2, 269; col 5, line 63 – col 6, line 23 provides for scanning application for scanning QR code messages);
Applying QR code malware filtering application to the QR code secure scanner, the QR code secure scanner being linked to a camera running on the first user’s mobile device (Joshi: Col. 1 Line 65 - Col. 2 Line 60 and Col. 5 line 63 - Col. 6 Line 40 Provides for filtering malicious QR codes and preventing exploitation through malware. It describes a scanning program that determines authenticity and prevents automatic URL launching.)
Running a temporary electronic connection from the camera to the digital secure client-access application, the temporary electronic connection rerouting each QR code to the QR code secure scanner (Joshi: Col. 5 line 63 – Col. 6 line 40 Provides for a scanning application 269 that uses a camera (scanning device 281) to scan QR codes and routes this data to a verification application 272 for security analysis. Col. 6, lines 30-33 Provides for a process of routing QR code data from the camera to a secure verification application before allowing further action.)
Scanning a first QR code via the QR code secure scanner, and prior to executing a transaction embedded in the first QR code: verifying the first QR code, (see Joshi Col. 11 lines 33-54 and Fig 5A: verification application performs authenticity checks. This includes computing a checksum of the machine-readable identifier (like a QR code) and comparing it with a verifying identifier surrounding the QR code. Additionally, the process may involve confirming that the machine-readable identifier has a signature generated by a trusted authority.)
the determining comprises:
verifying a security of a uniform resource locator (“URL”) included in the QR code data (see Joshi Col. 3 lines 59-65: internal characteristics of a machine-readable identifier may include a URI, such as a URL. This indicates a process for handling and verifying URLs within QR codes. See Joshi Col. 7 lines 24-36: discuss that if the URI is not authentic the verification application will not launch the URI and generate an alert)
when the received message is verified, releasing the QR code data embedded in the first QR code to the first user as readable QR code data for approval of the transaction (see Joshi Col. 11 lines 65-67 and Col. 12 lines 1-3 and Fig 5A: upon determining the authenticity of a machine-readable identifier, such as a QR code, the verification application then proceeds to take an action corresponding to the instructions encoded in the QR code);
when the first QR code is not verified; transmitting an instruction to the processor of a failure to validate; and in response to the instruction, displaying an alert message on a user interface (UI) of the mobile device (Joshi: Col. 12 lines 43-60 and Fig 5A Provides for a clear response in the event of a QR code not being verified, specifically the generation of an alert message.)
Joshi teaches wherein the application is a QR code scanner. Joshi discloses message processing applications such as various QR code scanning devices on a client device, such as cameras, infrared sensors, NFC devices, and RFID readers, and notes that a client device may have multiple scanning devices like a front-facing and back-facing camera (see Joshi Col. 5 lines 66-67 and Col. 6 lines 1-8)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni, which include effectuating a financial transaction via typical web-based or application-based messaging involving a payee, a first user, and an approver of the transaction, with the teachings of Joshi, which include utilizing QR codes as messages for communicating information and further verify the legitimacy of the data encoded within the QR code messages. One of ordinary skill in the art would recognize the ability to replace normal web-based communications with QR-code based communications and incorporate QR code scanning as a means of passing messages and information, and further verifying the legitimacy of encoded QR code data. One of ordinary skill in the art would be motivated to make this replacement in order to reduce risk of exposure of financial information to the Internet. The modification would allow users in Scipioni to use low energy and localized communications (NFC, etc.) or using a camera to take a picture of a QR code, thus reducing the potential audience of the communication (i.e., traversing the Internet).
However, Scipioni in view of Joshi does not teach identifying any application running on the mobile device, In response to the identifying, temporarily deactivating each applications running on the mobile device, in response to the deactivating, activating a application, wherein a security of the application is derived from the digital secure client-access application, reactivating each deactivated identified application.
In response to an initiation state, identifying any unknown applications running on the mobile device; (see Pinto [0042] and Fig 1: describes a scenario where, upon enabling "secure mode," the operating system kernel conducts a search for all processes and applications currently running on the operating system)
In response to the identifying, temporarily deactivating each unknown application running on the mobile device; (see Pinto [0043] and Fig 1: once the operating system kernel identifies all running processes and applications in "secure mode," it then suspends all those deemed unnecessary or not configured for operation in this mode)
In response to the deactivating, activating a secure application, wherein a security of the secure application is derived from the digital secure client-access application (see Pinto [0049]-[0050] and Fig 1: after deactivating applications not permitted in secure mode, the operating system kernel grants access and privileges to the protected applications that are allowed in this mode)
Upon disabling of the digital secure client-access application, reactivating each deactivated identified unknown application (see Pinto [0050] Pinto describes a process where, upon disabling "secure mode," the operating system kernel reactivates all processes and applications that were previously halted or suspended during the secure mode, wherein the unknown application is the many QR code scanners taught by Joshi).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni in view of Joshi, which disclose a financial transaction requiring approvers and utilizing QR code messages and scanning, with the teachings of Pinto, who discloses running financial applications in a ‘secure mode’, which requires suspending or terminating non-privileged processes. One of ordinary skill in the art would recognize the ability to incorporate Pinto’s secure mode feature in a financial transaction system such as Scipioni/Joshi’s. One of ordinary skill in the art would be motivated to make such an incorporation because it would ensure no malicious processes would have access to the QR code scanning applications or financial transaction details.
However, Scipioni in view of Joshi in further view of Pinto does not teach
wherein an initiation state comprises logging into an application
wherein a user logging out disables further processing of a secure client-access application In an analogous art.
However, Grigg discloses
wherein an initiation state comprises logging into an application (Grigg: Fig 3, 308->310->316; col 11, line 55 – col 12, line 34 provides for user logging in triggering the initiation of transaction workflow processing);
wherein a user logging out disables further processing of a secure client-access application (see Grigg Col 16. Lines 30-60, and Fig 6 reference point 610), which prevents further workflow processing of a financial application (Fig 3, item 314; col 11, line 55 – col 12, line 34).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni in view of Joshi in further view of Pinto, as discussed above, and in further view of Grigg, which discusses performing actions based on whether the user can authenticate (i.e., logged in) or has logged out. One of ordinary skill in the art would recognize the ability of triggering entering of ‘secure mode’ (and subsequently initiating a financial transaction workflow) based on a user logged into a financial application; and further a user logging out and exiting a secure financial application as a trigger for exiting a ‘secure mode’. One of ordinary skill in the art would be motivated to do this because logging in and out of the protected financial application is a clear indicator of the user’s intent to access (or stop accessing) protected information.
In reference to claim 5, "The method of claim 1 wherein when the first QR code is not verified, the method further comprises disabling access to any one or more URL links included in the QR code data," Scipioni in view of Joshi and in further view of Pinto disclose the method of claim 1. Joshi further teaches: "Further, the scanning program may prevent automatically launching the URL and may generate an alert. Here, the display of the mobile device 112 informs the user 103 that the code is not authentic. Accordingly, the user 103 then avoids accessing the fraudulent URL or providing private information." (see Joshi Col. 12 lines 43-60 and Fig 5A). This teaching is analogous to the claim as it describes a process where, upon detecting that a QR code is not authentic, the application prevents the automatic launch of any URL embedded in the QR code. This directly aligns with the claim’s requirement of disabling access to URLs in unverified QR codes. Joshi’s approach ensures security by preventing users from accessing potentially fraudulent or harmful links, which is a key aspect of the security measures outlined in the claim.
In reference to claim 6, "The method of claim 1 wherein when the first QR code is not verified, the method further comprises terminating the generating of the second QR code," Scipioni in view of Joshi and in further view of Pinto disclose the method of claim 1, which involves the use of QR code validation. Scipioni further teaches: “Furthermore, if the first user does not wish to authorize the payment request by the second user, the first user may select the deny button 402 c to send a deny authorization instruction over the network to the payment authorization system provider device, and the payment authorization system provider device will deny the payment request such that the second user cannot use the payment account to purchase the items.” (See Scipioni [0041]). This teaching is analogous to the claim as it describes a scenario where the process of generating a follow-up action (in this case, a second QR code) is terminated based on the first user's denial of the transaction.
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 8, 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over Scipioni et al. (US 20140006280 A1, referred to as Scipioni), in view of Joshi et al. (US 10230705 B1, referred to as Joshi) and in further view of Pinto et al. (US 20160381026 A1, referred to as Pinto).
In reference to claim 8, Scipioni teaches: A system for increasing a security of sensitive customer data when processing message data, the system implemented within a secure digital client-access platform, the system comprising; (See Scipioni [0029] and Fig 1; discloses a digital client-access application on a user's mobile device).
Authorization of a first user’s login credentials to the secure digital client-access platform; (See Scipioni [0029] and Fig 1; securely logging into a digital client-access application on a user's mobile device, where the first user launches an application requiring previously provided login credentials like a username and password to access their payment account.)
Receive approval from the first user of a transaction included in the readable message data (see Scipioni [0036] and Figure 4a: the second user receives a payment request, verifies the transaction details, and inputs the phone number of the first user to approve the transaction.)
Prior to initiating the transaction, verifying a receipt of approval of the transaction from the first user’s mobile device and a receipt of approval of the transaction from the second user’s mobile device, the verifying comprising: In response to a receipt of an approval of the transaction, generate a second message via the messaging device, the second message comprising message data embedded in the first message” (see Scipioni [0041] and Fig 4b: sending an authorization request with payment information to the first user's device following the approval of transaction details.)
Transmit the second message to a second user’s mobile device, the second user’s mobile device using the digital secure client-access application, the second user being a pre-assigned approver linked to the first user; (see Scipioni [0030] and [0041] and Fig 2: states the verification request is based off preassigned approvers but also shows the instructions on how to become a preassigned approver.)
And a second processor running on a mobile device of the second user configured to: receive a prompt inputted by the second user to approve the transaction; (see Scipioni [0041] and Fig 4b: Prompts the user to approve or deny the transaction.)
In response toa receipt of an approval by the second user of the transaction included in the second message;” (see Scipioni [0044] and Figure 4d: The payment authorization system provider sends an authorization request to the second user's device. This request includes an authorization confirmation and an authorization pad (such as a pin pad) for the second user to enter a security code.)
and in response to the verifying of the first message, the approval of the transaction by the first user, and the approval of the transaction by the second user, initiate the transaction (See Scipioni [0047] and Fig 4e: The payment authorization system provider sending a "purchase completed" page to the second user's device after both users have approved the transaction. This page includes details of the purchase and confirmation of its completion.)
However, Scipioni does not teach; processing a message comprises scanning a QR code. message data comprising scanning a quick-response (“QR”) code, a message processing application comprises a QR code scanner, wherein a message comprises a QR code, identifying any QR code scanner running on the mobile device, In response to the identifying, temporarily deactivating each QR code scanner running on the mobile device, in response to the deactivating, activating a secure QR code scanner, wherein a security of the QR code scanner is derived from the digital secure client-access application, when the QR code secure scanner scans a first QR code, verifying QR code data embedded in the first QR code, verifying a security of a uniform resource locator (“URL”) included in the QR code data, releasing the QR code data embedded in the first QR code to the first user as readable QR code data, in response to verifying the URL, upon logging out of the digital secure client-access application on the first user’s mobile device, reactivating each deactivated identified QR code scanner.
In an analogous art, Joshi discloses message processing applications such as various QR code scanning devices on a client device, such as cameras, infrared sensors, NFC devices, and RFID readers, and notes that a client device may have multiple scanning devices like a front-facing and back-facing camera (see Joshi Col. 5 lines 66-67 and Col. 6 lines 1-8) as well as a message comprising QR code data (see Joshi Col. 11 lines 65-67 and Col. 12 lines 1-3 and Fig 5A.)
Therefore, Joshi discloses
wherein a message processing application comprises a QR code secure scanner (Joshi: Fig 2, 269; col 5, line 63 – col 6, line 23 provides for scanning application for scanning QR code messages);
Apply QR code malware filtering application to the QR code secure scanner, the QR code secure scanner being linked to a camera running on the mobile device (Joshi: Col. 1 Line 65 - Col. 2 Line 60 and Col. 5 line 63 - Col. 6 Line 40 Provides for filtering malicious QR codes and preventing exploitation through malware. It describes a scanning program that determines authenticity and prevents automatic URL launching.)
Running a temporary electronic connection from the camera to the digital secure client-access application (Joshi: Col. 5 line 63 – Col. 6 line 40 Provides for a scanning application 269 that uses a camera (scanning device 281) to scan QR codes and routes this data to a verification application 272 for security analysis.)
Scanning a first QR code via the QR code secure scanner, and prior to executing a transaction embedded in the first QR code: verifying the first QR code, (see Joshi Col. 11 lines 33-54 and Fig 5A: verification application performs authenticity checks. This includes computing a checksum of the machine-readable identifier (like a QR code) and comparing it with a verifying identifier surrounding the QR code. Additionally, the process may involve confirming that the machine-readable identifier has a signature generated by a trusted authority.)
the determining comprises:
verifying a security of a uniform resource locator (“URL”) included in the QR code data (see Joshi Col. 3 lines 59-65: internal characteristics of a machine-readable identifier may include a URI, such as a URL. This indicates a process for handling and verifying URLs within QR codes. See Joshi Col. 7 lines 24-36: discuss that if the URI is not authentic the verification application will not launch the URI and generate an alert)
when the received message is verified, releasing the QR code data embedded in the first QR code to the first user as readable QR code data for approval of the transaction (see Joshi Col. 11 lines 65-67 and Col. 12 lines 1-3 and Fig 5A: upon determining the authenticity of a machine-readable identifier, such as a QR code, the verification application then proceeds to take an action corresponding to the instructions encoded in the QR code);
when the first QR code is not verified; transmitting an instruction to the processor of a failure to validate; and in response to the instruction, displaying an alert message on a user interface (UI) of the mobile device (Joshi: Col. 12 lines 43-60 and Fig 5A Provides for a clear response in the event of a QR code not being verified, specifically the generation of an alert message.)
Joshi teaches wherein the application is a QR code scanner. Joshi discloses message processing applications such as various QR code scanning devices on a client device, such as cameras, infrared sensors, NFC devices, and RFID readers, and notes that a client device may have multiple scanning devices like a front-facing and back-facing camera (see Joshi Col. 5 lines 66-67 and Col. 6 lines 1-8)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni in view of Joshi to incorporate QR code scanning as a means of verifying transaction details and recipients. Joshi’s detailed disclosure of various message processing applications including QR code scanners, and the process of verifying QR code data and URL security, provides a clear technological pathway for enhancing Scipioni’s payment authorization system. This modification would streamline the verification process in Scipioni’s system, leveraging Joshi’s efficient and secure method of QR code scanning and data verification.
However, Scipioni in view of Joshi does not teach identifying any application running on the mobile device, In response to the identifying, temporarily deactivating each applications running on the mobile device, in response to the deactivating, activating a application, wherein a security of the application is derived from the digital secure client-access application.
Pinto describes a process where, upon disabling "secure mode," the operating system kernel reactivates all processes and applications that were previously halted or suspended during the secure mode (see Pinto [0050]).
Therefore, Pinto teaches the rest of the claim language “,a first processor running on the mobile device is configured to, in response to an authorization of the first user’s login credentials: identify the default application running on the mobile device;” (see Pinto [0042] and Fig 1: describes a scenario where, upon enabling "secure mode," the operating system kernel conducts a search for all processes and applications currently running on the operating system. Wherein the application is one of the QR code scanners taught by Joshi)
In response to the identifying, temporarily deactivate the default application running on the mobile device; (see Pinto [0043] and Fig 1: once the operating system kernel identifies all running processes and applications in "secure mode," it then suspends all those deemed unnecessary or not configured for operation in this mode. Wherein the application is one of the QR code scanners taught by Joshi)
And in response to the deactivating, activate the secure application, a security of the secure application derived from the secure digital client-access platform; (see Pinto [0049] and Fig 1: after deactivating applications not permitted in secure mode, the operating system kernel grants access and privileges to the protected applications that are allowed in this mode. Wherein the application is one of the QR code scanners taught by Joshi)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni in view of Joshi in further view of Pinto in order to integrate a secure operating mode within a digital client-access application that enhances the security and functionality of QR code scanning and transaction processes.
In reference to claim 10, "The system of claim 8 wherein when the first QR code is not verified, the processor is further configured to disable access to a URL link included in the QR code data.” Scipioni in view of Joshi and in further view of Pinto disclose the method of claim 8. Joshi further teaches: "Further, the scanning program may prevent automatically launching the URL and may generate an alert. Here, the display of the mobile device 112 informs the user 103 that the code is not authentic. Accordingly, the user 103 then avoids accessing the fraudulent URL or providing private information." (see Joshi Col. 12 lines 43-60 and Fig 5A). This teaching is analogous to the claim as it describes a process where, upon detecting that a QR code is not authentic, the application prevents the automatic launch of any URL embedded in the QR code. This directly aligns with the claim’s requirement of disabling access to URLs in unverified QR codes. Joshi’s approach ensures security by preventing users from accessing potentially fraudulent or harmful links, which is a key aspect of the security measures outlined in the claim.
In reference to claim 11, "The system of claim 8 wherein when the first QR code is not verified, the processor is further configured to terminate the generating of the second QR code." Scipioni in view of Joshi and in further view of Pinto disclose the method of claim 1, which involves the use of QR code validation. Scipioni further teaches: “Furthermore, if the first user does not wish to authorize the payment request by the second user, the first user may select the deny button 402 c to send a deny authorization instruction over the network to the payment authorization system provider device, and the payment authorization system provider device will deny the payment request such that the second user cannot use the payment account to purchase the items.” (See Scipioni [0041]). This teaching is analogous to the claim as it describes a scenario where the process of generating a follow-up action (in this case, a second QR code) is terminated based on the first user's denial of the transaction.
In reference to claim 12, "The system of claim 8 wherein the prompt inputted by the second user is one of a tap of a finger, swipe of the finger, and a voice input," Scipioni in view of Joshi and in further view of Pinto disclose the method of claim 8. Scipioni further teaches: “Furthermore, the payment authorization system provider device also provides, over the network to the first user device 200, an authorization request 402 that includes payment request information 402 a, along with an authorize button 402 b and a deny button 402 c. In an embodiment, the authorization request 402 may be provided by a text message, a pop-up window, an alert in an application, a web page, and/or in a variety of other manners known in the art.” (see Scipioni [0041]). This teaching is analogous to the claim as it describes a user interaction mechanism involving an authorize or deny button, which would typically be activated by a tap of the finger. Scipioni also references to "other manners known in the art" which could encompass swipes and voice commands.
In reference to claim 13, "The system of claim 8 wherein the digital secure client access platform includes a secure database storing sensitive data," Scipioni in view of Joshi and in further view of Pinto disclose the method of claim 8. Scipioni further teaches: “Upon receiving the payment request, the payment authorization system provider device will either retrieve, over the network from the first user device 200, or look up in a database, an IP address of the first user device 200. The payment authorization system provider device may then compare the IP address of the first user device 200 to the IP address of the second user device 300 to determine whether the payment request is being received from a user device that is not the first user device 200.” (see Scipioni [0038]). This teaching is analogous to the claim as it clearly indicates the use of a database within the digital secure client access platform. The database stores sensitive information, such as IP addresses, to ensure secure transactions, reflecting the secure database storage of sensitive data as mentioned in the claim.
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 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Scipioni et al. (US 20140006280 A1, referred to as Scipioni), in view of Joshi et al. (US 10230705 B1, referred to as Joshi) in further view of Pinto et al. (US 20160381026 A1, referred to as Pinto), in further view of Grigg et al. (US 8195576 B1, referred to as Grigg) in further view of Dogu et al. (US 20210168172 A1, referred to as Dogu), and in further view of Dotan (US 8850428 B2, referred to as Dotan).
In reference to claim 7, “The method of claim 1 wherein when in response to the releasing of the QR code data, a URL is determined to be malicious, the method comprises automatically logging out the user from the digital secure client-access application thereby protecting sensitive data of the first user stored in the digital secure client-access application,” Scipioni in view of Joshi, in further view of Pinto and in further view of Grigg discloses the method of claim 1 including upon determining the authenticity of a machine-readable identifier, such as a QR code, the verification application then proceeds to take an action corresponding to the instructions encoded in the QR code (see Joshi Col. 11 lines 65-67 and Col. 12 lines 1-3 and Fig 5A) and including logging in and out of an application (see Grigg Col. 16 lines 30-60 and Fig.6 reference point 610).
However, Scipioni in view of Joshi in further view of Pinto and in further view of Grigg does not explicitly disclose detecting a URL as malicious after releasing QR code data and automatically logging out the user as a remedial action, however, Dogu teaches:
Dogu discloses a method of detecting falsification and storing the access source URL as a malicious URL in the database, Dogu teaches If a URL is already categorized as benign URL, the category can be dynamically changed to malicious URL (see Dogu [0056]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni in view of Joshi in further view of Pinto, in further view of Grigg and in even further view of Dogu to include detection of malicious URLs after QR code data is released, this combination would further increase the likelihood of determining malicious URLs even after it has been released to a user.
However, Scipioni in view of Joshi in further view of Pinto, in further view of Grigg and in further view of Dogu does not explicitly disclose a specific remedial action to be performed after a URL is malicious, however, Dotan teaches:
Dotan discloses a method of transitioning to a virtualized environment as a security measure upon accessing non-trusted URLs, thus denying access to anything running outside the sandbox (see Dotan col. 10, line 26 to col. 11, line 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Scipioni in view of Joshi in further view of Pinto, in further view of Grigg, in further view of Dogu and in even further view of Dotan to implement logging off as taught by Grigg to be an automated remedial action taught by Dotan. Integrating an automatic security measure as a response to malicious URL detection aligns with standard practices in digital security which would thus enhance over safety of an application.
In reference to claim 14, “The system of claim 8 wherein when in response to the releasing of the QR code data, the processor determines that a URL is malicious, the processor is configured to automatically log out the user from the digital secure client-access platform thereby protecting the first user's sensitive data stored in a secure database within the digital secure client-access platform,” Scipioni in view of Joshi, and in further view of Pinto discloses the method of claim 8 including upon determining the authenticity of a machine-readable identifier, such as a QR code, the verification application then proceeds to take an action corresponding to the instructions encoded in the QR code (see Joshi Col. 11 lines 65-67 and Col. 12 lines 1-3 and Fig 5A).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Applicant’s amendment necessitated the new ground(s) of rejection presented in this office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 AIDAN EDWARD SHAUGHNESSY whose telephone number is (703)756-1423. The examiner can normally be reached on Monday-Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson, can be reached at telephone number (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/usptoautomated-interview-request-air-form.
/A.E.S./Examiner, Art Unit 2432
/SYED A ZAIDI/Primary Examiner, Art Unit 2432