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 .
Claim Objections
Claim 19 is objected to because of the following informalities recited “medium containing instruction, comprising…” followed by steps, Examiner suggests amending the claim to recite “non-transitory medium containing instruction, when executed by a processor …” Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “authentication layer” “a workflow orchestration layer” “data pipeline layer” followed by “configured to and functions in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al (2020/0387360) in views of Mehta et al (9344427).
For claim 1, Patel teaches an embedded services platform (abstract), comprising:
an authentication layer configured to receive data from a partner device, a merchant device, and a provider device, and authenticate the data (Patel teaches that the service authorization component 133, within the enterprise network 130 to call a service widget 124 (also referred to as a data collection widget in other examples). To allow access to the enterprise network 130, the enterprise network 130 may authenticate the client device via an authentication process, such as OAuth or the like. One of the benefits of authentication is that it enables scalability and is a first step in security and Correctly identifying and authenticating third-party sites calling a platform or component in the enterprise network 130 is germane to scalability and security purposes. For example, most third-party client backend devices 113 and the third-party website 117 may need to “onboard” (e.g., provide verifiable credentials and fulfill security requirements in exchange for the authentication token) with the enterprise network 130. The authentication token 116 may contain information identifying the third party, who is the entity responsible for the third-party network 110, and that may be sent for each call to the enterprise network as Patel teaches in par.21-22).
a workflow orchestration layer configured to implement one or more event- triggered workflows based on the data associated with the request received from the application layer (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget as Patel teaches in par.17);
one or more databases configured to store the data associated with the request (Patel teaches that The composite repository may store a number of data collection containers. Each container of the plurality of data collection containers may include two or more universal modules from the plurality of universal modules. The pipeline processing component may be coupled to the memory, the module repository, and the composite repository. The pipeline processing component is operable to execute the programming code stored in the memory. When executing the programming code, the pipeline processing component performs functions to select a first universal module from the number of universal modules stored in the module repository as Patel teaches in par.5);
and a data pipeline configured to transmit data stored in the one or more databases to the partner device, the merchant device, and the provider device (Patel teaches that The pipeline processing component 220 may also be coupled to the memory 223, the module repository 210, and the composite repository 230 of the enterprise data collection and service delivery system 201. The pipeline processing component 220 may be operable to execute the programming code stored in the memory 223 to perform different functions as Patel teaches in par.39).
Patel fails to teach that an application layer accessible via authentication from the authentication layer, configured to receive data associated with a request from the partner device, the merchant device, and the provider device.
Mehta teaches, similar system, an application layer accessible via authentication from the authentication layer, configured to receive data associated with a request from the partner device, the merchant device, and the provider device (Mehta teaches that the application layer 202 may generally include one or more of the third party applications 108, the applications 116, and the network-based services 118, the control layer 204 may include the authentication subsystem 128, and the data layer may include the directory subsystem 122 and the agent and The application layer 202 passes the user credentials to the control layer 204, which authenticates and manages the session. During the session, the control layer 204 passes requests and queries to the data layer 206, as necessary. The user device 104 may also communicate directly with the data layer, e.g., independently of the control layer. For example, certain applications and services, including some managed desktop computing services and file sharing services, may require a user to access the data layer 206 directly, i.e., independently of the control layer as Mehta teaches in col.2, lines 48-68, and col.9, lines 5-23). It would have been obvious to one ordinary skill in the art before effective filling date to modify Patel to include application layer accessible via authentication from the authentication layer as taught and suggested by Mehta in order authenticate user credentials through the application (e.g., to initiate a session with the application) and independently of the application and facilitate multiple authentications of user credentials, with a single presentation of the credentials (Mehta, col.2, lines 15-20).
For claim 2, Patel, as modified by Mehta, further teaches that wherein data includes one or more of a partner ID, a merchant ID, a provider ID, or an access token (Patel teaches that most third-party client backend devices 113 and the third-party website 117 may need to “onboard” (e.g., provide verifiable credentials and fulfill security requirements in exchange for the authentication token) with the enterprise network as Patel teaches in par.22).
For claim 3, Patel, as modified by Mehta, further teaches an object registry configured to receive data from the application layer or the data pipeline (Patel teaches that the pipeline processing component 220 may analyze the respective data summary pages of each of the selected several universal modules to identify data dependencies. Based on the identified data dependencies being valid, the pipeline processing component 220 may couple the selected second universal module to the selected first universal module to form a first set of coupled modules in a customized data collection widget as Patel teaches in par.54).
For claim 4, Patel, as modified by Mehta, further teaches wherein the workflow orchestration layer further comprises one or more workflows: a new partner workflow configured to onboard a new partner to the embedded services platform; and a change partner workflow configured to modify an existing partner in the embedded services platform (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget as Patel teaches in par.17).
For claim 5, Patel, as modified by Mehta, further teaches wherein the application layer further comprises: an administrative portal configured transmit data to trigger the new partner workflow and/or the change partner workflow, based on an interaction with the application layer (Patel teaches that The composite repository may store a number of data collection containers. Each container of the plurality of data collection containers may include two or more universal modules from the plurality of universal modules as Patel teaches in par.5).
For claim 6, Patel, as modified by Mehta, further teaches wherein the application layer further comprises: a provider portal configured to transmit data to the application layer from the partner device (Patel teaches that The customized data collection container and one or more other data collection containers may be selected from the plurality of other data collection containers. The selected customized data collection container and the selected one or more other data collection containers may be combined to form a customized data collection widget. The customized data collection widget may be delivered to a composite repository. The customized data collection widget is uniquely identifiable from other widgets stored in the composite repository as Patel teaches in par.6).
For claim 7, Patel, as modified by Mehta, further teaches wherein the workflow orchestration layer further comprises one or more workflows: a provider workflow configured to generate offer data for a merchant (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget and fetch application information, decision offers for a customer, and process vehicle pricing information to service any customer's flow through the prequalification process as Patel teaches in par.17 and 26).
For claim 8, Patel, as modified by Mehta, further teaches wherein the application layer is further configured to generate an embedded shell widget (Patel teaches that customized data collection widget. Building of the customized data collection widget includes receiving a selection of several universal modules for inclusion in the widget. Each universal module of the selected several universal modules may include programming code that causes rendering of user-fillable data fields on a display, and a summary page including data requirements of the respective universal module as Patel teaches in abstract).
For claim 9, Patel, as modified by Mehta, further teaches wherein the embedded shell widget is configured to render an offer, a service, or an application from a provider to a merchant (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget and fetch application information, decision offers for a customer, and process vehicle pricing information to service any customer's flow through the prequalification process as Patel teaches in par.17 and 26).
For claim 10, Patel, as modified by Mehta, further teaches wherein the embedded shell widget is further configured to receive partner styling data from the application layer and render the embedded shell widget with the partner styling data (Patel teaches that the user via the user browser 123 may interact with the website provided by the third-party network 110. The user browser 123 may, in response to inputs to the website provided by the third-party, may send a widget delivery request to the enterprise network 130 for a services widget. The communication interface 131 may forward the request to the composite repository 138. The composite repository 138 may, in some examples, include a processor or controller that is responsive to received requests. The composite repository 138 may receive a widget delivery request for delivery of the service widget to the user browser 123. For example, the widget delivery request may be a request for a specific service provided by the enterprise via the enterprise network 130. In some embodiments, the specific service may be a process for prequalifying a user for lender financing for purchase of an item (e.g., a vehicle). The widget delivery request, in some examples, may also include information related to an item available for purchase through the third-party network 110 as well as information usable to deliver a widget, such as an address of the user device 120 on the data network 160. The composite repository 138 may, in response to the widget delivery request, obtain a copy of the service widget 124 of the service widgets 139 and deliver the copy of the services widget 124 to the user browser 123. The delivered services widget 125 may include programming code that executes within a website, such as a website 117, executed by user browser 123. The website 117 may have multiple webpages as Patel teaches in par.6 and 32).
Claims 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Maes et al (2018/0130106) in views of Patel et al (2020/0387360).
For claim 11, Maes teaches that a method (abstract), comprising:
receiving, by one or more processors of an embedded services platform, a request from a merchant device to integrate one or more embedded services from one or more providers (Maes teaches that onboarding of resellers to the aggregated marketplace under the control of the reseller management platform 400 is described, but it should be understood that other types of onboarding may be carried out in the systems 10, 11. In particular, each entity in the system 10, 11 may be “onboarded” to another entity in the system (e.g., service vendors 300 may be onboarded to the aggregated marketplace, down-stream resellers may be onboarded to an up-stream reseller's marketplace, etc.), and therefore each entity in the system 10, 11 may include instructions that may be configured to facilitate such other onboardings which may be in addition to the reseller management platform 400 or the sub-reseller management platforms as Maes teaches in par.28, 55, and 85); aggregating, by the one or more processors of the embedded services platform, one or more merchant datasets of a merchant account associated with the merchant device, wherein the one or more merchant datasets are stored in a database of the embedded services platform (Maes teaches that aggregate multiple catalogs of service vendors into an aggregated catalog of the first instance, and additional instances of the marketplace platform (reseller instances) to aggregate the aggregated catalog of the first instance (or the aggregated catalog of another reseller instance) into the aggregated catalog of the respective reseller instance into the aggregated catalog of the respective reseller instance as Maes teaches in abstract and par.10);
transmitting, by the one or more processors of the embedded services platform, the one or more merchant datasets to the one or more providers; receiving, by the one or more processors of the embedded services platform, offer data from the one or more providers (Maes teaches that the reseller marketplace platforms 200 may be, but do not necessarily have to be, hosted on infrastructure of the marketplace operator—that is, the infrastructures 260_1 through 260_M may be, but do not have to be, owned by the marketplace operator. For example, some or all of the reseller marketplace platforms 200 may be hosted on shared infrastructure in a cloud of the marketplace operator. As another example, some or all of the reseller marketplace platforms 200 may be hosted on infrastructure of their respective reseller—e.g., the reseller associated with reseller platform 200_1 owns the infrastructure 260_1, and so on. As another example, some or all of the reseller marketplace platforms 200 may be hosted on infrastructure of a third-party. For example, the marketplace operator may provide software corresponding to the reseller management platform 400 to the reseller (e.g., via download), who may then install/run the platform 400 on infrastructure of their choosing (their own, or a third-party's) as Maes teaches in par.25, 33 and 50).
Maes fails to teach that generating, by the one or more processors of the embedded services platform, one or more embedded widgets based on the offer data from the one or more providers and transmitting, by the one or more processors of the embedded services platform, the one or more embedded widgets to the merchant device associated with the merchant account, wherein the one or more embedded widgets are configured to display the offer data from the one or more providers.
Patel teaches, similar system, generating, by the one or more processors of the embedded services platform, one or more embedded widgets based on the offer data from the one or more providers (Patel teaches in abstract), transmitting, by the one or more processors of the embedded services platform, the one or more embedded widgets to the merchant device associated with the merchant account, wherein the one or more embedded widgets are configured to display the offer data from the one or more providers (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget and fetch application information, decision offers for a customer, and process vehicle pricing information to service any customer's flow through the prequalification process as Patel teaches in par.17 and 26). It would have been obvious to one ordinary skill in the art before effective filling date to modify Maes to include the one or more embedded widgets to the merchant device associated with the merchant account as taught and suggested by Patel in order to form a uniquely identifiable, customized data collection widget. The customized data collection widget may be delivered to the composite repository (Patel, abstract).
For claim 12 and 20, Maes, as modified by Patel, fails to teach receiving, by the one or more processors of the embedded services platform, a selection of an embedded widget of the one or more embedded widgets and a merchant access token; authenticating, by the one or more processors of the embedded services platform, the merchant device associated with the merchant account; and generating, by the one or more processors of the embedded services platform, an embedded application widget based on the selection of the embedded application widget.
Patel further teaches that receiving, by the one or more processors of the embedded services platform, a selection of an embedded widget of the one or more embedded widgets and a merchant access token; authenticating, by the one or more processors of the embedded services platform, the merchant device associated with the merchant account; and generating, by the one or more processors of the embedded services platform, an embedded application widget based on the selection of the embedded application widget (Patel teaches that customized data collection container may be stored in a composite repository with a number of other data collection containers. The customized data collection container and one or more other data collection containers may be selected from the number of other data collection containers. The executable programming code of respective universal modules may be combined in the selected customized data collection container and the selected one or more other data collection containers to form a customized data collection widget. The combined executable programming code may include client style code and universal style code as presentation elements into the executable programming code that builds a customized data collection widget having a substantially unique appearance when presented in a browser. The customized data collection widget may be delivered to a composite repository. The customized data collection widget is uniquely identifiable from other widgets stored in the composite repository as Patel teaches in par.7). It would have been obvious to one ordinary skill in the art before effective filling date to modify Maes to include the one or more embedded widgets to the merchant device associated with the merchant account as taught and suggested by Patel in order to form a uniquely identifiable, customized data collection widget. The customized data collection widget may be delivered to the composite repository (Patel, abstract).
For claim 13, Maes, as modified by Patel, further teaches that retrieving, by the one or more processors of the embedded services platform, daily net-sales transaction data of the merchant account; determining, by the one or more processors of the embedded services platform, a selected provider amount and a merchant amount of based on the daily net-sales transaction data and a service agreement between a selected provider associated with the selected provider amount and a merchant associated with the merchant amount; and transmitting, by the one or more processors of the embedded services platform, the selected provider amount to a provider account and the merchant amount to the merchant account (Maes teaches that Each of the catalogs 301 may include various offerings. As used herein, an “offering” is an item in a catalog that corresponds to a distinct service or combination of services that are offered for sale, and may include an identification of the service or combination of services (e.g., name, identification number, etc.), description of characteristics of service(s), commercial terms (e.g., price, licensing conditions, etc.), aggregation policy information (e.g., whether aggregation of the item is permitted, etc.), resale policy information (e.g., whether resale of the item is permitted, conditions associated with resale, etc.), and other metadata as Maes teaches in par.31).
For claim 14, Maes, as modified by Patel, further teaches wherein the daily net-sales transaction data is automatically generated based on periodically updated transaction data (Maes teaches that the reseller instances may be created statically or dynamically. Statically creating a reseller instance means creating the reseller instance and then keeping it instantiated over an extended period of time as Maes teaches in par.16).
For claim 15, Maes, as modified by Patel, further teaches wherein the one or more merchant datasets include demographic data and transaction data associated with the merchant account (Maes teaches in par.31 and 44).
For claim 16, Maes, as modified by Patel, further teaches wherein the merchant account is associated with a partner account, and wherein the partner account is associated with a plurality of merchant accounts (Maes teaches in par.31 and 44).
For claim 17, Maes, as modified by Patel, fails to teach that generating, by the one or more processors of the embedded services platform, the one or more embedded widgets with partner styling data and one or more provider offers.
Patel further teaches that generating, by the one or more processors of the embedded services platform, the one or more embedded widgets with partner styling data and one or more provider offers (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget and fetch application information, decision offers for a customer, and process vehicle pricing information to service any customer's flow through the prequalification process as Patel teaches in par.17 and 26). It would have been obvious to one ordinary skill in the art before effective filling date to modify Maes to include widgets to the merchant device associated with the merchant account as taught and suggested by Patel in order to form a uniquely identifiable, customized data collection widget. The customized data collection widget may be delivered to the composite repository (Patel, abstract).
For claim 18, Maes, as modified by Patel, fails to teach that in response to generating the one or more embedded widgets, transmitting, by the one or more processors of the embedded services platform, a notification including one or more of an automated email, a text message, or an embedded offer via the one or more embedded widgets.
Patel further teaches generating the one or more embedded widgets, transmitting, by the one or more processors of the embedded services platform, a notification including one or more of an automated email, a text message, or an embedded offer via the one or more embedded widgets (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget and fetch application information, decision offers for a customer, and process vehicle pricing information to service any customer's flow through the prequalification process as Patel teaches in par.7, 17 and 26). It would have been obvious to one ordinary skill in the art before effective filling date to modify Maes to include widgets to the merchant device associated with the merchant account as taught and suggested by Patel in order to form a uniquely identifiable, customized data collection widget. The customized data collection widget may be delivered to the composite repository (Patel, abstract).
For claim 19, Maes teaches that A non-transitory computer-readable medium containing instructions (Maes teaches that marketplace platform instructions 1000 stored in a non-transitory machine readable medium as Maes teaches in par.68), the instructions comprising: receiving, by one or more processors of an embedded services platform, a request from a merchant device to integrate one or more embedded services from one or more providers (Maes teaches that onboarding of resellers to the aggregated marketplace under the control of the reseller management platform 400 is described, but it should be understood that other types of onboarding may be carried out in the systems 10, 11. In particular, each entity in the system 10, 11 may be “onboarded” to another entity in the system (e.g., service vendors 300 may be onboarded to the aggregated marketplace, down-stream resellers may be onboarded to an up-stream reseller's marketplace, etc.), and therefore each entity in the system 10, 11 may include instructions that may be configured to facilitate such other onboardings which may be in addition to the reseller management platform 400 or the sub-reseller management platforms as Maes teaches in par.28, 55, and 85); aggregating, by the one or more processors of the embedded services platform, one or more merchant datasets of a merchant account associated with the merchant device, wherein the one or more merchant datasets are stored in a database of the embedded services platform (Maes teaches that aggregate multiple catalogs of service vendors into an aggregated catalog of the first instance, and additional instances of the marketplace platform (reseller instances) to aggregate the aggregated catalog of the first instance (or the aggregated catalog of another reseller instance) into the aggregated catalog of the respective reseller instance into the aggregated catalog of the respective reseller instance as Maes teaches in abstract and par.10);
transmitting, by the one or more processors of the embedded services platform, the one or more merchant datasets to the one or more providers; receiving, by the one or more processors of the embedded services platform, offer data from the one or more providers (Maes teaches that the reseller marketplace platforms 200 may be, but do not necessarily have to be, hosted on infrastructure of the marketplace operator—that is, the infrastructures 260_1 through 260_M may be, but do not have to be, owned by the marketplace operator. For example, some or all of the reseller marketplace platforms 200 may be hosted on shared infrastructure in a cloud of the marketplace operator. As another example, some or all of the reseller marketplace platforms 200 may be hosted on infrastructure of their respective reseller—e.g., the reseller associated with reseller platform 200_1 owns the infrastructure 260_1, and so on. As another example, some or all of the reseller marketplace platforms 200 may be hosted on infrastructure of a third-party. For example, the marketplace operator may provide software corresponding to the reseller management platform 400 to the reseller (e.g., via download), who may then install/run the platform 400 on infrastructure of their choosing (their own, or a third-party's) as Maes teaches in par.25, 33 and 50);
Maes fails to teach that generating, by the one or more processors of the embedded services platform, one or more embedded widgets based on the offer data from the one or more providers and transmitting, by the one or more processors of the embedded services platform, the one or more embedded widgets to the merchant device associated with the merchant account, wherein the one or more embedded widgets are configured to display the offer data from the one or more providers.
Patel teaches, similar system, generating, by the one or more processors of the embedded services platform, one or more embedded widgets based on the offer data from the one or more providers (Patel teaches in abstract), transmitting, by the one or more processors of the embedded services platform, the one or more embedded widgets to the merchant device associated with the merchant account, wherein the one or more embedded widgets are configured to display the offer data from the one or more providers (Patel teaches that the customized enterprise supported widget may be configured specific to the dealer requests to provide a flow and aesthetic that is seamless for the customer. For example, dealer websites require support and an ability to construct and integrate widgets into the dealership's website that seamlessly guide customers through the web site and provide a satisfying user experience that includes the user's experience with the widget and fetch application information, decision offers for a customer, and process vehicle pricing information to service any customer's flow through the prequalification process as Patel teaches in par.17 and 26). It would have been obvious to one ordinary skill in the art before effective filling date to modify Maes to include the one or more embedded widgets to the merchant device associated with the merchant account as taught and suggested by Patel in order to form a uniquely identifiable, customized data collection widget. The customized data collection widget may be delivered to the composite repository (Patel, abstract).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYUB A MAYE whose telephone number is (571)270-5037. The examiner can normally be reached Monday-Friday 9AM-5PM.
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, SHEWAYE GELAGAY can be reached at 571-272-4219. 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.
/AYUB A MAYE/Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights