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
Applicant’s submission filed 1/27/26 has been entered. Claims 2-21 are presented for examination.
Claim Rejections - 35 USC § 101
The combination of the merchant device being able to display a form, receive input data via the form and cause the merchant device to transition to the offline mode , as presently written, integrates the abstract idea into a practical application.
The rejection under 35 U.S.C. 101 is withdrawn
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2-21 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
For example, claim 2 recites:
--a digital form
--sending the first data representing the digital form message to the first portion of merchant devices such that the first portion of merchant devices are caused to display the digital form;
--causing, based on user input data received via an individual instance of the digital form, the first portion of the merchant devices to transition to the offline mode;
At best, paragraph 0051 of the specification describes “sending the customer an e-mail requesting permission to re-attempt to authorize the payment instrument, sending the customer a form for inputting valid payment instrument information, or sending the customer a copy of a digital receipt that includes transaction information associated with the transaction.”
Paragraph 0059 describes The POS device 204 may be configured to automatically transition between the online mode and the offline mode based on an array of different reasons other than simply a loss of network connectivity. For instance, the POS device 204 may transition to the offline mode in order to increase an efficiency of transactions conducted between the merchant 202 and the customers 206.”
There is no support for causing the transition to the offline mode based on user input data received via an individual instance of the digital form.
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 2-, 18, 22-18 are rejected under 35 U.S.C. 103 as being unpatentable over Nair et al. (US 5428210 A), in view of Robertson et al. (US 20080126213 A1).
Re-claim 2, Nair et al. teach A system comprising:
one or more processors; and
non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
--monitoring merchant processes performed in association with merchant devices;
(see e.g. (24) Some transaction processors provide research services on behalf of their customers/merchants in an effort to resolve the dispute to the benefit of the merchant and re-present the transaction to the issuer for payment.
(9) Many data card transactions involve third-party credit card transaction processors in addition to the merchant and credit card issuer. Transaction processors, which are sometimes independent business institutions, provide merchants with data processing services that facilitate the flow of credit card transaction data and the corresponding payments of monies between the merchants and card issuers. The flow of transaction data from the merchant to the issuer via a transaction processor is commonly referred to as "processing" or "clearing" the transactions. )
--determining, based at least in part on the merchant processes, that a trigger event has occurred indicating an issue with at least a portion of the merchant processes; associated with a first portion of merchant devices, wherein the issue is an issue other than a loss of network connection
(see e.g. 340) If at step 1159 the transaction is of a magnitude that exceeds the floor limit amount, the program branches to step 1175. At step 1175, the terminal automatically dials a preprogrammed number associated with the transaction processor's off-line authorization source. Such an off-line authorization source in the preferred system is the transaction processor's own ARU 70.
(343) Once the audio response unit 70 receives the transaction data, the ARU automatically attempts to obtain an authorization approval from the card issuer via its connection to an appropriate authorization source, or, in the event of a host outage, determines whether the transaction may be approved according to predetermined guidelines for off-line authorizations maintained by the transaction processor 12. If so, the ARU produces an audible series of numbers corresponding to an off-line authorization number.)
--generating, based at least in part on the trigger event occurring, first data representing a digital form configured to receive user input and indicating a message recommending that the first portion of merchant devices be transitioned from an online mode to an offline mode;
(see e.g. (336) If at the inquiry step 1166 the response received from the authorization source is not an approval, the only other alternative is a "referral" or call me. In this case, the program branches to step 1175.
(346) If at inquiry step 1180 the transaction is to receive an off-line approval, the program branches to step 1192. At step 1192, it is assumed that a speech-synthesized three-digit authorization code has been spoken to the merchant by the ARU 70, in accordance with the discussion in connection with HG. 35. The merchant at 1192 is then prompted (by synthesized speech from the ARU) to enter this three digit code via the keypad. )
342) --the terminal can be made operative to require keyboard entry of transaction data.
--sending the first data representing the digital form to the first portion of merchant devices such that the first portion of merchant devices are caused to display the digital form;
(see e.g. (345) If the response was a decline, the at step 1184 the terminal displays "DECLINE" on the LCD 123 and the subroutine exits and control is returned to the CREDIT SALE AUTHORIZATION routine 900. The merchant of course must at this juncture decide whether to proceed with the transaction using another source of payment.)
Nair et al. do not explicitly teach the following limitations.
However, Robertson et al. teach - --causing, based on user input data received via an individual instance of the digital form, the first portion of the merchant devices to transition to the offline mode;
(see e.g. [0035] In the event the customer presents a payment card that does not require off-site authorization using the host processing system 29, but rather the payment server 23 or the site controller 18 can itself authorize such payment card, the site controller 18 will determine if such payment card is authorized without communicating to the host processing system 29. The payment server 23 may contain a local database of payment cards or other accounts that customers may use for payment that only requires on-site authorization.)
--storing second data indicating that the first portion of the merchant devices have transitioned to the offline mode and a second portion of merchant devices have remained in the online mode in response to the message;
(see e.g. [0029] The present invention additionally provides the ability for the forecourt devices to communicate with each other in a peer-to-peer fashion to provide a backup of off-line payment information stored locally at the forecourt devices.
[0064] As illustrated in FIG. 12, when the control process 113 transitions to the off-line state 206, the primary data server 116A and the secondary data server 116B receive off-line payment information from the forecourt payment devices 12, 18, 28, 30, 40 as previously discussed over the peer-to-peer virtual communication links 119 (step 350).
[0011] The primary data server and secondary data server are provided as part of a forecourt payment device's local memory. Each of the forecourt payment devices is coupled to the primary data server and the secondary data server via communications over the LAN using peer-to-peer virtual communication links. In this manner, every time one of the forecourt payment devices processes an off-line payment transaction in the event that the payment server is not available, the transaction data is communicated to each of the data servers so that the transaction data can be additionally stored in the primary data server and the secondary data server for replication of storage.
[0028] The present invention is a failsafe, redundant storage system for storing additional copies of off-line transactional or payment information generated by retail terminals. In particular, the retail terminals may be fuel dispensers or other service station forecourt devices that include retail terminals for handling retail transactions initiated by customers. The forecourt devices may continue to allow customers to initiate and carry out transactions using payment accounts even if payment processing is unavailable or off-line. In this manner, the forecourt devices are not rendered inoperable for handling customer transactions if payment processing is not available as a convenience to customers. )
--determining that the issue has abated; -----generating third data configured to cause the first portion of the merchant devices to transition from the offline mode to the online mode; and
--sending, based at least in part on the issue abating, the third data to the first portion of the merchant devices, the third data causing the first portion of the merchant devices to transition from the offline mode to the online mode.
(see e.g. [0059] The replication data services 112 receive payment information from one of the forecourt payment devices 12, 18, 28, 30, 40 via the virtual links 113 in a peer-to-peer communication (step 300). The control process then determines if the payment server 23 is still off-line (decision 302).
[0060] FIG. 10 is a flowchart illustration of the processing by the replication data service 112 when transitioning to the online state 202. The control process retrieves data from the local data store and sends the data to the payment server 23 for processing (step 312). The control process 111 then waits for acknowledgement from the payment server 23 that the off-line payment information has been received and processed (decision 314). If it has, the control process 111 deletes the data stored locally and calls upon the replication data services 112 to delete the off-line payment information held in the replication data store 114 (step 320) since the payment information has been properly processed by the payment server 23, and thus does not need to be stored as off-line payment transaction in replication data stores 114. If more stored off-line payment information exists that has not been processed (decision 322), the control process 111 repeats by going back to step 310, otherwise the process ends (step 324).
*****The Examiner note the combination of Nair’s teaching (of processing a transaction of a magnitude that exceeds the floor limit amount), and Robertson’s teaching (of receipt of payment from one of the forecourt payment devices) implies the issue has abated;
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nair et al., and include the steps cited above, as taught by Robertson et al. In this manner, the forecourt devices are not rendered inoperable for handling customer transactions if payment processing is not available as a convenience to customers. (see e.g. [0028]).
Re-claim 3, Nair et al. teach -- The system of claim 2, wherein sending the first data includes the message to the merchant devices causes the portion of the merchant devices indicating that the trigger event has occurred and is affecting the first portion of the merchant devices.
(see e.g. (343) Once the audio response unit 70 receives the transaction data, the ARU automatically attempts to obtain an authorization approval from the card issuer via its connection to an appropriate authorization source, or, in the event of a host outage, determines whether the transaction may be approved according to predetermined guidelines for off-line authorizations maintained by the transaction processor 12. If so, the ARU produces an audible series of numbers corresponding to an off-line authorization number.
(345) If the response was a decline, the at step 1184 the terminal displays "DECLINE" on the LCD 123 and the subroutine exits and control is returned to the CREDIT SALE AUTHORIZATION routine 900. The merchant of course must at this juncture decide whether to proceed with the transaction using another source of payment.)
Re-claim 4, Nair et al teach --The system of claim 2, wherein: the trigger event includes a transaction being declined; and determining that the issue has abated is based at least in part on a reauthorization attempt succeeding.
(see e.g. (345) At step 1180, the inquiry is made whether an approval was received from the ARU 70. If not, the terminal branches to step 1182, where the inquiry is made whether the response to the authorization request was a decline. If the response was a decline, the at step 1184 the terminal displays "DECLINE" on the LCD 123 and the subroutine exits and control is returned to the CREDIT SALE AUTHORIZATION routine 900.
(354) On the other hand, it will be understood that if the transaction was authorized by an off-line authorization code, the transaction data will not have been transferred to the host computer since the terminal was unable to establish communications with the host computer. Thus, the terminal stores all of the transaction data including the cardholder's signature until such time as the terminal again establishes communications with the host computer and is able to transfer transaction data to the host).
Re-claim 5, Nair et al. teach -- The system of claim 2, wherein: the trigger event includes determining that processing performed by a given merchant device has failed; and
(see e.g. (63) In response to a failure to obtain the remotely obtained authorization indicia or a determination not to authorize the transaction by the transaction processing host computer system, the method comprises providing a "call me" indicia to the terminal, and terminating the communication between the terminal and the transaction processing host computer system. In response to being provided the call me indicia, the preferred terminal automatically seeks authorization from an audio response unit (ARU).)
Nair et al. do not explicitly teach the following limitations.
However, Robertson et al. teach - determining that the issue has abated is based at least in part on determining that the given merchant device is processing normally.
(see e.g. [0059] The replication data services 112 receive payment information from one of the forecourt payment devices 12, 18, 28, 30, 40 via the virtual links 113 in a peer-to-peer communication (step 300). The control process then determines if the payment server 23 is still off-line (decision 302).
[0060] FIG. 10 is a flowchart illustration of the processing by the replication data service 112 when transitioning to the online state 202. The control process retrieves data from the local data store and sends the data to the payment server 23 for processing (step 312). The control process 111 then waits for acknowledgement from the payment server 23 that the off-line payment information has been received and processed (decision 314). If it has, the control process 111 deletes the data stored locally and calls upon the replication data services 112 to delete the off-line payment information held in the replication data store 114 (step 320) since the payment information has been properly processed by the payment server 23, and thus does not need to be stored as off-line payment transaction in replication data stores 114. If more stored off-line payment information exists that has not been processed (decision 322), the control process 111 repeats by going back to step 310, otherwise the process ends (step 324).
*****The Examiner note the combination of Nair’s teaching (of processing a transaction of a magnitude that exceeds the floor limit amount), and Robertson’s teaching (of receipt of payment from one of the forecourt payment devices) implies the issue has abated;
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nair et al., and include the steps cited above, as taught by Robertson et al. In this manner, the forecourt devices are not rendered inoperable for handling customer transactions if payment processing is not available as a convenience to customers. (see e.g. [0028]).
Re-claim 6, Bennett et al. teach -- The system of claim 2, wherein: monitoring the merchant processes is performed while the merchant devices are in the online mode;
(see e.g. (63) In response to a failure to obtain the remotely obtained authorization indicia or a determination not to authorize the transaction by the transaction processing host computer system, the method comprises providing a "call me" indicia to the terminal, and terminating the communication between the terminal and the transaction processing host computer system. In response to being provided the call me indicia, the preferred terminal automatically seeks authorization from an audio response unit (ARU).)
Nair et al. do not explicitly teach the following limitations.
However, Robertson et al. teach - and determining that the issue has abated is performed while the first portion of the merchant devices are in the offline mode.
(see e.g. [0059] The replication data services 112 receive payment information from one of the forecourt payment devices 12, 18, 28, 30, 40 via the virtual links 113 in a peer-to-peer communication (step 300). The control process then determines if the payment server 23 is still off-line (decision 302).
[0060] FIG. 10 is a flowchart illustration of the processing by the replication data service 112 when transitioning to the online state 202. The control process retrieves data from the local data store and sends the data to the payment server 23 for processing (step 312). The control process 111 then waits for acknowledgement from the payment server 23 that the off-line payment information has been received and processed (decision 314).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nair et al., and include the steps cited above, as taught by Robertson et al. In this manner, the forecourt devices are not rendered inoperable for handling customer transactions if payment processing is not available as a convenience to customers. (see e.g. [0028]).
Re-claim 7, Nair et al. teach -- The system of claim 2, wherein the first data, when received at the merchant devices, cause the merchant devices to alter the merchant processes based at least in part on the issue associated with the trigger event.
(see e.g. (340) If at step 1159 the transaction is of a magnitude that exceeds the floor limit amount, the program branches to step 1175. At step 1175, the terminal automatically dials a preprogrammed number associated with the transaction processor's off-line authorization source. Such an off-line authorization source in the preferred system is the transaction processor's own ARU 70.)
Re-claim 8, Nair et al. teach -- The system of claim 2, wherein the first data, when received at the merchant devices, cause the merchant devices to alter the merchant processes based at least in part on the issue associated with the trigger event.
(see e. g. 338) At step 1159, the inquiry is first made whether the proposed transaction amount is less than a predetermined floor limit or minimum transaction size for which an authorization is required. If the transaction is beneath the floor limit (e.g., the transaction is less than, say $10.00), a "floor limit" process is carried out at step 1177, comprising in the preferred embodiment the generation of an off-line approval code within the terminal itself, indicative of a less than floor limit transaction.)
Re-claim 8, Nair et al. teach -The system of claim 2, wherein: the trigger event includes detection of a threshold amount of interactions between a given merchant device and customers;
(see e.g. (38) The preferred system 25 also provides an alternative method for providing "off-line" authorization if the terminal 35 is unable to communicate with the host 40, or if the host 40 responds to the terminal's authorization request with a "referral". Off-line authorization is effected automatically under predetermined conditions, namely, if a primary telecommunications network is unable to connect the terminal 35 to the host terminal 40, if a secondary telecommunications network is unable to connect the terminal 35 to the host terminal 40, or if a call me signal is generated at the host. In the preferred embodiment of the terminal 35, an off-line authorization is sought automatically under the indicated conditions.)
Nair et al. do not explicitly teach the following limitations.
However, Robertson et al. teach --determining that the issue has abated includes determining that the interactions no longer satisfy the threshold amount of interactions.
(see e.g. [0004]The off-line payment transactions are processed at a later time when the site controller and/or host processing are back online and operational.).
Robertson et al. also teach --wherein: the trigger event includes detection of a threshold amount of interactions between a given merchant device and customers;
(see e.g. [0055] The control process 99 the forwards the payment information to the payment server 23 for processing, now that it is online (step 260). The control process 99 then waits to receive acknowledgement from the payment server 23 that the off-line payment information has been processed (decision 262). If it has been processed, the payment information is deleted from the DDS 110. If it has not been processed, the control process 99 determines if the payment server 23 has gone off-line (decision 264). If not, the process repeats until the payment server 23 acknowledges processing of the off-line payment information by going back to step 260.)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nair et al., and include the steps cited above, as taught by Robertson et al., as a failsafe measure (see e.g. [0007]).
Claim 12 recites similar limitations as claim 2 and is therefore rejected under the same arts and rationale.
Claim 13 recites similar limitations as claim 3 and is therefore rejected under the same arts and rationale.
Claim 14 recites similar limitations as claim 4 and is therefore rejected under the same arts and rationale.
Claim 15 recites similar limitations as claim 5 and is therefore rejected under the same arts and rationale.
Claim 16 recites similar limitations as claim 6 and is therefore rejected under the same arts and rationale.
Claim 17 recites similar limitations as claim 7 and is therefore rejected under the same arts and rationale.
Claim 18 recites similar limitations as claim 8 and is therefore rejected under the same arts and rationale.
Claims 9-11,19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Nair et al. (US 5428210 A), in view of Robertson et al. (US 20080126213 A1), in further view of Bennett et al. (US 20060004675 A1).
Re-claims 9-11, Nair et al., in view of Robertson et al. do not explicitly teach the limitations as claimed.
However, Bennett et al. teach -- The system of claim 2, wherein: the trigger event includes determining, based at least in part on historical merchant processes, that an increase in an amount of the merchant processes will occur during a period of time; and determining that the issue has abated includes determining that the period of time has lapsed.
(see e.g. [0078] Time in transit data and calculations are generally supported for shipments made during the offline mode. For instance, and as an example, air time in transit data is derived from the UPS Air Commit database and exact time in transit data will be available for all domestic services except UPS Ground. Estimated time in transit data will be used for all UPS Ground shipments wherein time in transit for Ground shipments will be estimated as Zone minus 1 day(s). Generally, though, while in offline mode the time in transit information for shipments will be displayed as "not guaranteed" in the CMS's rate list.)
10.--The system of claim 2, wherein sending the first data to the merchant devices causes at least the portion of the merchant devices to store characteristics associated with the merchant processes, and the operations further comprise receiving the characteristics from the first portion of the merchant devices based at least in part on the first portion of the merchant devices transitioning to the online mode.
(see e.g. [0073] The application files 418 include at least a portion of the CMS and allow a user at the user terminal 412 to process and/or ship packages in the online or offline modes (discussed further herein). The user terminal 412 also includes at least rating files 420 and shipping files 422. The rating files 420 are used to store rating information for carriers that are supported in the offline mode. The information contained within the rating files is used to apply a shipping cost to packages when the user terminal 412 is unable to access the data center 404. The shipping files 422 include the preference settings for the user terminal 412 and the CMS. The shipping files also include information about shipping transactions that are processed in the offline mode, such information may include, for example, package weight and dimensions, address data, "bill to" data, international information, international data, commodity data, carrier and class of service, local retail rates, etc.).
11 --- The system of claim 2, wherein sending the third data further causes a recommendation to be displayed on the first portion of the merchant devices, the recommendation to transition from the offline mode to the online mode.
(see e.g. 0039] FIG. 8 is an exemplary Offline Expiration Warning dialog that is displayed at a user terminal when a user terminal has been operating an in offline mode for an extended period of time).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Nair et al., in view of Robertson et al., and include the steps cited above, as taught by Bennett et al., in order to allow offline processing for business continuance and help ensure that a user of the user terminal is provided with current service offerings and rates. (see e.g. [0019, 0016]).
Claim 19 recites similar limitations as claim 9 and is therefore rejected under the same arts and rationale.
Claim 20 recites similar limitations as claim 10 and is therefore rejected under the same arts and rationale.
Claim 21 recites similar limitations as claim 11 and is therefore rejected under the same arts and rationale.
Response to Arguments
Applicant’s arguments with respect to claims 2-21 have been considered but are moot 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.
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 LUNA CHAMPAGNE whose telephone number is (571)272-7177. The examiner can normally be reached M-F 8:00-5:00.
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.
/LUNA CHAMPAGNE/
Primary Examiner, Art Unit 3627
March 25, 2026
Prosecution Insights