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 .
Claims 1-20 are currently pending for examination.
Claim Rejections - 35 USC § 103
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kaplinger (US 20160162447 A1) in view of Yu (US 10545640 B1) in further view of in further view of Jenks (US 10505875 B1) in further view of Kaushal (US 11888955 B1).
As per claim 1, Kaplinger discloses:
An apparatus for supporting business transactions comprising: one or more processors configured to execute instructions; and a memory storing the instructions, wherein execution of the instructions configures the one or more processors to: receive a business process notification from a business system, the business process notification including one or business notification details and business process details ("In another embodiment, a system includes a memory and one or more processors communicatively coupled to the memory. The one or more processors are configured to receive first event details from a provider. The first event details are related to a first event in a business process flow associated with a user and related to a user interaction.”, 0006 ; "The event details may provide the user with details about the event within the business process flow that resulted in the document 210 being issued.", 0019 ; Examiner Note: an event with event details equates to a notification with business process details)
Kaplinger discloses the above limitations of claim 1, but does not disclose generating an app card based on the business process notification.
However, Yu discloses:
generate an app card based on the one of the business notification details and the business process notification; ("The executable computer code may further include code for generating a visual representation of the e-book. The visual representation may be, for example, a content card that can be presented in conjunction with the website content (e.g., rendered by a browser application as part of a rendering of the website content). Alternatively, the executable computer code may transmit an indication of the identifier to a remote server which may, in turn, generate the content card (or retrieve a previously generated content card corresponding to the identifier) and transmit the content card to a host device storing the website source code which may, in turn, transmit the content card to the browser application. The browser application may be configured to display the content card in connection with the website content.", 0011 ; Examiner Note: a content card equates to an app card and an indication of the identifier corresponds to a business process notification. The remote server equates to a server, and the browser application equates to an application)
It would have been obvious to one of ordinary skill in the art to combine Kaplingers business process notification/event processing method with the content/app card generation of Yu in order to provide a content card generation system which uses the identifier, or business process notification details, to select whether certain content should be included based on performance metrics in order to cause desired user behavior (Yu, [0013])
Kaplinger in view of Yu may disclose the above limitations of claim 1, but does not disclose a messaging application provided by a messaging server.
However, Jenks discloses:
transmit the app card to a messenger server, wherein the app card is transmitted to a user terminal through the messenger server to be displayed using a messenger application of the user terminal ( "At operation 622, the device service 240 may make a call to the card service 244 to fetch the new/updated card. At operation 624, the device service 240 may send the new/updated card to the device agent 206.", 0149 ; "The selected content card 4802 may be rendered in a respective messaging application user interface that corresponds to the electronic messaging application and that is being displayed on each user device associated with each user profile participating in the conversation.”, 0284 ; Examiner Note: being a part of the user device, the device agent equates to a user terminal. As it provides a messaging application, the device service 240 equates to a messenger server, and since the card is fetched it is necessarily transmitted from card service 244 to device service 240. The card is then transmitted to the user terminal and displayed using a messaging/messenger application.)
It would have been obvious to one of ordinary skill in the art to combine Kaplingers business process notification/event processing method and the content/app card generation of Yu with the messaging server and application of Jenks in order to adapt the generation and displaying of cards to a messaging application which improves the personalization and contextual relevance of a card presented to a user (Jenks, [0063]).
Kaplinger in view of Yu in further view of Jenks discloses the above limitations of claim 1, but does not disclose that the generation of the app/content card is done through converting standard data into a standard format.
However, Kaushal discloses:
the generation of the app card is performed using standard data obtained by converting the one of the business notification details or the business process details included in the business process notification according to a preset standard format ("As discussed above, the card content 302 can include values for one or more attributes to be rendered and displayed in a card. In some examples, the card content 302 can be provided as JSON data, or other card data 108, that includes one or more AVPs indicating values for one or more attributes.", 0063 ; " The ARC engine 118 can provide action data 126 to the card engine 110, based on the action request 120 from the client application 104 and/or the action response 124 from the backend system. The card engine 110 can use the action data 126 to dynamically generate new card data 108 for a card to be displayed in response to the action request 120, and the ARC engine 118 can route the new card data to the client application 104.", 0030 ; “The ARC engine 118, in response to receiving an action response 124 from a backend system, can send action data 126 to the card engine 110. The action data 126 can be formatted as fact data 112 that the card engine 110 is configured to interpret and use.”, 0050 ; Examiner Note: the action data which is in a preset standard format which the card engine may use equates to business process details included in the business process notification)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Kaplinger in view of Yu in further view of Jenks with those of Kaushal in order to provide the system with the ability to generate card data in JSON format which may then be sent to a remote client application, thus reducing the memory footprint of the client application (Kaushal, [0018-0019]).
As per claim 2, Kaplinger in view of Yu in further view of Jenks in further view of Kaushal fully discloses the limitations of claim 1.
Furthermore, Kaushal discloses:
the app card includes, as a card-type interface, one of: a simple notification type app card, the simple notification type app card including only an area for displaying the business notification details ("A card can visually present text, images, and/or other content, as defined by corresponding card data 108. For example, the card 106 may display a current account balance due to be paid by the user, as shown in FIG. 1.", 0023 ; Examiner Note: displaying a current account balance equates to displaying business notification details)
a business processing type app card, business processing type app card including a first area for displaying the business process details and a second area for implementing a processing function for the business process details. ("The action request 120 may be sent by the client application 104 in association with a particular card. Some types of cards, such as card 106 shown in FIG. 1, can include a call-to-action (CTA) 128. The CTA 128 can be a user-selectable button, link, image, or other UI element. If the user selects the CTA 128 of a card, the client application 104 can send an action request 120 associated with that card.", 0035 ; Examiner Note: sending the action request 120 equates to implementing a processing function for the business process details (i.e., user input).)
As per claim 3, Kaplinger in view of Yu in further view of Jenks in further view of Kaushal fully discloses the limitations of claim 1.
Furthermore, Kaushal discloses:
the preset standard format is a JavaScript Object Notation (JSON) format, and wherein the standard data includes, in addition to the business notification details or the business process details, one or more of an environment, a content type, an app card ID, an ID of a transmission target messenger server, and an ID of a user receiving the app card. ("As discussed above, the card content 302 can include values for one or more attributes to be rendered and displayed in a card. In some examples, the card content 302 can be provided as JSON data, or other card data 108, that includes one or more AVPs indicating values for one or more attributes.", 0063 ; "The action request 120 may be addressed to the card engine 110 as if it were any other type of request for a card, but may include header data or another type of backend system identifier data that is associated with a particular backend system… The ARC engine 118 can provide action data 126 to the card engine 110, based on the action request 120 from the client application 104 and/or the action response 124 from the backend system. The card engine 110 can use the action data 126 to dynamically generate new card data 108 for a card to be displayed in response to the action request 120, and the ARC engine 118 can route the new card data to the client application 104.", 0030)
As per claim 4, Kaplinger in view of Yu in further view of Jenks in further view of Kaushal fully discloses the limitations of claim 2.
Furthermore, Kaushal discloses:
the processing function is implemented in a form of a button in the second area for implementing the processing function. ("Some types of cards, such as card 106 shown in FIG. 1, can include a call-to-action (CTA) 128. The CTA 128 can be a user-selectable button, link, image, or other UI element. If the user selects the CTA 128 of a card, the client application 104 can send an action request 120 associated with that card.", 0035 )
As per claim 5, Kaplinger in view of Yu in further view of Jenks in further view of Kaushal fully discloses the limitations of claim 4.
Furthermore, Kaushal discloses:
when the app card is the business processing type app card: receiving processing details of a user from the user terminal through the messenger server, the processing details of the user including a click event of the button implemented in the area for implementing the processing function; and transmitting the processing details of the user to the business system. ("The action request 120 may be sent by the client application 104 in association with a particular card. Some types of cards, such as card 106 shown in FIG. 1, can include a call-to-action (CTA) 128. The CTA 128 can be a user-selectable button, link, image, or other UI element. If the user selects the CTA 128 of a card, the client application 104 can send an action request 120 associated with that card.", 0035 ; " As discussed above, the ARC engine 118 can receive an action request 120 from the client application 104, and send an ARC action request 122 to a corresponding backend system, such as the payment system 130, the account management system 132, the retail system 134, or another backend system. ", 0045 ; Examiner Note: the action request equates to the processing details of the user)
As per claim 6, Kaplinger in view of Yu in further view of Jenks in further view of Kaushal fully discloses the limitations of claim 5.
Furthermore, Jenks discloses:
receiving a processing result from the business system; generating an app card based on the processing result; and transmitting the app card to the messenger server, wherein the app card is transmitted to the user terminal through the messenger server to be displayed using the messenger of the user terminal. ("The results of the natural language processing may be provided to a card producer 248 to facilitate generation of cards that include card content that is relevant to the subject matter of an electronic messaging conversation and/or that meets constraints or restrictions gleaned from the subject matter (as indicated by the processing results)", 0089 ; "At operation 622, the device service 240 may make a call to the card service 244 to fetch the new/updated card. At operation 624, the device service 240 may send the new/updated card to the device agent 206.", 0149 ; "The selected content card 4802 may be rendered in a respective messaging application user interface that corresponds to the electronic messaging application and that is being displayed on each user device associated with each user profile participating in the conversation.”, 0284; Examiner Note: being a part of the user device, the device agent equates to a user terminal, and the device service equates to a messenger server)
As per claim 7, it is a method claim with substantially the same limitations as claim 1, as such, it is rejected for substantially the same reasons.
As per claim 8, it is a method claim with substantially the same limitations as claim 2, as such, it is rejected for substantially the same reasons.
As per claim 9, it is a method claim with substantially the same limitations as claim 3, as such, it is rejected for substantially the same reasons.
As per claim 10, it is a method claim with substantially the same limitations as claim 4, as such, it is rejected for substantially the same reasons.
As per claim 11, it is a method claim with substantially the same limitations as claim 4, as such, it is rejected for substantially the same reasons.
As per claim 12, it is a method claim with substantially the same limitations as claim 6, as such, it is rejected for substantially the same reasons.
As per claim 13, it is a non-transitory computer readable storage medium (Kaplinger discloses: “A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.”, 0046) claim with substantially the same limitations as claim 6, as such, it is rejected for substantially the same reasons.
As per claim 14, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 1, as such, it is rejected for substantially the same reasons.
As per claim 15, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 5, as such, it is rejected for substantially the same reasons.
As per claim 16, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 5, as such, it is rejected for substantially the same reasons.
As per claim 17, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 2, as such, it is rejected for substantially the same reasons.
As per claim 18, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 5, as such, it is rejected for substantially the same reasons.
As per claim 19, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 6, as such, it is rejected for substantially the same reasons.
As per claim 20, it is a non-transitory computer readable storage medium claim with substantially the same limitations as claim 2, as such, it is rejected for substantially the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sirpal (US 20160231973 A1)- discloses method for operating the user interface of an application; including detecting a command for a user interface associated with a card element displayed.
Soo (US 20160216875 A1) – discloses a computer implemented GUI for monitoring and controlling and EMS in real time; includes a card carousel GUI control including a plurality of cards arranged in a sequence.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
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, April Blair can be reached at (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196