Decisions of the Commissioner of Patents - Summary of decision number  1341

Third-Party Information Liability Disclaimer

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.


This table provides a summary of decision number 1341

Decision Number 1341
Application Number 2222229
Date 2013-03-28
Patent Number n/a
CPC:
IPC: G06Q 30/06 (2012.01)
Topics J00: SUBJECT MATTER OF APPLICATIONS - Meaning of Art
J70: SUBJECT MATTER OF APPLICATIONS - Process or Method Claims
O00: OBVIOUSNESS

Decision Text

COMMISSIONER'S DECISION SUMMARY




C.D. 1341, Application 2,222,229


Obviousness, Statutory Subject Matter


The examiner rejected the application for being obvious and for being directed to non-statutory
subject matter.

The application was refused by the Commissioner of Patents.

IN THE CANADIAN PATENT OFFICE


DECISION OF THE COMMISSIONER OF PATENTS







Patent application number 2,222,229 was rejected by the examiner under Subsection 30(3) of
the Patent Rules. The rejection has been considered by a panel of the Patent Appeal Board
and by the Commissioner of Patents. The findings of the panel and the decision of the
Commissioner are as follows:











Agent for the applicant

MARKS & CLERK
Suite 1800
280 Slater Street
OTTAWA Ontario
K1P 1C2 INTRODUCTION

[1] This decision deals with a review by the Commissioner of Patents of the examiner's
Final Action (FA) on patent application number 2,222,229 which is entitled "SYSTEM
AND METHOD FOR DISTRIBUTED CONTENT ELECTRONIC COMMERCE". The
current applicant is RPX Corporation [Applicant] and the inventor is James McKanna
Gregory. The application was filed and a request for examination was received on
November 25th, 1997. The application claims priority from a United States application
filed on January 15th, 1997.

[2] Following four examiner's reports, the examiner in charge of the application issued a FA
on November 20th, 2006 rejecting the application based on obviousness and non-
statutory subject matter. Applicant submitted arguments in response to the FA on May
22nd, 2007.

[3] Subsequent to the FA, on November 6th, 2008, the Supreme Court released its decision
in Sanofi-Synthelabo Canada Inc. v. Apotex Inc. 2008 SCC 61 [Sanofi] which outlined a
four-step approach to be followed when assessing the obviousness of a claim.

[4] Also subsequent to the FA, on March 5th, 2009, the Commissioner set out an approach
to be followed when assessing patentable subject matter under section 2 of the Patent
Act in view of Re Application 2,246,933 of Amazon.com Inc. (2009) C.D. 1290 [CD
1290].

[5] In a letter dated May 29th, 2009, Applicant was given the opportunity to address, in
writing and/or at a hearing, obviousness in view of Sanofi as well as section 2 in view of
the approach set out in CD 1290. Accompanying the letter was a Summary of Reasons
(SOR) provided by the examiner which clarified the particulars of the rejection of the
application for non-compliance with sections 28.3 and 2 of the Patent Act. In response
to the letter, Applicant provided written submissions on August 28th, 2009.

[6] In a letter dated January 19th, 2010, Applicant declined the opportunity for an oral
hearing and requested that a decision without a hearing be rendered based on the
written submissions.

[7] On April 20th, 2010, the application was assigned from AT&T Intellectual Property II, L.P.
to the current applicant, RPX Corporation.

[8] On November 24th, 2011, the Federal Court of Appeal, in Canada (Attorney General) v.
Amazon.com Inc., 2011 FCA 328 [Amazon FCA], delivered a judgement pertaining to
statutory subject matter which disagreed with the approach presented in CD 1290.

[9] In a letter dated August 31st, 2012, the panel presented Applicant with the opportunity to
comment on whether or not the subject matter of the claims of the present application is
statutory in view of the draft office practice that was developed and consulted on post
Amazon FCA. In this letter, the panel also identified a new reference which it considered
relevant in establishing the common general knowledge of a person skilled in the art.
The panel also made observations regarding the clarity of the specification. Applicant
was given an opportunity to address the issues raised by the panel in writing and/or at a
hearing. Applicant declined to provide any further submissions in a letter dated
November 14th, 2012.


BACKGROUND

[10] The present application sets out a system and method for electronic commerce (e-
commerce) that separates detailed merchant content from transaction functionality over
separate servers. A transaction server is connected over a network to one or more
merchant servers. The transaction server provides purchasers with summary
information on subscribing merchants and the products they offer. Purchasers desiring
to obtain more detailed information about a specific product offered by a certain
merchant can link directly to the corresponding merchant server through the transaction
server. Once the purchaser selects an item for purchase from the merchant site, a
purchase request is transmitted from the merchant server to the transaction server which
processes the transaction for the selected item.

[11] Applicant contends that traditionally, merchants were faced with the choice of either
having to operate their own commerce server or purchase e-commerce services from a
commerce service provider. The former option resulted in merchants having to operate
complex and expensive servers that provided both content and transaction functionality.
The latter option caused the merchant to lose control over the manner in which business
is conducted and information is presented by relinquishing it to the provider, and forced
the provider to offer an e-commerce service that accommodates the varying
requirements of each merchant (pages 1-3 of instant application).

[12] In order to allow merchants and providers to overcome the problem of having to operate
a complex e-commerce server that "provides substantially all of the functionality needed
to carry out buying and selling on a network" (page 2, lines 4-6 of instant application),
the present application offers a solution that involves splitting e-commerce functionality
over multiple servers. Applicant proposes that by separating transaction functionality
from detailed merchant content over separate servers, merchants and providers can
each dedicate themselves to offering services within their areas of expertise, thus
avoiding the operation of complex e-commerce servers.

[13] An embodiment of the proposed invention is depicted in Figure 2 of the present
application. Content servers (22) are controlled by merchants and provide detailed
information about the merchants and the products they offer. The transaction server
(23) (also known as the e-commerce server) is controlled by a transaction service
provider and provides transaction functionality as well as access to merchant summary
information (24) on products offered through the e-commerce system. Through a
content searching means, the transaction server provides the purchaser (25) with the
ability to search the merchant summary information for a desired merchant and product.
The merchant summary information presented to the purchaser provides a link (through
a URL or network address - page 17, lines 2-9 of instant application) to the merchant's
website which the purchaser may access to obtain more detailed information about a
specific product offered by that merchant. Once the purchaser has selected a product
for purchase from the merchant site that they've accessed, a purchase request is
transmitted from the merchant server to the transaction server (the description suggests
that this may be accomplished by clicking on a "Make Purchases" button - page 18, lines
3-6 of instant application). The transaction server effectuates the transaction by
retrieving the necessary information from its own commerce database and interacting
with external payment systems such as banks. The transaction server is able to
generate reports for the purchaser and merchant based on a history of the transaction
data.


CLAIMS

[14] The latest claim set is dated November 25th, 2004 and contains 15 claims. There are
three independent claims directed to a method, transaction server and electronic
commerce system.

[15] Claim 1 is as follows:

1. A method for conducting electronic commerce transactions in a transaction server storing merchant
summary information connected over a network to a merchant server, said method comprising the
steps of:
searching for general merchant information in the merchant summary information based
on a received information request;
displaying results of the search;
providing reference to detailed merchant information stored on the merchant server;
receiving a purchase request from the merchant server for a selected product; and
processing the purchase request to form a purchase transaction.

[16] Dependent claims 2-9 set out further limitations related to the processing of the
purchase request, the storage/retrieval of transaction records and payment information
in/from a database, and the generation of transaction reports.

[17] Claim 10 is as follows:

10. A transaction server in an electronic commerce system for processing electronic transactions, said
transaction server being connected to a merchant server via a network, the merchant server
containing detailed information about products, said transaction server comprising:
a content searching means for enabling a purchaser to search through merchant summary
information on all products available through the electronic commerce system;
a transaction processor for accepting from the merchant server and processing
transaction requests from the purchaser; and
a database having stored thereon the merchant summary information about at least one
subscribing merchant, the merchant summary information including a reference to the detailed
information stored on the merchant server, the reference being provided based on a result of a
search.

[18] Dependent claims 11-12 set out further limitations related to the transaction processor
and a merchant interface used for the modification of the merchant summary
information.

[19] Claim 13 is as follows:

13. An electronic commerce system for carrying out electronic transactions between a purchaser and at
least one subscribing merchant over a network, said electronic commerce system comprising:
a transaction server for processing electronic transactions comprising:
a transaction processor for accepting transaction requests from the purchaser
and processing the transaction requests;
a database having stored thereon merchant summary information about the at
least one subscribing merchant;
a content searching means for enabling the purchaser to search through all
products available through the electronic commerce system; and
at least one merchant server connecting to the transaction server over the network, said
merchant server having a database for storing detailed product and merchant information;
wherein the merchant server forwards the transaction requests from the purchaser to the
transaction processor.

[20] Dependent claims 14-15 set out further limitations related to the transaction processor
and a merchant interface used for the modification of the merchant summary
information.




ISSUES

[21] The following questions are before the panel:

1 Are claims 1-15 obvious under section 28.3 of the Patent Act?

2 Are claims 1-15 directed to non-statutory subject matter under section 2 of the
Patent Act?


REFERENCES

Documents considered from the FA

[22] The following references are cited in the FA:

D1: Internet site www.amazon.com, 1996

D2: Publication CNET news "PSINet joins commercial trend", October 9th,
1996 (reference available from http://news.cnet.com/2100-1017-
236324.html)

D3: PCT International Application No 95/16971 (Gifford) published June 22nd,
1995

D4: United States Patent No 5 557 518 (Rosen) published September 17th,
1996

Document introduced by the panel

[23] In a letter dated August 31st, 2012, the panel introduced the following document as
relevant in establishing the common general knowledge of a person skilled in the art.


D5: Arthur M. Keller, "Smart Catalogs and Virtual Catalogs," in International
Conference on Frontiers of Electronic Commerce, October 95; earlier
version appeared in USENIX Workshop on Electronic Commerce, July
1995.

[24] D5 can be retrieved from: http://infolab.stanford.edu/pub/keller/keller-papers.html


OVERVIEW OF THE REFERENCES

[25] Regarding D1, the panel notes that it is not possible at this time to access or verify the
functionality of the website as it existed in 1996. Therefore, in our analysis of the prior
art, D1 will not be assessed as an applied reference.

[26] Before considering issues of obviousness and subject matter, a discussion of each of
the references, D2 to D5, is in order.

Teachings of D2

[27] D2 discusses PSINet, an Internet service provider offering businesses an e-commerce
service that allows them to sell their products on the Internet through the use of its web
hosting service PSIWeb. PSIWeb adds back-end services since it already has the
hardware required for processing e-commerce transactions. The article states the
following:

PSIWeb eCommerce creates, integrates, and manages virtual storefronts for merchants who want
to conduct commerce on the Internet without investing heavily in hardware and communications.
Merchants control content and administration of their storefront.

The service integrates the secure payment system of CyberCash to process credit card
transactions and SoftCart virtual store technology from Mercantec.

The CyberCash payment system includes an electronic "wallet" for consumers, an electronic "cash
register" for merchants, and a gateway service connected to existing bank networks for handling
transactions.

SoftCart allows developers to create a complete shopping environment so that they can browse
online and pay for purchases using secure payment methods such as CyberCash. SoftCart tracks
purchases, creates invoices, calculates shipping and sales tax, and delivers completed orders
directly to accounting systems.

Teachings of D3

[28] D3 discloses a system for the purchasing of products (goods or information) over a
computer network.

[29] A primary objective of D3 is to "provide a user interactive network sales system in which
the user can freely use any merchant of choice and utilize existing financial instruments
for payment" (page 2, lines 16-19 of D3). D3 states that "at present no merchant
independent payment mechanism is available for computer networks that permits users
to utilize conventional financial instruments such as credit cards, debit cards, and
demand deposit account balances" (page 1, lines 26-30 of D3). D3 claims that in past
systems, a user had to "establish an account with each merchant in advance in order to
be able to utilize the merchant" (page 2, lines 8-9 of D3).

[30] In the network sales system of D3, a user (purchaser) at a buyer computer sends a user
inquiry for an advertisement to a merchant computer. The merchant computer retrieves
the advertisement and sends it to the buyer computer for display. If the user desires to
purchase the product described by the ad, a purchase request is communicated from the
buyer computer to the merchant computer which then sends a payment order to a
payment computer for authorization (Figure 6 of D3). In another embodiment, the buyer
computer sends the actual payment order to the merchant computer for forwarding to
the payment computer. In yet another embodiment, the payment order is sent directly
from the buyer computer to the payment computer (Figure 12 of D3). The payment
computer interfaces with real time financial systems to effectuate the authorization
(Figures 13 and 14 of D3). If authorization is issued, the merchant fulfills the product
delivery.

Teachings of D4

[31] D4 discloses a system for open e-commerce that allows customers to purchase
electronic products or services from merchants on demand, in a secure and anonymous
fashion.

[32] The system comprises a merchant trusted agent (MTA) capable of establishing a
cryptographically secure session with a customer trusted agent (CTA). The system also
comprises a first money module that is capable of securely communicating with the CTA,
and a second money module that is capable of securely communicating with the MTA
and of establishing a cryptographically secure session with the first money module.
Electronic merchandise is transferred from the MTA to the CTA but is provisionally
retained and cannot be used until payment is made. To effectuate payment, the CTA
provides first payment information to the first money module, the MTA provides second
payment information to the second money module, and an amount of electronic money
consistent with the first and second payment information is transferred from the first
money module to the second money module. The electronic merchandise becomes
accessible and retention is no longer provisional once the first money module informs
the CTA that the money has been successfully transferred and the second money
module informs the MTA that the money has been successfully received.

Teachings of D5

[33] D5 discusses electronic catalogs, and in particular, virtual catalogs which dynamically
retrieve information from multiple smart catalogs and present the product data in a
unified manner. Section 4, titled Virtual Catalogs, presents a scenario wherein a retailer
or distributor selling products from multiple manufacturers wishes to provide the
consumer with access to detailed product specifications. Rather than replicating all the
product information of each manufacturer in its own catalog and incurring considerable
storage and cost, D5 suggests that "the typical current approach using the WWW is for
the retailer to hyperlink to each manufacturer's catalog so that the customer may obtain
detailed product specifications". D5 continues by listing the problems associated with
the hyperlink approach:

There are several problems with the hyperlink approach. First, the customer may get "lost" within
the manufacturer's webspace and not know how to get back to the retailer. Second, the
manufacturer does not know the context of the customer's interactions with the retailer. Third, the
customer may stumble upon a how-to-order page provided by the manufacturer, and wind up
ordering from someone other than the original retailer. Fourth, if the customer does make it back to
the original retailer by using the "back" button, no information determined at the manufacturer's site
is carried along with the customer, such as the desired product configuration. Fifth, if the customer
gets back to the retailer through the manufacturer's how-to-order page, the retailer does not know
the original context of the interaction with the customer (e.g., other products selected for order in
this same session).

[34] D5 proposes to overcome these problems through the use of virtual catalogs which allow
retailers to dynamically retrieve information from manufacturers' catalogs upon a
consumer's request.


OBVIOUSNESS

Legal principles - Obviousness

[35] As noted at paragraph [3], subsequent to the FA, the Supreme Court of Canada
rendered its decision in Sanofi, in which the Court set out the approach to be followed in
assessing obviousness, as follows:

(1) (a) Identify the notional "person skilled in the art";
(b) Identify the relevant common general knowledge of that person;
(2) Identify the inventive concept of the claim in question or if that cannot readily be done,
construe it;
(3) Identify what, if any, differences exist between the matter cited as forming part of the
"state of the art" and the inventive concept of the claim or the claim as construed;
(4) Viewed without any knowledge of the alleged invention as claimed, do those differences
constitute steps which would have been obvious to the person skilled in the art or do they
require any degree of invention?

[36] As noted at paragraph [5], Applicant was given the opportunity to address Sanofi as per
our letter dated May 29th, 2009.

References applied

[37] The references applied by the examiner are D2 in light of the common general
knowledge in the art of e-commerce disclosed by either D3 or D4.

[38] As per our letter dated August 31st, 2012, Applicant was notified of additional evidence of
common general knowledge (see D5).

Analysis - Are claims 1-15 obvious?

(1)(a) Identify the notional "person skilled in the art"

[39] In the SOR, the examiner defines the skilled person(s) as being "skilled in the fields of
electronic commerce, marketing and sales as well as computer programming". In
response, Applicant comments that the person skilled in the art "would be familiar with
computer programming for web applications" and that "the person skilled in marketing
and sales may not be skilled in electronic commerce and computer programming and
vice versa".

[40] The panel notes that the notional skilled technician can be a composite (or team) of
scientists, researchers and technicians bringing their combined expertise to bear on the
problem at hand (Lundbeck Canada Inc. v. Minister of Health 2009 FC 146). Therefore,
the panel agrees with the examiner's characterization of a skilled person.

(1)(b) Identify the relevant common general knowledge of that person

[41] Regarding the common general knowledge, the examiner states that "the skilled person
understands electronic commerce including the concepts of purchase requests between
entities for the fulfilment of an electronic transaction. The skilled person is also
knowledgeable in computer programming techniques including modular design for the
separation of different functionality". In response, Applicant does not disagree but
comments that "the extent to which the skilled person is knowledgeable in modular
design for the separation of different functionality would be according to the extent that
such modular design was used in electronic commerce and web applications at the
claim date of this application".

[42] The panel considers a skilled computer programmer to be familiar with many
programming techniques and their possible areas of application, such as the common
use of modular design for the division of functionality. We reiterate that the skilled
person is a team with knowledge of computer programming as well as e-commerce.
Therefore, the panel agrees with the examiner's characterization of the relevant common
general knowledge of the skilled person.

[43] The present application acknowledges that under current methods of carrying out e-
commerce, merchants are able to purchase services from providers who have expertise
in operating e-commerce hardware and software and who are forced to acquire, publish
and maintain merchant content as well (pages 1-3 of instant application). Therefore, the
panel notes that the ability of a transaction server to maintain and provide searchable
merchant information, in addition to its conventional ability to process a purchase
request to form a purchase transaction (as e-commerce servers are known to do), is
also considered part of the common general knowledge.

[44] In view of D5, the panel adds that the person skilled in the art is also familiar with what
was characterized in 1995 as "the typical current approach" of hyperlinking the retailer to
each manufacturer's catalog in order to provide a customer with access to detailed
product specifications. Applicant elected not to provide any submissions in response to
our letter dated August 31st, 2012 which identified D5 as a reference of common general
knowledge and invited Applicant to consider section 4 of the document which specifically
discusses the hyperlink approach. We take the lack of comment to mean that Applicant
accepts our assessment of D5 as relevant in establishing the common general
knowledge in the art before the claim date.




(2) Identify the inventive concept of the claim in question or if that cannot readily be
done, construe it

[45] The SOR identifies a single inventive concept for all the claims as follows:

Inventive concept relates to the separation of e-commerce transaction functionality and
detailed merchant information by providing reference (from a transaction server) to
detailed merchant information stored on the merchant server, and receiving a purchase
request from the merchant server at the transaction server.

[46] In response, Applicant does not identify an inventive concept, but rather comments on
the proposed advantages of the invention and its features. Having reviewed Applicant's
response, the panel considers these advantages to be implicit or embodied within the
inventive concept provided by the examiner. As such, the assessment of ingenuity
under step 4 takes these advantages into account.

[47] In determining whether the inventive concept identified by the examiner is correct, the
panel first verifies whether it properly reflects the practical problem the invention sets out
to address, and its solution. This is consistent with the office Practice Notice on
Obviousness dated November 2nd, 2009 which notes that in light of subsection 80(1) of
the Patent Rules, "the description shall...describe the invention in terms that allow the
understanding of the technical problem, ..., and its solution".

[48] Although Applicant's response does not provide a statement of the inventive concept, it
does point to a specific passage in the description of the present application which is
useful for the purpose of identifying the inventive concept. The passage identifies what
Applicant considers to be the deficiency or problem in the prior art that the present
application promises to overcome or solve:

Thus, under current methods of carrying out electronic commerce, the merchant whose expertise
lies in producing and managing content is faced with the choice of operating and maintaining an
expensive commerce server or losing control of his marketing to a provider. The provider, whose
expertise lies in the acquisition and maintenance of electronic commerce hardware and software,
must shoulder the burden of acquiring, publishing and maintaining merchant content. (page 3, lines
18-26 of instant application)

[49] Applicant suggests that "a better way of conducting electronic commerce is to allocate
most of the task of content acquisition and maintenance to the merchant, and allocate
most of the task of providing electronic commerce transaction functionality to the service
provider" (page 3, line 29 - page 4, line 2 of instant application). Applicant achieves this
by providing "a system for carrying out electronic commerce over a network where
transaction functionality is provided by a commerce server having a commerce
database, while detailed merchant content is provided on separate merchant content
servers" (page 4, lines 4-9 of instant application).

[50] Based on Applicant's own considerations of what deficiencies exist in the prior art,
namely the merchant and provider being obligated to provide functionality outside of
their areas of expertise, the practical problem addressed by the claims is in relation to
how to overcome the complexities of operating a single server that provides all e-
commerce functionality. The solution claimed involves the separation of e-commerce
functionality over multiple servers by providing reference from a transaction server to a
merchant server offering detailed merchant information and transmitting a purchase
request from the merchant server to the transaction server for processing. The panel
therefore finds that the examiner's characterization of the inventive concept is accurate
and can be re-phrased in the following manner:

A method for conducting electronic commerce by: (i) providing, from a transaction server, reference
to detailed merchant information stored on a merchant server; and (ii) receiving, at the transaction
server, a purchase request from the merchant server for processing.

[51] The panel has reviewed claims 1-15 which, in addition to the inventive concept, set out
limitations related to the processing of the purchase request, generation of reports, and
modification of summary information. We find that all the claims share the same
inventive concept since these further limitations do not contribute anything substantial to
the inventive concept. Our finding accords with Applicant's submissions which do not
put forth any other distinguishing or inventive features. Therefore, we adopt the
inventive concept, as stated at paragraph [50] above, for the purpose of assessing the
obviousness of all the claims.
(3) Identify what, if any, differences exist between the matter cited as forming part of
the "state of the art" and the inventive concept of the claim or the claim as
construed

[52] D2 reflects the state of the art. D3, D4 and D5 reflect the common general knowledge.
For clarity of analysis, D3 and D4 are evaluated under step 3, and D5 is evaluated under
step 4.

[53] Having reviewed the cited documents, the panel has identified differences between the
state of the art and the inventive concept. For the reasons set out below, we find that
D2-D4 do not teach: (i) providing, from a transaction server, reference to detailed
merchant information stored on a merchant server; and (ii) receiving, at the transaction
server, a purchase request from the merchant server for processing.

(i) Providing, from a transaction server, reference to detailed merchant information stored
on a merchant server

[54] The FA admits that D2 "doesn't teach that the transaction server provides a link to more
detailed information on the merchant's web site".

[55] According to D2 "PSIWeb eCommerce creates, integrates, and manages virtual
storefronts for merchants who want to conduct commerce on the Internet...Merchants
control content and administration of their storefront". PSIWeb eCommerce allows a
merchant to control its storefront, but it is not clear that contents of the merchant server
are actually accessible through any transaction server. In attempting to confirm this
point, the panel discovered an article regarding PSINet that quotes a source (Eric
Paulak, research analyst at Gartner Group, Inc.) as remarking that PSINet's offering "is
good for online catalog shopping. But if you need to tap a merchant's database, you
can't do it" (Wexler, Joanie. "PSINet takes E-commerce plunge." Network World 13.41
(1996): 8.). The panel takes this to mean that the merchant server and its contents are
not accessible to the user through PSIWeb eCommerce. Therefore, D2 does not
disclose a transaction server that provides reference to detailed merchant information
stored on a merchant server.

(ii) Receiving, at the transaction server, a purchase request from the merchant server for
processing

[56] D2 does not disclose a transaction server capable of receiving purchase requests from
one or more merchant servers since, as paragraphs [54-55] above demonstrate, it does
not teach a transaction server that links to one or more merchant servers. Moreover, the
FA admits that D2 does not teach "receiving a purchase request and processing the
purchase request to form a purchase transaction".

[57] The examiner relies on D3 and D4 to demonstrate that the transmission of purchase
requests is common general knowledge. The FA states that although D2 does not
specifically teach "receiving a purchase request and processing the purchase request to
form a purchase transaction", these are commonly practiced steps in e-commerce as
taught by D3 or D4.

[58] The systems of D3 and D4 operate differently than the system of the present application.
According to the present application, a user accesses the transaction server directly,
links to the merchant server through the transaction server to obtain more detailed
information on a desired product, and then back to the transaction server with a
purchase request for processing once a product selection is made.

[59] In the system of D3, a user does not access the merchant computer through a
transaction server, but rather, through the use of a buyer computer, retrieves merchant
information directly from the merchant computer. Based on the retrieved information,
either the user sends a purchase request for a desired product to the merchant
computer which then constructs a payment order and sends it to a payment computer, or
the user constructs the actual payment order at the buyer computer and sends it to the
merchant computer for forwarding to the payment computer. The constructed payment
order may also be directly sent from the buyer computer to the payment computer. The
purpose of the payment computer is to perform authorization of payment orders.

[60] In the system of D4, a Buyer Transaction Application (BTA) connects to the merchant
server in order to browse the seller's merchandise and make a selection. Once a user
selects a product for purchase, the BTA sends the identity of the desired product to the
merchant server as well as a message to the Customer Trusted Agent with instructions
to purchase the identified product. On the merchant side, a message is sent from the
merchant server to the Merchant Trusted Agent with instructions to sell the identified
product. The Trusted Agents communicate with each other and with their respective
money modules to effectuate transfer of the merchandise and payment.

