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
Status of Claims
Claim(s) 1 are cancelled.
Claim(s) 2-21 have been examined.
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) 2-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Purves (US 2013/0290203) in view of Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” Request for Comments (RFC) 6749, Internet Engineering Task Force (IETF), ISSN 2070-1721 (October 2012) (hereinafter “RFC 6749” and the citations refer to the page numbering of the PDF itself, not the document).
Referring to Claim 2, Purves teaches a system, comprising:
a non-transitory memory and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising (see Purves ¶¶0176,180):
providing, on a device associated with a merchant, a user interface for integrating the merchant with one or more third-party channels (see Purves ¶0087; see also ¶¶00046,50, describing a merchant control panel / widget designer interface through which a merchant integrates its offerings into third-party channels, including social media);
receiving, via the user interface, first credential data associated with a merchant account of the merchant with an electronic commerce platform and second credential data associated with a funding account of the merchant with an electronic payment provider (see Purves ¶¶0050,113,45, seller login/registration information and integration information for the V.me payment/checkout widget);
retrieving, via a software module on the device, product data associated with one or more products offered by the merchant and stored on the electronic commerce platform using the first credential data (see Purves ¶¶0051-52, obtaining item, inventory, description, and pricing information for the merchant’s products);
transmitting, via the software module and using a first application programming interface (API) the product data to a third-party server associated with a third-party channel from the one or more third-party channels, wherein receiving the product data by the third-party server causes the third-party server to display the product data on a website hosted by the third-party server and associated with the third-party channel (see Purves ¶¶0057,60,95 and Fig. 9C, the product content is transmitted/injected to the social media server and displayed on the associated third-party site);
in response to receiving a purchase request for the one or more products from the third-party server, transmitting a purchase order to the electronic commerce platform using a second API associated with the electronic commerce platform, wherein receiving the purchase order by the electronic commerce platform causes the electronic commerce platform to process the purchase order for the one or more products through the merchant account (see Purves ¶¶0082,111, the order is forwarded to and processed such that the transaction is settled through the merchant’s account).
Purves does not teach obtaining, from the electronic commerce platform and based on the first credential data, an access token for accessing the merchant account from the electronic commerce platform; that the receiving of the product data is performed using the access token; or that the transmitted purchase order comprises the access token, such that receiving the purchase order comprises the access token by the electronic commerce platform causes the electronic commerce platform to process the order for the one or more products through the merchant account.
However, RFC 6749 teaches these limitations. It describes an authorization framework in which, rather than repeatedly using the account holder’s credentials to reach protected resources, “the client obtains an access token” that is used for subsequent access (see RFC 6749 p.4). This access token is issued by the platform, which RFC 6749 designates the “authorization server” and defines as “[t]he server issuing the access tokens to the client after successfully authenticating the resource owner” (see RFC 6749 p.5). RFC 6749 further teaches obtaining the access token based on the account holder’s credentials: under the resource owner password credentials grant, the account holder’s credentials “are exchanged for an access token” (see RFC 6749 p.7). The client thereafter presents that same access token on each request to the resource server (i.e., the platform hosting the protected product data and order-processing functionality): the client “authenticates by presenting the access token,” and the resource server “validates the access token, and if valid, serves the request” (see RFC 6749 p.6). Presenting the access token on a request is therefore what authorizes both the retrieval of the protected resource (the product data) and the write operation (submission and processing of the purchase order through the merchant account).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Purves such that access to the electronic commerce platform, including both the retrieval of the product data and the submission of the purchase order, is authorized by an access token obtained from the platform based on the merchant’s credentials as taught by RFC 6749. Purves already authenticates the seller to the platform in order to access platform functionality (see Purves ¶0123, describing an authentication request and the platform’s authentication of the seller); substituting the standardized OAuth access-token mechanism of RFC 6749 for the authentication used in Purves is the use of a known technique to improve a similar system in the same way, and yields only predictable results. In addition, a person of ordinary skill in the art would have been motivated to make this combination because token-based authorization avoids exposing and repeatedly transmitting the account holder’s password, and RFC 6749 recognizing that, absent such a framework, “[c]ompromise of any third-party application results comprise of the end-user’s password” (see RFC 6749 p.4), and that an access token may be issued with a limited scope and lifetime. The combination therefore not only leads to predictable results, but also improves security of the merchant-to-platform access already contemplated by Purves.
Referring to Claim 3, the combination teaches the system of claim 2, wherein the device is a merchant device, and wherein the software module is a plug-in application installed on the merchant device (see Purves ¶¶0048,121).
Referring to Claim 4, the combination teaches the system of claim 2, wherein the user interface presents a plurality of options corresponding to a plurality of electronic commerce platforms, and wherein the operations further comprise: receiving, via the user interface, a selection of an option from the plurality of options, wherein the selection corresponds to the electronic commerce platform (see Purves ¶¶0087,50, the user may choose the platforms they wish to integrate the widget and/or social media application views into).
Referring to Claim 5, the combination teaches the system of claim 2, wherein the user interface presents a plurality of options corresponding to a plurality of electronic payment providers, and wherein the operations further comprise: receiving, via the user interface, a selection of an option from the plurality of options, wherein the selection corresponds to the electronic payment provider (see Purves ¶0111 lines 10-12).
Referring to Claim 6, the combination teaches the system of claim 2, wherein the third-party channel is associated with one of a social networking platform, a retail aggregator, or a consumer platform (see Purves ¶0046, Facebook).
Referring to Claim 7, the combination teaches the system of claim 2, wherein the purchase request comprises funding information usable for purchasing the one or more products, and wherein the operations further comprise: transmitting, based on the second credential data and using a third API associated with the electronic payment provider, the funding information to a payment server associated with the electronic payment for processing the purchase request (see Purves ¶0081-82,126, the order is shown with the payment/funding information being sent via the API, and the CWI server processes the order which charges the user’s payment account, and the seller server(s) generate a payment authorization message using the purchase request).
Referring to Claim 8, the combination teaches the system of claim 7, wherein the operations further comprise: in response to receiving a payment complete signal from the payment server, transmitting a notification to the electronic commerce platform using the second API (see Purves ¶¶0083,129).
Referring to Claim 9, Purves teaches a method, comprising:
providing, by a computer system and on a device associated with a merchant, a user interface for integrating the merchant with one or more third-party channels, wherein the user interface presents a plurality of options corresponding to a plurality of electronic commerce platforms (see Purves ¶¶0092,65,87);
receiving, via the user interface, a selection of a particular option from the plurality of options, wherein the particular option corresponds to a particular electronic commerce platform from the plurality of electronic commerce platforms (see Purves ¶¶0087, the user may choose a product or products to feature in the integration and this can be further seen in [0050]);
retrieving, by the computer system, product data associated with a set of products offered by the merchant and stored on the particular electronic commerce platform (see Purves ¶0052);
transmitting, via the software module and using a first application programming interface (API) the product data to a third-party server associated with a third-party channel from the one or more third-party channels, wherein receiving the product data by the third-party server causes the third-party server to display the product data on a website hosted by the third-party server and associated with the third-party channel (see Purves ¶¶0057,60,95 and Fig. 9C, the product content is transmitted/injected to the social media server and displayed on the associated third-party site);
in response to receiving a purchase request for the one or more products from the third-party server, transmitting a purchase order to the electronic commerce platform using a second API associated with the electronic commerce platform, wherein receiving the purchase order by the electronic commerce platform causes the electronic commerce platform to process the purchase order for the one or more products through the merchant account (see Purves ¶¶0082,111, the order is forwarded to and processed such that the transaction is settled through the merchant’s account).
Purves does not teach obtaining, by the computer system and from the particular electronic commerce platform, an access token for accessing a merchant account with the particular electronic commerce platform based on first credential data provided by the merchant via the user interface; that the retrieving of the product data is performed using the access token; or that the transmitted purchase order comprises the access token such that its receipt causes the particular electronic commerce platform to process the purchase order through the merchant account.
However, as already set forth in claim 2, the same portions of RFC 6749 teach these limitations, namely that “the client obtains an access token” issued by the authorization server “after successfully authenticating the resource owner,” that the account holder’s credentials “are exchanged for an access token,” and that the client thereafter “authenticates by presenting the access token” on each protected-resource request (see RFC 6749 p.4-7). Additionally, the same reasons to combine persist, as it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Purves to obtain and use the access token as taught by RFC 6749 because the results would remain predictable and it would continue to lead to a security improvement (see the reasons and rational as set forth in claim 2 above).
Referring to Claim 10, the combination teaches the method of claim 9, further comprising:
receiving, from the third-party server, a content request, wherein the retrieving the product data is responsive to the content request (see Purves ¶0010, the social media server may contact the CWI server 503 and request the CWI render the social media application containing the integrated ecommerce capability; also see ¶0076).
Referring to Claim 11, the combination teaches the method of claim 10, wherein the content request is associated with an advertisement presented on a webpage of the website (see Purves ¶0046, advertising banners).
Referring to Claim 12, the combination teaches the method of claim 9, wherein the user interface further presents a second plurality of options corresponding to a plurality of electronic payment providers, and wherein the method further comprises: receiving, via the user interface, a second selection of a second option from the second plurality of options, wherein the second option corresponds to a particular electronic payment provider in the plurality of electronic payment providers (see Purves ¶0111 lines 10-12).
Referring to Claim 13, the combination teaches the method of claim 12, wherein the purchase request comprises funding information usable for purchasing the one or more products, and wherein the method further comprises: transmitting, using a third API associated with the particular electronic payment provider, the funding information to a payment server associated with the particular electronic payment provider for processing the purchase request (see Purves ¶0081,126).
Referring to Claim 14, the combination teaches the method of claim 13, further comprising:
obtaining, via the user interface, second credential data associated with the merchant for accessing a funding account of the merchant with the particular electronic payment provider; causing the payment server to process the purchase request based on the second credential data (see Purves ¶¶0113-114,82).
Referring to Claim 15, the combination teaches the method of claim 9, wherein the computer system comprises a plug-in application installed on the device (see Purves ¶0201, plug-ins).
Referring to Claim 16, this claim is similar to claims 2 and 9 and therefore rejected under the same reasons and rationale.
Referring to Claim 17, the combination teaches the non-transitory machine-readable medium of claim 16, wherein the operations further comprise causing the software module to be installed on the device (see Purves ¶¶0048,121).
Referring to Claim 18, the combination teaches the non-transitory machine-readable medium of claim 16, wherein the user interface is provided by the software module installed on the device (see Purves ¶¶0087,48,121, the widget/SDK software module loaded on the device provides the merchant control panel/designer interface).
Referring to Claim 19, the combination teaches the non-transitory machine-readable medium of claim 16, wherein the purchase request comprises funding information usable for paying for the one or more products, and wherein the operations further comprise: transmitting the funding information to a payment server associated with a payment provider for processing a payment associated with the purchase transaction (see Purves ¶0081, the funding information in the order request; ¶0126, the seller server(s) may invoke the purchase transaction authorization component which facilitates payment processing via payment gateway and settlement).
Referring to Claim 20, the combination teaches the non-transitory machine-readable medium of claim 19, wherein the operations further comprise: in response to receiving a payment completion signal from the payment server, transmitting a payment confirmation to the electronic commerce platform using the second API, wherein the transmitting the payment confirmation causes the electronic commerce platform to fulfill a shipment of the one or more products (see Purves ¶0130-132,136, when the transaction state is successful, the logical flow continues and the seller servers send a payment success message for display to the client, and the shipping information is collected after successful payment, including order fulfillment details).
Referring to Claim 21, the combination teaches the non-transitory machine-readable medium of claim 19, wherein the operations further comprise: receiving, via the user interface, second credential data for accessing a funding account of the merchant with the payment provider; accessing, via the payment server, the funding account of the merchant using the second credential data, wherein the transmitting the funding information to the payment server causes the payment to be processed through the funding account based on the second credential data (see Purves ¶¶0113,45, login information and integration information for a V.me API payment widget; also see ¶0082, showing merchant revenue from orders processed through their account).
Remarks
Additional prior art relevant to the claimed application, but not relied upon, includes:
Hutchinson (US 9,864,990) teaches ordering goods using a virtual payment system and commerce gateway.
Rashwan (US 2014/0229270) teaches selling products through a purchase interface on different internet channels.
Reference U (see PTO-892) teaches a third-party payment system for e-commerce.
The rejection under 35 U.S.C. 112 was withdrawn because the applicant has overcome the rejection.
The rejection under 35 U.S.C. 101 is also withdrawn because the amendment overcomes the rejection.
In regards to the rejection under 35 U.S.C. 102, the arguments are now moot because the amendment lead to the use of new prior art to reject the claims under 35 U.S.C. 103.
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 MATTHEW E ZIMMERMAN whose telephone number is (571)270-5278. The examiner can normally be reached 8-4pm M-T, 8-12pm W.
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.
/MATTHEW E ZIMMERMAN/Primary Examiner, Art Unit 3688
Prosecution Insights