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 .
Application Status – Pro Se
It appears the inventor(s) filed the current application pro se (i.e., without the benefit of representation by a registered patent practitioner). While inventors named as applicants in a patent application may prosecute the application pro se, lack of familiarity with patent examination practice and procedure may result in missed opportunities in obtaining optimal protection for the invention disclosed. The inventor(s) may wish to secure the services of a registered patent practitioner to prosecute the application, because the value of a patent is largely dependent upon skilled preparation and prosecution. The Office cannot aid in selecting a patent practitioner.
A listing of registered patent practitioners is available at https://oedci.uspto.gov/OEDCI/. Applicants may also obtain a list of registered patent practitioners located in their area by writing to Mail Stop OED, Director of the U.S. Patent and Trademark Office, P.O. Box 1450, Alexandria, VA 22313-1450.
Claims Status
Claims 1-15 are pending and stand rejected.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1-15, claims 1-15 are rejected as failing to define the invention in the manner required by 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. The claim(s) are narrative in form and replete with indefinite language.
The following is a list of examples of the errors found in the claims. Though the Examiner has attempted to identify a complete listing of errors, this list below is non-exhaustive and all of the claims must be reviewed for similar and additional errors. A sample amendment and interpretation have been provided below (beginning on p. 14) in order to aid Applicant in responding to this office action. Applicant is invited to contact the Examiner if further explanation and guidance is needed.
Regarding claim 1, claim 1 recites:
In lines 4-5: “identifies the communication class to set up data for a URL”. There is insufficient antecedent basis for “the communication class” in the claim.
In lines 9-10: “allowing the user to tap the send button to have the message transmitted…”. Claim 1 recites an “action button” prior to “the send button”, but does not reciter a “send button”. There is insufficient antecedent basis for “the send button” in the claim.
In lines 10-11: “…to message transcripts on devices used by the user group via a messaging host…”. There is insufficient antecedent basis for “the user group” in the claim.
In lines 11-12: “with callbacks to trigger the core on the sending device to call the session app to update the timestamped data in the entity data model cache”. The phrasing “the core” has insufficient antecedent basis because the previous recitation of a core is “an ecommerce extension core”. Likewise, there is insufficient antecedent basis for each of “the sending device” and “the entity data model cache”. Further, “the timestamped data” lacks antecedent basis because the prior recitation is “timestamped status”.
In line 14: “…in a message transcript, the active core performing a tap-to-update process…”. There is insufficient antecede4nt basis for “the active core” in the claim.
In lines 15-16: “…invoking the evaluation process for session app launch preparations…”. There is insufficient antecedent basis for “the evaluation process” in the claim.
In lines 17-18: “update entity data and action-key-based computation in the receiving session data model cache”. There is insufficient antecedent basis for “the receiving session data model cache” in the claim.
In lines 19-20: “then the core initializes full-screen mode, and launches the session app that opens the view for further action”. Claim 1 recites each of an “ecommerce extension core” (line 4) and an “active core” (line 14). It is unclear which core “the core” in line 19 refers to.
In lines 20-22: “if present, an action button enables a tap-to-message reply to the sender for the next status update in the workflow”. Claim 1 positively recites the presence of “an action button” in line 3. It is unclear how the condition of “if present” relates back to the already positively recited app button.
Further, each of “the sender”, “the next status update”, and “the workflow” lack antecedent basis in the claim.
In lines 25-27: “apply business rules to the items merged in search results and shopping carts, and store results in memory objects to compute prices that are updated in the first session data model cache on the first device and displayed in the current UI (user interface). There is insufficient antecedent basis for each of “the items merged”, “the first session data model cache”, “the first device” and “the current UI (user interface)” in the claim.
In lines 27-29: “and then the first session app propagates these changes to memory objects associated with the shopping list, order list, checkout, and dynamic checkout widget UIs in the active store, refreshing these interconnected UIs automatically”. It is unclear what “these changes” may be a reference to, and there is insufficient antecedent basis for this limitation in the claim.
The terms “the shopping list, order list, checkout, and dynamic checkout widget UIs” and “the active store” also lack antecedent basis in the claim.
In lines 32-33: “in assigned caches to keep the first and second session data model caches unchanged”. There is insufficient antecedent basis for “the first and second caches”.
In line 33: “unchanged until the workflow is complete for the core”. Claim 1 recites “the workflow” (line 21-22) as well as “an order-return workflow” (line 21). It is unclear to which workflow “the workflow” in line 33 refers.
Further, claim 1 recites each of an “ecommerce extension core” (line 4) and an “active core” (line 14). It is unclear which core “the core” in line 33 refers to.
In line 34: “perform a one-time update in the sending and receiving session apps”. There is insufficient antecedent basis for “the sending and receiving session apps”. Claim 1 recites “a session app” and “a first session app” but does not recite “sending and receiving session apps”.
In line 39-40: “wherein the core on the sending device receives a callback confirming a first user (customer) tapping the send button”. Claim 1 recites each of an “ecommerce extension core” (line 4) and an “active core” (line 14). It is unclear which core “the core” in line 39 refers to.
In lines 37-39: extracts from the temporary table and updates the order history, return-refund data, return-shipment table, and SKU table in the first session data model cache”. There is insufficient antecedent basis for “the order history, return-refund data, return-shipment table, and SKU table”.
In lines 39-40: “wherein the core on the receiving device receives a callback confirming a second user (seller) tapping the received refund-confirmed message in the transcript”. Claim 1 recites each of an “ecommerce extension core” (line 4) and an “active core” (line 14). It is unclear which core “the core” in line 39 refers to.
The terms “the receiving device” and “the received refund-confirmed message” also lack antecedent basis in the claim.
Further, “the transcript” lacks antecedent basis in the claim. Although reciting “message transcripts” claim 1 does not recite a singular “transcript”.
In lines 41-42: “performs a tap-to-update process to decode the temporary table in the URL,”. There is insufficient antecedent basis for the term the temporary table in the URL. Although the term “the temporary table” has antecedent basis, there is no prior recitation of a temporary table in the URL as claimed in lines 41-42.
In lines 46: “role-based communication between the distributor and one or more publishers”. There is insufficient antecedent basis for “the distributor” in the claim.
In line 48: “wherein the second session app identifies a second user’s multiple devices”. There is insufficient antecedent basis for “the second session app” (singular) because the claim recite plural “second session apps” (e.g., line 45).
In lines 49-50: “to appoint the second user on the first-registered device to act as the distributor”. There is insufficient antecedent basis for “the first-registered device” in the claim.
In the lines 50-51: “and the ones on storefront devices to act as publishers and customizes the UIs for the distributor. There is insufficient antecedent basis for “the ones on storefront devices” and “the UIs for the distributors”.
In line 55: “allowing first users to conveniently shop across multiple stores.”. The scope of what may be considered “convenient” verses not convenient is unclear. This is a relative term that is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Further regarding claim 1, claim 1 uses the term “core” (e.g., ecommerce extension core, active core, and “the core”) throughout. The specification provides little detail that enables one of ordinary skill in the art to ascertain the scope of what may or may not comprise a “core”, and ultimately avoid infringement of the claim. This is because the specification never sets forth any definition of “core”, the drawings fail to provide any depiction of a “core”, and the specification fails to provide any other description of what the core may comprise.
Various portions of the specification use the term “core” and describe “core” in terms of its functionality (e.g., 0010-0011, 0020, 0022, 0025, Fig. 5 (560), Fig. 6 (600, 646), et. al); however, this does not provide adequate disclosure of what a “core” comprises.
At best, Fig. 10A-B depict “the core (1020) sans any further detail. Descriptive paragraphs 0100-0102, 0104, and 0106-0107 further recite the use of the core in relation to its function only sans any description of what it may comprise.
Further regarding claim 1, claim 1 recites each of an “ecommerce extension core” and an “active core”. The specification, however, does not provide sufficient details such that one of ordinary skill in the art would be able to delineate the metes and bounds of each term and understand the distinction between an “extension” core and an “active” core. In fact, the specification in 0101-0102 refers to element 1020 (Fig. 10A-10B) as “the extension core”, while in paragraphs 0106-0107 referring to element 1020 as “the active core”. It is thereby unclear whether there are two distinct cores, and what the scope of an “extension core” and an “active core” may be.
As best understood by the Examiner, the term “core” will be understood as software that forms part of an application (“app”). Further, as only one core is depicted in Fig. 10A-10B, the extension core and active core will be interpreted as a singular core (e.g., software) that intermediates communications between two or more session apps.
Further regarding claim 1, in lines 48-49 claim 1 recites “the second session app identifies a second user’s multiple devices”; however, “a second user (seller)” was previously recited in line 40 of claim 1. It is unclear whether “a second user’s” in line 48 is the same “second user” as recited in line 40, and whether the second user of line 48 is also a “seller” as recited in line 40.
Regarding claim 2, claim 2 recites “the extension core”. As discussed above with respect to claim 1, both the term “core” and “extension core” are unclear. Claim 2 is rejected for similar reasons herein.
Regarding claim 3, claim 3 recites “a first session app”; however, claim 1 recites “a first session app” and “the first session app” (e.g., lines 23, 27). It is unclear whether “a first session app” in claim 3 intends to reference “the first session app” of claim 1. Further, claim 3 recites “these changes”. It is unclear what “these changes” may refer to as there is a lack of antecedent basis for “changes” in the claim.
Further regarding claim 3, claim 3 also recites “seamless navigation”. It is unclear how “seamless” navigation may differentiate from “navigation”. This is a relative term that is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Regarding claim 4:
Claim 4 recites “the core” and is indefinite for at least the reasons discussed above with respect to claim 1 in relation to the term “core”.
Claim 4 recites “in response to a second user’s tapping”; however, “a second user (seller)” was previously recited in line 40 of claim 1, as well as “a second user” in line 48-49. It is unclear whether “a second user’s” in claim 4 is the same “second user” as recited in line 40 or lines 48-49 of claim 1, and whether the second user of claim 4 is also a “seller” as recited in claim 1.
Claim 4 recites “tapping the publish button”. There is insufficient antecedent basis for “the publish button” in the claim.
Claim 4 recites “a second session app invokes the process to partition and serialize the store entity data”; however, claim 1 recites “a second session app” (line 45) and “the second session app” (line 48). It is unclear whether “a second session app” in claim 4 intends to reference “the second session app” of claim 1.
Claim 4 recites “invokes the process to partition and serialize the store entity data”. There is insufficient antecedent basis for each of “the processes” and “the store entity data”.
Claim 4 recites “notify the messaging host to transmit the message and push the attachments with sequential IDs”. It is unclear which message the message is referring to.
There is also a lack of antecedent basis for and “the attachments with sequential IDs”. This is because the previous recitation is “multimedia attachment files” sans sequential IDs.
Claim 4 recites “on devices used by the current group with callbacks”. Although claim 1 recites a “user group” (line 10-11), there is insufficient antecedent basis for “the current group”.
Claim 4 recites “saves the timestamped attachment files and group ID in second session data model cache”. There is insufficient antecedent basis for “the timestamped attachment files”.
Claim 4 recites “in response to the attachments copied over by the first user from the messaging app to the container app”. There is insufficient antecedent basis for “the attachments copied over” because there is no recitation of attachments that have been copied over. There is also insufficient antecedent basis for “the messaging app” and “the container app”.
Claim 4 recites “a specific smart service API deserializes the attachments, updates the store entity data streams”. It is unclear to which attachments “the attachments” refers back to. Further, although there is antecedent basis for “the store entity data” there is not antecedent basis for “the store entity data streams”.
Claim 4 recites “moves product photos into the application sandbox”. There is insufficient antecedent basis for “the application sandbox” in the claim.
Claim 4 recites “to present the store UIs”. There is insufficient antecedent basis for “the store UIs” in the claim.
Regarding claims 5-7, as with claims 1-4 above, claims 5-7 are narrative in form and replete with indefinite language. Claims 5-7 are replete with similar errors as discussed above, and are rejected herein for failing to define the invention in the manner required by 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. The Examiner again draws Applicant’s attention to the sample amendment below to review the errors in claims 5-7 and for guidance in amending claims 5-7 to comply with 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Further regarding claims 5-7, Applicant is reminded that the claim(s) must be in one sentence form only. Claims 5-7 contain multiple sentences. Appropriate correction is required. Note the format of the claims in the patent(s) cited.
Regarding claim 8, claim 8 recite substantially parallel limitations and scope as recited in claim 1. That is, claim 8 recites:
A system comprising:
at least one processor; and
at least one non-transitory computer readable storage medium storing executable program instructions that, when executed by the at least one processor, configure the at least one processor to perform operations comprising:
The language following “operations comprising” parallels the method outlined in the body of claim 1. That is, claim 8 parallels claim 1 in the following manner:
Claim 8
Claim 1
Lines 6-15
Lines 3-12
Lines 16-25
Lines13-22
Lines26-33
Lines23-30
Lines 34-48
Lines31-44
Lines 49-59
Lines45-55
The body of claim 8 exudes parallel deficiencies to those raised with respect to claim 1. Accordingly, claim 8 is rejected under at least similar rationale and grounds as discussed above with respect to claim 1.
Regarding claims 9-15, claims 9-15 recite substantially parallel limitations and scope as recited in claim s 2-7. The body of claims 9-15 exude parallel deficiencies to those raised with respect to claims 2-7. Accordingly, claims 9-15 are rejected under at least similar rationale and grounds as discussed above with respect to claims 2-7.
Sample Amendment and Claim Interpretation
The following amendment is adopted as the interpretation of claims 1-7 and serves as an example of remedying deficiencies raised above under 35 USC 112(b) (though further correction may be necessary).
Similar interpretations and amendments are adopted for system claims 8-15, which parallel method claims 1-7. Applicant is advised that similar amendments can be applied by Applicant to claims 8-15. The amendment sample is as follows:
1. A method for facilitating commerce within a messaging app, the method comprising:
in response to a user tapping an action button within a session app, tap-to-message process includes:
staging order or store data, a timestamped status, and an action key that identifies [[the]] a communication class to set up data for a URL,
calling smart service APIs (application programming interfaces) to encode the staged data into the URL and overlay a dynamically computed branding image to generate a branded message to be posted to a message bar via an IPC (interprocess communication), and
allowing the user to tap [[the]] a send button to have the branded message transmitted to message transcripts on devices used by a [[the]] user group via a messaging host with callbacks to trigger a sending device to call the session app to update the timestamped [[data]] status in [[the]] an entity data model cache;
in response to a callback confirming a recipient tapping a received branded message in a message transcript, tap-to-update process includes:
decoding the order or store data and the action key in [[a]] the URL,
invoking an [[the]] evaluation process for session app launch preparations, and calling an action-key-based smart service API to finish processing the order or store data in the URL,
update entity data and action-key-based computation in a [[the]] receiving session data model cache, and
assemble data required for opening a subsequent deep link view, a full-screen mode, and launches the session app that opens the view for further action[[;]], wherein the a sender for a [[the]] next status update in [[the]] a workflow;
performing, through one or more memory objects, dynamic updates by a first session app and smart services using APIs to create and update memory objects, apply business rules to [[the]] items merged in search results and shopping carts, and store results in memory objects to compute prices that are updated in [[the]] a first session data model cache on a [[the]] first device and displayed in [[the]] a current UI (user interface), and [[then]] the first session app propagating the updated prices to memory objects associated with [[the]] shopping list, order list, checkout, and dynamic checkout widget UIs and refreshing these interconnected UIs automatically;
processing, within an order-return workflow, return-refund data by order number in a temporary table that is also stored in a first data model cache and a second data model cache data model cache and the second session data model cache[[s]] unchanged until the order-return workflow is complete, respective sending and receiving session apps with data in the temporary table, wherein the URL to message transcripts via a messaging host, extracts from the temporary table and updates [[the]] an order history, return-refund data, return-shipment table, and a SKU table in the first session data model cache, and wherein a a received refund-confirmed message in the message transcripts, and performs a tap-to-update process to decode
configuring, with a second session app[[s]], a multi-store shopping system utilizing a store-as-a-service model [[and]] that facilitates role-based communication between a [[the]] distributor and one or more publishers for first users to subscribe to multiple stores created by the distributor and managed by respective publishers; wherein the second session app identifies of the second user by unique PINs to appoint the second user on a [[the]] first-registered device to act as the distributor and users of distributor UIs s and distribute store production copies to publishers, and for publishers to create user groups on their storefront devices to generate and share individual subscription lists with the distributor to get approval to add custom promotions to their production copies and publish them to subscribed user groups[[,]]
2. (Currently Amended) The method as in claim 1, wherein branded messages are categorized by action keys
3. (Currently Amended) The method as in claim 1, wherein [[a]] the first session app merges product data, including SKU-identified item prices, quantities, styles, and promotions for items selected from search results and shopping carts, sorts the merged items based on selected filters, recomputes deal prices and checkout savings based on promotion business rules only if product attributes and quantities of a selected category item have changed, saves the changes product attributes and quantities
4. (Currently Amended) The method as in claim 1, wherein the second user to publish an in-app store to a group of first users for in-app shopping with a method comprising: (a) in response to [[a]] the second user tapping [[the]] a publish button in an editor fa process to partition and serialize [[the]] store entity data into one or more multimedia attachment files having sequential IDs, and s the [[a]] tap-to-message process to generate [[a]] the branded store message, notify the messaging host to transmit the branded message and push the multimedia attachment filed user [[current]] group with callbacks, and a group ID in the second session data model cache; (b) in response to [[a]] the first user tapping the received message in the transcript with callbacks, perform a tap-to-update process to open to a default store with preset data; (c) in response to copying over the timestamped attachment[[s]] files a [[the]] messaging app to [[the]] a container app, a specific smart service API deserializes the attachments copied over, updates the store entity data an application sandbox; and (d) in response to the user tapping the message in the transcript again, launching the first session app to present [[the]] store UIs with photos, metadata, promotions, business policies, store collections, and data model cache streams for in-app shopping and order tracking.
5. The method as in claim 1, calling an action-key-based smart service API to compute order-payment summaries with the data stored in the second session data model cache to ensure first users to have [[the]] accurate payment information when order workflows progress from being requested at [[the]] an ordered stage to being billed at an [[the]] invoiced stage with a method comprising: (a) in response to [[a]] the second user tapping a received order-requested message in a message transcript, receiving a callback and performing new order-payment summary, merge [[the]] reconciled order-payment data and timestamped order-requested status into the order history, update the data and status in the second session data model cache, and assemble data required for opening a deep link view, initializing full-screen mode and launching the second session app that opens [[the]] a payment-request view with [[the]] a reconciled summary and explanations of price differences; (b) in response to the second user tapping the notify button in the view to reply to the first user, generating and sending a branded payment-requested message including a branded image and a URL encoded with the reconciled order-payment data and timestamped payment-requested status via a tap-to-message process with callbacks performing a tap-to-update process to call the smart service API to replace [[the]] matching order-payment data in the order history and first session data model cache with the one decoded from the URL.
6. The method as in claim 1, wherein processing a return-refund workflow a respective assigned cache in the session app, so that the respective order data in the first and second session data model caches remain unchanged without having to rollback transactions to previous versions if a return request is canceled or disqualified, and wherein upon receiving a callback confirmation for a branded refund-confirmed message on the sending and receiving devices, a one-time update for each session app is processed, synchronizing return-refund data between session apps when a return-refund workflow is complete at the refund-confirmed step with a method comprising: (a) in response to a first user tapping the send button for the messaging host to transmit the branded refund-confirmed message with a URL encoded with the temporary table data, the active core receives a callback confirmation, updates the order history, return-refund data, return-shipment table, and SKU table in the first session data model cache, deletes the temporary table a return shipment and return-refund summary; and (b) in response to a callback triggered by a second user tapping the received branded refund-confirmed message on the second device, the active core performs a tap-to-update process, decoding the data in the URL, calling the action-key-based smart service API to update the order history, return-refund data, return-shipment table, and SKU table in the second session data model cache,a return-refund summary.
7. The method as in claim 1, wherein respective production copies to their subscribed user groups an assign button in [[the]] a store manager UI, generate and send a [[the]] branded assignment-list message to a group of publishers via a tap-to-message process; in response to each publisher tapping the received message, perform a tap-to-update process to update the store-device assignment list in the second session data model cache on the respective storefront device to be used for planning; (b) in response to each publisher tapping the received branded store message sent by the distributor, performing a tap-to-update process to launch [[the]] a production copy of the store in the second session app for read-only review; (c) in response to each publisher tapping [[the]] a subscribe button in [[the]] a group manager UI, send a subscription list of reviewed stores subscribed by user groups created by a respective publisher to the distributor, the distributor verifying the subscription list of reviewed stores through a tap-to-update process and replies with a branded approved message via a tap-to-message process to the respective publisher, granting privileges to promote and publish the stores on the subscription list to the subscribed groups; (d) in response to each publisher tapping the received approved message, the second session app activates [[the]] promotion manager, publish button, order history, and sales analytics UIs for each publisher to add promotions customized by user groups to a respective production copy, and then publish the store to subscribed user groups; and (e) in response to each subscriber tapping the received branded store message in transcripts sent by a publisher, having performing a tap-to-update process to launch the first session app that opens [[the]] a store homepage with data retrieved and populated across shopping UIs.
Discussion of Prior Art
Claims 1-15 are rejected under 35 USC 112(b) as discussed above. In light of the interpretation in the section Sample Amendment and Claim Interpretation, the Examiner has determined that the claim – as a whole – are neither anticipated nor rendered obvious in light of the particular combination of elements as claimed. That is, the Examiner emphasizes the claims as a whole and hereby asserts that the totality of the evidence fails to set forth, either explicitly or implicitly, an appropriate rationale for combining or otherwise modifying the available prior art to arrive at the claimed invention. The combination of features as claimed would not have been obvious to one of ordinary skill in the art because any combination of the evidence at hand to reach the combination of features as claimed would require a substantial reconstruction of Applicant’s claimed invention relying on improper hindsight bias. A discussion of the most pertinent prior art is provided below:
Jayaraman (US 2024/0220951) discloses an app-based refund processing system and method which provides user interfaces for requesting refunds and refund status, providing refund status alerts (see: Fig. 3-6, 0092, 0095-0096).
Pye (US 20220138228) discloses a message-based payment system that enables processing of refund and chargeback requests in relation to disputed transactions (see: 0020, 0038, 0057-0058).
Schmidt (US 2016/0285816) discloses a consumer-to-business messaging system for processing refunds to users. The consumer-to-business messaging system utilizes a messaging endpoint and allows a user to request a refund from a merchant from within the messaging endpoint by associating a messaging thread between the user and the merchant with a transaction identifier tied to a payment transaction between the user and the merchant (see: 0091, 0165, 0246, Fig. 7).
Milbank (US 2022/0036433) discloses a publish/subscribe model of collaborative online shopping between a customer and a retailer through a shared virtual shopping basket (see: 0034, 0038-0039, 0040, 0043)
Ayad (US 2021/0125247) discloses merchant management of multiple online store, each with its own separate inventory, orders, domain name (or subdomain), currency, etc. The merchant defines a plurality of steps of a workflow, the steps including a trigger that triggers the workflow, a condition, and an action to be taken if the condition is met. A particular step of the workflow is associated with a plurality of online stores that belong to the merchant. The method further includes storing the workflow in memory, including storing a respective store identifier for each online store associated with the particular step (se: Fig. 5-6, Fig. 9, 0006, 0026, 0058-0068).
Kassemi (US 2015/0332365) discloses an email-based e-commerce system that facilitates payments using email, SMS, MMS and Social Media to make payments for products or services (see: 0038, 0042, 0049-0050, Fig. 3).
PTO form 892-U discusses the integration of SMS payments into merchants' business models through the utilization of various digital wallet technology (see: Introduction, sections 3.1-3.3, section 4).
PTO form 892-V discusses integrating Web content, a “Webhook API” and an SMS server in order to serve requests for information and transactions from users (e.g., payers, merchants, and administrators) (see: section (II)(B), section (III), Fig. 1, Fig. 3-5).
Although various aspects of the claimed invention (as interpreted above) can be found across the references above and in disparate references available as prior art, the prior art available does not provide adequate disclosure of proper rationale to combine multiple references to arrive at the claimed invention. Accordingly, the particular combination of limitations as recited in claim 1 and parallel claim 8 is considered unobvious over the prior art. Claims 2-7 and 9-15 depend from claims 1 and 8, respectively, and are unobvious therewith.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM J ALLEN whose telephone number is (571)272-1443. The examiner can normally be reached Monday-Friday, 8:00-4:00.
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, Anita Coupe can be reached at 571-270-3614. 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.
WILLIAM J. ALLEN
Primary Examiner
Art Unit 3625
/WILLIAM J ALLEN/Primary Examiner, Art Unit 3619