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 .
DETAILED ACTION
Status of the Claims
Claims 1-24 are pending, with claims 1, 10, and
19 being independent. Claims 1-2, 5-11, and 14-19 are amended.
Claims 21-24 are new.
The rejection under 35 USC 101 is withdrawn.
Response to Applicant Remarks
Applicant’s well-articulated remarks have been considered but are unpersuasive for the reasons below.
Applicant’s amendments are addressed by the newly cited art.
Regarding the rejection under 35 USC 101, the examiner concurs that the claimed invention is directed to an improvement to conventional POS terminal. Accordingly, the rejection is withdrawn.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1,2,3,8,9, 10,11,12,17,18,19,24 is/are rejected under 35 U.S.C. 103 as being unpatentable over White 20130138518 in view of Bondesen 20150254658 in view of Official Notice
Regarding Claim 1,
receiving, by a point-of-sale terminal (a POS terminal) over the Internet, a network packet comprising an instruction to initiate a payment transaction between a first entity and a second entity,
wherein the network packet comprises an account number associated with a first account corresponding to the customer first entity,
White is directed to a system for connecting a wireless device to a POS for payments over a network like the Internet. (White, abstract; para 0029, “[0029] The customer may use his wireless communication device to acquire the identifier (S161). The identifier may include a POS identifier (e.g., a network address, web address, URL, etc. of a POS terminal) and a respective location identifier corresponding to a respective location (e.g., physical location) at a premise having a plurality of locations. The POS identifier (e.g., network address) may be any logical identifier used to distinguish the POS terminal from any number of other devices in communication with the network, such as an IP address, a combination of a public and private IP addresses, a SIP address, a unique name, etc. In an example embodiment, the form of the POS identifier may depend on the type of network. The network may be any private, local, or wide-area network, the Internet, a cloud-based network, or any combination thereof. The wireless communication device may use at least the POS identifier to initiate communication with the POS terminal (S162).”) White discloses that communications could comprise packets. (White, para 0042, “Communication across a network may be packet-based, and may include radio and frequency/amplitude modulations to enable communication between wireless communication devices using appropriate converters and other elements. A plurality of elements may host logic for performing tasks on the network. This logic may be programmed on a server, or a complex of servers. A particular logic unit is not limited to a single logical location on a network.”) The customer may send account information to the merchant POS via the network. (White, para 0045, “Once the customer is satisfied with the bill and confirms payment on wireless communication device 410, payment information may be submitted (S479) from wireless communication device 410 to POS terminal 430 via the network. The payment information may include a copy of the bill, as well as information for one or more payment accounts owned by the customer, such as credit cards, bank accounts, gift certificates, etc. The payment information may further include additional instructions such as a partial amount, a request for a receipt, a tip amount, etc. POS terminal 430 may receive the payment information, complete the transaction, and send the confirmation of the transaction to wireless communication device 410.”)
The invention of White does not explicitly disclose
wherein the POS terminal includes a sensor to initiate the payment to the second entity based on receiving account information from a payment device within a detection range of the sensor, wherein the POS terminal includes a network interface to receive the network packet over the Internet, and
However, White discloses that it is known that POS terminals may employ near field communication to accommodate customer payments. (White, para 0004, “[0004] Many businesses, such as restaurants, place their point-of-sale devices away from the customer. Therefore, customers who choose to pay with a mobile telephone typically relinquish their mobile telephone so that the mobile telephone can be placed near the point-of-sale device to enable the transaction. For many mobile telephone users, this presents a problem of security and utility. Not only is the mobile telephone potentially exposed to unauthorized and unknown access, but the user is now completely without electronic communication. In today's world of smartphones with push mail, instant updates, and full web browsing capability, this can be a handicap depending on how much the user's lifestyle involves wireless communication. While a restaurant customer may in some instances feel comfortable in handing the mobile telephone to a trusted waiter, there are many instances where the same level of trust is not there, such as a baseball fan who will probably never feel comfortable passing his smartphone down a row of ten other fans just to pay for a hot dog.”) ; See also Applicant’s background, “Conventionally, financial transactions have been initiated at point-of-sale (POS) terminals via a form of payment being submitted to the POS terminal via a sensor of the POS terminal. In an example, a customer provides a vendor with a form of payment such as a credit card. The vendor manually or electronically via a computing system submits a transaction amount for a financial transaction. Thereafter, the vendor swipes the credit card at the POS terminal for a reader of the POS terminal to detect information from the credit card. If a credit card is a contactless credit card, the vendor may simply “tap” the credit card on the POS terminal. “). It would have been obvious to one of ordinary skill in the art before the filing date of the invention to combine White with the near field communication of White with the motivation of processing customer payments. ID.
wherein the POS terminal is managed by the second entity to initiate transactions to the second entity;
White discloses that the restaurant premises must be configured to use the payment system. The examiner interprets this to managing the POS terminal by the second entity merchant. (White, para 0033, “[0033] Referring back to FIG. 1, during initiation S162, the wireless communication device may also send a location identifier corresponding to a respective physical location at a premise having a plurality of locations. The location identifier may have been read, retrieved, or received by the wireless communication device from, for example, an NFC tag, barcode, QR code, or any present or future wireless media, available at the respective physical location. The location identifier may include at least enough information to distinguish the location from the other locations at the premise (e.g., business), which may include a seat number, a parking spot code, geographical coordinates, or other such differentiating variable. The POS terminal may receive this location identifier from the wireless communication device, and in response, associate the wireless communication device with the location identifier and/or the physical address associated with the location identifier (S163).”)
wherein the POS terminal … to the computer system associated with the financial institution automatically, without receiving user input at the POS terminal; and
storing or presenting information indicating the processing of the payment was successful.
(White, para 0045, “POS terminal 430 may receive the payment information, complete the transaction, and send the confirmation of the transaction to wireless communication device 410.”)
White does not explicitly disclose
responsive to extracting the account number, generating by the POS terminal … a new transaction request corresponding to the account number;
transmitting, by the POS terminal, … the new transaction request to a computer system associated with a financial institution,
wherein the computer system associated with the financial institution executes a payment process, based on the account number, that transfers funds from the first account corresponding to the first entity to a second account corresponding to the second entity,
Bondesen is directed to a system for making customer payments via tokens. (Bondesen, abstract). Bondesen discloses generating a transaction request to a financial institution to pay a merchant for a customer transaction. (Bondesen, para 0048, “[0048] The merchant 10 submits the token (as well as any user account information not substituted by a token) and the transaction information for authorization along the normal processing channels (also described as processing rails), which are normally used to process a transaction made by the user 2 using a user account number. In one embodiment of the invention the acquiring financial institution 20, or any other institution used to process transactions from the merchant 10, receives the token, user account information, and transaction information from the merchant 10.”; para 0049, “[0049] If the acquiring financial institution 20 receives the user account number from the tokenization service 50 (e.g., the transaction is allowed), then the acquiring financial institution 20 thereafter sends the user account number, the other user information, and the transaction information directly to the issuing financial institution 40, or otherwise indirectly through the card association networks 30. The financial institution determines if the user 2 has the funds available to enter into the transaction, and if the transaction meets other limits on the user account, and responds with approval or denial of the transaction. The approval runs back through the processing channels until the acquiring financial institution 20 provides approval or denial of the transaction to the merchant 10 and the transaction between the merchant 10 and the user 2 is completed. After the transaction is completed the token may be deleted, erased, or the like if it is a single-use token, or stored for further use if it is a multi-use token.”) It would have been obvious to one of ordinary skill in the art before the filing date of the invention to combine White with the transaction request of Bondesen with the motivation of executing customer payments. Id.
White does not explicitly disclose
unpacking, by the POS terminal, the network packet to extract the account number from a particular field of the network packet;
a set of network packets including
the set of network packets including
unpacks the network packet, extracts the account number, generates the set of network packets, and transmits the set of network packets
However, the limitations are obvious in view of Official Notice. The examiner takes official notice that it is old well known for Internet protocols to generate, unpack and read fields from packets. (e.g. the TCIP/IP protocol that forms the basis of the Internet). For example, the TCP packet contains header information and data in a specific format that is generated by a sender, received and read by a recipient to reconstitute a message made up of data within packets. As White specifically discloses the use of the Internet and packets (see above) to perform payment transactions, claiming a standard underlying network implementation is believed to be obvious. It is the examiner’s understanding that Applicant has not invented the underlying network protocols. The claim would have been obvious because “a person of ordinary skill has good reason to pursue the known options within his or her technical grasp. If this leads to the anticipated success, it is likely the product not of innovation but of ordinary skill and common sense.”
Regarding Claim 2, White, Bondesen and Official Notice disclose the media of claim 1.
White does not explicitly disclose
wherein the account number, associated with the first account corresponding to the customer first entity, is not accessible by the customer first entity.
Bondesen discloses that a single use token may be requested on demand for a transaction and be subsequently erased. The examiner interprets that in such a scenario the customer did not access the token. (Bondesen, para 0046, “[0046] As illustrated in FIG. 1, a tokenization service 50 may be available for the user 2 to use during transactions. As such, before entering into a transaction, the user 2 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52. The token may be stored in the user's payment device 4 (e.g., on the digital wallet) or stored on the cloud or other service through the tokenization service 50. The tokenization service 50 may also store limits (e.g., geographic limits, transaction amount limits, merchant limits, product limits, or the like) associated with the token that may limit the transactions in which the user 2 may enter. The limits may be placed on the token by the user 2, or another entity (e.g., person, company, or the like) responsible for the transactions entered into by the user 2 using the account associated with the token. The generation of the token may occur at the time of the transaction or well in advance of the transaction, as a one-time use token or multi-use token.”; “After the transaction is completed the token may be deleted, erased, or the like if it is a single-use token, or stored for further use if it is a multi-use token.”) It would have been obvious to one of ordinary skill in the art before the filing date of the invention to combine White and Official Notice with the token of Bondesen with the motivation of improving security. (Bondesen, background)
Regarding Claim 3, White, Bondesen and Official Notice disclose the media of claim 1.
Wherein the account number is valid for one time use.
See prior art rejection of claim 2.
Regarding Claim 8, White, Bondesen and Official Notice disclose the media of claim 1.
wherein the account number comprises a Virtual Card Number (VCN) generated by a tokenization service associated with the financial institution, the VCN substituting for an actual account number of the first entity.
See prior art rejection of claim 1 regarding Bondesen. The examiner interprets a token to be a virtual card number
Regarding Claim 9, White, Bondesen and Official Notice disclose the media of claim 1.
receiving, by the POS terminal, credit card information via a card reader, wherein the card reader determines the credit card information in response to a credit card being swiped through the card reader;
analyzing, by the POS terminal, the credit card information to determine a second account number corresponding to a third account;
generating by the POS terminal a second transaction request corresponding to the second account number; and
transmitting, by the POS terminal to the financial institution, the second transaction request for executing a second payment process that transfers a second payment from the third account to the second account corresponding to the supplier second entity.
See prior art rejection of claim 1 regarding Bondesen. ( See also Bondesen, para 0044, Bondesen discloses that payment information could be received via a network or a conventional read, “As such, when using a payment device 4 the transaction may be made between the point of sale (POS) and the payment device 4 by scanning information from the payment device 4, using near field communication (NFC) between the POS and the payment device 4, using wireless communication between the POS and the payment device 4, or using another other type of communication between the POS and the payment device 4.”).
Regarding Claims 10,11,12,17,18,19
See prior art rejections of claims 1,2,3,8,9,1
Regarding Claim 24, White, Bondesen and Official Notice disclose the media of claim 1.
wherein the POS terminal is a special-purpose machine comprising a combination of hardware, software, and sensors that together are configured to receive instructions to initiate payments over the Internet
See prior art rejection of claim 1 regarding White.
and receive account information to initiate payments from payment devices within detection range of the sensors.
See prior art rejection of claim 1 regarding White and Bondesen.
Claim(s) 4,5,7,13,14,16,20,21,22, 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over White 20130138518 in view of Bondesen 20150254658 in view of Official Notice in view of Lamba 20130085875
Regarding Claim 4, White, Bondesen and Official Notice discloses the media of claim 1.
White does not explicitly disclose
wherein the instruction to initiate the payment is received from the financial institution to which the new transaction request is transmitted.
Lamba is directed to a payment processor utilizing a secure intermediary. (Lamba, abstract; para 0036, “[0036] A method aspect is directed to a method of operating a payment processor system comprising a wireless network, a relay network, a point of sale (POS) device having associated therewith a merchant account…”; para 0047-48, “[0047] Once the processor 31 has determined the unique POS identifier, the processor 31 sends the unique POS identifier, together with the account access information to the POS device 12 via the relay network 18. The processor 31 cooperates with the transceiver 27 to send the unique POS identifier and account access information to the wireless network 72 (Arrow 80). The wireless network 72 in turn sends the unique POS identifier and account access information to the relay network 18 (Arrow 81). The relay network 18 then sends the account access information to the POS device 12 using the unique POS identifier (Arrow 82). The relay network 18 may send the access information to the POS device 12 via a direct connection, or via a network connection, such as the Internet or the wireless network 72, as will be appreciated by those of skill in the art. If the relay network 18 is to send the access information to the POS device 12 via a network, the relay network 18 first determines a network address of the POS device based upon the unique POS identifier, and then sends the access information to the POS device 12 using the network address. Determining the network address may be performed through the use of a look-up table, for example. [0048] Since the POS device 12 now has the account access information, the processor 16 thereof causes a transfer of funds from the payment account to a merchant account associated with the POS device, based upon the account access information. The processor 16 does this by sending the account access information together with transaction information (e.g. the amount of the transaction, etc) to a transaction server (e.g. a credit server) 70 (Arrow 83).”) It would have been obvious to one of ordinary skill in the art before the filing date of the invention to combine Bondesen with the payment processor of Lamba with the motivation of improving transaction security. (Lamba, background)
Regarding Claim 5, White, Bondesen, Official Notice and Lamba disclose the media of claim 4.
wherein the instruction received by the POS terminal comprises invoice data corresponding to a plurality of invoices grouped into a batch,
wherein the set of network packets stores batch data identifying the plurality of invoices, and
(White, para 0049, “[0049] In other example embodiments, customers can simply link bills so that one collective bill is created for an entire table. Customers linked together at this table may view the collective bill and order on behalf of all customers linked together at the table. Linked customers may pay for the entire collective bill, or any portion thereof until the collective bill is paid in full. Each customer may still pay his individual portions through his own wireless communication device by simply refraining from linking to the collective bill. All of these features may be facilitated via wireless communication between the customers' wireless communication devices, or by a centralized payment server that is accessible to the wireless communication devices via a network.”)
wherein the account number is valid for one time use for the plurality of invoices included in the batch.
See prior art rejection of claim 1 regarding Bondesen. As Bondesen discloses a single use token for a transaction, presumably it could be used for a conventional transaction or a batched transaction. (e.g. one person could pay for all the checks of all the diners at one table in a restaurant)
Regarding Claim 7, White, Bondesen and Official Notice discloses the media of claim 1.
wherein the computer system associated with the financial institution transmits the instruction to the POS in response to receiving a request from the first entity to initiate the payment.
See prior art rejection of claim 4 regarding Lamba
Regarding Claims 13,14,16,20,21,22
See prior art rejections of claim 4,5,7,4,7,5
Regarding Claim 23, White, Bondesen and Official Notice discloses the media of claim 1.
…independently of any interaction between the payment device and the sensor, and
White discloses that a customer device may obtain POS connectivity information from a tag device that is independent of the POIS. (White, para 0039, “[0039] In example embodiments of the subject disclosure, wireless tag 202 may use Near-Field Communication (NFC), which refers to a point-to-point wireless communication protocol. NFC readers are used to read information from NFC tags. NFC readers may also be capable of programming NFC tags with new information. NFC tags may be used in credit cards, kiosks, museum exhibits, passports, etc., and may be designed to provide information accessible by NFC readers, including authentication, transaction, identification, and other types of information. NFC tags may be a version of RFIDs, which may be utilized instead of NFC tags, as well as smartcards, universal integrated circuit cards (UICC), etc.”)
White does not explicitly disclose
wherein the network packet comprising the account number is transmitted to the POS terminal from the computer system associated with the financial institution…
See prior art rejection of claim 4 regarding Lamba
wherein the account number comprises a virtual card number (VCN) generated by the financial institution and valid for a defined num
See prior art rejection of claim 3 regarding Bondesen.
Claim(s) 6,15 is/are rejected under 35 U.S.C. 103 as being unpatentable over White 20130138518 in view of Bondesen 20150254658 in view of Official Notice in view of Dunjic 20190172038
Regarding Claim 6, White, Bondesen and Official Notice discloses the media of claim 1.
See prior art rejection of claim 1 regarding White
transmitting, by the POS terminal, a settlement request based on the authorization information for the processing of the payment; and
receiving, by the POS terminal, confirmation of the payment to the POS terminal.
White does not explicitly disclose
transmitting, by the POS terminal to a second device, an authorization request for processing the payment to the second entity based on the account number; receiving, by the POS terminal, authorization information corresponding to the processing of the payment;
Dunjic is directed to a payment system. (Preibisch, abstract). Dunjic discloses that a merchant device may contact a customer device for transaction consent. (Dunjic, para 0060, “[0060] Based on confirmation data 226, routing module 222 may access stored data identifying a network address of tokenization system 170 (e.g., TSP data 146), and may transmit the authorization request 216 to the network address of the tokenization system 170 through a corresponding API or other programmatic interface. In some aspects, and in additional to the tokenization services described herein, one or more application program modules, when executed by tokenization system 170, may cause tokenization system 170 to, among other things, intercept the initiated transaction and modify a status of the initiated transaction at POS terminal 122, and perform any of the exemplary processes described herein to delegate an approval of the initiated transaction to device operated by an approving party, and based on the delegated approval, to authorize the transaction using a payment instrument held by the approving party.”) It would have been obvious to one of ordinary skill in the art before the filing date of the invention to combine Bondesen with the approval of Dunjic with the motivation of controlling transactions. (Dunjic, para 0046)
Regarding Claims 15
See prior art rejections of claim 6
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLEN C CHEIN whose telephone number is (571)270-7985. The examiner can normally be reached Monday-Friday 8am -5pm.
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, Florian Zeender can be reached at (571) 272-6790. 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.
/ALLEN C CHEIN/Primary Examiner, Art Unit 3627