[61] Since the purpose of the present application is to achieve separation of transaction
functionality from detailed content over separate servers, in assessing how the division
of functionality is accomplished in the cited art, it is necessary to determine which unit
transmits the purchase request, which unit receives and processes the purchase
request, and how the control flows between them. Although D3 and D4 do show that the
transmission of electronic purchase requests is known, the panel agrees with Applicant
in that neither D2, D3 nor D4 discloses transmitting a purchase request from a merchant
computer to the same transaction server that referenced or linked the customer to the
merchant computer.

(4) Viewed without any knowledge of the alleged invention as claimed, do those
differences constitute steps which would have been obvious to the person skilled
in the art or do they require any degree of invention

[62] As discussed in step 3, D2-D4 do not teach: (i) providing, from a transaction server,
reference to detailed merchant information stored on a merchant server; and (ii)
receiving, at the transaction server, a purchase request from the merchant server for
processing. The question therefore is whether or not there is any degree of invention in
these steps.

(i) Providing, from a transaction server, reference to detailed merchant information stored
on a merchant server

[63] D5, which represents the common general knowledge before the claim date, specifically
states that "the typical current approach using the WWW is for the retailer to hyperlink to
each manufacturer's catalog so that the customer may obtain detailed product
specifications". Therefore, a transaction server that provides reference to detailed
merchant information stored on a merchant server is recognized by D5 to be common
general knowledge.

(ii) Receiving, at the transaction server, a purchase request from the merchant server for
processing

[64] Applicant's response to the SOR indicates that it is important that "the transaction itself
is performed by the transaction server, which originally referred the customer to the
merchant". Otherwise, "transactions originated by the transaction server could be
referred anywhere by the merchant server for transaction processing, negating any
benefit to the operator of the transaction server" (page 3 of Applicant's August 28th, 2009
submission). Similarly, D5 recognizes that after visiting the manufacturer's catalog,
there is a need to revert the customer back to the same retailer (transaction server)
which originally linked the customer to the manufacturer (merchant server), presumably,
in order for the retailer to make the actual sale, thus benefitting from having engaged the
customer and made the referral. D5 suggests that there are challenges in achieving this
through the hyperlink approach, namely: 1) the customer may get lost at the
manufacturer's site and not know how to get back to the retailer; 2) the manufacturer
may not know the context of the customer's interactions with the retailer; 3) the customer
may end up ordering from someone other than the retailer should they stumble upon a
how-to-order page at the manufacturer's site; 4) should the customer use the "back"
button to return to the retailer's site, none of the information determined at the
manufacturer's site, such as the desired product configuration, would be relayed to the
retailer; 5) should the customer be linked back to the retailer through the manufacturer's
how-to-order page, the retailer may not know the original context of the interaction with
the customer such as other products selected for order in the same session.

[65] To overcome these challenges, D5 proposes a solution that avoids the use of the
hyperlink approach altogether by providing a virtual catalog operated by a distributer that
dynamically accesses information from manufacturers' catalogs, thus eliminating any
direct contact between the consumer and the manufacturer. While the solution
proposed by D5 is significantly different than that offered by the present application, in
articulating the challenges associated with the current hyperlink approach, D5 also
discloses, as common general knowledge, the step of (ii) receiving, at the transaction
server, a purchase request from the merchant server for processing.
[66] Of particular significance is the fifth challenge listed at paragraph [64] above, which
recognizes the possibility of a customer being linked back to the retailer from the
manufacturer's how-to-order page using the hyperlink approach. It is presumed that
once the customer has reached the manufacturer's order page, the customer has
already selected a product and is ready to make a purchase. Therefore, linking the
customer back to the retailer at this stage to make an order, instead of ordering from the
manufacturer or using the "back" button, implies that a purchase request is being
transmitted from the manufacturer to the retailer with the necessary information for
processing.

[67] Admittedly, D5 does not detail how to achieve linking the customer back to the retailer
through the manufacturer's order page. It only recognizes the need and ability to do so.
However, the same can be said of the present application which promises to transmit a
purchase request from the merchant server back to the transaction server for
processing, but fails to disclose how this is accomplished or how a conventional
merchant server can accommodate such functionality. In fact, the following excerpts
taken from the description of the present application as well as submissions made by
Applicant raise some confusion with regards to this matter:

