DETAILED ACTION
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 .
Priority
Applicant claims continuation priority to U.S. Patent Application No. 18/215,005 filed June 27, 2023, now patent number 12,125,084, which is a continuation of U.S. Patent Application No. 17/321,071, filed May 14, 2021, now patent number 11,710,163, which is a continuation of U.S. Patent Application No. 16/518,112, now patent number 11,010,804, filed 7/22/2019, which claims continuation priority to U.S. Patent Application No. 15/925,316, now patent number 10,380,665, filed 3/19/2018, which claims continuation priority to U.S. Patent Application No. 15/482,334, now patent number 9,940,653, filed 4/7/2017.
Information Disclosure Statement
The IDS submitted 9/23/2024 was previously considered.
Terminal Disclaimer
The terminal disclaimer filed on 4/28/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of Patent Number 12,125,084, Patent Number 11,710,163, Patent Number 11,010,804, Patent Number 10,380,665, and Patent Number 9,940,653 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Status of Claims
Applicant’s amended claims, filed 4/28/2026, have been entered. Claims 1-3, 16-18, and 20 have been amended. Claims 1-20 are currently pending in this application and have been examined.
Interview
Examiner invites the representative of this application to contact the Examiner to schedule an interview to expedite prosecution of this application.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-9, 11-14, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Isaacson et al. (US 2016/0379213 A1 [previously recited]) in view of Graylin et al. (US 2010/0299212 A1 [previously recited]).
Regarding claim 1, Isaacson et al., hereinafter Isaacson discloses a method comprising:
receiving, at an interface of a computer system comprising a processor and memory, a request from a third party application (Figs. 8, 15, 19, and 33; ¶0166 [API receives input data from user] in view of ¶0137 [wherever a “website” is mentioned, an application or site could also apply, such as when a mobile application is used to access data], ¶0170 [social networking mobile device applications], and ¶0231) for a product from within the third party application (Fig. 2A; ¶0081 [the user clicks on the Amazon.com one-click purchasing button 206. Thus, from this field, the system receives that input, processes the input, and can execute a purchase, just as though the user had navigated through Amazon.com to an iPhone 5S, having 32 GB of storage, and a silver color, and had just clicked on the one-click purchase button. However, in this first example, the user did not need to navigate to Amazon.com but rather was able to make a one-click purchase from a separate website, namely the one-search.com website], ¶¶0166-0167, ¶¶0172-0173, and ¶¶0276-0279), the request comprising an identifier for the product (¶0171 [receiving text-based user input in the input field and determining whether the text-based user input is associated with a product database of products for sale from a merchant using the text-based user input to yield a first determination]);
generating, by the computer system, a customized user interface based on the identifier for the product, an identifier for the merchant, and information associated with a third party system that provided the third party application to a user device (Figs. 1-2A [“Amazon one click” is comparable to an identifier of a merchant system], 3 [[“Amazon purchase” and “Apple Purchase” are comparable to an identifier of a merchant system], 6, 8, 11-13, 14B, 14C, 20, 27, 30-33; ¶¶0166-0168 [API 1502 can handle all of these tasks automatically in response to an API request, and pass that information back to the browser at the first website 1510, which presents these possible destinations or actions to the user] and ¶0232 [the browser can navigate to a stage where the order has already been placed, such as the page that would load after the user clicks the purchase button 2008. Notably, the merchant has some branding on screen 2004. Where the purchase button 2008 is used to process a payment using the stored payment information at the search engine site, as can be appreciated via the disclosure here, the coordination between the payment processing on the search engine side of the API, and the delivery being handled on the merchant side of the API, makes the process more simple and easy for the buyer, thus increasing the chances that a sale will occur. The screen 2004 can be hosted by the search engine/social media site and/or the merchant. The system can populate other details of the shopping cart automatically on behalf of the user, as well. The system can even create a new account at the merchant on behalf of the user, if the user does not have an account with that merchant. In this way, the system enables a user to access websites, through a unified search field, as if they were one-click purchase merchant websites, even if the user has not previously registered with that merchant or if the merchant does not offer an “Amazon style” one-click purchase interface. For example, the first website entity associated with offering the generalized input field can process the payment for an item based on payment account information it stores and coordinate with the merchant on finalizing delivery of the item.] in view of ¶¶0172-0173);
serving, by the computer system, the customized user interface to the third party application to cause the third party application to render the customized user interface displaying the identifier for the product, the identifier for the merchant, and a checkout user interface within at least a portion of a third party application user interface(Figs. 8, 15, 19, and 33; ¶0114 in view of ¶0137 [wherever a “website” is mentioned, an application or site could also apply, such as when a mobile application is used to access data], ¶0170 [social networking mobile device applications], and ¶¶0231-0232), wherein the customized user interface is styled based on the information associated with the third party system to have an appearance consistent with an appearance of the third party application user interface (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 15, 19, 20, 27, 30-33; ¶¶0231-0232 [In the first user interface 2000, the user has entered the text “Buy ACME toaster 4.5” in the unified input field 2002 of a web page in a browser…The screen 2004 can be hosted by the search engine/social media site…the system enables a user to access websites, through a unified search field, as if they were one-click purchase merchant websites] in view of ¶¶0166-0168 [A one-search server, a web server, social media site or some other computing device or computing devices can provide services accessible via the API 1502. The services provided by the API 1502 can be accessible from a web server serving pages to web browsers or other web clients, an application for mobile devices, or from a web browser, such as through a JavaScript call to the API 1502… If the action is a one-click purchase action with the second website 1508, the API 1502 can, on behalf of the user or the browser 1504, negotiate with the second website 1508 to navigate to the appropriate location at the second website 1508, populate the appropriate data fields automatically, create an account (if necessary) or log in to an account for the user, and so forth. The API 1502 can handle all of these tasks automatically in response to an API request, and pass that information back to the browser at the first website 1510, which presents these possible destinations or actions to the user.] and ¶¶0172-0173); and
receiving, via the customized user interface, user data for a user who caused the request for the product within the third party application (¶0094 in view of ¶¶0172-0173).
While Isaacson discloses an API receiving data from a user including interactive information and text query information that is used to determine purchase intent and if the data is associated with a product database of products for sale from a merchant and presenting results based on the information (¶¶0166-0168 and ¶¶0171-0173), Isaacson does not explicitly disclose the information includes an identifier for the merchant associated with the product and generating a user interface based on the identifier for the merchant. In the field of purchasing products using an application executing on a consumer device (abstract), Graylin et al., hereinafter Graylin, teaches each product offer is associated with a product offer identifier and a specific merchant identifier and displaying (i.e., generating) a user interface based on these identifiers (¶0015 and ¶¶0050-0055). The step of Graylin is applicable to the method of Isaacson as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the request and the generated user interface as taught by Isaacson with the specific merchant identifier as taught by Graylin. One of ordinary skill in the art at the time of filing would have been motivated to expand the method of Isaacson in order to let many merchants present offers to a mobile customer in a single mobile application (Graylin ¶0005).
Regarding claim 2, Isaacson in view of Graylin teach the method of claim 1. Isaacson further teaches a method further comprising:
storing, in a customer profile, the user data collected from the user during a purchase of the product, wherein the customer profile is stored in a customer profile data store of the computer system and associated with a third party that provides the third party application, and wherein data of the customer profile comprises one or more of: a user name, user contact information, a shipping address, and user financial data (Figs. 1-2A, 15, 33-35; ¶0012, ¶0014, ¶0078 [user information, debit/credit card information, address information, etc., is stored in a user profile and available], ¶0081, ¶0107 [the system has the user profile, purchasing (credit/debit/PayPal, etc. account), address and any other information and can move seamlessly between purchasing/processing entities with ease. When the user sets up a profile and account on the website, all of these permissions and accessibility capability is established and approved], ¶0166, ¶0231 [database 1914 of payment and delivery data or other personal data about the user 1902 to populate data fields at the merchant website 1916… The server 1910 can continuously receive additional data entered by the user in the unified input field via, and update or modify data entered… server 1910 can update the network-based payment and delivery data 1914 from time to time based on information processed from the local payment and delivery data 1908, or based on user input.], ¶0235 [a profile stored in a browser cache or a profile stored on a server.], ¶¶0276-0277, ¶¶0277-284 and ¶0290 [the payment/delivery information is stored at the search entity, social networking entity, a separate agent, a browser, or in any other location so that the data can be applied to a purchasing transaction in such a way that the user does not need to manually fill out fields (such as address, credit card number, etc.) to complete a purchase]).
While Isaacson teaches maintaining purchase information from multiple interfaces (¶0008) and not sharing payment information (¶0209, ¶0266, and ¶0303), Isaacson does not explicitly disclose wherein a plurality of different customer profiles is maintained by the computer system for the user in the customer profile data store, each of the different customer profiles is associated with a different third party system, and customer profile data for the user is not shared between different customer profiles. However Graylin further teaches a commerce window gateway that uses numerous payment processors and associates different payment processors with different merchants and stores multiple user payment profiles from which the user can choose from stored in user accounts or e-wallets to complete the transaction, wherein account information isn’t shared between profiles (Figs. 1A [elements 161-163], 1B [elements 180 and 182] 3 [elements 160-163], 8-11 [choosing account to pay with and password], 14A, 14B; ¶¶0039-0040, ¶¶0045-0046 in view of ¶0055). The step of Graylin is applicable to the method of Isaacson as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the stored payment information as taught by Isaacson with the numerous payment processors and stored payment profiles as taught by Graylin. One of ordinary skill in the art at the time of filing would have been motivated to expand the method of Isaacson in order to store multiple payment instruments for the user to select and associate the correct payment processor with the correct merchant (Graylin ¶0055 in view of ¶0016).
Regarding claim 3, Isaacson in view of Graylin teach the method of claim 2, Isaacson further discloses further comprising:
processing, by the computer system, a transaction initiated by the user from the third party application (Figs. 1-2A, 15, 33-35; ¶0019, ¶0021, ¶0024, ¶0231, ¶0106 [switch the order from one merchant to another merchant], ¶¶0277-0284);
receiving user identification data during the processing of the transaction (¶¶0166-0168 [stored payment information for the user at the generalized search engine] in view of ¶0155 and ¶0174);
determining, by the computer system, that the user identification data is associated in the customer profile with the third party system that provides the third party application (¶0166-0168 and ¶¶0173-0174 [payment information stored through the social networking site or another service like Apple Pay or Paypal such that products from all different merchants that are offered through this service can be purchased without needing to be transferred to that merchant for inputting payment information]);
accessing, based on the user identification data, one or more items of user data including one or more of: the user name, the user contact information, the shipping address, and the user financial data from the customer profile (Figs. 1-2A, 15, 33-35; ¶0012, ¶0014, ¶0107, ¶0231, ¶¶0276-0277, ¶¶0277-284);
automatically entering the accessed one or more items of user data within a user interface served to the third party application during the transaction (¶¶0163-0168 and ¶¶0171-0173); and
utilizing the automatically entered user financial data to complete a purchase of a different product during the transaction (¶0172 in view of ¶0231).
Regarding claim 4, Isaacson in view of Graylin teach the method of claim 3, Isaacson further discloses wherein a second merchant provides the different product for purchase through the third party application (Figs. 1-2A, 13, 15, 33-35; ¶0019, ¶0021, ¶0024, ¶0231, ¶0106 [switch the order from one merchant to another merchant], ¶0155, ¶¶0277-0284).
Regarding claim 5, Isaacson in view of Graylin teach the method of claim 1, Isaacson further discloses wherein the information associated with the third party system comprises branding information indicative of one or more of a logo associated with the third party, a color scheme used by the third party application user interface, and a font used by the third party application user interface (Fig. 2A [www.onesearch.com]; Examiner notes text written in a font, Fig. 4A, Figs. 13, 15, and 17A-19; ¶0155 [various merchant branding can be provided] and ¶0088 [The one-search.com system can display the logo of each pizza merchant, with a summary of the order that would be placed and the associated cost if the user clicks on the logo], ¶¶0172-0173 in view of ¶0166 [communications via an application programming interface (API)] and ¶¶0207-0211).
Regarding claim 6, Isaacson in view of Graylin teach the method of claim 1, Isaacson further discloses
selecting, by the computer system, one or more products available for purchase from the merchant, the one or more products being dynamically selected based on content in the third party application (¶0157);
generating, by the computer system, a second customized user interface comprising one or more identifiers corresponding to the one or more products (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 20, 27, 30-33; ¶0157, ¶¶0166-0168 and ¶0232 in view of ¶¶0172-0173); and
serving, by the computer system, the second customized user interface to the third party application to cause the third party application to render the second customized user interface displaying the one or more identifiers corresponding to the one or more products within at least a portion of the third party application user interface, wherein the second customized user interface is styled based on the information associated with the third party system to have an appearance consistent with the appearance of the third party application user interface (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 15, 19, 27, 30-33; ¶0157, ¶0114, ¶0137, ¶¶0231-0232, ¶¶0166-0168 and ¶¶0172-0173).
Regarding claim 7, Isaacson in view of Graylin teach the method of claim 6, Isaacson further discloses wherein the one or more products are dynamically selected further based on a purchase history associated with a user of the user device (Fig. 3; ¶0157 in view of ¶0104).
Regarding claim 8, Isaacson in view of Graylin teach the method of claim 6, Isaacson further discloses wherein the one or more products are dynamically selected further based on user preferences of a user of the user device and accessible to the third party application (Fig. 3; ¶0157 in view of ¶0144, ¶0160).
Regarding claim 9, Isaacson in view of Graylin teach the method of claim 6, Isaacson further discloses wherein the one or more products are selected from a merchant product feed comprising product information of a plurality of products offered by the merchant, the product information comprising product descriptions, shipment options, and images of the plurality of products (Fig. 3; ¶0157 in view of ¶0104, ¶0211, ¶0227, ¶0277).
Regarding claim 11, Isaacson discloses a system comprising:
a processor (Figs. 7, 19; ¶¶0128-0130); and
a memory connected to the processor and storing instructions that, when executed by the processor (Figs. 7, 19; ¶¶0128-0130), cause the processor to:
select one or more products available from a merchant, the one or more products being dynamically selected based on content to be displayed in a third party application on a user device (Fig. 5; ¶0157 in view of ¶¶0088-0089, ¶¶0116-0117, ¶¶0072-0073);
generate a customized user interface comprising one or more identifiers corresponding to the one or more products (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 20, 27, 30-33; ¶0157, ¶¶0166-0168 and ¶0232 in view of ¶¶0172-0173, ¶¶0088-0089, ¶¶0072-0073);
transmit the customized user interface to the third party application to cause the third party application to render the customized user interface displaying the one or more identifiers corresponding to the one or more products within at least a portion of a user interface of the third party application, wherein the customized user interface is styled based on information associated with the third party application to have an appearance-consistent with an appearance that of the user interface of the third party application (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 15, 19, 27, 30-33; ¶0157, ¶0072, ¶¶0088-0089, ¶¶0104-0105, ¶0114, ¶0137, ¶¶0231-0232, ¶¶0166-0168 and ¶¶0172-0173); and
receive a request from the third party application for a product of the one or more products, the request comprising an identifier for the product (Figs. Fig. 2A, 8, 15, 19, and 33; ¶0166 [API receives input data from user], ¶0114 [input field is part of an application downloadable or installable on a smartphone, tablet, or other mobile computing device], ¶0137 [wherever a “website” is mentioned, an application or site could also apply, such as when a mobile application is used to access data], ¶¶0170-0173 [social networking mobile device applications], ¶0231, ¶0081 [the user clicks on the Amazon.com one-click purchasing button 206. Thus, from this field, the system receives that input, processes the input, and can execute a purchase, just as though the user had navigated through Amazon.com to an iPhone 5S, having 32 GB of storage, and a silver color, and had just clicked on the one-click purchase button. However, in this first example, the user did not need to navigate to Amazon.com but rather was able to make a one-click purchase from a separate website, namely the one-search.com website], ¶¶0166-0167, and ¶¶0276-0279).
While Isaacson discloses an API receiving data from a user including interactive information and text query information that is used to determine purchase intent and if the data is associated with a product database of products for sale from a merchant and presenting results based on the information (¶¶0166-0168 and ¶¶0171-0173), Isaacson does not explicitly disclose the information includes an identifier for the merchant. In the field of purchasing products using an application executing on a consumer device (abstract), Graylin teaches each product offer is associated with a product offer identifier and a specific merchant identifier and displaying (i.e., generating) a user interface based on these identifiers (¶0015 and ¶¶0050-0055). The step of Graylin is applicable to the system of Isaacson as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the request and the generated user interface as taught by Isaacson with the specific merchant identifier as taught by Graylin. One of ordinary skill in the art at the time of filing would have been motivated to expand the system of Isaacson in order to let many merchants present offers to a mobile customer in a single mobile application (Graylin ¶0005).
Regarding claim 12, Isaacson in view of Graylin teaches the system of claim 11, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to: dynamically select the one or more products based on a purchase history associated with a user of the user device (Fig. 3; ¶0157 in view of ¶0104).
Regarding claim 13, Isaacson in view of Graylin teaches the system of claim 11, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to: dynamically select the one or more products based on user preferences of a user of the user device and accessible to the third party application (Fig. 3; ¶0157 in view of ¶0144, ¶0160).
Regarding claim 14, Isaacson in view of Graylin teaches the system of claim 11, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to select the one or more products from a merchant product feed comprising product information of a plurality of products offered by the merchant, the product information comprising product descriptions, shipment options, and images of the plurality of products (Fig. 3; ¶0157 in view of ¶0104, ¶0211, ¶0227, ¶0277).
Regarding claim 16, Isaacson in view of Graylin teaches the system of claim 11, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to:
generate a second customized user interface based on the identifier for the product, the identifier for the merchant, and information associated with a third party system that provided the third party application to a user device (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 20, 27, 30-33; ¶0157, ¶¶0166-0168 and ¶0232 in view of ¶¶0172-0173); and
serve the second customized user interface to the third party application to cause the third party application to render the second customized user interface displaying the identifier for the product, the identifier for the merchant, and a checkout user interface within at least a portion of a third party application user interface, wherein the second customized user interface is styled based on the information associated with the third party system to have an appearance consistent with the appearance of the third party application user interface (Figs. 1-2A, 3, 6, 8, 11-13, 14B, 14C, 15, 19, 27, 30-33; ¶0157, ¶0114, ¶0137, ¶¶0231-0232, ¶¶0166-0168 and ¶¶0172-0173).
Regarding claim 17, Isaacson in view of Graylin teaches the system of claim 16, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to:
receive user data for a user who caused the request for the product within the third party application (¶0094 in view of ¶¶0172-0173);
store, in a customer profile, user data collected from the user during the purchase of the product, wherein the customer profile is stored in a customer profile data store of the system and associated with a third party that provides the third party application, and wherein data of the customer profile comprises one or more of: a user name, user contact information, a shipping address, and user financial data (Figs. 33-35; ¶0012, ¶0014, ¶0078 [user information, debit/credit card information, address information, etc., is stored in a user profile and available], ¶0107 [the system has the user profile, purchasing (credit/debit/PayPal, etc. account), address and any other information and can move seamlessly between purchasing/processing entities with ease. When the user sets up a profile and account on the website, all of these permissions and accessibility capability is established and approved], ¶0231 [database 1914 of payment and delivery data or other personal data about the user 1902 to populate data fields at the merchant website 1916… The server 1910 can continuously receive additional data entered by the user in the unified input field via, and update or modify data entered… server 1910 can update the network-based payment and delivery data 1914 from time to time based on information processed from the local payment and delivery data 1908, or based on user input.], ¶0235 [a profile stored in a browser cache or a profile stored on a server.], ¶¶0276-0277, ¶¶0277-284 and ¶0290 [the payment/delivery information is stored at the search entity, social networking entity, a separate agent, a browser, or in any other location so that the data can be applied to a purchasing transaction in such a way that the user does not need to manually fill out fields (such as address, credit card number, etc.) to complete a purchase]).
While Isaacson teaches maintaining purchase information from multiple interfaces (¶0008) and not sharing payment information (¶0209, ¶0266, and ¶0303), Isaacson does not explicitly disclose wherein a plurality of different customer profiles is maintained by the system for the user in the customer profile data store, each of the different customer profiles is associated with a different third party system, and customer profile data for the user is not shared between different customer profiles. However Graylin further teaches a commerce window gateway that uses numerous payment processors and associates different payment processors with different merchants and stores multiple user payment profiles from which the user can choose from stored in user accounts or e-wallets to complete the transaction, wherein account information isn’t shared between profiles (Figs. 1A [elements 161-163], 1B [elements 180 and 182] 3 [elements 160-163], 8-11 [choosing account to pay with and password], 14A, 14B; ¶¶0039-0040, ¶¶0045-0046 in view of ¶0055). The step of Graylin is applicable to the system of Isaacson as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the stored payment information as taught by Isaacson with the numerous payment processors and stored payment profiles as taught by Graylin. One of ordinary skill in the art at the time of filing would have been motivated to expand the system of Isaacson in order to store multiple payment instruments for the user to select and associate the correct payment processor with the correct merchant (Graylin ¶0055 in view of ¶0016).
Regarding claim 18, Isaacson in view of Graylin teaches the system of claim 17, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to
process a transaction initiated by the user from the third party application (Figs. 33-35; ¶0019, ¶0021, ¶0024, ¶0231, ¶0106 [switch the order from one merchant to another merchant], ¶¶0277-0284);
receive user identification data during the processing of the transaction (¶¶0166-0168 [stored payment information for the user at the generalized search engine] in view of ¶0155 and ¶0174);
determine that the user identification data is associated in the customer profile with the third party system that provides the third party application (¶0166-0168 and ¶¶0173-0174 [payment information stored through the social networking site or another service like Apple Pay or Paypal such that products from all different merchants that are offered through this service can be purchased without needing to be transferred to that merchant for inputting payment information]);
access one or more items of user data including one or more of: the user name, the user contact information, the shipping address, and the user financial data from the customer profile (Figs. 33-35; ¶0012, ¶0014, ¶0107, ¶0231, ¶¶0276-0277, ¶¶0277-284);
automatically enter the accessed one or more items of user data within a second user interface served to the third party application during the transaction (¶¶0163-0168 and ¶¶0171-0173); and
utilize the automatically entered user financial data to complete purchase of a different product during the transaction (¶0172 in view of ¶0231).
Regarding claim 19, Isaacson in view of Graylin teaches the system of claim 18, Isaacson further discloses wherein a second merchant provides the different product for purchase through the third party application (Figs. 13, 33-35; ¶0019, ¶0021, ¶0024, ¶0231, ¶0106 [switch the order from one merchant to another merchant], ¶0155, ¶¶0277-0284).
Regarding claim 20, Isaacson in view of Graylin teaches the system of claim 17, Isaacson further discloses wherein the memory further stores instructions that, when executed by the processor, cause the processor to
generate a series of user interfaces that are served to the third party application (Figs. 15 and 17A-19; ¶0166 [communications via an application programming interface (API)] in view of ¶¶0207-0211), wherein the series of user interfaces comprise a user interface to configure characteristics of the product being purchased (Fig. 4A; ¶0106, ¶¶0093-0034, ¶0126, ¶0157), a user interface to receive user information (¶¶208-0209 [system may present the user with current information and an opportunity to add a shipping address, correct data, or change any of the necessary data for the transaction. The system receives and updates any changed data. If options are presented to the user, the user can select which payment option to use for processing the transaction]), a user interface to receive payment information (¶¶208-0209 [system may present the user with current information and an opportunity to add a shipping address, correct data, or change any of the necessary data for the transaction. The system receives and updates any changed data. If options are presented to the user, the user can select which payment option to use for processing the transaction]), a user interface to request for a product (Fig. 2A; ¶0081 [the user clicks on the Amazon.com one-click purchasing button 206. Thus, from this field, the system receives that input, processes the input, and can execute a purchase, just as though the user had navigated through Amazon.com to an iPhone 5S, having 32 GB of storage, and a silver color, and had just clicked on the one-click purchase button. However, in this first example, the user did not need to navigate to Amazon.com but rather was able to make a one-click purchase from a separate website, namely the one-search.com website], ¶¶0166-0167, ¶¶0172-0173, and ¶¶0276-0279), or a combination thereof; and
capture the user data of the customer profile from user inputted information into one or more fields of the series of user interfaces (¶¶208-0209 and ¶0231 [database 1914 of payment and delivery data or other personal data about the user 1902 to populate data fields at the merchant website 1916…The server 1910 can continuously receive additional data entered by the user in the unified input field via, and update or modify data entered… server 1910 can update the network-based payment and delivery data 1914 from time to time based on information processed from the local payment and delivery data 1908, or based on user input.], ¶0290 [the payment/delivery information is stored at the search entity, social networking entity, a separate agent, a browser, or in any other location so that the data can be applied to a purchasing transaction in such a way that the user does not need to manually fill out fields (such as address, credit card number, etc.) to complete a purchase]).
Claim(s) 10 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Isaacson in view of Graylin and Jensen (US 2012/0059730 A1 [previously recited]).
Regarding claim 10, Isaacson in view of Graylin teach the method of claim 9. While Isaacson further discloses
wherein the merchant product feed is specific to the merchant (Fig. 3; ¶0157 in view of ¶0104, ¶0211, ¶0227, ¶0277), and
wherein a second merchant product feed specific to a second third party application comprises a plurality of products offered by the merchant (Fig. 3; ¶0157 in view of ¶0104, ¶0211, ¶0227, ¶0277),
Isaacson in view of Graylin does not explicitly disclose a different plurality of products. However, in the field of electronic marketplaces (abstract), Jensen teaches marketplaces with exclusive access to products (Fig. 3; ¶0048). The step of Jensen is applicable to the process of Isaacson in view of Graylin as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the marketplaces as taught by Isaacson in view of Graylin with marketplaces with exclusive products as taught by Jensen. One of ordinary skill in the art at the time of filing would have been motivated to expand the process of Isaacson in view of Graylin in order to provide a buyer of the marketplace with access to a new product, product line, or server available within the electronic marketplace, to the exclusion of the general public (Jensen ¶0048).
Regarding claim 15, Isaacson in view of Graylin teaches the system of claim 14, Isaacson further wherein
the merchant product feed is specific to the merchant (Fig. 3; ¶0157 in view of ¶0104, ¶0211, ¶0227, ¶0277), and
wherein a second merchant product feed specific to a second third party application comprises a plurality of products offered by the merchant (Fig. 3; ¶0157 in view of ¶0104, ¶0211, ¶0227, ¶0277),
Isaacson in view of Graylin does not explicitly disclose a different plurality of products. However, in the field of electronic marketplaces (abstract), Jensen teaches marketplaces with exclusive access to products (Fig. 3; ¶0048). The step of Jensen is applicable to the system of Isaacson in view of Graylin as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the marketplaces as taught by Isaacson in view of Graylin with marketplaces with exclusive products as taught by Jensen. One of ordinary skill in the art at the time of filing would have been motivated to expand the system of Isaacson in view of Graylin in order to provide a buyer of the marketplace with access to a new product, product line, or server available within the electronic marketplace, to the exclusion of the general public (Jensen ¶0048).
Examiner’s Comment
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Reference A of the Notice of References Cited Lopez et al. (US 10,867,276 B1) discloses aggregating an order queue by consolidating multiple orders to be displayed via a single user interface and presenting each of the pending orders with a consistent look and feel in terms of appearance, layout , and positioning.
Response to Arguments
Applicant’s arguments, on page 10 of the Remarks filed 4/28/2026, with respect to the previous claim objections have been fully considered and are persuasive in view of the currently amended claims. Accordingly the previous claim objections are withdrawn.
Applicant’s arguments, on pages 10-11 of the Remarks filed 4/28/2026, with respect to the previous double patenting rejections have been fully considered and are persuasive in view of the terminal disclaimer filed and approved on 4/28/2026. Accordingly the previous double patenting rejections are withdrawn.
Applicant’s arguments, on pages 11-14 of the Remarks filed 4/28/2026, with respect to the previous 35 USC §103 rejections have been fully considered and are not persuasive. Applicant argues on pages 11-12 that Isaacson teaches the opposite of what is claimed. Examiner respectfully disagrees. During patent examination, the pending claims must be "given their broadest reasonable interpretation consistent with the specification" (see MPEP 2111). The argued claim limitation “wherein the customized user interface is styled based on the information associated with the third party system to have an appearance consistent with an appearance of the third party application user interface” does not exclude “merchant branding” of a merchant. Applicant argues “the checkout interface must visually match the third party application (e.g., a social media app, microblogging app), not the merchant selling the product”, but this is a much narrower interpretation than what is currently claimed. As noted above in the full rejection of the claims, Isaacson discloses a unified input field of a web page in a browser, wherein the interface screen can be hosted by a social media site and enables the user access to products of other websites through the unified search field, as if they were one-click purchase websites (see 1-2A, 3, 6, 8, 11-13, 14B, 14C, 15, 19, 20, 27, 30-33; ¶¶0231-0232). This can be accomplished through an API communicating between a one-search server, a web server, social media site, or some other computing device or computing device (see ¶¶0166-0168 in view of ¶¶0019-0022 [API that is designed to communicate information to and from multiple different types of sites that now manage purchases… A purchase management engine receives the various pieces of data and correlates the data into a single user account that spans multiple purchasing platforms], ¶0114 [input field is part of an application downloadable or installable on a smartphone, tablet, or other mobile computing device. The functionality could also apply to a unified search field on a website. The application can be customizable as can any website disclosed herein.]). As shown in Figure 2A, a user can enter a search in the unified input field (element 202) and click on a purchase button on the first web page (element 206), after receiving the input the server system can process the input and execute a purchase, just as though the user had navigated though amazon.com to purchase the iPhone, but the user did not need to navigate to amazon.com and was able to make a one-click purchase from the original website (see at least Fig. 2A; ¶0081 in view of ¶¶0231-0232). As shown in Fig. 2A and 4A, the customized user interface is styled based on the information associated with www.onesearch.com to have an appearance consistent with an appearance of the application user interface and Issacson further discloses the first website can be a social media site (i.e. a third party system) communicating via an API with the system server to generate the customized interface (see also ¶¶0231-0232 [the interface screen can be hosted by a social media site] ¶0137 [wherever a “website” is mentioned, an application or site could also apply, such as when a mobile application is used to access data], ¶0105 [FIG. 4A illustrates the resulting screen 400 presented to the user from choosing option 306. Screen 400 includes data 402 informing the user that the iPhone 5S had been purchased via Amazon.com.], ¶0166 [FIG. 15 illustrates an example scenario 1500 showing communications via an application programming interface (API) 1502. A one-search server, a web server, social media site or some other computing device or computing devices can provide services accessible via the API 1502. The services provided by the API 1502 can be accessible from a web server serving pages to web browsers or other web clients, an application for mobile devices, or from a web browser] and Figs. 1, 4A, 15 ).
Examiner additionally notes that while Issacson discloses the system can transition the user directly to the merchant website (¶0089) and/or the browser or search engine could also be configured to transition the user to any second site and preprocess the use input in the input field as though the user had searched the second site (¶0101), these are presented in the alternative as Issacson discloses the user did not need to navigate to the merchant website but was able to make the purchase of the item from the merchant using the one-search.com website (i.e., third party website) or the one-search.com system can display a logo of each merchant with a summary of the order that would be placed but the user only need to interact with the one-search.com page (¶0081 and ¶0088). As shown in Fig. 2A and 4A, the customized user interface is styled based on the information associated with www.onesearch.com to have an appearance consistent with an appearance of the application user interface.
As such, Examiner maintains Issacson discloses “wherein the customized user interface is styled based on the information associated with the third party system to have an appearance consistent with an appearance of the third party application user interface” given the broadest reasonable interpretation for the reasons disclosed above in the full rejection of the claim.
In response to applicant's arguments against the references individually on page 12, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Graylin was used in combination with Isaacson to teach the information includes an identifier for the merchant associated with the product and generating a user interface based on the identifier for the merchant. As noted above in the full rejection of the claims, Graylin was used to teach each product offer is associated with a product offer identifier and a specific merchant identifier and displaying (i.e., generating) a user interface based on these identifiers (¶0015 and ¶¶0050-0055). Accordingly, Examiner maintains Isaacson in view of Graylin teaches the limitations of the argued claims for the reasons noted above in the full rejection of the claims.
Applicant argues on pages 12-13 that there is no teaching, suggestion, or motivation to combine the cited references because the user interface would still be styled based on merchant branding, not third party application branding. Examiner respectfully disagrees. Once again, Applicant is interpreting the claims narrower than is actually claimed. As noted above and shown in Figure 2A of Isaacson, a user can enter a search in the unified input field (element 202) and click on a purchase button on the first web page (element 206), after receiving the input the server system can process the input and execute a purchase, just as though the user had navigated though amazon.com to purchase the iPhone, but the user did not need to navigate to amazon.com and was able to make a one-click purchase from the original website (see at least Fig. 2A; ¶0081 in view of ¶¶0231-0232). As shown in Fig. 2A and 4A, the customized user interface is styled based on the information associated with www.onesearch.com to have an appearance consistent with an appearance of the application user interface. Examiner additionally notes that claim 5 (as an example) recites “wherein the information associated with the third party system comprises branding information indicative of one or more of a logo associated with the third party, a color scheme used by the third party application user interface, and a font used by the third party application user interface.” The limitations “associated with”, as currently claimed, can encompass merchants with branding information “associated with” the third party. As noted above, Graylin was used in combination with Isaacson to teach the information includes an identifier for the merchant associated with the product and generating a user interface based on the identifier for the merchant. Graylin was used to teach each product offer is associated with a product offer identifier and a specific merchant identifier and displaying (i.e., generating) a user interface based on these identifiers (¶0015 and ¶¶0050-0055). The step of Graylin is applicable to the method of Isaacson as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the request and the generated user interface as taught by Isaacson with the specific merchant identifier as taught by Graylin. One of ordinary skill in the art at the time of filing would have been motivated to expand the method of Isaacson in order to let many merchants present offers to a mobile customer in a single mobile application (Graylin ¶0005). Further, Jensen was used in claims 10 and 15 to teach a different plurality of products. Jensen teaches marketplaces with exclusive access to products (Fig. 3; ¶0048). The step of Jensen is applicable to the process of Isaacson in view of Graylin as they both share characteristics and capabilities, namely, they are directed to selling products. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the marketplaces as taught by Isaacson in view of Graylin with marketplaces with exclusive products as taught by Jensen. One of ordinary skill in the art at the time of filing would have been motivated to expand the process of Isaacson in view of Graylin in order to provide a buyer of the marketplace with access to a new product, product line, or server available within the electronic marketplace, to the exclusion of the general public (Jensen ¶0048).
Applicant argues on pages 13-14 that Isaacson in view of Graylin does not teach maintaining separate customer profiles for different third party applications recited in claims 2 and 17 because Graylin teaches “a commerce window gateway that uses number payment processors and associates different payment processors with different merchants and stores multiple user payment profiles” and this is fundamentally different from maintaining separate customer profiles for different third party applications. Examiner respectfully disagrees. Once again, Applicant is arguing a much narrower interpretation than what is currently claimed. The broadest reasonable interpretation of “different third party systems” encompasses numerous payment processors the stored customer payment profiles for the processors.
Accordingly, Examiner maintains Isaacson in view of Graylin (and in further view of Jensen for claims 10 and 15) teaches the limitations of the argued claims for the reasons noted above in the full rejection of the claims.
Accordingly, Examiner maintains the 35 USC §103 rejections of the claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 LINDSEY B SMITH whose telephone number is (571)272-0519. The examiner can normally be reached Monday - Friday 9-6 EST.
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, Jeff Smith can be reached at 571-272-6763. 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.
LINDSEY B. SMITH
Examiner
Art Unit 3688
/LINDSEY B SMITH/ Examiner, Art Unit 3688
/MARISSA THEIN/ Supervisory Patent Examiner, Art Unit 3689
Prosecution Insights