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
Claims 1-20 are pending.
Examiner Notes
Examiner cites particular paragraphs and/or columns and lines in the references as applied to Applicant’s claims for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. The prompt development of a clear issue requires that the replies of the Applicant meet the objections to and rejections of the claims. Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06.
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 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.
Authorization for Internet Communications in a Patent Application
Applicant is encouraged to file an Authorization for Internet Communications in a Patent Application form (http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) along with the response to this office action to facilitate and expedite future communication between Applicant and the examiner. If the form is submitted then Applicant is requested to provide a contact email address in the signature block at the conclusion of the official reply.
Allowable Subject Matter
Claims 5-6, 12-13, and 19-20 are objected to as being dependent upon a rejected base claim, but would be allowable over the prior art of record if rewritten to overcome the applicable rejection(s) and/or objection(s) set forth in this Office action and to include all of the limitations of the base claim and any intervening claims because the examiner found neither prior art cited in its entirety, nor based on the prior art, found any motivation to combine any of the said prior art.
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, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Leonard (US 8,966,487) in view of Itwaru et al. (US 2014/0108252) (hereinafter Itwaru) in view of Spector et al. (US 11,620,639) (hereinafter Spector).
As per claim 1, Leonard primarily teaches the invention as claimed including a method, in a data processing system, for routing transactions to backend application instances (col. 4, ll. 37-41 the transaction application may transmit the transaction request to a messaging platform, such as a message queue manager server, and the messaging platform may transmit the transaction request on to the backend application), the method comprising:
receiving a transaction from a source computing system (col. 4, ll. 37-41 the transaction application may transmit the transaction request to a messaging platform, such as a message queue manager server, and the messaging platform may transmit the transaction request on to the backend application);
routing the transaction to the backend application instance (col. 4, ll. 25-41 transmit the transaction request to the backend server/application);
processing, utilizing the backend application instance, the transaction to generate transaction results (col. 4, ll. 25-36 the transaction application transmits a transaction request via the network to the backend server to be processed by a backend application or backend application instance that executes on the backend server. The backend application may perform the requested transaction processing and return a transaction result to the transaction application); and
returning the transaction results to the source computing system (col. 4, ll. 41-45 the backend application may send the transaction result to the messaging platform, and the messaging platform may send the transaction result on to the transaction application).
Leonard does not explicitly teach:
wherein the transaction comprises at least one identifier of a product or service associated with the transaction;
performing a lookup operation in an in-memory database of transaction routing information, based on the at least one identifier, wherein the transaction routing information maps the at least one identifier to a backend application instance identifier of a backend application instance;
routing the transaction to the backend application instance based on the backend application instance identifier.
However, Itwaru teaches:
wherein the transaction comprises at least one identifier of a product or service associated with the transaction ([0031]-[0032] product identifier/information/data associated with transaction service/data/process);
performing a lookup operation in an in-memory database of transaction routing information, based on the at least one identifier, wherein the transaction routing information maps the at least one identifier to a backend application instance identifier of a backend application instance ([0028] Sound Code contains or is otherwise associated with e.g. via database, via a transaction interface, and/or via payment application provisioned on the consumer device, sound-based transaction data and is used as a lookup or index identifier (ID) by the merchant Point of Sale Terminal e.g. via a merchant application or interface to be provided to the consumer. The Sound Code directly, and/or the sound-based transaction data is received and used by a transaction service to identify transaction information, as mapped in a lookup table. For example, the lookup identifier provided as the sound-based transaction data of "tone A followed by tone B" as obtained from the sound code 3 could be received and used by the transaction service 20 to look up from the lookup table the actual merchant credit card number or other sensitive financial account number, as well as any other merchant data including product pricing, shipping instructions that is mapped to the "tone A followed by tone B" identifier, etc.).
Itwaru and Leonard are both concerned with transaction processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru because it would provide for enhanced security by removing much of the payment processing functions away from merchant point-of-sale terminals and using a mobile device to facilitate a purchase directly from a TV screen, sound portion of a television program, radio broadcast or other sound-based messages e.g. in-store announcements, catalogue, an electronic billboard, poster or any type of sound-based or print/image-based media, without having to place a phone call or manually browse to a website.
Leonard in view of Itwaru do not explicitly teach routing the transaction to the backend application instance based on the backend application instance identifier.
However, Spector teaches routing the transaction to the backend application instance based on the backend application instance identifier (col. 12, ll. 64 to col. 13, ll. 11 receiving, by the backend and from a merchant point of transaction device for a merchant over a second communication network, a second communication comprising a transaction request for the transaction that was received by the merchant point of transaction device from the mobile payment application, the transaction request comprising a unique identifier for the financial instrument, a session identifier, and the mobile wallet computer application identifier; matching, by the backend, the first communication and the second communication using the mobile wallet computer application identifier and the session identifier; and processing the transaction request according to the instruction).
Spector and Leonard are both concerned with transaction processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector because it would provide for the dynamic inclusion of enhanced data in transactions with dynamic enhanced data using a mobile payment application. This can include receiving, from a merchant point of transaction device, a transaction request from a mobile payment application executed by a mobile electronic device, the transaction request comprising a unique identifier for a financial instrument provisioned to a mobile wallet computer application and a payment option selection, and processing the transaction request according to the payment option selection. These transactions can improve security against fraud by providing cryptographic card authentication. Card data may be replaced with tokens that are not usable by third parties, and have no value outside the transaction.
As per claim 8, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
As per claim 15, it has similar limitations as claim 1 and is therefore rejected using the same rationale.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Leonard in view of Itwaru in view of Spector in view of Liu et al. (US 7,631,810) (hereinafter Liu).
As per claim 2, Leonard in view of Itwaru in view of Spector do not explicitly teach wherein the backend application instance is one of a plurality of backend application instances for a same backend application, and wherein the transaction routing information maps the at least one identifier to one backend application instance in the plurality of backend application instances, each backend application instance in the plurality of backend application instances having a different backend application instance identifier.
However, Liu teaches wherein the backend application instance is one of a plurality of backend application instances for a same backend application (abstract multiple instances of the same application for performing wireless transactions), and wherein the transaction routing information maps the at least one identifier to one backend application instance in the plurality of backend application instances (col. 8, ll. 47-55 an application manager for identifying one of the instances associated with the second application identifier as active, for detecting a request from the wireless reader for performing a wireless transaction with an application, the request identifying the application by the second application identifier, and for communicating the request to the identified active instance and identifying the active instance using its respective first application identifier), each backend application instance in the plurality of backend application instances having a different backend application instance identifier (col. 8, ll. 32-46 each of the plurality of instances of the application having a different first application identifier and each of the plurality of instances of the application being of a same type, which has a second application identifier that is different from any of the first application identifiers).
Liu and Leonard are both concerned with transaction processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector in view of Liu because it would provide for advantages of allowing multiple instances of the same application on a wireless smart device. For example, it may be desirable to have multiple payment applications from a single financial institution or brand on a single wireless smart device, to allow a consumer to use a single wireless smart device as both a credit card and a debit card, as both a personal card and a corporate card, as both a card with a high credit limit and a card with a low credit limit, and so on. Another advantage is to allow the user multiple card issuer accounts from different financial institutions, while allowing a user to selectively activate or deactivate individual applications, regardless of type. A user may desire this feature as a means to avoid accidental or malicious transactions from occurring without the user's knowledge, or to avoid the use of a payment account which has reached its credit limit, for example.
As per claim 9, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
As per claim 16, it has similar limitations as claim 2 and is therefore rejected using the same rationale.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Leonard in view of Itwaru in view of Spector in view of Liu in view of Narayanaswamy et al. (US 2025/0045287) (hereinafter Narayanaswamy) in view of Gunter (US 2020/0097390) in view of Boran et al. (US 2020/0250013) (hereinafter Boran).
As per claim 3, Leonard in view of Itwaru in view of Spector in view of Liu do not explicitly teach wherein the backend application is a monolithic application, and wherein the plurality of backend application instances are copies of the monolithic application in a backend component separate from an enterprise application programming interface (API) implementing a lookup service to perform the lookup operation, which are part of a frontend component.
However, Narayanaswamy teaches wherein the backend application is a monolithic application ([0041] a backend application may be a monolithic application).
Narayanaswamy and Leonard are both concerned with transaction processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector in view of Liu in view of Narayanaswamy because it would improve on a cloud-based computing system by providing a search process configured to find the most relevant assets for a user that is more efficient and more accurate, while giving the user a better understanding of how each asset is classified, grouped, and/or related to other assets.
Leonard in view of Itwaru in view of Spector in view of Liu in view of Narayanaswamy do not explicitly teach wherein the plurality of backend application instances are copies of the monolithic application in a backend component separate from an enterprise application programming interface (API) implementing a lookup service to perform the lookup operation, which are part of a frontend component.
However, Gunter teaches wherein the plurality of backend application instances are copies of the monolithic application ([0013] copy the monolithic application) in a backend component ([0050] back-end component)
Gunter and Leonard are both concerned with application processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector in view of Liu in view of Narayanaswamy in view of Gunter because it would provide for a monolithic application packaged as a self-contained, compiled, deployable file such as a Java WAR file. To deploy the application, a developer can simply copy the monolithic application to a server and the application is ready to perform end-to-end functions. This makes testing the monolithic application simple because the monolithic application already includes most, if not all business logic necessary for end-to-end testing
Leonard in view of Itwaru in view of Spector in view of Liu in view of Narayanaswamy in view of Gunter do not explicitly teach separate from an enterprise application programming interface (API) implementing a lookup service to perform the lookup operation, which are part of a frontend component.
However, Boran teaches separate from an enterprise application programming interface (API) implementing a lookup service to perform the lookup operation, which are part of a frontend component ([0002] an API gateway that provides the front-end, say, of the enterprise site xyz.com, may route browser requests addressed to xyz.com/support to one micro-services server (a/k/a “API server” or “micro-server”) hosted by the enterprise, while routing those addressed to xyz.com/orders to another of the enterprise's micro-services servers. Routing decisions are typically made based on lookup tables or other metadata local to the API gateways).
Boran and Leonard are both concerned with transaction processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector in view of Liu in view of Narayanaswamy in view of Gunter in view of Boran because it would provide a way of supporting responses to client requests routed from client digital data devices to micro-servers via an API gateway. The gateway performs selective processing on the API requests after return from the micro-servers but before return to the client devices. This can be done without any a priori knowledge by either the client devices or the micro-servers of whether and how such processing is provided. It has the additional benefit of facilitating uniformity of responses to client requests by disparate micro-servers.
As per claim 10, it has similar limitations as claim 3 and is therefore rejected using the same rationale.
As per claim 17, it has similar limitations as claim 3 and is therefore rejected using the same rationale.
Claims 4, 7, 11, 14, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Leonard in view of Itwaru in view of Spector in view of Fox et al. (US 2022/0391271) (hereinafter Fox).
As per claim 4, Leonard in view of Itwaru in view of Spector do not explicitly teach wherein the at least one identifier for the product or service is registered with an enterprise application programming interface (API) during a digital onboarding of the product or service, by a digital onboarding platform, and stored in the transaction routing information of the in-memory database.
However, Fox teaches wherein the at least one identifier for the product or service is registered with an enterprise application programming interface (API) during a digital onboarding of the product or service, by a digital onboarding platform ([0029] a user may interact with the user device to access a visual dashboard of API-based products displayed via the display device to request a list of registered services for the user's account, a listing of API-based products available to the user's account for registration, a performance metric indicating a performance of at least one API-based product that the user's account is registered with, account information associated with the user's account, and the like. The user may interact with the user device to register or create an account or account profile, register the user's account with an available API-based product, and perform an on-board process for the available API-based product), and stored in the transaction routing information of the in-memory database ([0032] product servers store and provide an API-based product and a configuration file associated with the corresponding API-based product and the configuration file associated with a corresponding API-based product may be stored remote to the product server and [0046] the graphical user interface includes a listing of registered API-based products and additional information associated with each registered API-based product such as an identifier and a type).
Fox and Leonard are both concerned with application processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector in view of Fox because enable a user to navigate through a series of graphical user interfaces as a visual dashboard to interact with various API-based products, access information relating to various API-based products (for example, information enabling the user to better understand the benefits of API-based products), and the like. This would provide a customer on-boarding experience for API-based products or solutions that is greatly simplified and provide a clearer customer value proposition than previous solutions (for example, via one or more visual indicators of the value proposition of the API-based product).
As per claim 7, Leonard in view of Itwaru in view of Spector do not explicitly teach wherein the at least one identifier comprises at least one of a product identifier or a product code.
However, Fox teaches wherein the at least one identifier comprises at least one of a product identifier or a product code ([0048] a user may provide information, such as a name, a type, an identification, and the like, for the new API-based product).
Fox and Leonard are both concerned with application processing in computing environments and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Leonard in view of Itwaru in view of Spector in view of Fox because enable a user to navigate through a series of graphical user interfaces as a visual dashboard to interact with various API-based products, access information relating to various API-based products (for example, information enabling the user to better understand the benefits of API-based products), and the like. This would provide a customer on-boarding experience for API-based products or solutions that is greatly simplified and provide a clearer customer value proposition than previous solutions (for example, via one or more visual indicators of the value proposition of the API-based product).
As per claim 11, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
As per claim 14, it has similar limitations as claim 7 and is therefore rejected using the same rationale.
As per claim 18, it has similar limitations as claim 4 and is therefore rejected using the same rationale.
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Shmulevich et al. (US 2023/0385793) disclose submitting a payment transaction request through the network to a backend application.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Adam Lee whose telephone number is (571) 270-3369. The examiner can normally be reached on M-TH 8AM-5PM.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, Pierre Vital, can be reached at the following telephone number: (571) 272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/Adam Lee/Primary Examiner, Art Unit 2198 September 24, 2026
Prosecution Insights