DETAILED ACTION
Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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-4, 8, 12, 16, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009/0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al.
As to claim 1, Hertel teaches a method comprising:
receiving, by a first computing platform of a system (Transaction Authority 102) a first request (transaction/Instruction 112) for execution of a first transaction from a first client device (Buyer Electronic Wallet 7/User Computer 100), the first computing platform including a transaction service (Seller System 101) (“…FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101…” paragraph 0128);
receiving, by the first computing platform, a second request (Message 115) for execution of the first transaction, from a second client device (Seller System 101) (“…The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…” paragraph 0129); and
determining, based on an execution status of the first transaction (transaction identifier), whether to associate a result (pending transaction) of the first transaction with the second request (The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100) (“…FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101…The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…At this point the transaction proceeds between electronic wallet 7 on the user computer 100 and transaction authority 102 over communication channel 105 separate from the seller system 101. When transaction authority 102 determines that the electronic wallet 7 on the user system 100 has fulfilled the terms and conditions of the pending transaction, the transaction authority 102 transfers resources from one or more buyer accounts to one or more seller accounts. The transaction authority 102 also provides separate confirmations of the transfer of resources to electronic wallet 7 of the user computer 100 and seller system 101 over the respective communication channel 105, 104. Other details optionally can be provided that correspond to the transaction, for example shipping details provided by the buyer. The seller then provides the goods or services to according to the terms and conditions of the transaction…” paragraphs 0128-0130).
Hertel is silent with reference to queuing, by the transaction service, the first request and the second request.
Donnelly teaches queuing (Matching Queue 130), by the transaction service, the first request (Transaction A) and the second request (Transaction B) (“…The matching queue 130 represents a simplified view of such a queue, including a transaction identifier (ID), a delayed field to indicate whether the given transaction request is delayed, and a metric (e.g., value) used to sort transactions in the matching queue 130. In the illustrated example, the value field orders the transactions. Thus, if transaction A were not delayed, as illustrated in entry 135 (e.g., record), transaction A would be matched, and thus completed, before transaction B, illustrated in entry 140. However, when transaction A is delayed, as illustrated in entry 145, the value field for entry 145 is modified to sort lower in the matching queue 130. Thus, the entry 145—the delayed transaction A—sorts lower than the entry 140 for transaction B, resulting in transaction A being matched after transaction B…” Col. 3 Ln. 33-51).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel with the teaching of Donnelly because the teaching of Donnelly would improve the system of Hertel by providing a queue data structure for storing and managing data in a specific order.
As to clam 2, Hertel teaches the method of claim 1, further comprising associating the result of the first transaction with the second request based on the execution status of the first transaction being that the first transaction is currently executing (The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100) (“…FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101…The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…At this point the transaction proceeds between electronic wallet 7 on the user computer 100 and transaction authority 102 over communication channel 105 separate from the seller system 101. When transaction authority 102 determines that the electronic wallet 7 on the user system 100 has fulfilled the terms and conditions of the pending transaction, the transaction authority 102 transfers resources from one or more buyer accounts to one or more seller accounts. The transaction authority 102 also provides separate confirmations of the transfer of resources to electronic wallet 7 of the user computer 100 and seller system 101 over the respective communication channel 105, 104. Other details optionally can be provided that correspond to the transaction, for example shipping details provided by the buyer. The seller then provides the goods or services to according to the terms and conditions of the transaction…” paragraphs 0128-0130).
As to claim 3, Hertel teaches the method of claim 2, further comprising sending the result of the first transaction to the first client device and the second client device (“…The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…” paragraph 0129).
As to claim 4, Hertel teaches the method of claim 1, further comprising: executing the second request using a second transaction based on determining not to associate the result of the first transaction with the second request (step fails) (“…If at any time during the initialization of any of these transaction configurations a step fails, for example one party uses the conveyed transaction identifier with the transaction authority, but the authority has no record of the transaction, or the transaction is not in the correct pending state, or there are some other conditions on the transaction which cannot be met such as the transaction violating the conditions of parental controls put in place by the guardian of a user who is a minor, then the violations are stored at the transaction authority 102 for security and debugging purposes and appropriate messages are sent to the parties. If the failure occurs after the user has applied some payment instruments, the failure rolls back their application…” paragraph 0148).
As to claim 8, Hertel teaches the method of claim 1, further comprising: determining that the first transaction is queued as a pending transaction by the transaction service; and attaching the second request to the pending transaction (The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100) (“…FIG. 10 illustrates one embodiment of a configuration for initiating and conducting a transaction between a buyer and a seller in which transaction identification information flows in the opposite direction from the direction described in FIG. 1d. In this example case, a buyer has selected one or more goods or services for purchase. The buyer electronic wallet 7 on the user computer 100 transmits an instruction 112 over the communication channel 105 to the transaction authority 102 to register a pending transaction. The transaction authority 102 associates a transaction identifier to the pending transaction and transmits a message 113 containing the transaction identifier over communication channel 105 to the electronic wallet 7 on the user computer 100. The electronic wallet 7 on the user computer 100 transmits over communication channel 103 a message 114 containing the transaction identifier to the seller system 101…The seller system 101 then transmits a message 115 containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services to the transaction authority 102. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction. The transaction authority 102 transmits over communication channel a message 116 containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet 7 of the user computer 100 105…At this point the transaction proceeds between electronic wallet 7 on the user computer 100 and transaction authority 102 over communication channel 105 separate from the seller system 101. When transaction authority 102 determines that the electronic wallet 7 on the user system 100 has fulfilled the terms and conditions of the pending transaction, the transaction authority 102 transfers resources from one or more buyer accounts to one or more seller accounts. The transaction authority 102 also provides separate confirmations of the transfer of resources to electronic wallet 7 of the user computer 100 and seller system 101 over the respective communication channel 105, 104. Other details optionally can be provided that correspond to the transaction, for example shipping details provided by the buyer. The seller then provides the goods or services to according to the terms and conditions of the transaction…” paragraphs 0128-0130).
As to claims 12 and 17, see the rejection of claim 1 above, expect for a processing device, memory and a computer program product comprising a computer readable storage medium.
Hertel teaches a processing device (Processor 2), memory (Memory 6) and a computer program product comprising a computer readable storage medium (Storage Device 8).
As to claims 16 and 20, see the rejection of claim 8 above.
Claims 5, 6, 13, 14, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009/0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claims 1. 12 and 17 above, and further in view of U.S. Pub. No. 2006/0080394 A1 to Goodman et al.
As to claim 5, Hertel as modified by Donnelly teaches the method of claim 1, however it is silent with reference to routing, by the transaction service, a callback request associated with the first transaction to the first computing platform.
Goodman teaches routing, by the transaction service (server), a callback request (Requesting 103/Callback Request 313) associated with the first transaction to the first computing platform (Database/Disk 411) (“…FIG. 1 illustrates a flow diagram for a method of enabling asynchronous callback and broadcast notification between a server and a client software application in a web services network, in accordance with an embodiment of the invention. The method illustrated in FIG. 1 comprises processing (101) computer logic instructions in the network; requesting (103), by the client software application, a notification of a completion of the processing of the computer logic instructions; storing (105) the notification request in a registry; queuing (107) the notification request according to a response to the notification request and a list of system endpoints requesting the notification of a completion of the processing of the computer logic instructions; and notifying (109) a recipient system of the completion of the processing of the computer logic instructions upon execution of the queued notification request… The notification comprises a callback request, and wherein the recipient system comprises the client software application corresponding with the system endpoints. The requesting process (103) comprises sending the notification request to the server; identifying a system endpoint requiring notification of completion of the processing of the computer logic instructions; specifying computer logic instructions requiring notification for an identified system endpoint; generating a message of the specific computer logic instructions requiring notification; and sending the message to a register notification interface. In the identifying process, the system endpoint comprises a target Uniform Resource Identifier (URI)… A system running a callback has to know where to send the initial callback request to and where the callback event will be sent when and if the event occurs. Having identified the endpoints, the local application must identify (303) which events it requires notification of. Moreover, if this callback is in response to a message, it is possible that the message is submitting data for processing. Thereafter, an XML message is generated (305) representing the endpoints and the events that are required to complete the callback. The XML message format may be SOAP. The message is then sent (307) to the register callback interface (not shown). The bottom part of FIG. 3 shows that a client or another client is waiting (i.e., listening) (311) for callbacks of message events 309. The processing (313) of the callback request is further illustrated in FIG. 4…The flow process illustrated in FIG. 4 reads from left to right and from top to bottom. The callback request process begins with receiving (313) the callback request (from FIG. 3), which correspondingly identifies (303) events for notification, which identifies (301) the endpoints. This validates the message inputs and stores the information into persistent storage of a database/disk 411…” paragraphs 0034/0035).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Goodman because the teaching of Goodman would improve the system of Hertel and Donnelly Hertel by providing a programming pattern in which a function reference is passed from one context (consumer) to another (provider) such that the provider can call the function.
As to claim 6, Hertel as modified by Donnelly teaches the method of claim 5, however it is silent with reference to sending, by a callback service of the first computing platform, a callback notification to one or more of the first client device or the second client device responsive to receiving the callback request.
Goodman teaches sending, by a callback service of the first computing platform, a callback notification (Notifying (109)/Message Events 309) to one or more of the first client device or the second client device responsive to receiving the callback request (“…and notifying (109) a recipient system of the completion of the processing of the computer logic instructions upon execution of the queued notification request…The bottom part of FIG. 3 shows that a client or another client is waiting (i.e., listening) (311) for callbacks of message events 309. The processing (313) of the callback request is further illustrated in FIG. 4…” paragraphs 0034/0042).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Goodman because the teaching of Goodman would improve the system of Hertel and Donnelly Hertel by providing a programming pattern in which a function reference is passed from one context (consumer) to another (provider) such that the provider can call the function.
As to claims 13 and 18, see the rejection of claim 5 above.
As to claims 14 and 19, see the rejection of claim 6 above.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009/0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claims 1 and 12 above, and further in view of U.S. Pub. No. 2015/0309837 A1 to Shen et al.
As to claim 7, Hertel as modified by Donnelly teaches the method of claim 6, however it is silent with reference to wherein the callback service resides in middleware of the first computing platform.
Shen teaches wherein the callback service (User Callback 110) resides in middleware (Tuxedo) of the first computing platform (“…Alternatively, the transaction server 103 can dynamically register the user callback 110, e.g. based on a shared library 105 associated with the data source 102. For example, Tuxedo can dynamically register the callback when a user connects to an Oracle Database using a non-XA server (e.g. via OCI or Pro*c/c++). Tuxedo can first load Oracle OCI library OCI API dynamically and obtain the related OCI environment handle. Then, Tuxedo can register a user callback via an OCIUserCallbackRegister in the OCISessionBegin function….” Paragraph 0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Shen because the teaching of Shen would improve the system of Hertel and Donnelly Hertel by providing a robust, enterprise-class middleware platform designed for managing distributed transaction processing (TP) and developing high-performance, scalable, mission-critical applications.
As to claim 15, see the rejection of claim 7 above.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009/0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claims 1 and 12 above, and further in view of C.N. No. 103843290 A Shi et al.
As to claim 9, Hertel as modified by Donnelly teaches the method of claim 1, however it is silent with reference to wherein the transaction service resides in middleware of the first computing platform.
Shi teaches wherein the transaction service (Transaction Service 110) resides in middleware (Tuxedo) of the first computing platform (“…Picture 1 according to one embodiment of the present invention showing the support different message queue in a transactional middleware machine environment. As shown in FIG. 1, the transaction server 106 may be the notification table 101 (such as Tuxedo in the bulletin) publishing one or more transaction service 110. notification table adapted to be executed by one or more client terminal 104 and 105 used to locate transaction service provided by the server…Picture 6 is according to one embodiment of the present invention, instructions are for supporting different message queue structure of frame of the transaction server 610 in a transactional middleware machine environment. transaction server 610 blocks can be realized by hardware, software or a combination of hardware and software to perform the principles of the present invention. Those skilled in the art should understand, FIG. 6 described in the blocks may be combined or separated into sub block to realize the above principle of the present invention. Therefore, the description herein may support any possible combination or separation of the functional block or further defined…” paragraph 0021/0039).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Shi because the teaching of Shi would improve the system of Hertel and Donnelly Hertel by providing a robust, enterprise-class middleware platform designed for managing distributed transaction processing (TP) and developing high-performance, scalable, mission-critical applications.
Claims 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2009/0288012 A1 to Hertel et al. in view of U.S. Pat. No. 11,526,943 B1 issued to Donnelly et al. as applied to claim 1 above, and further in view of U.S. Pub. No. 2023/0153826 A1 to Srivastava et al.
As to claim 10, Hertel as modified by Donnelly teaches the of claim 1, however it is silent with reference to wherein the first transaction comprises a configuration management transaction for the first computing platform.
Srivastava teaches wherein the first transaction comprises a configuration management transaction for the first computing platform (Configuration Interface 660) (“…FIG. 8 depicts a flowchart illustrating an example method 800 to dynamically reconfigure a transaction exchange platform, such as transaction exchange platform 320. Method 800 may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method 800…At step 805, the configuration interface 660 may generate a configuration transaction object. The configuration transaction object may be configured to cause a reconfiguration of the transaction exchange platform, one or more workflows, one or more microservices, and/or one or more transactions. The configuration interface 660 may receive a request to generate the configuration transaction object from a user and/or other system processes, such as a watchdog microservice (discussed further below with respect to FIG. 9). The configuration transaction object may comprise transaction details and transaction metadata. The transaction metadata may indicate that the transaction object has a configuration workflow type and a current workflow stage of the configuration transaction object. In some embodiments, the workflow type of the configuration transaction object is a workflow that is modified by the configuration transaction object, and other aspects of the configuration transaction object indicate to a processing microservice that it includes an update to the processing of the microservice. The configuration transaction object may include instructions that, when processed by the microservice, cause the microservice to be reconfigured. Reconfiguration may include modifying which workflow/version/stage the microservice looks for on the SDP, and/or may include modifying the core processing logic employed by the microservice…At step 810, the configuration interface 660 may add the configuration transaction object to the SDP, where it may await processing by first microservice 820 and second microservice 830…The configuration transaction object may be picked up by first microservice 820 and second microservice 830 in a similar fashion to that described above with respect to FIG. 5. At steps 821 and 831, first and second microservices 820 and 830 may poll the SDP to retrieve transactions matching their assigned workflow stages in corresponding workflow types. The configuration transaction objects may have a configuration workflow type, and the microservices may watch for a configuration workflow type object having the workflow stage corresponding to the microservice. At steps 823 and 833, the microservices may retrieve the configuration transaction object for processing…” paragraphs 0121-0123).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Srivastava because the teaching of Srivastava would improve the system of Hertel and Donnelly Hertel by providing a method to dynamically reconfigure a transaction exchange platform to allow for automatic reconfiguration of the transaction exchange platform.
As to claim 11, Hertel as modified by Donnelly teaches the method of claim 10, however it is silent with reference to wherein the configuration management transaction includes a configuration change for the first computing platform.
Srivastava teaches wherein the configuration management transaction includes a configuration change for the first computing platform (Configuration Interface 660) (“…FIG. 8 depicts a flowchart illustrating an example method 800 to dynamically reconfigure a transaction exchange platform, such as transaction exchange platform 320. Method 800 may be performed by any suitable computing device and/or combination of computing devices, referred to as the system implementing method 800…At step 805, the configuration interface 660 may generate a configuration transaction object. The configuration transaction object may be configured to cause a reconfiguration of the transaction exchange platform, one or more workflows, one or more microservices, and/or one or more transactions. The configuration interface 660 may receive a request to generate the configuration transaction object from a user and/or other system processes, such as a watchdog microservice (discussed further below with respect to FIG. 9). The configuration transaction object may comprise transaction details and transaction metadata. The transaction metadata may indicate that the transaction object has a configuration workflow type and a current workflow stage of the configuration transaction object. In some embodiments, the workflow type of the configuration transaction object is a workflow that is modified by the configuration transaction object, and other aspects of the configuration transaction object indicate to a processing microservice that it includes an update to the processing of the microservice. The configuration transaction object may include instructions that, when processed by the microservice, cause the microservice to be reconfigured. Reconfiguration may include modifying which workflow/version/stage the microservice looks for on the SDP, and/or may include modifying the core processing logic employed by the microservice…At step 810, the configuration interface 660 may add the configuration transaction object to the SDP, where it may await processing by first microservice 820 and second microservice 830…The configuration transaction object may be picked up by first microservice 820 and second microservice 830 in a similar fashion to that described above with respect to FIG. 5. At steps 821 and 831, first and second microservices 820 and 830 may poll the SDP to retrieve transactions matching their assigned workflow stages in corresponding workflow types. The configuration transaction objects may have a configuration workflow type, and the microservices may watch for a configuration workflow type object having the workflow stage corresponding to the microservice. At steps 823 and 833, the microservices may retrieve the configuration transaction object for processing…” paragraphs 0121-0123).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Hertel and Donnelly with the teaching of Srivastava because the teaching of Srivastava would improve the system of Hertel and Donnelly Hertel by providing a method to dynamically reconfigure a transaction exchange platform to allow for automatic reconfiguration of the transaction exchange platform.
Response to Arguments
Applicant's arguments filed on 06/17/26 have been fully considered but they are not persuasive.
Applicants argues in substance that (1) the Hertel and Donnelly prior arts do not teach or suggest the receiving, receiving and deleting steps of the independent claims, (2), the Hertel prior arts do not teach or suggest the limitation of claim 2, specifically associating the result of the first transaction because the associating of transaction identifier is not the same a result, (3) the Hertel prior art does not teach or suggest the limitation of claim 3 of sending result to at least two client devices and (4) there is no proper basis for combining the Hertel and Donell prior arts.
The Examiner disagrees.
As to points (1&2), the Hertel prior art discloses a method for initiating a transaction (claimed first request) between a first party (Buyer Electronic Wallet 7/User Computer 100) and a second party (Seller System 101) through a third party transaction system (Transaction Authority 102). The buyer electronic wallet on the user computer generates and transmits a transaction/nstruction over the communication channel to the transaction authority to register a pending transaction. The transaction authority and the user computer generates and associates a transaction identifier to the pending transaction and transmits it as a message containing the transaction identifier over communication channel the seller system (first receiving step). The seller system after processing the transaction generates and transmits a response message containing the transaction identifier, details of the pending transaction and terms and conditions of the selected one or more goods or services back to the transaction authority. The transaction system matches the transaction identifier with the pending transaction and associates the details, terms and conditions with the pending transaction (claimed determining step/claim 2). The transaction authority thereafter transmits over communication channel another message containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet of the user computer (second receiving step).
Contrary to Applicant’s assertion that the disclosed “associating a transaction identifier” is not a result, the transaction authority associates a transaction identifier to the pending transaction and transmits a message containing the transaction identifier over communication channel to the electronic wallet on the user computer which is functionally equivalent a result been returned to the user computer.
As to claim (3), contrary to Applicant’s argument, the Hertel prior art discloses that the transaction authority transmits over communication channel a message containing the details of the transaction and terms and conditions of the pending transaction to the electronic wallet of the user computer 100 105 (two client devices, see paragraph 0129).
As to point (4), Hertel in view of Donnelly prior arts is non-analogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, the Hertel and Donnelly prior art are analogous prior arts because they are both directed to transaction processing system.
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 CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights