Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed 8/28/2024 where claims 1-20 are pending and ready for examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12, 107,922. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims and/or limitations of US Patent No. 12,107,822 are a broadened version of the claims and/or limitations from the Instant Application and therefore it would have been obvious to apply teachings of US Patent No. 12,107,822 to solve and/or contemplate the features of the Instant Application.
The examiner has performed a side by side analysis of all the claims (independent and dependent claims). An example of the analysis of Independent claim 1 is illustrated below.
Instant Application 18/817,458
US Patent No. 12, 107,922
PNG
media_image1.png
168
223
media_image1.png
Greyscale
PNG
media_image2.png
302
268
media_image2.png
Greyscale
The Independent claims (8 and 15) are also rejected as they are merely statutory equivalents comprising the same subject matter
An example of the analysis from a dependent claim is shown below:
Instant Application 18/817,458
US Patent No. 12, 107,922
PNG
media_image3.png
57
296
media_image3.png
Greyscale
PNG
media_image4.png
49
309
media_image4.png
Greyscale
As detailed above all independent and dependent claims have been analyzed. Accordingly, claims 1-20 are rejected.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,882,185 Although the claims at issue are not identical, they are not patentably distinct from each other because the claims and/or limitations of US Patent No. U.S. Patent No. 11,882,185 are a broadened version of the claims and/or limitations from the Instant Application and therefore it would have been obvious to apply teachings of US Patent No. U.S. Patent No. 11,882,185 to solve and/or contemplate the features of the Instant Application.
The examiner has performed a side by side analysis of all the claims (independent and dependent claims). An example of the analysis of Independent claim 1 is illustrated below.
Instant Application 18/817,458
US Patent No. 11,882,185
PNG
media_image1.png
168
223
media_image1.png
Greyscale
PNG
media_image5.png
119
257
media_image5.png
Greyscale
PNG
media_image6.png
265
255
media_image6.png
Greyscale
The Independent claims (8 and 15) are also rejected as they are merely statutory equivalents comprising the same subject matter
An example of the analysis from a dependent claim is shown below:
Instant Application 18/817,458
US Patent No. 11,882,185
PNG
media_image3.png
57
296
media_image3.png
Greyscale
PNG
media_image7.png
48
316
media_image7.png
Greyscale
As detailed above all independent and dependent claims have been analyzed. Accordingly, claim 1-20 are rejected.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4-5, 7-8, 11-12, 14-15 and 18-19 are rejected under 35 USC 102(a)(1) as being anticipated by Smith (US 2014/0046859)
Regarding claim 1, Smith discloses a system comprising:
a processor (See e.g. Claim 1 “... processor ...”); and
memory including instructions that are executable by the processor to cause the processor to (See e.g. Claim 1 “... processor ... memory ...”
The Examiner notes instructions are inherently present in order for the apparatus to execute the following steps):
receive a status indicator of a downstream system processing a transaction request, the status indicator being in a transaction processing format of the downstream system (Smith; Smith teaches an entity receives a document specifying a format (i.e. a status indicator) and where the status indicator is in a format oof the downstream system associated with a rental car service transaction (i.e. transaction request)
The Examiner notes Applicant specifications equates status indicator to a particular electronic format and/or data structure
see e.g. [0033] “ ... inform business partners how to transact rental business with the rental car service provider, the rental car service provider preferably makes a web service specification document available to its business partners. The web service specification document describes the types of web service operations available, where on a network to find the web service operations, and the data requirements for successfully communicating with any particular web service operation. These data requirements include both the types of data needed for a web service operation and the format within which that data must be communicated ...”
see e.g. [0066] “So that the business partner may know how to properly communicate data with the web service connector 200, a web service specification document 206 is preferably made available to business partners by the rental car service provider, through publication thereof by the rental car service provider (e.g., posting document 206 online), communication (email, file transfer, etc.) from the rental car service provider to the business partners, or some other means. The web service specification document 206, which is preferably a Web Service Description Language (WSDL) document 206, describes the types of web service operations available from the rental car service provider, describes where to find the web service, and describes the data requirements for successfully communicating with the web service. In a preferred embodiment, an XML schema 208 comprises part of the WSDL document 206. The XML schema 208 describes these data requirements. A preferred WSDL document 208 for use with the present invention can be generated using ordinary skill in the art upon a review of the teachings herein”
see e.g. Fig. 6 illustrating a transaction flow within the context of downstream processing );
transform the status indicator into a channel-specific format associated with a transaction channel that sent the transaction request by transforming the status indicator from the transaction processing format into the channel- specific format of the transaction channel (Smith; Smith teaches the status indicator is utilized to facilitate a transaction request which subsequently results into a transformation of the status indicator into another format (i.e. channel -specific format);
see e.g.[0067] “ Using the WSDL document 206, a technician of the business partner can appropriately program the business partner computer system 22 to format outgoing messages destined for the rental car service provider such that the data requirements of the XML schema 208 can be met. The technician can also program the business partner computer system 22 such that web service requests from the business partner are directed to the appropriate URL of the rental car service provider's web service, which is also identified in the WSDL document 206 ...”
see e.g. [0070] Once the proper web service operation for the XML document has been identified, The XML data of XML document 240 is passed to transformer software 214 which operates to transform the XML data of the XML document 240 to one or more data objects of the format supported by the backend processing of servers 70. To achieve this transformation, the transformer 212 preferably accesses the WSDL document 206 to identify how to appropriately map the XML data into Java objects 216. In a preferred embodiment, the transformer software 214 is a serialization/deserialization component that functions to transform the XML data of XML document 240 into one or more Java objects 216 that are passed to the business logic resident on backend servers 70.
); and
send the status indicator in the channel-specific format to the transaction channel, the transaction channel configured to perform an action in response to receiving the status indicator (Smith; Smith teaches the status indicator in the channel specific format is passed downstream to back end servers to execute the request provided by the request entity resulting in confirmation messages, reservations (i.e. actions);
see e.g. [0075] “Java objects 216 are passed to business logic on servers 70 that process the data contained in the Create Reservation request (such as insured/claimant name, start date/end date for reservation, pick-up location, etc.) using business logic and program calls to the AS/400 32 as necessary to create a reservation as requested by the business partner. Once the reservation has been created, a confirmatory message can be sent back to the business partner, either through the web connector block of FIG. 5 or through the web services connector 200 (in which case the preceding steps will be reversed, as explained above)”
Regarding claim 4, Smith discloses the system of claim 1, wherein the memory further includes instructions that are executable by the processor for causing the processor to: prior to transforming the status indicator into the channel-specific format: determining that the status indicator is associated with the transaction request from the transaction channel (Smith ([0067]) as Smith teaches that web service requests from the business partner are directed to the appropriate web service URL identified in the WSDL document, thereby enabling the system to determine the associated transaction request and corresponding service operation prior to performing the subsequent message transformation).
Regarding claim 5, Smith discloses the system of claim 1, wherein the status indicator comprises an acknowledgement or a confirmation of an execution of the transaction request based on a specification of the transaction channel (Smith;
See e.g. [0018] “ ... send confirmatory communications to the user that the reservation has been received and entered into the provider's system for fulfillment, custom report design including the capability to save and re-generate the custom report upon user command, increased flexibility to process and pay invoices, etc.) Regarding claim 7, Smith discloses The system of claim 1, wherein the channel-specific format comprises a comma-separated values file, a messaging queue message, or an extensible markup language file (Smith;
see e.g.. [0033] In a preferred implementation of the present invention, the rental car service provider uses variable format variable length data messages (preferably Extensible Markup Language (XML) documents) as the mode of communication between itself and its business partners. To inform business partners how to transact rental business with the rental car service provider, the rental car service provider preferably makes a web service specification document available to its business partners)
Regarding claim 8, Smith discloses a non-transitory computer-readable medium comprising instructions that are executable by a processor for causing the processor to:
receive a status indicator of a downstream system processing a transaction request, the status indicator being in a transaction processing format of the downstream system (Smith; Smith teaches an entity receives a document specifying a format (i.e. a status indicator) and where the status indicator is in a format oof the downstream system associated with a rental car service transaction (i.e. transaction request)
The Examiner notes Applicant specifications equates status indicator to a particular electronic format and/or data structure
see e.g. [0033] “ ... inform business partners how to transact rental business with the rental car service provider, the rental car service provider preferably makes a web service specification document available to its business partners. The web service specification document describes the types of web service operations available, where on a network to find the web service operations, and the data requirements for successfully communicating with any particular web service operation. These data requirements include both the types of data needed for a web service operation and the format within which that data must be communicated ...”
see e.g. [0066] “So that the business partner may know how to properly communicate data with the web service connector 200, a web service specification document 206 is preferably made available to business partners by the rental car service provider, through publication thereof by the rental car service provider (e.g., posting document 206 online), communication (email, file transfer, etc.) from the rental car service provider to the business partners, or some other means. The web service specification document 206, which is preferably a Web Service Description Language (WSDL) document 206, describes the types of web service operations available from the rental car service provider, describes where to find the web service, and describes the data requirements for successfully communicating with the web service. In a preferred embodiment, an XML schema 208 comprises part of the WSDL document 206. The XML schema 208 describes these data requirements. A preferred WSDL document 208 for use with the present invention can be generated using ordinary skill in the art upon a review of the teachings herein”
see e.g. Fig. 6 illustrating a transaction flow within the context of downstream processing;
transform the status indicator into a channel-specific format associated with a transaction channel that sent the transaction request by transforming the status indicator from the transaction processing format into the channel-specific format of the transaction channe channel (Smith; Smith teaches the status indicator is utilized to facilitate a transaction request which subsequently results into a transformation of the status indicator into another format (i.e. channel -specific format);
see e.g.[0067] “ Using the WSDL document 206, a technician of the business partner can appropriately program the business partner computer system 22 to format outgoing messages destined for the rental car service provider such that the data requirements of the XML schema 208 can be met. The technician can also program the business partner computer system 22 such that web service requests from the business partner are directed to the appropriate URL of the rental car service provider's web service, which is also identified in the WSDL document 206 ...”
see e.g. [0070] Once the proper web service operation for the XML document has been identified, The XML data of XML document 240 is passed to transformer software 214 which operates to transform the XML data of the XML document 240 to one or more data objects of the format supported by the backend processing of servers 70. To achieve this transformation, the transformer 212 preferably accesses the WSDL document 206 to identify how to appropriately map the XML data into Java objects 216. In a preferred embodiment, the transformer software 214 is a serialization/deserialization component that functions to transform the XML data of XML document 240 into one or more Java objects 216 that are passed to the business logic resident on backend servers 70.l; and
send the status indicator in the channel-specific format to the transaction channel, the transaction channel configured to perform an action in response to receiving the status indicator(Smith; Smith teaches the status indicator in the channel specific format is passed downstream to back end servers to execute the request provided by the request entity resulting in confirmation messages, reservations (i.e. actions);
see e.g. [0075] “Java objects 216 are passed to business logic on servers 70 that process the data contained in the Create Reservation request (such as insured/claimant name, start date/end date for reservation, pick-up location, etc.) using business logic and program calls to the AS/400 32 as necessary to create a reservation as requested by the business partner. Once the reservation has been created, a confirmatory message can be sent back to the business partner, either through the web connector block of FIG. 5 or through the web services connector 200 (in which case the preceding steps will be reversed, as explained above)”
Regarding claim 11, Smith discloses the The non-transitory computer-readable medium of claim 8, further comprising instructions that are executable by the processor to cause the processor to: prior to transforming the status indicator into the channel-specific format: determine that the status indicator is associated with the transaction request from the transaction channel (Smith ([0067]) as Smith teaches that web service requests from the business partner are directed to the appropriate web service URL identified in the WSDL document, thereby enabling the system to determine the associated transaction request and corresponding service operation prior to performing the subsequent message transformation.
Regarding claim 12, Smith discloses the non-transitory computer-readable medium of claim 8, wherein the status indicator comprises an acknowledgement or a confirmation of an execution of the transaction request based on a specification of the transaction channel channel (Smith;
See e.g. [0018] “ ... send confirmatory communications to the user that the reservation has been received and entered into the provider's system for fulfillment, custom report design including the capability to save and re-generate the custom report upon user command, increased flexibility to process and pay invoices, etc.) . Regarding claim 14, Smith discloses the non-transitory computer-readable medium of claim 8, wherein the channel-specific format comprises a comma-separated values file, a messaging queue message, or an extensible markup language file (Smith;
see e.g.. [0033] In a preferred implementation of the present invention, the rental car service provider uses variable format variable length data messages (preferably Extensible Markup Language (XML) documents) as the mode of communication between itself and its business partners. To inform business partners how to transact rental business with the rental car service provider, the rental car service provider preferably makes a web service specification document available to its business partners)
Regarding claim 15, Smith discloses a method comprising:
receiving a status indicator of a downstream system processing a transaction request, the status indicator being in a transaction processing format of the downstream system(Smith; Smith teaches an entity receives a document specifying a format (i.e. a status indicator) and where the status indicator is in a format oof the downstream system associated with a rental car service transaction (i.e. transaction request)
The Examiner notes Applicant specifications equates status indicator to a particular electronic format and/or data structure
see e.g. [0033] “ ... inform business partners how to transact rental business with the rental car service provider, the rental car service provider preferably makes a web service specification document available to its business partners. The web service specification document describes the types of web service operations available, where on a network to find the web service operations, and the data requirements for successfully communicating with any particular web service operation. These data requirements include both the types of data needed for a web service operation and the format within which that data must be communicated ...”
see e.g. [0066] “So that the business partner may know how to properly communicate data with the web service connector 200, a web service specification document 206 is preferably made available to business partners by the rental car service provider, through publication thereof by the rental car service provider (e.g., posting document 206 online), communication (email, file transfer, etc.) from the rental car service provider to the business partners, or some other means. The web service specification document 206, which is preferably a Web Service Description Language (WSDL) document 206, describes the types of web service operations available from the rental car service provider, describes where to find the web service, and describes the data requirements for successfully communicating with the web service. In a preferred embodiment, an XML schema 208 comprises part of the WSDL document 206. The XML schema 208 describes these data requirements. A preferred WSDL document 208 for use with the present invention can be generated using ordinary skill in the art upon a review of the teachings herein”
see e.g. Fig. 6 illustrating a transaction flow within the context of downstream processing );
transforming the status indicator into a channel-specific format associated with a transaction channel that sent the transaction request by transforming the status indicator from the transaction processing format into the channel-specific format of the transaction channel(Smith; Smith teaches the status indicator is utilized to facilitate a transaction request which subsequently results into a transformation of the status indicator into another format (i.e. channel -specific format);
see e.g.[0067] “ Using the WSDL document 206, a technician of the business partner can appropriately program the business partner computer system 22 to format outgoing messages destined for the rental car service provider such that the data requirements of the XML schema 208 can be met. The technician can also program the business partner computer system 22 such that web service requests from the business partner are directed to the appropriate URL of the rental car service provider's web service, which is also identified in the WSDL document 206 ...”
see e.g. [0070] Once the proper web service operation for the XML document has been identified, The XML data of XML document 240 is passed to transformer software 214 which operates to transform the XML data of the XML document 240 to one or more data objects of the format supported by the backend processing of servers 70. To achieve this transformation, the transformer 212 preferably accesses the WSDL document 206 to identify how to appropriately map the XML data into Java objects 216. In a preferred embodiment, the transformer software 214 is a serialization/deserialization component that functions to transform the XML data of XML document 240 into one or more Java objects 216 that are passed to the business logic resident on backend servers 70.
); and
sending the status indicator in the channel-specific format to the transaction channel, the transaction channel configured to perform an action in response to receiving the status indicator(Smith; Smith teaches the status indicator in the channel specific format is passed downstream to back end servers to execute the request provided by the request entity resulting in confirmation messages, reservations (i.e. actions);
see e.g. [0075] “Java objects 216 are passed to business logic on servers 70 that process the data contained in the Create Reservation request (such as insured/claimant name, start date/end date for reservation, pick-up location, etc.) using business logic and program calls to the AS/400 32 as necessary to create a reservation as requested by the business partner. Once the reservation has been created, a confirmatory message can be sent back to the business partner, either through the web connector block of FIG. 5 or through the web services connector 200 (in which case the preceding steps will be reversed, as explained above).
Regarding claim 18, Smith discloses .the method of claim 15, further comprising:
prior to transforming the status indicator into the channel-specific format: determining that the status indicator is associated with the transaction request from the transaction channel(Smith ([0067]) as Smith teaches that web service requests from the business partner are directed to the appropriate web service URL identified in the WSDL document, thereby enabling the system to determine the associated transaction request and corresponding service operation prior to performing the subsequent message transformation).
Regarding claim 19, Smith discloses the method of claim 15, wherein the status indicator comprises an acknowledgement or a confirmation of an execution of the transaction request based on a specification of the transaction channel (Smith;
see e.g. [0018] “ ... send confirmatory communications to the user that the reservation has been received and entered into the provider's system for fulfillment, custom report design including the capability to save and re-generate the custom report upon user command, increased flexibility to process and pay invoices, etc.).
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, 9, and 16 are rejected under 35 USC 103 as being unpatentable over Smith in view of Morris (US 2018/0088991)
Regarding claim 2, Smith discloses the system of claim 1, wherein the memory includes instructions that are executable by the processor to cause the processor to transform the status indicator into the channel-specific format by:
transforming the status indicator into an internal specific format of a transaction management layer that receives the transaction request based on a first mapping from the transaction processing format to the internal specific format(Smith, Per independent claim 1 Smith executes a first mapping ([0070]);
Smith does not expressly disclose:
transforming the status indicator into the channel-specific format of the transaction channel based on a second mapping from the internal specific format to the channel-specific format.
However in analogous art Morris discloses:
transforming the status indicator into the channel-specific format of the transaction channel based on a second mapping from the internal specific format to the channel-specific format (Morros;
see e.g. [0049] communicating via one or more application layer protocols. Exemplary application protocols include hypertext transfer protocol (HTTP) and instant messaging and presence (XMPP-IM) protocol. Matching protocols enabling applications 403 to communicate via network 504 in FIG. 5 are not required, if communication is via a protocol gateway or other translator
A person of ordinary skill would recognize that multiple format or protocol mappings a re common in middleware gateway systems, and would apply such known techniques to Smith’s system in order to enable communication across different transaction channels.
).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Morris’ protocol gateway. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of providing multiple protocol translations.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Morris’ protocol gateway. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of providing multiple protocol translations.
Regarding claim 9, claim 9 comprises the same and/or similar subject matter as claim 2 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 16, claim 16 comprises the same and/or similar subject matter as claim 2 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 3, 10, and 17 are rejected under 35 USC 103 as being unpatentable over Smith in ofr Morris and in further view of Smith_2 ( US 20130198726)
Regarding claim 3, Smith in view of Morris disclose the system of claim 2, wherein the memory further includes instructions that are executable by the processor for causing the processor to:
access the first mapping and the second mapping from a database storing the first mapping between the transaction processing format and the internal specific format and a set of mappings between a plurality of channel-specific formats for a plurality of transaction channels and the internal specific format, wherein the set of mappings includes the second mapping, and wherein the plurality of transaction channels includes the transaction channel (The combined solution provides for the translator/gateway components to necessarily rely on mapping of information defining how data in one format corresponds to data in another format. Because Smith teaches repeatedly performing transaction data to back end tata objects and Morris teaches enabling communication across differing protocols . through a gateway or translator, the system must access mapping information specifying the correspondence between the transaction processing format, the internal representation, and the channel-specific format. Such mapping information must be stored and retrieved during operation so the transformations can be performed when processing transaction requests. Accordingly the mapping information would reasonably be stored in an accessed from a data store or database by the system)
As evidence of the rationale above Smith_2 discloses:
database (Smith_2; Smith_2 within the context of protocol translation utilizes a conventional database for storage;
see e.g. [0063] “ ... the mapping of the predetermined command of the first computer operating language to a corresponding protocol command of a different computer operating language may also include retrieving a translation table from the database 640 and matching the action to the predetermined command stored in the translation table ... “
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Smith_2’s database. The motivation being the combined solution provides for implementing a known technique and increases efficiencies of transaction processing.
Moreover, tt would have been obvious to configure the transaction processing system of Smith to store and access the mapping information used for protocol/format translation in a database as taught by Smith_2, which discloses retrieving a translation table from a database for mapping commands between different protocol formats. Incorporating such database stored mapping information into Smith’s translator gateway architecture would have been a predictable implementation choice to manage and repeatedly apply the format/protocol mappings used during transaction processing.
Regarding claim 10, claim 10 comprises the same and/or similar subject matter as claim 3 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 17, claim 17 comprises the same and/or similar subject matter as claim 3 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 6,13, and 20 are rejected under 35 USC 103 as being unpatentable over Smith in view of Altschuler (US 2016/0148289)
Regarding claim 6, Smith discloses The system of claim 1, Smith does not expressly disclose wherein the transaction request comprises a wire transfer request and the downstream system comprises a wire transfer system.
However in analogous art Altschuler discloses:
wherein the transaction request comprises a wire transfer request and the downstream system comprises a wire transfer system (Altschuler;
see e.g. [0068] In accordance with an embodiment of the present invention, the EXPCommerce 613 comprises a Transaction processing unit 650 to enable the buying and selling of a product through the EXPCommerce Website(s), the user-branded EXPCommerce websites, and across multiple other third-party online and offline transaction channels. The Transaction processing unit 650 contains a settlement system that integrates with third-party payment processing systems such as PayPal®, Google Checkout.sup.SM, Western Union®, credit card gateways and other systems to process credit or debit card payments, electronic checks, wire transfers, bank account transactions and the like.
It would have been obvious to configure the system of Smith to process wire transfer requests using wire transfer system as it would have been a predictable implementation choice motivated by the need to support multiple payment transaction channels in electronic commerce systems.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Altschuler’s wire transfers/transaction systems. The motivation being the combined solution provides for implementing a known technique resulting in increased commerce platforms for consumers.
Regarding claim 13, claim 13 comprises the same and/or similar subject matter as claim 6 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 20, claim 20 comprises the same and/or similar subject matter as claim 6 and is considered an obvious variation; therefore it is rejected under the same rationale.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304
/TODD L BARKER/Primary Examiner, Art Unit 2449