DETAILED ACTION
This Action is responsive to the Amendments filed on 11/17/2025.
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 .
Claim Status
Claims 1-8, 10-17, and 19-20 are amended. Claims 9 and 18 are cancelled. Claims 1-8, 10-17, and 19-20 are pending and have been examined.
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.
Claims 1-8 and 10-11 are 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.
Regarding Claim 1,
Claim 1 recites “the customer” in the 9th line without providing proper antecedent basis. Therefore, the scope of Claim 1 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). Examiner recommends amending Claim 1, 9th line instead to read “a customer” in order to overcome this rejection.
Claims 2-8 and 10-11 depend on Claim 1 and are therefore similarly rejected under 35 U.S.C. 112(b).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 6, 10-13, 15, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Slensker et. al (US 20220139175 A1)(cited by examiner in previous Action)(hereafter referred to as Slensker) further in view of Arora et al. (US 20200005263 A1)(cited by examiner in previous Action)(hereafter referred to as Arora) and Lu et al. (US 20230104923 A1)(hereafter referred to as Lu).
Regarding Claim 1,
Slensker discloses the following limitations:
A method for identifying and monitoring memory storage on a third-party transactional device (System 100, Fig. 1), wherein each of the foregoing steps are performed by a computing device (Monitoring Device 122, Fig. 3) comprising at least one processor (Processor 302, Fig. 3), a communication interface (Network Interface 304, Fig. 3), and memory (Memory 306, Fig. 3), comprising the steps of:
… a financial institution controlled software (Monitoring Device Instructions 308, Fig. 3) on a third-party transactional device (System 100, Fig. 1 // “an ATM” [0015])(“the one or more processors are configured to execute instructions (monitoring device instructions 308) to implement the monitoring device 122. In this way, processor 302 may be a special-purpose computer designed to implement the functions disclosed herein of the monitoring device 122.” [0057] // “The motherboard may be installed in an ATM” [0015]) – Examiner considers the monitoring device instructions 308 which execute on a monitoring device 122 installed within an ATM as “a financial institution controlled software” which executes on “a third-party transactional device”--;
identifying (step 204, Fig. 2) third-party … hardware (“peripheral devices” [0015]) on the third-party transactional device (“The method 200 may be performed by the monitoring device 122 shown in FIG. 1. Example method 200 begins at step 202, where the monitoring device monitors a voltage associated with a peripheral device … At step 204, the monitoring device checks if the monitored voltage across a peripheral device matches an expected voltage profile of the peripheral device. The monitoring device has access to an expected voltage profile for each of the devices on the motherboard 102 or peripheral devices connected to the motherboard 102.” [0038-40]) – As shown in Fig. 2, during step 204, monitoring device 122 compares the measured voltage of a particular peripheral device to an “expected voltage profile” associated with the peripheral device. As clarified in ¶0040, the monitoring device has access to an expected voltage profile for each (e.g., of three; see Fig. 1) peripheral device which is connected to the system motherboard. One of ordinary skill in the art would accordingly understand that comparing a measured voltage to a particular (e.g., one of three) expected voltage profile necessarily requires the monitoring device to understand which (e.g., out of the three) peripheral device is being measured. Accordingly, examiner considers step 204 of Fig. 2 as at least “identifying” “hardware” in a third-party transactional device--, …
coupling the financial institution controlled software with the third-party memory storage hardware (Fig. 1 // “As shown, the monitoring device 122 may be implemented as a PCI card that can be inserted into a PCI slot 108 on the motherboard 102 … The monitoring device 122 is connected to the motherboard bus 104 and is capable of measuring voltages across … peripheral devices connected to the motherboard 102.” [0021]) – As shown in Fig. 1 and as detailed in ¶0021, monitoring device 122 is connected to motherboard bus 104 (e.g., via PCI slots 108) and is capable of measuring voltages across each peripheral device connected to motherboard bus 104. In this case, examiner considers physically connecting a monitoring device 122 comprising monitoring software instructions 308 to a motherboard bus 104 including multiple peripheral devices as “coupling” the software with the peripheral devices (i.e., enabling interaction between the software and the peripheral devices)--;
…
monitoring (steps 204 + 218, Fig. 2) the third-party … hardware on the third-party transactional device (“At step 204, the monitoring device checks if the monitored voltage across a peripheral device matches an expected voltage profile of the peripheral device … If the monitored voltage of a peripheral device matches with the expected voltage profile of the device, the method 200 proceeds back to step 202 where the monitoring device continues to monitor the voltage across the peripheral device. On the other hand, if the monitored voltage of the peripheral device fails to match the expected voltage profile of the peripheral device, the method 200 proceeds” [0040-41] // “In response, the monitoring device determines (at process block 218) that an unauthorized activity related to the ATM has occurred.” [0052] // Fig. 2 // ¶¶0038-53) – As shown in Fig. 2, comparing the measured voltage of a peripheral device to the expected voltage profile for the peripheral device enables the monitoring device to either determine that the peripheral device is operating as expected (see step 204 ‘Yes’) or is operating in an “unauthorized” manner (see steps 204 ‘No’ + 218). Accordingly, examiner considers Fig. 2 as a “monitoring” process of the “hardware” in the third-party transaction device—
generating an alert and sending the alert to a financial institution of a customer (“the monitoring device 122 to wirelessly transmit an alert and/or information relating to an ATM attack to concerned authorities” [0036]) – As taught in ¶0036, an alert is generated and is wirelessly transmit to “concerned authorities”. One of ordinary skill in the art would understand that the “concerned authorities” would be associated with the ATM being attacked (i.e., with “a financial institution of a customer”).
Although Slensker Fig. 1 shows a memory device 114 connected to motherboard 102; and ¶0040 discloses that expected voltage profiles for both “devices on the motherboard” and “peripheral devices connected to the motherboard” are accessible by monitoring device 122, Slensker does not appear to explicitly disclose a “memory storage” type of peripheral device which would be monitored as depicted in Fig. 2. Specifically, Slensker does not explicitly disclose the following limitations:
identifying a financial institution controlled software on a third-party transactional device;
identifying third-party memory storage hardware …
wherein the third-party memory storage hardware comprises customer data, and wherein the customer is a member of the financial institution;
identifying customer data stored on the third-party memory storage hardware;
extracting and encrypting the customer data stored on the third-party memory storage hardware;
establishing a communication channel between a server of the financial institution and the third-party memory storage hardware;
transmitting encrypted customer data to the server of the financial institution
monitoring … the customer data
However, Arora discloses the following limitations:
identifying (Fig. 2, step 220) a financial institution controlled software (ATM Management Service 124, Fig. 1) on a third-party transactional device (Self-Service Transaction Device 110, Fig. 1)(“In some cases, the processor of the ATM 110 may process instructions stored in the memory 114 to process an ATM authentication Engine 120 to control an ATM management service 124” [0025] // “At 220, … the ATM 110 may initiate the ATM management service 124 to fetch the user identifier” [0039]) – In this case, examiner considers ATM management service 124 included within an ATM Authentication Engine 120 of Self-Service Transaction Device 110, as depicted in Arora Fig. 1, as analogous to Monitoring Device Instructions 308 included within a Monitoring Device 122 of an ATM, as depicted in Slensker Fig. 3 (i.e., “a financial institution controlled software”) because both are a software installed onto an ATM which serves a purpose of authorizing interactions with the ATM. As shown in Arora Fig. 2 and detailed in ¶0039, after a user swipes a card on an ATM, during step 220, the ATM initiates the ATM management service 124. Examiner considers initiating an ATM management service after a user swipes a card at an ATM as at least “identifying” (e.g., initiating or invoking) the ATM management service—
identifying third-party memory storage hardware (Memory 122, Fig. 3) -- In this case, examiner considers the Self-Service Transaction Device 110 which comprises both a memory module 114 and a memory module 122, as depicted in Arora Fig. 1, as analogous to system 100 which comprises both a memory module 114 and peripheral devices, as depicted in Slensker Fig. 1. Accordingly, examiner considers memory module 122 of Arora as analogous to a peripheral device identified and monitored by monitoring device 122 of Slensker (i.e., “third-party memory storage hardware”)—
wherein the third-party memory storage hardware comprises customer data (“In some cases, one or more data structures may be used to store authentication information, image data and/or associated metadata and the like. For example, the memory device 122 may be used to store data captured locally at the ATM 110, such as a user image 128 … Additionally, metadata associated with the image may be stored in the memory 122, such as date information, time information, location information, and/or user data and the like” [0030]) – As detailed in ¶0030, a memory device 122 located within self-service transaction device 110 stores “user data” associated with users of an ATM., and
wherein the customer (User 105, Fig. 3) is a member of the financial institution(“allowing the user 105 to perform one or more actions on the ATM 110, such as providing access to an account held at an associated financial institution” [0025] // “a financial institution associated with the ATM and/or with an account associated with the user” [0037]) – As taught in ¶0025, users 105 of the self-service transactional device 110 hold accounts associated with a financial institution.—
identifying (Fig. 2, step 230) customer data (User Image 128, Fig. 1) stored on the third-party memory storage hardware (“At 230, the ATM 110 may initiate a camera … to capture an image 128 of the user’s face … The user image 128 may be stored in local memory 122 of the ATM” [0039]);
extracting and encrypting (Fig. 2, step 240 // “encrypted communication” [0040]) the customer data (“encrypted communications” [0037]) stored on the third-party memory storage hardware;
establishing (Fig. 2, step 240 // “coordinate secure and/or encrypted communication” [0040]) a communication channel (“secure communication channels” [0037]) between a server (Authentication Server 130, Fig. 1) of the financial institution and the third-party memory storage hardware;
transmitting (Fig. 2, step 240) encrypted customer data to the server of the financial institution (“At 240, the ATM 110 may invoke the authentication server … to authenticate the user … The ATM management service may coordinate secure and/or encrypted communication between the ATM 110 and the authentication server 130 to communicate user identification information obtained from the card data and the user image 128 to the authentication server 130 to authenticate the user” [0040] // “The authentication server may be communicatively coupled to one or more communication networks to securely communicate authentication information to and from a requesting device, such as via encrypted communications, secure communication channels, and the like” [0037]) – As shown in Fig. 2 and detailed in ¶0040, after a user image 128 is stored in memory module 122 (e.g., during step 230), the ATM management service “coordinate[s] secure and/or encrypted communication” between the ATM and an authentication server 130 so that user image data 128 can be authenticated. As clarified in ¶0037, communications between the ATM and the authentication server 130 are both “encrypted” and take place over “secure communication channels”. One of ordinary skill in the art would accordingly understand that user image data 128 transmitted to authentication server 130 over secure and encrypted communication channels would necessarily be encrypted as part of “encrypted communications” between the ATM and the authentication server.--
monitoring … the customer data (“The user image 128 .. may be communicated wholly or in part to the authentication server 130 for comparison to stored user facial biometric data as at least a portion of the user authentication process” [0039]) – As disclosed in ¶0039, user image data 128 is transmit to authentication server 130 so that the authentication server 130 can compare the image data to stored user facial biometric data. Accordingly, examiner considers transmitting the user image 128 for authentication by an authentication server 130 as “monitoring” (e.g., ensuring the authenticity of) the user image.
Slensker and Arora are considered analogous to the claimed invention because they all relate to the same field of identifying and mitigating unauthorized activity performed on ATM devices. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker with the teachings of Arora and realize a third-party transactional device which includes memory storage hardware comprising customer data. Including memory storage hardware within a third-party transactional device would be expected to improve the security, accuracy of identification, and confidence in user transactions performed on the transactional device by increasing a number of transaction authentication options available to the transactional device, as disclosed in Arora ¶¶0021 // 0039: “In many cases, a currently existing ATM may be limited by one or more existing standards in use when installed and/or upgraded … Recent developments have increased a number of authentication options available, such as facial biometric capture at an ATM, facial biometric compare at an authentication server that may be remote or local to the ATM … and the like. In some cases, one or more authentication methods may be used together to allow for increased security, accuracy of identification, and confidence that the correct user is accessing their own accounts.” [0021] // “The user image 128 may be stored in local memory 122 of the ATM for comparison locally” [0039]
Slensker and Arora are silent regarding purging monitored customer data. Specifically, the combined teachings of Slensker and Arora do not explicitly disclose the following limitations:
wherein the financial institution purges the customer data stored on the identified memory storage hardware in the third-party transactional device
However, Lu discloses the following limitations:
wherein the financial institution (¶0038) purges (Fig. 3, step 308) the customer data (“sense information” [0047]) stored on the identified memory storage hardware (Data generation device 110, Fig. 1) in the third-party transactional device (Gateway 100, Fig. 1)(“Gateway 100 receives sense information transmitted by one or more data generation devices … A data generation device can also be a data storage device and the sense information is the data in the data storage device.” [0047] // “Tamper switch 104 is configured to sense tampering … of gateway 100 … tampering may be interfering with the transmission of data between the data generation device to the gateway” [0051] // “At 308, the gateway is placed in a secure state in response to receiving the alert signal … any combination of the following actions may be taken: … 3) remove sense previously-stored information from the memory of the gateway … 6) delete and overwrite all information” [0060-62] // ¶0049) – As shown in Lu Fig. 1 and taught in ¶¶0047 // 0051, a gateway 100 (used in the “financial sector”; see ¶0038) identifies tampering associated with “sense information” stored on a data generation device 110 and transmits the sense information to servers of an external network (see ¶0049), similar to how self-service transaction device 110 of Arora Fig. 1 monitors user images 128 stored in a memory 122 and transmits the user images to an external authentication server 130. Examiner accordingly considers gateway 100 and data generation device 110 storing sense information, as taught in Lu, as analogous to the claimed “third-party transactional device” and “memory storage hardware” storing “customer data”, respectively. As shown in Fig. 3, when tampering is detected, all information (specifically including “sense previously-stored information”) included within gateway 100 is deleted and overwritten (i.e., “purges the customer data”).
Slensker, Arora, and Lu are considered analogous to the claimed invention because they all relate to the same field of monitoring memory storage hardware for tampering and associated corrective action. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker and Arora with the teachings of Lu and realize a method of purging monitored data stored on third-party memory storage hardware. Doing so improves data reliability and security by providing a mechanism to protect data from physical or remote attacks and to meet security requirements in cloud environments, as disclosed in Lu ¶¶0042-43: “There are transmission gateways on the market and used today that connect devices online and send data to the cloud. However, some of these devices do not meet the security requirements of many use cases, especially against physical tampering … the inventors have developed gateways, software, and methods designed to reliably and securely transmit, store and process data while being tamper proof and able to defend against physical and remote attacks.”
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1, wherein the third-party transactional device is an Automatic Teller Machine (ATM) (Slensker, “As shown, system 100 includes a motherboard 102 configured to hold a plurality of electronic components and provide connectors for connecting peripheral devices … The motherboard may be installed in an ATM to control operations related to the ATM.” [0014-15]).
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein the established communication channel is via an existing circuit (Arora, Communication Interface 119, Fig. 1 // “The ATM management service may coordinate secure and/or encrypted communication between the ATM 110 and the authentication server 130 … Communication between the ATM and the authentication server may be performed over one or more communication networks, such as a WAN, a LAN, the Internet, a cellular communication network, a private network, and the like” [0040]) – As previously discussed (see Claim 1 limitation mappings above) and as detailed in Arora ¶0040, secure and encrypted communication between the ATM and authentication server 130 is coordinated in response to capturing the user data 128. As clarified in Arora ¶0040, aforementioned communication between the ATM and the authentication server takes place over “one or more communication networks”. One of ordinary skill in the art would accordingly understand that the secure and encrypted communication over a communication network would take place using Communication Interface 119 included within Self-Service Transaction Device 110 depicted within Arora Fig. 1 (i.e., “via an existing circuit”).
Regarding Claim 10,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 10. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising generating (Slensker, Fig. 2, step 220) an alert (Slensker, “an alert” [0053]), wherein the alert comprises information related to a change in the customer data stored on the third-party memory storage hardware (Slensker, “The cash dispenser may be configured to send out an alert to the monitoring device over the cable 130 when the cash dispenser does not detect the pre-negotiated code or detects a code different from the pre-negotiated code in a command it receives for dispensing cash” [0050] // “At step 220, the monitoring device 122 may perform one or more actions in response to detecting that an unauthorized activity related to the ATM has occurred … the monitoring device 122 may send out an alert and/or information relating to an ATM attack” [0053]) – As taught in Slensker, a monitoring device determines unauthorized activity has occurred when detecting that data received from a peripheral device (e.g., “the pre-negotiated code” of Slensker ¶0050; i.e., “customer data”) differs from what is expected (i.e., is “chang[ed]”). As clarified in ¶0053, after determining unauthorized activity has occurred, monitoring device 122 sends an alert including information relating to the detected change (step 220).
Regarding Claim 11,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 11. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1, wherein the alert comprises information related to a change in the memory storage hardware on the third-party transactional device (Slensker, “For example, if the measured voltage of a peripheral device does not match any of the expected voltage values for the device, the monitoring device may determine that an unauthorized change has been made to the device” [0043] // “At step 220, the monitoring device 122 may perform one or more actions in response to detecting that an unauthorized activity related to the ATM has occurred … the monitoring device 122 may send out an alert and/or information relating to an ATM attack” [0053]) – As shown in Slensker Fig. 2 and detailed in ¶¶0043 + 0053, after determining that the measured peripheral device voltage does not match the expected profile (step 204 ‘No’), monitoring device 122 identifies that an “unauthorized change” has been made to the peripheral device (step 218) and subsequently sends an alert including information relating to the detected change (step 220).
Regarding Claim 12,
Slensker discloses the following limitations:
A system (Monitoring Device 122, Fig. 1) for identifying and monitoring memory storage on a third-party transactional device (System 100, Fig. 1) comprising:
at least one processor (Processor 302, Fig. 3);
a vendor hardware scanning program (Monitoring Device 122, Fig. 3);
a storage memory identification engine (Monitoring Device 122, Fig. 3);
a hardware telemetry monitoring engine (Monitoring Device 122, Fig. 3); and
memory (Memory 306, Fig. 3) storing computer-readable instructions (Monitoring Device Instructions 308, Fig. 3) that, when executed by the at least one processor, cause the system to (¶0057):
scan (step 202, Fig. 2), via the vendor hardware scanning program (Monitoring Device 122, Fig. 1 // Instructions 308, Fig. 3), a third-party transactional device (System 100, Fig. 1 // “an ATM” [0015])(“The method 200 may be performed by the monitoring device 122 shown in FIG. 1. Example method 200 begins at step 202, where the monitoring device monitors a voltage associated with a peripheral device” [0038-39]) – As shown in Figs. 1 - 3, a monitoring device 122 storing monitoring instructions 308 measures the voltages across each of a plurality of peripheral devices (e.g., 116 + 118 + 120 of Fig. 1) during step 202 of Fig. 2. In this context, examiner considers measuring a voltage across a peripheral device located within a system 100 as “scanning” the system--;
identify (step 204, Fig. 2), via the storage memory identification engine, … hardware (“peripheral devices” [0015]) in the third-party transactional device (“At step 204, the monitoring device checks if the monitored voltage across a peripheral device matches an expected voltage profile of the peripheral device. The monitoring device has access to an expected voltage profile for each of the devices on the motherboard 102 or peripheral devices connected to the motherboard 102.” [0040]) – As shown in Fig. 2, during step 204, monitoring device 122 compares the measured voltage of a particular peripheral device to an “expected voltage profile” associated with the peripheral device. As clarified in ¶0040, the monitoring device has access to an expected voltage profile for each (e.g., of three; see Fig. 1) peripheral device which is connected to the system motherboard. One of ordinary skill in the art would accordingly understand that comparing a measured voltage to a particular (e.g., one of three) expected voltage profile necessarily requires the monitoring device to understand which (e.g., out of the three) peripheral device is being measured. Accordingly, examiner considers step 204 of Fig. 2 as at least “identifying” “hardware” in a third-party transactional device--;and
monitor (steps 204 + 218, Fig. 2), via the hardware telemetry monitoring engine, the identified … hardware on the third-party transactional device (“At step 204, the monitoring device checks if the monitored voltage across a peripheral device matches an expected voltage profile of the peripheral device … If the monitored voltage of a peripheral device matches with the expected voltage profile of the device, the method 200 proceeds back to step 202 where the monitoring device continues to monitor the voltage across the peripheral device. On the other hand, if the monitored voltage of the peripheral device fails to match the expected voltage profile of the peripheral device, the method 200 proceeds” [0040-41] // “In response, the monitoring device determines (at process block 218) that an unauthorized activity related to the ATM has occurred.” [0052] // Fig. 2 // ¶¶0038-53) – As shown in Fig. 2, comparing the measured voltage of a peripheral device to the expected voltage profile for the peripheral device enables the monitoring device to either determine that that the peripheral device is operating as expected (see step 204 ‘Yes’) or is operating in an “unauthorized” manner (see steps 204 ‘No’ + 218). Accordingly, examiner considers Fig. 2 as a “monitoring” process of the “identified … hardware” in the third-party transaction device—
generate an alert and sending the alert to a financial institution of a customer (“the monitoring device 122 to wirelessly transmit an alert and/or information relating to an ATM attack to concerned authorities” [0036]) – As taught in ¶0036, an alert is generated and is wirelessly transmit to “concerned authorities”. One of ordinary skill in the art would understand that the “concerned authorities” would be associated with the ATM being attacked (i.e., with “a financial institution of a customer”).
Although Slensker Fig. 1 shows a memory device 114 connected to motherboard 102; and ¶0040 discloses that expected voltage profiles for both “devices on the motherboard” and “peripheral devices connected to the motherboard” are accessible by monitoring device 122, Slensker does not appear to explicitly disclose a “memory storage” type of peripheral device which would be monitored as depicted in Fig. 2. Specifically, Slensker does not explicitly disclose the following limitations:
memory storage hardware in a third-party transactional device…
identified memory storage hardware
However, Arora discloses the following limitations:
memory storage hardware (Memory 122, Fig. 1) in a third-party transactional device (Self-Service Transaction Device 110, Fig. 1) – In this case, examiner considers the Self-Service Transaction Device 110 which comprises both a memory module 114 and a memory module 122, as depicted in Arora Fig. 1, as analogous to system 100 which comprises both a memory module 114 and peripheral devices, as depicted in Slensker Fig. 1--…
identified memory storage hardware (Fig. 1) -- In this context, examiner considers memory device 122 included within self-service transaction device 110 as depicted in Arora Fig. 1 as analogous to a peripheral device included within system 100, as depicted in Slensker Fig. 1 (i.e., an “identified” hardware of the third-party transactional device; i.e., “identified memory storage hardware”)
Slensker and Arora are considered analogous to the claimed invention because they all relate to the same field of identifying and mitigating unauthorized activity performed on ATM devices. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker with the teachings of Arora and realize a third-party transactional device which includes memory storage hardware comprising customer data. Including memory storage hardware within a third-party transactional device would be expected to improve the security, accuracy of identification, and confidence in user transactions performed on the transactional device by increasing a number of transaction authentication options available to the transactional device, as disclosed in Arora ¶¶0021 // 0039: “In many cases, a currently existing ATM may be limited by one or more existing standards in use when installed and/or upgraded … Recent developments have increased a number of authentication options available, such as facial biometric capture at an ATM, facial biometric compare at an authentication server that may be remote or local to the ATM … and the like. In some cases, one or more authentication methods may be used together to allow for increased security, accuracy of identification, and confidence that the correct user is accessing their own accounts.” [0021] // “The user image 128 may be stored in local memory 122 of the ATM for comparison locally” [0039]
Slensker and Arora are silent regarding purging monitored customer data. Specifically, the combined teachings of Slensker and Arora do not explicitly disclose the following limitations:
wherein the financial institution purges the customer data stored on the identified memory storage hardware in the third-party transactional device
However, Lu discloses the following limitations:
wherein the financial institution (¶0038) purges (Fig. 3, step 308) the customer data (“sense information” [0047]) stored on the identified memory storage hardware (Data generation device 110, Fig. 1) in the third-party transactional device (Gateway 100, Fig. 1)(“Gateway 100 receives sense information transmitted by one or more data generation devices … A data generation device can also be a data storage device and the sense information is the data in the data storage device.” [0047] // “Tamper switch 104 is configured to sense tampering … of gateway 100 … tampering may be interfering with the transmission of data between the data generation device to the gateway” [0051] // “At 308, the gateway is placed in a secure state in response to receiving the alert signal … any combination of the following actions may be taken: … 3) remove sense previously-stored information from the memory of the gateway … 6) delete and overwrite all information” [0060-62] // ¶0049) – As shown in Lu Fig. 1 and taught in ¶¶0047 // 0051, a gateway 100 (used in the “financial sector”; see ¶0038) identifies tampering associated with “sense information” stored on a data generation device 110 and transmits the sense information to servers of an external network (see ¶0049), similar to how self-service transaction device 110 of Arora Fig. 1 monitors user images 128 stored in a memory 122 and transmits the user images to an external authentication server 130. Examiner accordingly considers gateway 100 and data generation device 110 storing sense information, as taught in Lu, as analogous to the claimed “third-party transactional device” and “memory storage hardware” storing “customer data”, respectively. As shown in Fig. 3, when tampering is detected, all information (specifically including “sense previously-stored information”) included within gateway 100 is deleted and overwritten (i.e., “purges the customer data”).
Slensker, Arora, and Lu are considered analogous to the claimed invention because they all relate to the same field of monitoring memory storage hardware for tampering and associated corrective action. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker and Arora with the teachings of Lu and realize a method of purging monitored data stored on third-party memory storage hardware. Doing so improves data reliability and security by providing a mechanism to protect data from physical or remote attacks and to meet security requirements in cloud environments, as disclosed in Lu ¶¶0042-43: “There are transmission gateways on the market and used today that connect devices online and send data to the cloud. However, some of these devices do not meet the security requirements of many use cases, especially against physical tampering … the inventors have developed gateways, software, and methods designed to reliably and securely transmit, store and process data while being tamper proof and able to defend against physical and remote attacks.”
Regarding Claim 13,
The same motivation to combine provided in Claim 12 is equally applicable to Claim 13. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The system of claim 12, wherein the third-party transactional device is an Automatic Teller Machine (ATM) (Slensker, “As shown, system 100 includes a motherboard 102 configured to hold a plurality of electronic components and provide connectors for connecting peripheral devices … The motherboard may be installed in an ATM to control operations related to the ATM.” [0014-15]).
Regarding Claim 15,
The same motivation to combine provided in Claim 12 is equally applicable to Claim 15. The combined teaching of Slensker, Arora, and Lu disclose the following limitations:
The system of claim 12 (see Claim 12 limitation mappings above), further comprising generating (Slensker, ¶0025), via the storage memory identification engine (Slensker, Monitoring Device 122, Fig. 1), a memory storage hardware profile (Slensker, “expected voltage profiles” [0025]) of the third-party transactional device, wherein the memory storage profile includes components (Slensker, “peripheral devices” [0025] // Arora, Memory Device 122, Fig.1) of the third-party transactional device comprising the customer data (Slensker, “The monitoring device 122 may be configured to build expected voltage profiles for one or more devices on the motherboard 102 or peripheral devices connected to the motherboard … In order to build an expected voltage profile for a device, the ATM may be run in an training mode supervised by authorized personnel” [0025]) – As disclosed in Slensker ¶0025, expected voltage profiles for each peripheral device connected to the ATM motherboard are built (i.e., are “generat[ed]”) based on data gathered during tests performed on the ATM during a training mode. In this case, examiner considers the collective expected voltage profiles which are generated for an ATM as “a memory storage hardware profile of the third-party transactional device”. As previously discussed (see Claim 12 limitation mappings above) and as shown in Arora Fig. 1, memory storage hardware (e.g., memory device 112) is a type of peripheral device included within an ATM. One of ordinary skill in the art would accordingly understand that an expected voltage profile would accordingly be generated for a peripheral memory storage device which stores customer data (i.e., the profile at least includes “components” “comprising the customer data”).
Regarding Claim 19,
The same motivation to combine provided in Claim 12 is equally applicable to Claim 19. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The system of claim 12, further comprising identifying (Slensker, Fig. 2, steps 204 ‘No’ + 218 + 220), via the storage memory identification engine (Slensker, Monitoring Device 122, Fig. 1), changes to the memory storage hardware in the third-party transactional device (Slensker, “For example, if the measured voltage of a peripheral device does not match any of the expected voltage values for the device, the monitoring device may determine that an unauthorized change has been made to the device” [0043] // “At step 220, the monitoring device 122 may perform one or more actions in response to detecting that an unauthorized activity related to the ATM has occurred … the monitoring device 122 may send out an alert and/or information relating to an ATM attack” [0053]) – As shown in Slensker Fig. 2 and detailed in ¶¶0043 + 0053, after determining that the measured peripheral device voltage does not match the expected profile (step 204 ‘No’), monitoring device 122 identifies that an “unauthorized change” has been made to the peripheral device (step 218) and subsequently sends an alert including information relating to the detected change (step 220).
Regarding Claim 20,
Slensker discloses the following limitations:
A non-transitory machine-readable medium (Memory 306, Fig. 3) storing instructions (Monitoring Device Instructions 308, Fig. 3) that, when executed by one or more processors (Processor 302, Fig. 3), cause the one or more processors to perform steps (¶0057) comprising:
scanning (step 202, Fig. 2), via a vendor hardware scanning program (Monitoring Device 122, Fig. 1 // Instructions 308, Fig. 3), a third-party transactional device (System 100, Fig. 1 // “an ATM” [0015])(“The method 200 may be performed by the monitoring device 122 shown in FIG. 1. Example method 200 begins at step 202, where the monitoring device monitors a voltage associated with a peripheral device” [0038-39]) – As shown in Figs. 1 - 3, a monitoring device 122 storing monitoring instructions 308 measures the voltages across each of a plurality of peripheral devices (e.g., 116 + 118 + 120 of Fig. 1) during step 202 of Fig. 2. In this context, examiner considers measuring a voltage across a peripheral device located within a system 100 as “scanning” the system--;
identifying (step 204), via a storage memory identification engine(Monitoring Device 122, Fig. 1 // Instructions 308, Fig. 3), … hardware (“peripheral devices” [0015]) in a third-party transactional device (“At step 204, the monitoring device checks if the monitored voltage across a peripheral device matches an expected voltage profile of the peripheral device. The monitoring device has access to an expected voltage profile for each of the devices on the motherboard 102 or peripheral devices connected to the motherboard 102.” [0040]) – As shown in Fig. 2, during step 204, monitoring device 122 compares the measured voltage of a particular peripheral device to an “expected voltage profile” associated with the peripheral device. As clarified in ¶0040, the monitoring device has access to an expected voltage profile for each (e.g., of three; see Fig. 1) peripheral device which is connected to the system motherboard. One of ordinary skill in the art would accordingly understand that comparing a measured voltage to a particular (e.g., one of three) expected voltage profile necessarily requires the monitoring device to understand which (e.g., out of the three) peripheral device is being measured. Accordingly, examiner considers step 204 of Fig. 2 as at least “identifying” “hardware” in a third-party transactional device--; and
monitoring (steps 204 + 218, Fig. 2), via a hardware telemetry monitoring engine (Monitoring Device 122, Fig. 1 // Instructions 308, Fig. 3), the identified … hardware on the third-party transactional device (“At step 204, the monitoring device checks if the monitored voltage across a peripheral device matches an expected voltage profile of the peripheral device … If the monitored voltage of a peripheral device matches with the expected voltage profile of the device, the method 200 proceeds back to step 202 where the monitoring device continues to monitor the voltage across the peripheral device. On the other hand, if the monitored voltage of the peripheral device fails to match the expected voltage profile of the peripheral device, the method 200 proceeds” [0040-41] // “In response, the monitoring device determines (at process block 218) that an unauthorized activity related to the ATM has occurred.” [0052] // Fig. 2 // ¶¶0038-53) – As shown in Fig. 2, comparing the measured voltage of a peripheral device to the expected voltage profile for the peripheral device enables the monitoring device to either determine that peripheral device is operating as expected (see step 204 ‘Yes’) or is operating in an “unauthorized” manner (see steps 204 ‘No’ + 218). Accordingly, examiner considers Fig. 2 as a “monitoring” process of the “identified … hardware” in the third-party transaction device--,
wherein the third-party transactional device is an Automatic Teller Machine (ATM) (“an ATM” [0015]) or a Point of Sale (PoS) device (“As shown, system 100 includes a motherboard 102 configured to hold a plurality of electronic components and provide connectors for connecting peripheral devices … The motherboard may be installed in an ATM to control operations related to the ATM.” [0014-15]),
generating an alert and sending the alert to the financial institution of the customer (“the monitoring device 122 to wirelessly transmit an alert and/or information relating to an ATM attack to concerned authorities” [0036]) – As taught in ¶0036, an alert is generated and is wirelessly transmit to “concerned authorities”. One of ordinary skill in the art would understand that the “concerned authorities” would be associated with the ATM being attacked (i.e., with “a financial institution of a customer”).
Although Slensker Fig. 1 shows a memory device 114 connected to motherboard 102; and ¶0040 discloses that expected voltage profiles for both “devices on the motherboard” and “peripheral devices connected to the motherboard” are accessible by monitoring device 122, Slensker does not appear to explicitly disclose a “memory storage” type of peripheral device which would be monitored as depicted in Fig. 2. Specifically, Slensker does not explicitly disclose the following limitations:
memory storage hardware in a third-party transactional device…
wherein the identified memory storage hardware of the third-party transactional device comprises stored customer data, and
wherein the customer is a member of a financial institution identifying and monitoring the memory storage on the third-party transactional device.
However, Arora discloses the following limitations:
memory storage hardware (Memory 122, Fig. 1) in a third-party transactional device (Self-Service Transaction Device 110, Fig. 1) – In this case, examiner considers the Self-Service Transaction Device 110 which comprises both a memory module 114 and a memory module 122, as depicted in Arora Fig. 3, as analogous to system 100 which comprises both a memory module 114 and peripheral devices, as depicted in Slensker Fig. 1--…
wherein the identified memory storage hardware (Memory 122, Fig. 1) of the third-party transactional device comprises stored customer data (“In some cases, one or more data structures may be used to store authentication information, image data and/or associated metadata and the like. For example, the memory device 122 may be used to store data captured locally at the ATM 110, such as a user image 128 … Additionally, metadata associated with the image may be stored in the memory 122, such as date information, time information, location information, and/or user data and the like” [0030]) – As detailed in ¶0030, a memory device 122 located within self-service transaction device 110 stores “user data” associated with users of an ATM. In this context, examiner considers memory device 122 included within self-service transaction device 110 as depicted in Arora Fig. 1 as analogous to a peripheral device included within system 100, as depicted in Slensker Fig. 1 (i.e., an “identified” hardware of the third-party transactional device; i.e., “identified memory storage hardware”), and
wherein a customer (User 105, Fig. 1) is a member of a financial institution identifying and monitoring the memory storage hardware on the third-party transactional device (“allowing the user 105 to perform one or more actions on the ATM 110, such as providing access to an account held at an associated financial institution” [0025] // “a financial institution associated with the ATM and/or with an account associated with the user” [0037]) – As taught in ¶0025, users 105 of the self-service transactional device 110 hold accounts associated with a financial institution. As clarified in ¶0037, the financial institution is also associated with the self-service transactional device 110. One of ordinary skill in the art would accordingly understand that a financial institution is generally associated with the monitoring device 122 of Slensker Fig. 1 which performs the identification and monitoring of peripheral hardware devices.
Slensker and Arora are considered analogous to the claimed invention because they all relate to the same field of identifying and mitigating unauthorized activity performed on ATM devices. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker with the teachings of Arora and realize a third-party transactional device which includes memory storage hardware comprising customer data. Including memory storage hardware within a third-party transactional device would be expected to improve the security, accuracy of identification, and confidence in user transactions performed on the transactional device by increasing a number of transaction authentication options available to the transactional device, as disclosed in Arora ¶¶0021 // 0039: “In many cases, a currently existing ATM may be limited by one or more existing standards in use when installed and/or upgraded … Recent developments have increased a number of authentication options available, such as facial biometric capture at an ATM, facial biometric compare at an authentication server that may be remote or local to the ATM … and the like. In some cases, one or more authentication methods may be used together to allow for increased security, accuracy of identification, and confidence that the correct user is accessing their own accounts.” [0021] // “The user image 128 may be stored in local memory 122 of the ATM for comparison locally” [0039]
Slensker and Arora are silent regarding purging monitored customer data. Specifically, the combined teachings of Slensker and Arora do not explicitly disclose the following limitations:
purging, by the financial institution, the customer data stored on the identified memory storage hardware in the third-party transactional device
However, Lu discloses the following limitations:
purging (Fig. 3, step 308), by the financial institution, the customer data (“sense information” [0047]) stored on the identified memory storage hardware (Data generation device 110, Fig. 1) in the third-party transactional device (Gateway 100, Fig. 1)(“Gateway 100 receives sense information transmitted by one or more data generation devices … A data generation device can also be a data storage device and the sense information is the data in the data storage device.” [0047] // “Tamper switch 104 is configured to sense tampering … of gateway 100 … tampering may be interfering with the transmission of data between the data generation device to the gateway” [0051] // “At 308, the gateway is placed in a secure state in response to receiving the alert signal … any combination of the following actions may be taken: … 3) remove sense previously-stored information from the memory of the gateway … 6) delete and overwrite all information” [0060-62] // ¶0049) – As shown in Lu Fig. 1 and taught in ¶¶0047 // 0051, a gateway 100 (used in the “financial sector”; see ¶0038) identifies tampering associated with “sense information” stored on a data generation device 110 and transmits the sense information to servers of an external network (see ¶0049), similar to how self-service transaction device 110 of Arora Fig. 1 monitors user images 128 stored in a memory 122 and transmits the user images to an external authentication server 130. Examiner accordingly considers gateway 100 and data generation device 110 storing sense information, as taught in Lu, as analogous to the claimed “third-party transactional device” and “memory storage hardware” storing “customer data”, respectively. As shown in Fig. 3, when tampering is detected, all information (specifically including “sense previously-stored information”) included within gateway 100 is deleted and overwritten (i.e., “purges the customer data”).
Slensker, Arora, and Lu are considered analogous to the claimed invention because they all relate to the same field of monitoring memory storage hardware for tampering and associated corrective action. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker and Arora with the teachings of Lu and realize a method of purging monitored data stored on third-party memory storage hardware. Doing so improves data reliability and security by providing a mechanism to protect data from physical or remote attacks and to meet security requirements in cloud environments, as disclosed in Lu ¶¶0042-43: “There are transmission gateways on the market and used today that connect devices online and send data to the cloud. However, some of these devices do not meet the security requirements of many use cases, especially against physical tampering … the inventors have developed gateways, software, and methods designed to reliably and securely transmit, store and process data while being tamper proof and able to defend against physical and remote attacks.”
Claims 3, 5, 14, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Slensker further in view of Arora, Lu, and Kvochko et al. (US 20210160071 A1)(cited by examiner in previous action)(hereafter referred to as Kvochko).
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teaching of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Although Arora ¶0024 discloses that memory device 122 storing user data 128 is located within “a self-service transaction device”, Arora does not explicitly disclose that self-service transaction device 110 is a “Point of Sale (PoS)” type of device separate from an ATM. Specifically, the combined teachings of Slensker, Arora, and Lu do not explicitly disclose the following limitations:
wherein the third-party transactional device is a Point of Sale (PoS) device
However, Kvochko discloses the following limitations:
the third-party transactional device (User Device 110, Fig. 1) is a Point of Sale (PoS) device (“a point-of-sale device” [0031])(“the user 102 is an individual interacting with one or more entity systems 120, third party systems 130, and or other user devices via a user device 110 while a data stream or flow between the user device 110 and the entity system 120 and/or other user devices is intercepted and monitored by the encrypted data transmission system 130 over the network 101.” [0038] // “In one embodiment, a user device may comprise a point-of-sale device used to complete an interaction” [0031]) – As disclosed in Kvochko ¶0031, user interactions with user devices 110 and third party systems are monitored by an entity system 120, similar to how user data stored by a self-service transaction device 110 is authenticated by an authentication server 120 as depicted in Arora Fig. 1. Accordingly, examiner considers a user device 110 as shown in Kvochko Fig. 1 as analogous to a self-service transaction device 110 as shown in Arora Fig. 1. As clarified in ¶0031, a user device which might be monitored includes a “point-of-sale device”.
Slensker, Arora, Lu, and Kvochko are all considered analogous to the claimed invention because they all relate to the same field of monitoring ATM machines for unauthorized activity. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker, Arora, and Lu with the teachings of Kvochko and realize a point-of-sale (PoS) device which includes memory storage hardware which stores customer data and which is monitored by a financial institution. Monitoring a point-of-sale device comprising customer data would be expected to improve the data privacy of users performing transactions using the point-of-sale device while still allowing for resource transfers between the point-of-sale device and a third-party entity, as taught in Kvochko ¶¶0001 // 0034-35: “Data is typically transferred or exchanged between devices during most interactions such as resource transfers between devices. As such, users desire to be able to decide exactly what data about them is transferred and processed in a trusted context … there exists a need for an improved, privacy enabled data transmission system for generating and executing secure resource transfers and distribution while limiting data exposure” [0001] // “In a specific embodiment, a user is a customer or entity requesting a resource transfer to or from another party to complete an interaction … In one embodiment, a user device may comprise a point-of-sale device used to complete an interaction” [0034-35]
Regarding Claim 5.
The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein the customer data is encrypted (Arora, “encrypted communication” [0040]) – As previously discussed (see Claim 1 limitation mappings above) and as detailed in Arora, customer data is transmitted to an authentication server via “encrypted communication” over a secure channel.
Arora is silent regarding using homomorphic encryption in order to perform encrypted communication between the ATM and the authentication server. Specifically, the combined teachings of Slensker, Arora, and Lu are silent regarding the following limitations:
the customer data is encrypted via a homomorphic encryption layer
However, Kvochko discloses that ATM devices storing user data employ homomorphic encryption. the following limitations:
the customer data is encrypted via a homomorphic encryption layer (“The memory device 306 includes data storage 308 … Data stored in data storage 308 may comprise one or more of user data records 314 … an encryption function 318 … The encryption function may comprise a function configured for transforming data from a first form to a second encrypted form” [0048] // “In another embodiment, the system, and specifically the encryption function 318, is further configured to leverage homomorphic encryption methods, where the encrypted data may be directly processed or used in further calculations without being decrypted.” [0065] // “As used herein, the term ‘user device’ may refer to … automated teller machines (ATMs)” [0031])
Slensker, Arora, Lu, and Kvochko are all considered analogous to the claimed invention because they all relate to the same field of monitoring ATM machines for unauthorized activity. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker, Arora, and Lu with the teachings of Kvochko and realize a method of encrypting communication via homomorphic encryption. Doing so would improve security by allowing data resource transfers to be accomplished with a third party entity without requiring decryption of data, thereby reducing exposure of customer data, as disclosed in Kvochko ¶0065: “Instead, the encrypted data may be processed to produce an encrypted result, where any of the processes performed on the encrypted data are carried through to the encrypted result. In this way, data processes for completing a resource transfer may be performed on the encrypted data without the need to decrypt and potentially expose the data at the receiving end (e.g., third party entity).”
Regarding Claim 14,
The same motivation to combine provided in Claim 12 is equally applicable to Claim 14. The combined teachings of Slensker, Arora, and Lu disclose the following limitations:
The system of claim 12 (see Claim 12 limitation mappings above),
Although Arora ¶0024 discloses that memory device 122 storing user data 128 is located within “a self-service transaction device”, Arora does not explicitly disclose that self-service transaction device 110 is a “Point of Sale (PoS)” type of device separate from an ATM. Specifically, the combined teachings of Slensker, Arora, and Lu do not explicitly disclose the following limitations:
wherein the third-party transactional device is a Point of Sale (PoS) device.
However, Kvochko discloses the following limitations:
the third-party transactional device (User Device 110, Fig. 1) is a Point of Sale (PoS) device (“a point-of-sale device” [0031])(“the user 102 is an individual interacting with one or more entity systems 120, third party systems 130, and or other user devices via a user device 110 while a data stream or flow between the user device 110 and the entity system 120 and/or other user devices is intercepted and monitored by the encrypted data transmission system 130 over the network 101.” [0038] // “In one embodiment, a user device may comprise a point-of-sale device used to complete an interaction” [0031]) – As disclosed in Kvochko ¶0031, user interactions with user devices 110 and third party systems are monitored by an entity system 120, similar to how user data stored by a self-service transaction device 110 is authenticated by an authentication server 120 as depicted in Arora Fig. 1. Accordingly, examiner considers a user device 110 as shown in Kvochko Fig. 1 as analogous to a self-service transaction device 110 as shown in Arora Fig. 1. As clarified in ¶0031, a user device which might be monitored includes a “point-of-sale device”.
Slensker, Arora, Lu, and Kvochko are all considered analogous to the claimed invention because they all relate to the same field of monitoring ATM machines for unauthorized activity. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker, Arora, and Lu with the teachings of Kvochko and realize a point-of-sale (PoS) device which includes memory storage hardware which stores customer data and which is monitored by a financial institution. Monitoring a point-of-sale device comprising customer data would be expected to improve the data privacy of users performing transactions using the point-of-sale device while still allowing for resource transfers between the point-of-sale device and a third-party entity, as taught in Kvochko ¶¶0001 // 0034-35: “Data is typically transferred or exchanged between devices during most interactions such as resource transfers between devices. As such, users desire to be able to decide exactly what data about them is transferred and processed in a trusted context … there exists a need for an improved, privacy enabled data transmission system for generating and executing secure resource transfers and distribution while limiting data exposure” [0001] // “In a specific embodiment, a user is a customer or entity requesting a resource transfer to or from another party to complete an interaction … In one embodiment, a user device may comprise a point-of-sale device used to complete an interaction” [0034-35]
Regarding Claim 16,
The same motivation to combine provided in Claim 12 is equally applicable to Claim 16. The combined teaching of Slensker, Arora, and Lu disclose the following limitations:
The system of claim 15 (see Claim 15 limitation mappings above), further comprising the step of
extracting (Arora, Fig. 2, step 240), via the hardware telemetry monitoring engine, customer data stored on the identified memory storage hardware (Arora, “At 240, the ATM may invoke the authentication server … to authenticate the user … The ATM management service may coordinate secure and/or encrypted communication between the ATM 110 and the authentication server 130 … The authentication [server] may receive the user data and the user image 128 from the ATM” [0040]) – As shown in Arora Fig. 2 and detailed in ¶0040, the ATM transmits the user image 128 to authentication server 130 via an encrypted channel. In this context, examiner considers transmitting data from a memory (e.g., Memory 122 of Arora Fig. 1) as “extracting” the data from the memory--,
wherein the customer (Arora, User 105, Fig. 3) is a member of a financial institution identifying and monitoring the memory storage on the third-party transactional device (Arora, “allowing the user 105 to perform one or more actions on the ATM 110, such as providing access to an account held at an associated financial institution” [0025] // “a financial institution associated with the ATM and/or with an account associated with the user” [0037]) – As taught in Arora ¶0025, users 105 of the self-service transactional device 110 hold accounts associated with a financial institution. As clarified in ¶0037, the financial institution is also associated with the self-service transactional device 110. One of ordinary skill in the art would accordingly understand that a financial institution is generally associated with the monitoring device 122 of Slensker Fig. 1 which performs the identification and monitoring of peripheral hardware devices.--,
Although Arora ¶0020 discloses that the monitored user transactions are generally associated with financial institution customer transactions performed using an ATM, The combined teachings of Slensker, Arora, and Lu do not explicitly disclose the following limitations:
wherein the identifying and monitoring of the memory storage hardware on the third-party transactional device is in accordance with agreed upon protocols between the third-party and the financial institution.
However, Kvochko discloses the following limitations:
wherein the identifying and monitoring of the memory storage hardware on the third-party transactional device is in accordance with agreed upon protocols between the third-party and the financial institution. (“a user may be … a customer of an entity … (e.g., a financial institution). In a specific embodiment, a user is a customer or entity requesting a resource transfer to or from another party to complete an interaction. In one embodiment, a user may be a merchant or business owner who is a customer of a software providing entity such as an entity providing the encrypted data transmission system as a product or service.” [0030]) – As taught in Kvochko ¶0030, merchants and business owners (i.e., “the third-party”) purchase software services, such as an encrypted data transmission system, in order to monitor transactions with a financial institution. In this context, examiner considers a merchant purchasing services to support transactions with a financial institution as “agreed upon protocols” (e.g., such as encrypting communication) between the merchant and the financial institution.
Slensker, Arora, Lu, and Kvochko are all considered analogous to the claimed invention because they all relate to the same field of monitoring ATM machines for unauthorized activity. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker, Arora, and Lu with the teachings of Kvochko and realize a method of establishing agreed upon protocols, such as encrypted communication, between a third party and a financial institution which monitors customer data. Establishing encrypted communications between a third party and a financial institution would improve security by allowing data resource transfers to be accomplished with the third-party entity without requiring decryption of data, thereby reducing exposure of customer data, as disclosed in Kvochko ¶0065: “Instead, the encrypted data may be processed to produce an encrypted result, where any of the processes performed on the encrypted data are carried through to the encrypted result. In this way, data processes for completing a resource transfer may be performed on the encrypted data without the need to decrypt and potentially expose the data at the receiving end (e.g., third party entity).”
Regarding Claim 17,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 17. The combined teachings of Slensker, Arora, Lu, and Kvochko disclose the following limitations:
The system of claim 16, wherein the customer data is encrypted (Arora, “The ATM management service may coordinate secure and/or encrypted communication between the ATM 110 and the authentication server 130” [0040]), via a homomorphic encryption layer (Kvochko, “the encryption function 318, is further configured to leverage homomorphic encryption methods, where the encrypted data may be directly processed or used in further calculations without being decrypted.” [0065]), and transmitted to a network of the financial institution (Arora, “Communication between the ATM and the authentication server may be performed over one or more communication networks, such as a WAN, a LAN, the Internet, a cellular communication network, a private network, and the like” [0040])
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Slensker further in view of Arora, Lu, and Kurian et al. (US 20190058992 A1)(hereafter referred to as Kurian).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teaching of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Arora is silent regarding a cloud environment which includes authentication server 130. Specifically, the combined teachings of Slensker, Arora, and Lu are silent regarding the following limitations:
wherein the financial institution server is a cloud environment
However, Kurian discloses the following limitations:
the financial institution server (Authentication Server 106, Fig. 1) is a cloud environment (Fig. 1 // “The authentication server 106 is in signal communication with user devices 103, the cloud server 104, and/or one or more third-party servers 108.” [0016] // “the system may use information stored in a cloud server that is linked with a user as part of the authentication rules” [0005]) – In this case, examiner considers Authentication Server 106 depicted in Kurian Fig. 1 as analogous to Authentication Server 130 depicted in Arora Fig. 1. As shown in Kurian Fig. 1 and described in ¶0005, an authentication server 106 communicates with cloud servers 104 in order to perform authentication functionality. Examiner accordingly considers Authentication Server 106 as part of “a cloud environment”.
Slensker, Arora, Lu, and Kurian are all considered analogous to the claimed invention because they all relate to the same field of authenticating user transactions performed on third party transactional devices. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker, Arora, and Lu with the teachings of Kurian and realize a financial institution server which monitors third-party transactional devices and which is located within a cloud environment. Using an authentication server which is part of a cloud environment would allow for user-defined authentication rules to be updated as necessary, which improves system functionality by allowing the system to support a larger number of devices and to support different types of devices, as disclosed in Kurian ¶0005: “For example, the system may use information stored in a cloud serve that is linked with a user as part of the authentication rules. The system provides a technical advantage by allowing user-defined authentication rules that can be dynamically changed to provide increased security when necessary. This process provides improved functionality to the system by allowing the system to support a large number of devices and allowing the system to optimize authentication rules based on the capabilities of the different types of devices.”
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Slensker further in view of Arora, Lu, and She et al. (US 20230088676 A1)(hereafter referred to as She).
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teaching of Slensker, Arora, and Lu disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
The combined teachings of Slensker and Arora are silent regarding “Security Information and Event Management (SEIM) logic”. Specifically, the combined teachings of Slensker, Arora, and Lu are silent regarding the following limitations:
wherein the financial institution controlled software is coupled with the third-party memory hardware using Security Information and Event Management (SEIM) logic.
However, She discloses that “Security Information and Event Management (SEIM)” tools enable analysis, managing, monitoring, and reporting of security events and vulnerabilities. She discloses the following limitations:
wherein the financial institution controlled software is coupled with the third-party memory hardware using Security Information and Event Management (SEIM) logic (“Generalizing, Security Information and Event Management (SEIM) tools provide a range of services for analyzing, managing, monitoring, and reporting on IT security events and vulnerabilities. Such services typically include collection of events regarding monitored accesses and unexpected occurrences across the data network, and analyzing them in a correlative context to determine their contribution to profiled higher-order security events” [0050]) – As previously discussed (see Claim 1 limitation mappings above), financial institution controlled software (e.g., Monitoring Device Instructions 308 of Slensker Fig. 3) interacts with (i.e., is coupled to), monitors, and analyzes peripheral device voltages (e.g., Memory Device 122 of Arora Fig. 1) to determine unauthorized changes to the peripheral devices. As disclosed in She ¶0050, SEIM tools provide services which include collection of events related to monitored accesses and analysis of the events for security. One of ordinary skill in the art would accordingly understand that SEIM tools (i.e., SEIM “logic”), as described in She ¶0050, could provide the monitoring and analysis services performed by financial institution controlled software such as Monitoring Device Instructions 308 of Slensker Fig. 3.
Slensker, Arora, Lu, and She are all considered analogous to the claimed invention because they all relate to the same field of monitoring and reporting unauthorized access to devices comprising user data. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Slensker and Arora with the teachings of She and realize a method of monitoring third-party transactional device hardware using SEIM logic. Using SEIM logic would be expected to improve system security by providing a mechanism for ensuring security policy compliance, as disclosed in She ¶0050: “Generalizing, Security Information and Event Management (SEIM) tools provide a range of services … They may also include analysis of firewall configurations, network topology and connection visualization tools for viewing current and potential network traffic patterns, correlation of asset vulnerabilities with network configuration and traffic to identify active attack paths and high-risk assets, and support of policy compliance monitoring of network traffic, topology and vulnerability exposures.” [0050]
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Slensker further in view of Arora, Lu, She, and Watts, Jr. et al. (US 20210345219 A1)(hereafter referred to as Watts).
Regarding Claim 8,
The same motivation to combine provided in Claim 7 is equally applicable to Claim 9. The combined teaching of Slensker, Arora, Lu, and She disclose the following limitations:
The method of claim 7 (see Claim 7 limitation mappings above), wherein the financial institution controlled software and the third-party memory hardware communicate … protocols (Slensker, “The network interface 304 is configured to communicate data between the monitoring device 122 and other devices … The network interface 304 may be configured to use any suitable type of communication protocol as would be appreciated by one of ordinary skill in the art.” [0060])
Slensker does not explicitly suggest using RS232 and RS422 communication protocols. Specifically, the combine teachings of Slensker, Arora, Lu, and She do not explicitly disclose the following limitations:
communicate via RS232 and RS422 protocols
However, Watts discloses the following limitations:
communicate via RS232 and RS422 protocols (“The gateway device 110 communicates via a local network 140 with various machines. The machines that communicate with the gateway device 110 … include … an automated teller machine (ATM) 154.” [0028] // “Examples of hardware/firmware features include … zero or multiple serial ports (with RS232, RS422 and/or RS485 physical interfaces) that may be configured as standard serial ports (for applications such as POS and security) or as DEX & MDB ports (for vending applications)” [0144])
The combined teachings of Slensker, Arora, Lu, and She disclose an ATM machine (Slensker, System 100, Fig. 1) communicating via standard communication protocols, which examiner considers analogous to the Watts ATM device (ATM 154, Fig. 1). Watts [0144] discloses a known method of communicating with an ATM device according to RS232 and RS422 protocols (see limitation mappings above). It would have been obvious to someone of ordinary skill in the art, as taught by Watts, to implement the method of communicating with an ATM device according to RS232 and RS422 protocols in the ATM device communicating via standard communication protocols of Slensker. A person of ordinary skill in the art would have recognized that applying the known technique of communicating with an ATM device according to RS232 and RS422 protocols as taught by Watts to an ATM device communicating via standard communication protocols would have yielded the predictable results of financial institution controlled software communicating with memory hardware using RS232 and RS422 protocols. Communicating with an ATM device according to RS232 and RS422 protocols would have been expected to increase the number and type of communication ports which can be used to communicate with an ATM, thereby allowing for increased applications such as POS/security and vending applications (see also Watts ¶0144). Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to apply the known technique of communicating with an ATM device according to RS232 and RS422 protocols, as taught by Watts, to the ATM device communicating via standard communication protocols disclosed in Slensker. Doing so would predictably result in a financial institution controlled software communicating with memory storage hardware according to RS232 and RS422 protocols. See MPEP 2143, Rationale D.
Response to Arguments
The previous objections of Claims 4, 15, and 20 are withdrawn in view of the instant amendments.
The previous 35 U.S.C. 112(b) rejections of Claims 12-17 and 19-20 are withdrawn in view of the instant amendments.
The previous 35 U.S.C. 112(b) rejections of Claims 1-8 and 10-11 are maintained. Examiner notes that while certain 112(b) issues of the aforementioned claims are resolved in view of the instant claim amendments, outstanding 112(b) issues remain. See 35 U.S.C. 112(b) rejections above for additional details.
Applicant’s arguments with respect to claims 1-8, 10-17, and 19-20 have been considered but are moot in view of the newly-identified Lu reference because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With respect to applicant’s argument located within the 2nd paragraph of the 3rd page of remarks (numbered as page 9), which recites:
“Here, none of the cited references disclose, teach, or suggest 1) generating an alert and sending the alert to the financial institution of the customer; or 2) wherein the financial institution purges the customer data stored on the identified memory storage hardware in the third-party transactional device, as recited in the amended independent claims.”
Examiner has fully considered the aforementioned argument but does not find it persuasive. Applicant argues that none of the references of record disclose generating and sending an alert to a financial institution. However, examiner notes that Slensker ¶0036 discloses an alert which is wirelessly transmitted to concerned authorities in response to an ATM attack, which examiner considers as reading on the “generating an alert” limitation as recited in the claims as amended. Nothing in the claims as currently presented precludes such an interpretation of Claim 1.
Nevertheless, applicant’s argument regarding the outstanding 35 U.S.C. 103 rejections of independent claims are moot in view of the newly-identified Lu reference. See 35 U.S.C. 103 rejections above for additional details.
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Votaw et al. (US 20150227903 A1) – Discloses a method of remotely erasing banking customer data from a mobile device (see Fig. 3 // ¶0079)
Plymouth et al. (US 20130293363 A1) – Discloses an alert engine (Fig. 2A) which monitors customer banking data stored in a database and which deletes data from the customer database (see ¶0095)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm 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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights