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 .
Status of Claims
The following is a non-final Office Action in response to application number 19144208 filed on June 27, 2025. Claims 1-10 are currently pending, and have been examined.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. India 202221020555 filed on 04/05/2022.
Specification
The disclosure is objected to because of the following informalities:
Para 53, “providesa provide” should read “provides a”.
Para 54, providesa” should read “provides a”.
Para 56, providesa” should read “provides a”.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-10 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-6 are directed to a “system” and claims 7-10 are directed to a “method”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 7 recites “completing a monetary transaction”, which is a form of commercial or legal interactions (i.e., organizing human activity), and an abstract idea. Specifically, the claim recites “incorporating two or more chips (102) into a monetary transaction means (104) for initiating the monetary transaction of the system (100); transferring, by a processor (106) at the receiving end (116), a pre-defined amount of money to a pooled account (110) via a network (112); loading, by the processor (106), the pre-defined amount of money transferred in a form of tokens from the pooled account (110); syncing, by the processor (106), the monetary transaction means (104) and the receiving end (116) prior to initiating the monetary transaction; receiving, by the processor (106), a communication signal at the receiving end (116) by the monetary transaction means (104) when the user initiates the transaction; receiving, by the processor (106), a security code entered by the user on an interface of the receiving end (116) upon initiating the monetary transaction; authenticating, by the processor (106), the monetary transaction means (104) for a closed loop network; verifying, by the processor (106), the security code entered by the user with a pre-stored code, wherein the pre-stored code is encrypted within the monetary transaction means (104); completing, by the processor (106), the monetary transaction upon receiving a positive authentication result and a positive verification code; storing, by the processor (106), the completed monetary transaction on the receiving end (116); and transferring, by the processor (106), the money from a financial institution associated to the user to a financial institution associated with the receiving end (116) upon connecting the receiving end (116) to the network (112)”. The abstract idea is in italics, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “incorporating two or more chips (102) into a monetary transaction means (104) for initiating the monetary transaction of the system (100)”, “a processor (106) at the receiving end (116)”, “a network (112)”, “syncing, by the processor (106), the monetary transaction means (104) and the receiving end (116)”, “receiving, by the processor (106), a communication signal at the receiving end (116) by the monetary transaction means (104)”, and “the receiving end (116) upon connecting the receiving end (116) to the network (112)”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “completing a monetary transaction”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of “completing a monetary transaction” using computer technology (e.g., “a processor” and “a monetary transaction means”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 7 is non-statutory.
Claim 1 also recites the abstract idea of “completing a monetary transaction”, as well the additional elements of “A system (100) for monetary transaction”, “two or more chips (102) incorporated into a monetary transaction means (104), wherein the chips (102) are configured to initiate the monetary transaction”, “a receiving end (116) configured to enable a user to perform the monetary transaction using the monetary transaction means (104), wherein the receiving end (116) comprising:”, “a processor (106)”, “a memory (108) comprising a set of instructions, which when executed by the processor (106) cause the processor (106) to: …”, “sync the monetary transaction means (104) and the receiving end (116) prior to initiating the monetary transaction”, “receive a communication signal at the receiving end (116) by the monetary transaction means (104)”, “an interface of the receiving end (116)”, “the monetary transaction means (I04) for a closed loop network”, and “the receiving end (116) upon connecting the receiving end (116) to the network (112)”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “completing a monetary transaction”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of “completing a monetary transaction” using computer technology (e.g., “two or more chips (102) incorporated into a monetary transaction means (104)” and “a memory (108) comprising a set of instructions, which when executed by the processor (106) cause the processor (106) to: …”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 1 is non-statutory.
Dependent claims 2-6 and 8-10 further describe the abstract idea of “completing a monetary transaction”, which is insufficient to overcome the rejections of claims 1 and 7.
Dependent claims 2 and 8 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “completing a monetary transaction”, when analyzed under Step 2A, Prong Two. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Dependent claim 3 recites new additional elements of “a dual chip single interface card” and “a single chip dual interface card”, which do no more than employ a computer as a tool to implement the abstract idea. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field.
Dependent claim 4 recites a new additional element of “a contactless chip”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Dependent claims 5 and 9 recite new additional elements of “a POS”, “a mobile embedded application”, and “a kiosk”, which do no more than employ a computer as a tool to implement the abstract idea. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field.
Dependent claims 6 and 10 recite a new additional element of “a backend server”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Hence, claims 1-10 are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over Mullen (U. S. Patent Application Publication No. 20210103919 A1), herein referred to as Mullen, in view of Realini (U. S. Patent Application Publication No. 20090119190 A1), herein referred to as Realini, and in further view of Zamani et al (U. S. Patent Application Publication No. 20230344649 A1), herein referred to as Zamani.
Regarding claims 1 and 7, Mullen specifically discloses a system (100) for monetary transaction (FIG. 3, item 300; para 73, “… FIG. 3 shows network topologies according to example embodiments. Referring to FIG. 3, network topology 300 may be a logical topology of a transactional network including multiple network elements (e.g., servers, routers, switches, user devices, communications infrastructure and/ or the like). The network elements may include, for example, mobile device 305, card reader 310, card 315, network access infrastructure 325, mobile network 330, wireless access point 335, IP network 340, remote verification processor 345, payment network 355, issuers 360, device 370, contactless device 380 and/or online merchant 395…”), said system (100) characterized by comprising:
two or more chips (102) (FIG. 9, 10, 11, items 905, 910, 1010, 1060; para 220, “… FIG. 7 shows a token transaction method performed in accordance with the principles of the present invention. Referring to FIG. 7, a user may initiate a tokenization process required to utilize a transaction card with a multi-card device (e.g., as in step 705). The process may be initiated by uploading card data associated with the transaction card to a user computing device (e.g., a mobile telephonic device, a PDA, a laptop and/or a desktop computer) and communicating the card data to a multi-card provider (e.g., a provider of a multi-card application and/or a provider of a multi-card device, such as a dynamic and/or powered card manufacturer and/or retailer) …”; para 221, “… A card may have two contact chips (e.g., 905 and 910) on the front of the card … contact chip 905 may be on the left side of the card and contact chip 910 may be on the right side of the card, and each may be positioned on the card for insertion into a smart card reader (e.g., based on which end of the device is inserted). The card may have a single magnetic stripe and a single contactless antenna. The printing of the card may be different towards each contact chip … the left side contact chip may be associated with a credit card account. The right side contact chip may be associated with an installment functionality on that same credit card account …”) incorporated into a monetary transaction means (104) (FIG. 9, item 900; para 221, “… A card may have two contact chips (e.g., 905 and 910) on the front of the card … contact chip 905 may be on the left side of the card and contact chip 910 may be on the right side of the card, and each may be positioned on the card for insertion into a smart card reader (e.g., based on which end of the device is inserted). The card may have a single magnetic stripe and a single contactless antenna. The printing of the card may be different towards each contact chip … the left side contact chip may be associated with a credit card account. The right side contact chip may be associated with an installment functionality on that same credit card account …”), wherein the chips (102) are configured to initiate the monetary transaction; …
load the pre-defined amount of money transferred in a form of tokens (FIG. 7, items 720, 725; para 172, “… FIG. 7 shows a token transaction method performed in accordance with the principles of the present invention. Referring to FIG. 7, a user may initiate a tokenization process required to utilize a transaction card with a multi-card device (e.g., as in step 705). The process may be initiated by uploading card data associated with the transaction card to a user computing device (e.g., a mobile telephonic device, a PDA, a laptop and/or a desktop computer) and communicating the card data to a multi-card provider (e.g., a provider of a multi-card application and/or a provider of a multi-card device, such as a dynamic and/or powered card manufacturer and/or retailer) …”; para 175, “… Upon completion of the verification process, the user may receive one or more tokens (e.g., as in step 720) … the payment network and/or the financial institution may communicate one or more tokens to the multi-card provider and/or the user mobile device … the token may be directly usable by an application residing on the user's computing device, the multi-card provider may embed the token into an application and communicate the application to the user's computing device, the token and any required firmware/software may be communicated from the multi-card provider to the user's multi-card device, and/or the multi-card provider may provide a complete multi-card device (e.g., including the token) to the user (e.g., as in step 720). The user may conduct a transaction and the token may be communicated for authorization of the transaction (e.g., as in step 725) …”; para 176, “… one or more tokens may be retrieved by a multi-card device or application during a transaction, or a simulated transaction. For example, one or more tokens may be downloaded to a multi-card device that is used at a card reader (e.g., a point-of-sale IC chip and/or magnetic stripe card reader) …”) …
receive a communication signal at the receiving end (116) (FIG. 3, item 370; para 126, “… Device 370 may be … a server, a laptop computer, a PDA, a desktop computer, a mobile device, a stand-alone piece of electronic equipment, and/or the like … Device 370 may include a contactless interface that may initiate, sustain, and/or terminate communication channel 385 between contactless device 380 and device 370. Contactless device 380 and device 370 may communicate via channel 385 using any number of contactless mediums, which may include for example, visible, audible, capacitive, electromagnetic, magnetic, and/or RF mediums …”) by the monetary transaction means (104) (FIG. 9, item 900; para 221, “… A card may have two contact chips (e.g., 905 and 910) on the front of the card … contact chip 905 may be on the left side of the card and contact chip 910 may be on the right side of the card, and each may be positioned on the card for insertion into a smart card reader (e.g., based on which end of the device is inserted). The card may have a single magnetic stripe and a single contactless antenna. The printing of the card may be different towards each contact chip … the left side contact chip may be associated with a credit card account. The right side contact chip may be associated with an installment functionality on that same credit card account …”) when the user initiates the transaction (para 37, “… A signal may be received or generated by the dynamic card ( e.g., a counter signal, a randomly generated signal, a timing signal, etc.) and the dynamic card may produce a dynamic number based on the signal, the private key and/or the private card number. The processing facility may utilize the private key, private card number, the dynamic number, and/or the signal (or a different signal synchronized with the signal) to verify that the dynamic number is correct …”); …
complete the monetary transaction upon receiving a positive authentication result and a positive verification code (para 52, “… A random number generated by the random number generator may define each variable of the function. For each transaction, card 100 may generate a random number and determine a solution to the associated function using the random number to generate a dynamic number. Card 100 may communicate the random number, the dynamic number and an identifier, to a verification facility and/or device (hereinafter, "verifying entity"). The verifying entity may retrieve the function associated to card 100 from secure storage based on the identifier and/or may determine the function using the identifier. A solution to the retrieved/determined function may be calculated using the random number communicated by card 100 to generate a verification number. The verifying entity may determine whether or not the verification number matches the communicated dynamic number. A transaction may be authorized if … a match is determined…”); …
Mullen does not specifically disclose, however, Realini discloses transfer a pre-defined amount of money to a pooled account (110) (FIG. 7, 2. “Obopay transfers funds from pooled account to working account.”) via a network (112) (para 32, “… the invention is a financial transactions system including a consumer interface, connected to a network, including: a Web interface to handle transaction requests from a Web browser client; a mobile Internet browser interface to handle transaction requests from a mobile Internet browser on a mobile phone client; an SMS interface to handle transaction requests using SMS text mes-saging; and a mobile client application interface to handle requests from a mobile client application executing on mobile phone client …”; FIG. 1, item 109, para 137; “… FIG. 1 shows a block diagram of a system of the invention for conducting value exchange transactions includ-ing in specific implementations, mobile person-to-person payments and transactions, mobile person-to-merchant payment transactions, and mobile banking. An applications server 107 is connected to a network 109 …”); …
… from the pooled account (110) (FIG. 7, 2. “Obopay transfers funds from pooled account to working account.”); …
receive a security code entered by the user on an interface of the receiving end
(116) upon initiating the monetary transaction (para 37, “… displaying a fourth screen where the user enters a PIN code; and after the user enters the PIN code, wirelessly sending transaction information including the target phone number, transaction amount, and PIN code to a server for processing …”; para 203, “… Once the SMS message is sent to the payment server, the PIN is entered by the account holder and sent through a voice channel connection to the payment server to verify the SMS message. The PIN is entered in via the key-board and may be any alphanumeric code. The PIN is then sent to the payment sever as a DIMF encoded message where DIMF refers to dual-tone multi frequency, the signal a telephone company receives when a telephone's touch keys are pressed …”);
authenticate the monetary transaction means (I04) for a closed loop network (para 603, “… On the sending side of the transaction, the sending party uses a PIN code to identify the person with the phone. This authentication provides a high level of security because the payment server is able to identify the mobile device using caller ID and the person using the mobile device is identified by a PIN. Advantageously, the transferred in a secured manner and is not stored in the mobile device in a visible form…”; para 612, “… Upon receipt of a transaction request, as indicated at 5402, the payment server receives a sequence number from the cell phone and compares it with the sequence number held by payment server. If the sequence numbers match, as indicated at 5403, then the payment server authorizes the transaction to continue. The sequence numbers at both the cell phone and payment server are then updated to a new sequence number. This security mechanism is used to prevent spoofing attacks or cloned phones. The user is then requested to enter their PIN as indicated at 5405. By coupling the use of the sequence number with the PIN and the cell phone number, there is a three-level security blanket that authenticates the user (PIN), the phone number ( detected by caller ID and linked to a specific account) and the sequence number to validate the transaction (prevents an intruder from at empty-ing to capture a transaction and then resubmit duplicate requests for a transaction). The sequence number is also used to discriminate multiple attempts of the SMS system to deliver a transaction message from valid multiple transactions …”);
verify the security code entered by the user with a pre-stored code, wherein the pre-stored code is encrypted within the monetary transaction means (104) (FIG. 55, item 5517; para 618, “… Once the Caller ID is validated, the server then checks the PIN transmitted from mobile device against PIN recorded in system to verify that the PIN matches the expected phone number as indicated, at 5517. If and only if the PIN matches, will the server allow the transaction to proceed. If the PIN does not match, then the transaction is disallowed, as indicated at 5518…”); …
store the completed monetary transaction on the receiving end (116) (FIG. 7, (4) Mobile payment system updates T records in mobile payment system system-of-record”; para 282, “… A basic flow of the transaction is: (1) Consumer A sends the mobile payment system pay request. (2) Mobile payment system transfers funds from pooled account to working account. (3) Mobile payment system transfers funds from working account to pooled account. (4) Mobile payment system updates T records in mobile payment system system--of-record …”; FIG. 89, items 8902, 8903; para 1084, “… off-line manager 8902 also has an internal memory where it stores each transaction before it updates shared memory 8903. Off-line manager 8902 is controlled by MCA in terms of setting an initial account balance available for off-line transactions as well as clearing stale transactions from off-line manager 8902 after device 8901 resynchronizes accounts. Re-synching is performed by MCA 8901 using communications platform 8904 either at a set time each day or when a next to occur on-line transaction is initiated by the account holder…”); and …
Realini discloses a virtual pooled account for mobile banking. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a virtual pooled account for mobile banking, as in Realini, to improve and/or enhance the technology of multi-function applet powered cards and other devices, as in Mullen, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a payment system where the receiver of funds in a financial transaction is able to easily verify the validity of the entity holding the funds, the account and the balance and the identity of the person with the phone, making a more secure manner to access credit and debit cards to conclude financial transactions.
Mullen and Realini do not specifically disclose, however, Zamani discloses a receiving end (116) (para 65, “… The server computer 104 can include a remote computer. The server computer 104 can provide an offline amount to the first device 102 to be stored in a secure element of the first device 102 … the first device 102 can request an offline amount from the server computer 104 … the server computer 104 can push an offline amount to the first device 102…”) configured to enable a user to perform the monetary transaction using the monetary transaction means (104) (para 19, “… A "user device" may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. …The user device may include one or more processors capable of processing user input …”), wherein the receiving end (116) comprising:
a processor (106) (FIG. 1, item 104; para 61, “… FIG. 1 shows a system 100 according to embodiments of the disclosure. The system 100 comprises a first device 102, a server computer 104, a second device 106, a plurality of devices 108, and a certificate authority 110. The first device 102 can be in operative communication with the server computer 104, the second device, and one or more devices of the plurality of devices 108. The server computer 104 can be in operative communication with the certificate authority 11 …”; para 65, “… The server computer 104 can include a remote computer. The server computer 104 can provide an offline amount to the first device 102 to be stored in a secure element of the first device 102 … the first device 102 can request an offline amount from the server computer 104 … the server computer 104 can push an offline amount to the first device 102…”);
a memory (108) comprising a set of instructions, which when executed by the processor (106) cause the processor (106) (para 39, “… A "memory" may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation …”) to: …
sync the monetary transaction means (104) (para 19, “… A "user device" may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. …The user device may include one or more processors capable of processing user input …”) and the receiving end (116) (para 65, “… The server computer 104 can include a remote computer. The server computer 104 can provide an offline amount to the first device 102 to be stored in a secure element of the first device 102 … the first device 102 can request an offline amount from the server computer 104 … the server computer 104 can push an offline amount to the first device 102…”) prior to initiating the monetary transaction (FIG. 8A, 8B, 8C; para 258, “… FIGS. 8A-8C illustrate chained interactions in an offline interaction system according to embodiments … a user device A can pay xA to a user device B modeled as AxA➔B, and then the user device B pays xB to a user device C, as illustrated in FIG. 8A. The first payment can be incorporated into the second payment … the previous payment AxA➔B can be incorporated into the next payment to make the payment sequence: AxA➔B, BxB➔C. This payment sequence will form a payment chain in which a user device Z (e.g., a user device at the end of the chain of payments) will know all user devices involved in the payment chain, eventually linking to the user device A. If any honest user device in the chain synchronizes with the server as depicted in FIGS. 8B-SC, then the server will know the payment sequence from the user device A all the way up until that honest user device that synced with the server. This will allow the server to successfully learn about all the payments involving many user devices even though only one user device, which may not have been involved in those payments, syncs with the server …”); …
transfer the money from a financial institution associated to the user to a financial institution associated with the receiving end (116) upon connecting the receiving end (116) to the network (112) (FIG. 4, items 502, 504, Method C; para 142, “… rather than depositing an amount into the offline amount of the trusted application, an amount is withdrawn from the offline amount of the trusted application and provided to the server com-puter 502 (see Protocol 8). In some embodiments, a user of the first device 504 can select to transfer a portion or all of an offline amount to an online amount maintained by the server computer 502 …”; para 143, “… after receiving user input to initiate a withdraw method C, at step 440, the first device 504 can determine whether or not an offline amount is greater than or equal to a selected amount to transfer to the online amount … the user can select to transfer $5 from the offline amount to the online amount. The first device 504, in particular the trusted application, can determine if the offline amount is greater than or equal to $5. If the offline amount is less than the selected amount, then the first device 504 can terminate the method and notify the user of the determination. If the offline amount is greater than or equal to ( e.g., exceeds) the offline amount, then the first device 504 can proceed with the withdraw method C at step 442 …”).
Zamani discloses an offline interaction system and method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an offline interaction system and method, as in Zamani; and to include a virtual pooled account for mobile banking, as in Realini, to improve and/or enhance the technology of multi-function applet powered cards and other devices, as in Mullen, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a secure form of offline digital interactions for situations where an access device cannot connect to authorization computers for authorization, thus providing a resilient interaction system that users and resource providers can use to interact without the need to rely on third parties.
Regarding claim 2, Mullen, Realini, and Zamani disclose the limitations of claim 1. Mullen further discloses the system (100) as claimed in claim 1, wherein the monetary transaction means ( I04) comprises at least one of a debit card, a credit card or a prepaid card (FIG. 16, items 1601, 1611; para 235, “… FIG. 16 shows card 1600 that may include card structure 1601. Payment terminal contact packages 1610 and 1620 may be included. Any number of printed/embossed account numbers may be associated with any contact package … contact package 1610 may include a single printed/embossed account number, such as account number 1611, (e.g., a credit or debit account number)…”).
Regarding claims 3 and 8, Mullen, Realini, and Zamani disclose the limitations of claims 1-2 and 7. Mullen further discloses the system (100) as claimed in claim 2, wherein at least one of the debit card and the credit card comprises one of a dual chip single interface card or a single chip dual interface card or a prepaid card (FIG. 9, 10, 11, items 905, 910, 1010, 1060; para 220, “… FIG. 7 shows a token transaction method performed in accordance with the principles of the present invention. Referring to FIG. 7, a user may initiate a tokenization process required to utilize a transaction card with a multi-card device (e.g., as in step 705). The process may be initiated by uploading card data associated with the transaction card to a user computing device (e.g., a mobile telephonic device, a PDA, a laptop and/or a desktop computer) and communicating the card data to a multi-card provider (e.g., a provider of a multi-card application and/or a provider of a multi-card device, such as a dynamic and/or powered card manufacturer and/or retailer) …”; para 221, “… A card may have two contact chips (e.g., 905 and 910) on the front of the card … contact chip 905 may be on the left side of the card and contact chip 910 may be on the right side of the card, and each may be positioned on the card for insertion into a smart card reader (e.g., based on which end of the device is inserted). The card may have a single magnetic stripe and a single contactless antenna. The printing of the card may be different towards each contact chip … the left side contact chip may be associated with a credit card account. The right side contact chip may be associated with an installment functionality on that same credit card account …”).
Regarding claim 4, Mullen, Realini, and Zamani disclose the limitations of claim 1. Mullen further discloses the system (100) as claimed in claim 1, wherein the chips (102) correspond to a contactless chip (FIG. 13, items 1300, 1301, 1310, 1320; para 232, “… FIG. 13 shows card 1300 that may have structure 1301 and chip 1310 and chip 1320. A payment chip may be … on a printed circuit board having contacts that can electrically couple to the contacts of a contact payment card terminal (e.g., EMV contact terminal). A payment chip may also be coupled to an RFID antenna (e.g., embedded in card structure 1301) for electrically coupling to a contactless payment terminal (e.g., an EMV contactless payment terminal). Accordingly, a payment chip may be utilized for both contact and contactless payments. A card, such as card 1300, may have two chips. A cardholder may insert the card into a reader in one direction to utilize a first chip and may insert the card into the reader in another direction to utilize a second chip. A contactless antenna may be located above chip 1310 for chip 1310 and a contactless antenna may be located below chip 1320 for chip 1320. Accordingly, a cardholder may tap the card in different positions to make a contactless transaction with a different chip. Alternatively, for example, contactless payment functionality may only be provided for one chip (e.g., chip 1310) …”).
Regarding claims 5 and 9, Mullen, Realini, and Zamani disclose the limitations of claims 1 and 7. Mullen and Realini do not specifically disclose, however, Zamani discloses the system (100) as claimed in claim 1, wherein the receiving end (116) comprises at least one of a POS, a mobile embedded application, or a kiosk (para 25, “… An "access device" may be any suitable device that provides access to a remote system. An access device may also be used for communicating with a coordination computer, a communication network, or any other suitable system. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS or point of sale devices ( e.g., POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), vending machines, automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a mobile communication or payment device… access devices can have card readers that can include electrical contacts, radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with portable devices such as payment cards … an access device can be a user device operated by a second user, when a user device is operated by a first user …”).
Zamani discloses an offline interaction system and method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an offline interaction system and method, as in Zamani; and to include a virtual pooled account for mobile banking, as in Realini, to improve and/or enhance the technology of multi-function applet powered cards and other devices, as in Mullen, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a secure form of offline digital interactions for situations where an access device cannot connect to authorization computers for authorization, thus providing a resilient interaction system that users and resource providers can use to interact without the need to rely on third parties.
Regarding claims 6 and 10, Mullen, Realini, and Zamani disclose the limitations of claims 1 and 7. Mullen and Realini do not specifically disclose, however, Zamani discloses the system (100) as claimed in claim 1, wherein the processor (106) is configured to sync data associated to the transaction of the pre-defined amount with a backend server upon connecting the processor (106) to internet (para 215, “… Soon after the payment, A loses their device and contacts S to recover their offline balance. S is not aware of a payment between A and B. T, therefore, the server will demand that A show all the offline payments before her off BalA is recovered to a correct state. As such, unless there is some knowledge made available to the server (in this case, Pay(x, receiverCert) by B), then no recovery mechanism is possible in this initial example situation. This means that B has to come online and synchronize with the server to facilitate balance recovery …”; para 223, “… Additionally, the server can guarantee balance recovery in a specific time bound. For that purpose, the server can utilize a synchronization parameter A during which it is expected that all users report their offline interactions to the server. The synchronization parameter A can be considered an epoch during which the server can ideally construct the offline interaction flows. The synchronization parameter A can be a length of time between expected user synchronization (e.g., check-in) times … the synchronization parameter A can be 12 hours, 1 day, 1 week, 2 weeks, etc. …”).
Zamani discloses an offline interaction system and method. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an offline interaction system and method, as in Zamani; and to include a virtual pooled account for mobile banking, as in Realini, to improve and/or enhance the technology of multi-function applet powered cards and other devices, as in Mullen, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a secure form of offline digital interactions for situations where an access device cannot connect to authorization computers for authorization, thus providing a resilient interaction system that users and resource providers can use to interact without the need to rely on third parties.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Heo et al (U. S. Patent No. 10007873 B2) – Multifunction Smart Card
Heo discloses a payment processing service and a near field communication (NFC) tag processing service through the single smart card. The smart card may store identification (ID) information of one of a payment card and an NFC tag at a first memory sector and store associated information for providing a related service as the payment card and the NFC tag at predetermined memory sectors. The smart card may be also implemented with an NFC tag applet providing the ID information and the associated information as the NFC tag to the user terminal. The smart card may be recognized as the NFC tag while storing the ID information for the payment card at the first memory sector in the memory or as the payment card while storing the ID information for the NFC tag at the first memory sector in the memory.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, 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, Ryan D. Donlon can be reached (571) 270-3602. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
Prosecution Insights