A further advantage of the present invention is that any server having content may register with the
commerce server without having to be designed specifically to take advantage of the service.
Besides registering with the service, it is only necessary that the merchant enter content abstracts
to the commerce server. (pages 12-13 of instant application)

Every screen of this embodiment of the content server also can have a Make Purchases button.
The purchaser selects this button when he is ready to effectuate an electronic transaction whereby
the selected products are purchased. When the purchaser has finished shopping and he selects
the Make Purchases button, order information for his selected products is transmitted to the
commerce server. (pages 17-18 of instant application)

In the claimed server and system this single physical entity of the typical electronic commerce
system is split into two physical entities (i.e. the transaction server and the merchant server) with a
network connecting the two servers. This splitting requires a revision in the manner in which
products are searched, transactions are processed, purchaser interfacing is performed, and control
flows. There is a necessary revision in the communication process and control flow as a result of
the split. Each of the two resulting servers must be configured and designed in an entirely new
manner to implement and enable the communication process, control flow and arrangement of
networked hardware according to the claimed invention. (page 4 of Applicant's August 28th, 2009
submission)

The claimed server and system also include a transaction processor in the transaction server for
executing a transaction by accepting transaction requests forwarded by the merchant server from
the purchaser. That element assures that the transaction itself is performed by the transaction
server, which originally referred the customer to the merchant. Without that element, transactions
originated by the transaction server could be referred anywhere by the merchant server for
transaction processing, negating any benefit to the operator of the transaction server. (page 3 of
Applicant's August 28th, 2009 submission)

[68] According to the second passage listed at paragraph [67] above, a "Make Purchases"
button on the merchant server transmits order information back to the transaction server.
One would assume that design changes to the merchant server are required to
incorporate the functionality of such a button. The first passage however indicates that
any merchant server can register without requiring specific design changes. If no
adaptations are required, it is unclear how the conventional merchant server can
communicate with the transaction server and benefit from the present invention, whether
it be through a button or any other means. Moreover, this statement seems to contradict
the third passage which suggests that the merchant server and transaction server must
be configured and designed in an entirely new manner to take advantage of the present
invention. If indeed this is true, it is not evident where such "entirely new" configuration
and design changes are disclosed or claimed. Furthermore, it would be improper for the
panel to supplement the disclosure in the present application with technical details
disclosed in Applicant's submission that are not reasonably inferable from the
specification. The fourth passage seems to suggest that a transaction processor in the
transaction server is responsible for assuring that the merchant server refers the
purchase request back to the same transaction server. This too is neither claimed nor
disclosed in the present application. The disclosure simply indicates that the transaction
server accepts the purchase order from the merchant server but provides no further
details on how it assures that the order is transmitted from the merchant server back to
the same transaction server (page 18, lines 3-25 and page 20, line 44 - page 21, line 14
of instant application).

[69] Therefore, in view of what is disclosed, it appears that the solution proposed by the
present application is no more than a promise to meet the needs already identified by D5
or a statement of a desired result (i.e. the problems identified in D5 restated as being
solved in the present application with no explanation in support of how). In other words,
D5 recognizes that the hyperlink approach necessitates linking the customer back to the
retailer to process the transaction. It even suggests that this may be done through the
manufacturer's how-to-order page, as opposed to simply using the "back" button, in
order for the activity that took place at the manufacturer's site to be relayed to the
retailer. D5 recognizes that there are challenges in accomplishing this, however, the
present application fails to specify how the challenges identified in D5 regarding the
hyperlink approach are overcome. Therefore, it is not apparent what contribution the
present application has made over the existing art. It is possible that the inventor
considered that once the concept of splitting e-commerce functionality over separate
servers was given to the skilled team, details behind the implementation would require
no inventive effort, in which case, the panel would take this to mean that there is no
degree of ingenuity in the inventive concept since D5 already discloses splitting e-
commerce functionality over separate servers.

[70] In its discussion of the "typical current approach" of hyperlinking, D5 discloses all
elements of the inventive concept of the present application. There does not appear to
be any inventive ingenuity in (i) providing, from a transaction server, reference to
detailed merchant information stored on a merchant server and (ii) receiving, at the
transaction server, a purchase request from the merchant server for processing. In view
of D5, the panel considers all elements of the inventive concept to be part of the
common general knowledge in the art. Therefore, the panel finds claims 1-15 to be
obvious.





STATUTORY SUBJECT MATTER

Legal principles - Statutory subject